As DevOps has become a buzzword, we now see organizations hiring "a DevOps Team". Worse, Operations/Infrastructure/SRE people start to refer to themselves as the DevOps team. Even worse, those of us who are DevOps practitioners compound the problem by not correcting it and going along with the nomenclature in our own orgs.
If you have a DevOps team, what you have really done is given your Operations team some Development to do. You've made their problems harder. Rather than just letting Operations get on with the automation of their tasks, you've now made it their problem to provide tools to engineering in isolation. Now, yes, there are some organizations that might actually refer to the culture change team as the DevOps team, but it seems rare.
DevOps is not the same through all organization. There's been about 2 decades of figuring out how to handle software engineering and where we have got to is an inflection point of transformation. This transformation to a collaborative culture is clearly DevOps at work. DevOps takes time - where we are now is, to borrow Adam Jacob's "Chef Style Devops Kung-fu" (ChefConf 2015) and (https://github.com/chef/devops-kungfu) analogy, a point of excellence through long practice of our skills.
So why do I say so vehemently that a Devops Team is a Daft Idea? The fundamental building blocks of DevOps are these: Collaboration, Communication, Automation. Which of these 3 can you do effectively if you have a specific team? That's right - Automation. Communication through effectively a half-duplex pipe in and out of a team is never as effective as an open forum. Collaboration cannot be achieved if you isolate a team.
Returning to the DevOps Kung Fu model, DevOps in your organization is recognizable by a reliance on those 3 basics. It includes a broad experience that each practitioner can bring to the discussion. Engineers, Project Managers, and your customers see parts of the problem and can bring new light to bear on your situation.
Even in more traditional settings, the DevOps cycle looks like this:
None of this is isolation - this is Engineering, QA, Infrastructure/Operations, potentially a NOC, Project & Product Management ...
The pitfalls to creating a DevOps team become hugely apparent. Let's say that you subscribe to the fiction that you are an agile organization - at best, you end up in what Jez Humble calls "Water-scrum-fall" (21st Century Software Delivery with Jez Humble). Let's say that you plan effectively, and your DevOps team is responsible for the Release, Deploy, Operate and Monitor portion of your cycle (Fairly typical) - the people in that group will end up suffering hugely because:
- They are generally a smaller engineering team, but look at what they are shouldering - fully 50% of the cycle
- Generally speaking they are dependent on the engineering and qa teams to tell them what they are supporting, and without strong communication and collaborative practices, this becomes risky and the feedback loops are long
- Support for the released product still falls on the "DevOps Team" in that they know what they are monitoring, are responsible for it and therefore for fixing it - if not, then the loop to get a fix out the door is unweildy
- You now have a bunch of SRE/Infrastructure/Ops types who are now burned out because they are supporting code that they didn't write, they become the thin end of the wedge for outages, and they are almost always seen as a blocker because they have to fit Release and Deploy in around their project work - you know, the stuff that makes them DevOps not just Ops.... Suffice to say, building a DevOps team in this manner is a sure fire way to create burnout, increase risk and reduce perceived reliability.
Want to do it the "right" way? look at teams like Spotify ... Have rotating embeded SRE/Operations and QA people within your engineering teams ... create a culture whereby talking with one another is encouraged ... Create a culture where monitoring is part and parcel of software engineering ... if outages happen, it is on the engineers to fix and they should be the first to respond ... planning involves all parties involved (including QA and Operations).
But, and it is a big but.... Do what is right for your organization. Practice DevOps continuously, and don't get discouraged just because you are on a "devops team" - that gives you the opportunity to be a thought leader in your org.