The SRE Book, Ten Years On — Part 1: Hope Is Not a Strategy

“Hope is not a strategy.” It’s one of the most quoted lines in software operations, usually cited by people who’ve never followed the argument behind it — which is a shame, because it’s an economic argument dressed as an engineering one, and it holds up better than almost anything else written about operations in the last decade.

This series is about site reliability engineering, ten years into the industry actually practicing it. The Observability Engineering series on this blog covered how we see systems; the Practical OpenTelemetry series covered how we instrument them. This one covers the question both skipped: how do we actually run them?

Every post follows the same shape: here’s the idea, here’s what’s changed about it by 2026, and why. Some of it holds up perfectly. Some doesn’t. All of it deserves the audit — and Google’s original Site Reliability Engineering book (free at sre.google) is the place to go for the full, unabridged case.

This part makes one argument in three moves.

The Sysadmin Model Was an Incentive Failure

The diagnosis of pre-SRE operations is blunt. The traditional model: sysadmins assemble components into a service, then respond to events as they happen. As traffic grows, events grow, so the sysadmin team grows. Developers and sysadmins split into two teams with different vocabularies, different risk tolerances, and different incentives.

The direct cost is visible: team size scales linearly with load. The indirect cost is the real killer: the two teams end up in trench warfare.

Ops builds launch gates — a checklist of every problem that has ever caused an outage, an arbitrarily long list where not every item pulls its weight. Dev responds with “flag flips,” “incremental updates,” and “cherrypicks” to dodge the gates, sharding the product so fewer features are subject to review at all.

Both sides are rational. Both sides are correct. And the organisation loses. This is a pathology, not a disagreement: different vocabularies, different risk assumptions, and eventually a breakdown of trust between people who are, on paper, on the same team.

There’s a number for why the fight matters: roughly 70% of outages are caused by a change to a live system — a new configuration, a new feature, a new kind of user traffic. So the ops team’s instinct to gate every change isn’t paranoia; it’s pattern-matching on the actual cause of most incidents.

The dev team’s instinct to route around the gate isn’t recklessness either — it’s the only way to ship anything on a human timescale once the checklist has ballooned. Neither side is wrong. The structure is wrong.

Why this matters in 2026: the conflict wasn’t a personality clash. It was a structural consequence of splitting the people who ship changes from the people who carry the pager. Any model that recreates that split — whatever you name it — recreates the trench warfare.

SRE: Ask a Software Engineer to Design an Ops Team

My favourite definition of SRE is still the simplest one: “SRE is what happens when you ask a software engineer to design an operations team.” Ben Treynor Sloss, who coined the term, was a software engineer handed a “Production Team” of seven in 2003 and told to run it. He ran it the way he’d want to be managed as an engineer.

Three consequences follow, and all three are load-bearing:

1. Hiring: 50–60% of SREs are hired as standard software engineers; the rest are near-engineers with rare ops skills — at Google, UNIX internals and networking. Boredom is treated as a design smell: someone who gets bored doing tasks by hand is exactly the person who will automate them.
2. The 50% cap: SREs may spend at most 50% of their time on ops work — tickets, on-call, manual tasks. The other 50% must go to engineering. The cap is enforced by measuring where time goes and redirecting overflow back to the dev teams. The stated goal: systems that are automatic, not just automated.
3. Sublinear scaling: because engineers automate the work instead of staffing it, the number of SREs needed to run a service scales sublinearly with the service’s size. This is the entire economic justification for the model. An ops-oriented team scales linearly; an SRE team breaks the line.

DevOps or SRE?

The clearest answer, from back when DevOps was eight years old and still fuzzy: DevOps is the generalisation, SRE is a specific implementation. Same core principles — engineering practices applied to operations, automation over human effort — but SRE adds idiosyncratic extensions. The most important extension is that SRE has reliability as its explicit primary focus and a named owner for the tradeoff between stability and change: the error budget, which Part 2 covers.

SRE’s other tenets are worth naming up front, because the rest of this series is really just one responsibility each, worked all the way down to the mechanism:

• Availability — is the service usable right now?
• Latency — how long does it take to respond?
• Performance — how efficiently does it use what it’s given?
• Efficiency — how much does running it actually cost?
• Change management — how does it evolve without breaking?
• Monitoring — how do you know any of the above, without waiting for a user to tell you?
• Emergency response — what happens the moment one of them fails?
• Capacity planning — will it still hold up next quarter?

Beyond Google: Everyone Built an SRE, They Just Didn’t Call It That

This was predictable, if nobody quite said so at the time. A decade on, every large tech company independently arrived at some version of “software engineers running production,” even where the org chart never uses the word SRE:

