What Is SRE? Start with the Error Budget

“SRE” is a hot word, and it’s very often misread as “slightly more advanced operations” or “a sysadmin who can code”. Having read Google’s book, my take is that its soul isn’t in the job title at all but in one shift in thinking + one mechanism — “100% reliability is the wrong target”, and the error budget, which turns the eternal war between “dev wants speed” and “ops wants stability” into a maths problem both sides work out together. Let’s get those two things straight first.

What SRE is: software engineers doing operations

Google’s original definition of SRE is neat: “what happens when you ask a software engineer to design an operations team.” In one line — treat operations as a software problem, rather than piling on people. Traditional operations’ answer to “more work” is usually “more people”, with headcount growing linearly with service scale; SRE’s answer is “write code to automate it away”, decoupling headcount from scale. That starting point sets the flavour of every practice that follows: anything automatable shouldn’t be done by hand, and repetitive manual work is treated as “something to be eliminated” rather than “chores you resign yourself to”.

First, bust a myth: 100% reliability is the wrong target

Most people’s intuition is that reliability is obviously better the higher it goes, ideally 100%. But SRE’s first counter-intuitive claim is: chasing 100% is not just wrong, it’s harmful.

Why is 100% wrong? Three reasons: cost — each extra “nine” beyond 99.9% multiplies the investment several times over; marginal benefit — it approaches zero; users can’t feel it — their home network, phone and Wi-Fi were never that stable, so pulling your backend from 99.9% to 99.999% makes no perceptible difference at their end. So the right question isn’t “how do we avoid errors” but “how reliable is reliable enough” — set a target (the SLO, the next post’s subject), and the allowance left over for errors is the error budget.

The error budget: turning the dev vs ops war into maths

The real power of the error budget is that it dissolves a war almost every team is fighting: dev wants to go fast and ship features; ops wants stability and doesn’t want things touched. The two goals are inherently opposed, and traditionally the winner was decided by argument, seniority, or politics. The error budget provides an objective referee:

The mechanism is simple: error budget remaining → green light, ship boldly, launch risky features, since breakage is still within budget; budget spent → red light, all new feature releases freeze and the whole team turns to restoring stability. The clever part is that it aligns both sides’ interests — ops no longer blocks every change mindlessly (with “budget left” there’s no reason to block), and dev no longer forces things through mindlessly (spend it all and everyone gets frozen together). Everyone starts thinking about “spending our limited budget on the features that are most worth it”.

Reflections

The strongest thing about the error budget isn’t technical; it’s turning “arguing” into “reading a number”

I’ve watched the same play in different teams: whether to ship a somewhat risky feature, dev and ops each dig in, and in the end whoever is loudest, most senior, or closest to the boss wins. That way of deciding is exhausting and unfair. What made me slap the table about the error budget’s design is that it turns a human conflict into an objective, quantified question — “how much budget do we have left this month?” The two sides stop being enemies and become joint managers of one budget. It’s the most beautiful example I’ve seen of “using a mechanism to defuse a human conflict”, and it reminds me that many arguments inside a team come from lacking an agreed ruler, not from lacking reason.

”100% isn’t the target” is nearly a general rule of engineering judgement

“Don’t chase perfect, chase good enough” applies far beyond reliability. Over-pursuing any metric — 100% coverage, zero technical debt, ultimate performance — is at heart over-engineering, pouring resources where the marginal benefit approaches zero. It’s the same discipline as confirm the pain first, then bring the heavy weapons that I keep coming back to: first ask “how good is good enough”, then decide how much to invest. Most systems don’t need five nines at all; the effort saved by not chasing those two extra nines, spent on things users actually feel, pays off far more. SRE institutionalised this judgement with the error budget, and I treat it as the default question for any engineering trade-off.

SRE’s core: operations can, and should, be engineered

The underlying belief in this book that moved me most: operations isn’t “chores you resign yourself to”; it’s a pile of “problems that haven’t been engineered yet”. Once you see repetitive manual work as bugs to be eliminated rather than fate, your behaviour changes — you stop being chased around by on-call, worn out, and start proactively asking “how do we automate this away so nobody has to get up in the middle of the night again”. That mindset shift matters more than any tool or process; it decides whether you’re the slave of operations or its master. Eliminating toil, monitoring, automation — everything that follows is this belief unfolding — and its starting point is this post’s error budget: quantify “how stable is enough” first, and only then can you talk about spending effort intelligently where it cuts.