This is an anonymous post sent in by a member who does not want their name disclosed. Please be thoughtful with your responses, as these are usuall...
For further actions, you may consider blocking this person and/or reporting abuse
I know devs that think of themselves as full-full-stack, handle their CI, infra, containers, etc and think of devops as some obstacle to overcome.
I know devops people that think of themselves as a support role and think of devs as ranting children that do not know what they are doing with their infra.
My team does everything up to a paas service. All our dev/ops, monitoring etc.
The way we work it is that our team has some local experts on various topics like APM. Our company has a team of experts that are a resource to product teams.
Devs just have to learn new stuff, and a couple of them take the initiative to read a book or two etc to guide team decisions. They are the mini architects who also understand the product needs. Our team has individuals who are the go to for database arch, APM, ci/cd, etc. (not the same person! And often two people l oval experts per tech), but we're all responsible for deciding on and implementing solutions. This means we all have a decent knowledge of the subject and we all get to justify learning one or two big skill sets (8 devs, so some of us are the go to for multiple things).
The external group of experts handles things like supporting and educating teams by holding training and being available for questions. That also handle selecting tech when it makes sense to license a product for use across multiple teams. If that is the case they may also handle ops and infra for the shared tooling
Hi! I was leading a team that sounds like a similar role as you describe! Not quite ops, not quite SRE, but solving company problems and helping teams ship.
My team took over a traditional ops team, we were very much driving towards having application/product teams fully own their services in production. We built tools to help teams do this on their own (to varying degrees of success as the company grows). Nowadays, our problems are more focused on Enterprisey things like compliance and infra ops. We are an escalation point after product teams, and also offer support during all-hands-on-deck production incidents.
However, there are teams that have infrastructure needs and concerns and they need help from us, so we kinda "consult" with the teams and provide help to get them moving along.
You're Ops. But the industry is bad at naming things and not every definition fits every use case. So if you don't want to call yourself Ops or SRE you don't have to, but you easily could and no would be opposed to it.
Not dev, not ops... Q: Are we not DevOps? A: We are Devo. ;-)
The job you're describing is called "Application Manager" where I work.
Oh man could I rant about 99% of organisations doing 'devops', or the lack thereof.
As for the type of team you describe; in my mind it sounds like Application Support or Systems Integration with a 25% time towards alerting and monitoring.
Hope that helps out.
11 years ago I lead a "production support team". We handled dead letters, performance upgrades, bug fixes for existing code on a home built esb. Somewhat similar?