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 usually tough posts to write. Email sloan@dev.to if you'd like to leave an anonymous comment.
Some background for reference:
I'm a long time "ops" guy, who codes web apps for fun. I spent a large part of my career as manager of an ops team that managed apps, but not hosts. We partnered with infra to set up servers to our specs, mount storage, and open ports. We where given credentials to provision the machine. We handled the day to day support operations for the applications. I was lucky enough to be a part of a grass roots movement to implement DevOps before it became a buzzword.
From there I did some consulting and bounced around for a few years. Then I was offered the opportunity to manage a Site Reliability Engineering team. This was a new concept for me, but after doing some research, It wasn't anything new for me.
A couple years in there is one blazing truth. We are not a SRE team. I work for a large company with a micro service architecture, around 300 services in total. Ops teams are not integrated with development teams. I'm now trying to re-tool my team to better fit the company needs.
My proposal is our team of eight works with product owners to understand the portfolio of applications under their domain. We would help to make sure things like graceful degradation, and observability are being considered along with functional features. We would help build monitors and alerts, and work tightly with our 24/7 noc. We would build and manage alerting and incident management tools for our noc, be level 2 support, and severe level incident managers. We would also be responsible for unplanned production changes, lake feature flags, cache flushes, and adhoc batching jobs.
We are not positioned to take part in things like infrastructure architecture, or server management. We are more dev facing that infra ops. There is a need there, and a great opportunity. I see a lot of similarities on the team I used to manage in the first paragraph up there. Is anyone aware of a team structure, or concept similar to this? I'm looking for examples or resources to help set direction.
TL;DR Are there any devs who are aware of a team that "manages" and supports their apps in production, but isn't a traditional operations team?
Top comments (7)
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?