[falcolas]

Perhaps even more important is the ability to give developers, and managers, visibility into things which were only visible to System Admins in the past.

Why is this server running slowly? The graph shows a spike in disk IO usage. What's the process? The database. What changed at the spike? Adam's production push. Why? The explain plan for the new front page query shows a table scan against a 5m row table.

And done. No sysadmin needed, Adam can now identify and fix his own problems. The management can now watch the graphs of application response time go back down in response to Adam's fix, and everyone's happy.

This isn't theory, it's the example I saw demonstrated at a database convention a few weeks ago. Graphite, logship, nagios, and some development which pulls all of this data together can create some virtually magical systems. Casting devops as a side project for "real" developers limits what could be done to facilitate the creation of real agile development environments.

[toomuchtodo]

> And done. No sysadmin needed, Adam can now identify and fix his own problems.

> Graphite, logship, nagios, and some development which pulls all of this data together can create some virtually magical systems.

Who do you think pulls all that data together? DevOps/Sysadmins.

I build and wrap together the tools that make your job easier. And I take pride in that. I'm also on call so you don't have to be.

Relevant XKCD: https://xkcd.com/705/

[falcolas]

> Who do you think pulls all that data together? DevOps/Sysadmins.

That's what I was trying to point out. A devops engineer is involved in the creation of these systems, however she does not need to be involved at 3am when the problem is discovered, since Adam can identify his own problem and can verify his fix did what was necessary.

[toomuchtodo]

> That's what I was trying to point out.

Ouch, my mistake. In that case, I misread your post, and I apologize.