Site Reliability Engineering

Ben Treynor Sloss's formulation: SRE is what happens when you ask a software engineer to design an operations function.

The consequence is that operational work is treated as something to be automated away rather than staffed up, and that the team responsible for reliability is expected to write software rather than to perform procedures.

Ask a software engineer to design an operations team, and you get something that automates itself out of work.

Devmark’s reading — not a quotation from the book

The book's most influential and most transferable idea. A service has an availability target below one hundred per cent, and the difference is a budget that may be spent on releases, experiments and risk.

The mechanism resolves the structural conflict between development, which wants to ship, and operations, which wants stability: while the budget has room, shipping proceeds; when it is exhausted, releases stop until reliability is restored. Nobody has to win an argument.

Their measurement vocabulary: indicators are what you measure, objectives are the targets you hold internally, agreements are what you promise externally with consequences.

Their insistence that objectives should be achievable and deliberately imperfect is the useful part — a hundred per cent is the wrong target because it forbids change, and setting an objective higher than users can perceive spends money on nothing.

Their definition of toil as work that is manual, repetitive, automatable, tactical and scales linearly with service growth — and their rule that it should be capped at roughly half an SRE's time.

The cap is what protects the engineering half of the role. Without it, the operational load expands to consume the team, and the automation that would reduce it never gets written.

Their practices: bounded on-call load, formal incident command with separated roles, structured handover, and blameless post-mortems as a standing requirement rather than a response to severity.

Their argument that a person on call should have a documented procedure and sufficient staffing to respond without heroics is a direct attack on the common practice of relying on individual dedication.

The design goal is that responding to an incident should not require heroism from the person on call.

Devmark’s reading — not a quotation from the book

A theme running through the book: complexity is the primary source of unreliability, and the most effective reliability work is frequently deletion rather than addition.

Their treatment of software simplicity as an operational concern rather than an aesthetic one is a useful reframing, and connects directly to Ousterhout's argument from a different direction.

This needs stating clearly. The practices were developed at a company with enormous scale, deep engineering resources, homogeneous infrastructure and the ability to staff a dedicated reliability function.

Smaller organisations attempting to adopt the whole apparatus usually produce ceremony. The concepts — error budgets, SLOs, toil caps — transfer well; the organisational structure frequently does not.

It is a multi-author collection rather than a coherent book, and the chapters vary substantially in depth, quality and assumed context.

It is best used as a reference: read the chapters relevant to a current problem rather than working through it. The early chapters on principles are the most broadly applicable and the later system-specific ones the least.

A companion workbook and a later volume on building secure and reliable systems extend the material, and the workbook is in some ways more useful for practitioners because it addresses implementation in less idealised environments.

Anyone finding this book too abstract should look at the workbook rather than concluding the ideas do not apply.

Error budgets, which are the most portable idea in the whole operations literature: they convert a recurring political argument into an agreed number that decides it automatically.

And the toil cap, which is the mechanism that prevents an operations function being consumed by the work it exists to eliminate.