The many-faced god of operational excellence, DevOps and now 'site reliability engineering' Someone's been kicking up the "NoOps" ant pile again. There it was, sitting there finally rebuilt after the annual upturning, and The Lord of Cartography, Simon Wardley says: "I think you'll find that the new legacy is going to be DevOps." That said, it is winter, so the ants are moving a bit slower than usual. But we've only …
That's an easy one.
DevOps is a concept borrowed from sewage engineering and describes strategies and tactics for flushing crap through the continuous delivery pipeline as rapidly as possible, ensuring there is never a pause long enough for an accurate assessment of just how bad it smells (otherwise known as "Q.A.").
If you accidentally pump a particularly toxic batch of effluent, there is no need to evaluate how it happened ("No responsibility blame culture") or adopt preventative procedures (wetware Q.A testing), you simply accelerate the flow rate and hope to bury your previous noxious sludge under the next incoming batch ("Mean time to remediate" metrics).
Naturally, this integrates extremely well with [FR]Agile methodology which is itself concerned with shipping half finished, poorly specified and largely untested mockups "iterations" and worrying about details like security, compliance and reliability at some (hypothetical) future time (after the budget runs out).
When dealing with sewage, the priority is always to ensure that you hit your sprint flush timing targets. Everything else is secondary as any qualified scrum master sanitation supervisor will confirm.
How did I do?
Bloody Brillant!
If you're not too busy any chance you could swing by our office. There are a few wingnut morons (executives) that need the facts of life explained to them.
The new PMO (Primary Manglement Officer) implemented an "Agile" approach, to an already overdue and over budget project, has turned morning sprint sessions into half day workshops. Mandatory bi-weekly catch-up meetings for each "Workstream" (which is appropriate as they are as useful as pissin' into the wind).
I cannot recommend the Google SRE book (https://landing.google.com/sre/ - available to read online for free) enough. There'll be pieces you'll likely dismiss from your own routines/processes - however there's also bound to be a few insights in there that may give you some inspiration, fresh ideas.
[Note: I've no affiliation with Google!]
Unfortunately as you can define it any way you want, the ants define it as process, process, and more process. ITSM = ITs Silly Mate/ITIL = IT Is Ludicrous. Check this box, fill in this ten page form. Do that for every change. Have a three hours meeting about them. Have another three hour meeting about the first meeting. Finally release a two line change.
I do something that resembles work now.
I was at Google for a while, in SRE. While many would say that SREs were "super-powered sysadmins" or some such, that model is strictly limited. Ops guys have decades of expertise _in operations_. They cannot gain decades of expertise in software overnight, nor in a year or two. A year and a half ago, Google announced that they were reenvisioning SRE as a service organization. They would focus on providing libraries, platforms, and services. To that end, they suspended the hiring of additional operations guys into SRE, as the existing 50/50 mix was no longer appropriate.
The goal of keeping the interface narrow is critical to allowing real humans to operate with maximum efficiency. That change is the right way to go.
A successful SRE team is completely dependent on being in close communications with the "adults"--ops & security--so that they can know the problems that need to be addressed. But these are distinct classes of expertise.
The idea of Site Reliability Engineering, or "SRE", fits better in this view of what DevOps is. SRE-think is not focused on pulling developers into a unified team with sysadmins. Instead, the goal is to get sysadmins to start thinking like programmers, actually writing code and developing systems for production use.
The best coding I've ever done was some noodling around with batch files. I can pick apart a script and kinda figure out how it works, but writing something new from scratch. You absolutely DO NOT WANT me to do that. Not just No, but Hell No.
If anything, I make stuff that's fugly, brutal, and does exactly what it's supposed to do but has zero tolerances for bad input or something stupid happening.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
