DevOps as a team or a responsibility?
John E. Vincent writes in “DevOps – the Title Match”
I worked at a company several years ago. We created a dedicated devops team. The rationale was solid – the company had a monolithic idea of roles and titles. We also had a large group on both sides that were only interested in doing their little bit and going home. By creating this title/team, it was easier at a company level to justify them working on non-standard projects.
So a “devops” team was created. This was a small team of what essentially boiled down to “super sysadmins”. We wrote puppet manifests, worked with the developers to automate build processes…shit like that.
What ended up happening was that the devops team was seen as elitist by the operations team, nosy and invasive by the developers and everyone just passed the blame on to them – “Devops did that. Not us”
In my department we setup a DevOps responsibility rather than a team or specific job title. The responsibility lies with a subset of the sysadmins and developers. It doesn’t take them out of their main teams and it’s not their only responsibility. They do their main day to day work respectively with the rest of the sysadmins and developers but additionally have a role being on call, exposing monitoring capabilities in code as well as hooking it up to tools, setting up automation, doing deployments, etc. Lessons learned are shared with the rest of their teams and the members with this on call responsibility are not coincidentally also some of the most well respected troubleshooters and thought leaders in their groups leading the whole team to improve.
User stories for themselves or other dev/sysadmin team members are created in JIRA under a DevOps epic along with a DevOps label. Though it’s not a perfect world where these stories are always done right away in the next sprint or on top of Kanban TODO list, the team members do have incentive to push for the improvements generally in the areas of monitoring or some reliability improvement.
As with many places, there isn’t a special budget to just spin up a new DevOps team, but by building the roles from within existing teams we captured the experience of the teams. Augmented occasionally with some help from automation experts from other parts of the organization, this has worked well. It should go without saying that members with DevOps responsibility should have capacity budgeted in their sprint to deal with production issues and continuous reliability improvements, but sadly common sense is not necessarily common.
