Tech
DevOps explained to the people who sign, not the ones who code
DevOps is not a person or a product: it is how software reaches production. It is judged by four numbers — how often you release, how long from idea to production, how many releases cause failures, how long it takes to recover. Releasing often and small reduces risk rather than increasing it.
"DevOps" is one of those words that appear in quotes with no explanation, and that answer the question "what are we actually buying?" with a list of tool names. Let's try saying it without jargon.
DevOps is not a role to hire and not a product to buy. It is how a change to software travels from the machine of whoever wrote it into the hands of whoever uses it: how long it takes, how often it goes wrong, and what happens when it does.
Why it should matter to you
Because it is the difference between two companies running the same software and living two different lives.
In the first, a fix requested on Monday reaches customers three weeks later, releases happen on Friday evening because "if it breaks we have the weekend", and every update is a sleepless night. In the second, the same fix is in production on Wednesday morning, the release happens at eleven on Tuesday, and if something goes wrong they roll back in five minutes.
The difference is not how good the programmers are. It is everything around the programming.
The four numbers that tell you how you are doing
There is broad, well-established industry research on this, and the good news is that it reduces to four questions you can ask your supplier without knowing a line of code.
- How often do you release? Once a quarter or several times a week? Teams that release often release little at a time, and little at a time means little to check when something doesn't add up.
- How long from "let's do it" to "it's live"? It measures your speed of reaction to the market, not your speed of typing.
- How many releases cause a failure? An honest number sits below fifteen per cent. If nobody knows it, that is already an answer.
- How long does it take to get back up? The most important number of all: what matters is not how often it falls, but how long it stays down.
Notice what is not on this list: how many servers, which platform, which tools. Those are means. These four are the ends.
Releasing often isn't reckless: it is the only way to release small. And when it's small and something breaks, you know immediately what.The reversal that surprises decision makers
The paradox: releasing often lowers risk
Instinct says the opposite: if every release is dangerous, do fewer. But it is exactly the other way round, and the reason is simple.
A quarterly release contains three months of changes. When something breaks — and it will — you have to find the cause among hundreds of changes made by different people, some of whom are on holiday. A weekly release contains one week of work: if it breaks, there is only one suspect.
On top of that, rare releases become events: tension builds, one more change gets added "while we're at it", and the thing meant to reduce risk multiplies it.
What sits behind it, concretely
When the right work sits behind, those four numbers improve on their own. Here is what makes it possible, in plain language.
- Environments that rebuild identically. The server is born from a written, versioned file, not from a terminal session that went well. If it disappears tonight, tomorrow an identical one exists.
- Automated checks before release. A battery of tests running on every change, blocking the road when something doesn't add up. It is the tireless colleague who always re-checks the same things.
- A way back. Designed beforehand, not during the incident. Knowing you can roll back in five minutes changes how decisions get made.
- Measurements and alerts. Noticing something is wrong before a customer tells you. An alarm that always rings, though, is an alarm switched off.
- Backups actually restored. A backup never restored is not a backup: it is a file you trust.
The questions to ask a supplier
Five questions, and you learn a lot from the faces before you learn it from the answers.
- If the server disappears tonight, how long to rebuild it? And have you ever tried?
- How do you roll back a bad release? Who decides, and in how long?
- When was the last backup restored, and who checked the data was complete?
- Who tells you the system is slow — you, or our customers?
- If the person who built this part isn't here tomorrow, who else can work on it?
None of them requires technical knowledge to ask, and all of them require real practice to answer.
How much you actually need
A company with one business system and a website doesn't need the same machinery as a platform with thousands of users. But the foundations are the same, and at any scale they are cheap: a rebuildable environment, automated checks, a possible rollback, verified backups, alerts on the things that matter.
The rest — complex orchestration, environments that multiply themselves — comes when the numbers justify it. Buying that complexity early is the most common way to spend a lot and make the four metrics worse instead of better.
If you don't know your four numbers, you don't need a project to find out: the questions above, asked to whoever keeps your systems running, are enough. The answers already say where to act.