It's a small team. I'm not allowed to do Devops things because 'me being a developer is worth more'. I think that's a terrible idea. I can only become a better developer by working close to the deployed product.
Having less SREs and shared devops knowledge can only hurt things. The team rationale is computers fail all the time. We should have SRE scripts that recover things. I hate that idea. I want to know why servers failed. My belief is if you don't understand the root cause it'll just keep happening.
Is this a naieve belief? Am I in the wrong here?
See things from your manager's perspective. They have work they need accomplished. They have a small team - maybe not big enough for the work they need to accomplish - and of that work, some will directly create profit for the company and some will cut/ control costs, and still other work will be "stuff".
Your manager is telling you that they need your skills in a particular area, like due to staff shortages, skill shortages, or more specifically the value of the work. Take this as a sign that your skills set and labor are valued, just not perhaps in the way you prefer.
If developing skills in other areas (IE: SRE, devops, etc) is important to you, consider ongoing conversations where you make it clear you want to build this skills, and partner with your manager to do so. If that just isn't going to happen in this team, then consider your career path elsewhere if this is really important to you.
Learn to work with your devops team to get the information you need. Developers should not need direct production access.
This is a potentially very risky approach. I was given the task of having my org stand up a large, complicated system. My engineering team built a system that was failing 2% here, 10% there, 5% somewhere, etc. They built recovery and retry mechanisms for every failure scenario. We ended up with a combined failure rate of 40% that was masking the failures but basically doubled our execution time for the service. I locked down all new development and directed all of our effort toward driving accumulated failures below 5%. They completely disagreed with me (because they'd gotten used to the life of being firefighters). Once we got to below 5% their opinion changed completely. They're very proud of how they were able to drive down the error rate.
Watch out for accumulated error (or even worse--compounded error)!
On the other hand, you can expect that any network based service will fail and need to retry. It's especially important to make software that relies on cloud-based services resilient in this regard.
Some possibilities for doing DevOps things again are:
* request a "glass break" account for emergencies. You'll need to meet with someone senior to get that signed off on, and then someone needs to write some automation for that.
* Ask to move to a DevOps role instead of back end web dev.
Some possibilities for better visibility, which is a better goal if you ask me:
* set up a status meeting that's once every week or two weeks or month with the DevOps/SRE team or person(s)
* ask to be part of the monitoring setup, or set up your own monitoring that you can then share.
If you being a dev is worth more, the team either has the ops under control, or you need to demonstrate why you being closer to the ops provides business value.
In any case you definitely don’t want to move from a high status position to a low status one in your organization. Switch orgs to one that treats what you want to do as high status.
For what it’s worth, I agree that your manager is wrong but there are lots of ways to skin a cat and a dev/op split is a very traditional route that lots of teams are successful at.
It sounds like you are not only worried about you being involved, but also about the current state of your team's DevOps / SRE practices. Hopefully you can still push for higher standards in that space even if you are not directly involved day to day.
> It's a small team. I'm not allowed to do Devops things because 'me being a developer is worth more'. I think that's a terrible idea. I can only become a better developer by working close to the deployed product.
By the same token, it is not good for you to be the expert on everything. With a small team it's easy for one person to become the go-to SME for everything. This is just as dangerous as having faulty DevOps and SRE practices. The company has little ability to prevent you from leaving, getting sick, forgetting things that only you touched, etc.
This is just an extension of Taylorism -- early assembly-line thinking -- where each human becomes like a very simple machine -- and therefore stupid, dull-minded, unquestioning.
That said, I think you are conflating several different issues here.
But just sticking to your first question in the title -- no, you do not need to be worried.
Unless you decide you want to be more than a coder/developer. In that case, start looking for a new job.
so a salary increase is justified, then, eh?
>Writing anisble scripts
Skunkworks an effort on this in your downtime and in doing so prove your capabilities, would be my suggestion.
>maintaining production instances.
If you're deploying to AWS or another cloud provider it's more than rational that it's locked down to a certain set of people (devops/SRE) made responsible for that infrastructure.
>I want to know why servers failed.
Ask for read access to your logging infrastructure?