• Amazon never adopted the SRE title at scale, but the Well-Architected Framework’s Operational Readiness Review (ORR) is the same idea wearing an AWS badge: a service can’t take production traffic until it passes a checklist proving it’s actually ready to run, and the checklist itself is fed by the Correction of Error (COE) process — Amazon’s answer to the postmortem, which Part 7 covers in detail. The difference from the pre-SRE “trench warfare” model is that the gate’s contents are a living document updated by real incidents, not an arbitrarily long list nobody prunes.
• Meta calls the role production engineering — engineers who own a service’s full lifecycle, from capacity planning through incident response, explicitly measured against SLOs and reliability metrics. Meta’s own 2026 job postings for the role now describe driving AI-augmented engineering workflows into that same ownership model. Same 50%-engineering instinct as Google’s SRE, arrived at independently.
• Microsoft built IcM (Incident Management) as the connective tissue: a four-phase lifecycle — create, acknowledge, mitigate, resolve — that any team, SRE-titled or not, plugs into. It’s less a philosophy than Google’s book and more a piece of infrastructure, which is itself a very Microsoft answer to the same underlying problem.

Ten Years On: The Production Environment

Google’s production environment is worth walking through concretely — Borg, Colossus, Bigtable, Spanner, Chubby, Stubby, the GSLB load balancer and the GFE frontend — and a hypothetical Shakespeare search service makes it real. Capacity planning here doesn’t wave its hands; it does the arithmetic.

Load testing says a backend task handles 100 QPS; the expected peak is 3,470 QPS globally, so the service needs at least 35 tasks — except updates and failures each cost a task, so the real number is 37, or N+2. Traffic isn’t even across the globe either, so the 37 tasks get spread across regions, with a deliberate exception: South America gets N+1 instead of N+2, accepting a small latency risk during an outage in exchange for a real 20% hardware saving.

That single example is the whole discipline’s philosophy in miniature.

In 2016 this read like a tour of an alien civilisation. In 2026 it reads like a prophecy that already came true:

The monorepo lives on as a debate, not a default. A single shared repository — every engineer able to fix any bug anywhere, subject to review — was radical in 2016 and is now one legitimate answer among several (Google, Meta stayed monorepo; most of the industry didn’t), which says more about Google’s specific tooling investment than about a universal truth.

The mental model is what survived: a request’s life is a chain of hops, and every hop is a place where reliability can be silently spent. The names change; the diagram doesn’t.

And then there’s the discourse nobody saw coming. Through the 2020s, “SRE is dead” became a genre of blog post, usually in the service of platform engineering.

It’s worth being precise about this, because the rebuttal was already there a decade early: Google’s own engagement model evolved from per-team reviews toward shared frameworks and SRE platforms — the exact thing the industry later renamed platform engineering. Classic SRE’s “death” was an explicit strategy a decade before the thinkpieces, not a surprise.

The 50% cap is what distinguishes SRE from both the old ops world and the new platform teams: not “run it,” not “centralise the tooling,” but “keep enough engineering time to make the service run itself.”

Google didn’t stop at one book. The Site Reliability Workbook (2018) followed — a hands-on companion that, notably, isn’t just more Google war stories: it includes case studies from Google Cloud customers (Evernote, The Home Depot, The New York Times) putting SRE practices to work in organisations that are not Google, which is the honest answer to the question every reader of the original book asked (“does any of this apply outside a company with Google’s scale?”).

Then came Building Secure and Reliable Systems (2020), whose one-sentence thesis is that security and reliability are the same discipline wearing different hats: both are about engineering for the failure modes you haven’t seen yet, and an organisation that treats them as separate teams with separate incentives will eventually rediscover the exact dev/ops trench warfare described above, with “security” standing in for “ops.” Part 12 picks this thread back up when it covers what happened to SRE culture a decade on.

For the layer not covered here — how you actually see what’s happening inside that chain of hops — the Observability Engineering series on this blog picks up exactly where the production-environment story leaves off.

Next: Part 2: 100% Is the Wrong Target — Nines, SLOs, and Error Budgets, where the single most influential idea in the whole discipline resolves the dev/ops conflict.

References

• Google SRE Book — Introduction and The Production Environment at Google
• Site Reliability Engineering (O’Reilly, 2016) — Beyer, Jones, Petoff, Murphy (eds.)
• Kubernetes (Borg’s descendant)
• The Site Reliability Workbook — with Google Cloud customer case studies (Evernote, Home Depot, NYT)
• Building Secure and Reliable Systems — Google’s 2020 companion, security and reliability as one discipline
• AWS Well-Architected Framework — Operational Readiness Reviews
• Microsoft Azure Well-Architected Framework — Incident Management (IcM)