Someone has to run a service once it is built. The classic answer is a sysadmin team that deploys, operates and firefights, separate from the developers who write the code. The chapter opens by explaining why Google abandoned that model, then defines Site Reliability Engineering and lists the tenets every SRE team at Google shares.

The core move is simple to state and hard to do: hire software engineers to do the operations work, and give them time and incentives to automate themselves out of it. Everything else in the book follows from that choice.

In one minute

• The sysadmin model has two hidden costs. Direct: the ops team grows linearly with traffic. Indirect: dev and ops have different vocabularies, skills and incentives, so they fight about launches.
• SRE is what happens when you ask a software engineer to design an operations team. SREs are hired as engineers, either with full SWE skills or with 85 to 99 percent of them plus systems expertise (networking, Unix internals).
• The 50 percent cap: an SRE team spends at most half its time on operations. The rest is engineering that makes the service run itself. Overflow work is handed back to the developers.
• Tenets of SRE: ensure durable focus on engineering, pursue maximum change velocity without violating the SLO, monitoring, emergency response, change management, demand forecasting and capacity planning, provisioning, and efficiency and performance.
• 100 percent reliability is the wrong target. Users cannot tell a 99.999 percent service from a perfect one, because their phone and ISP are worse than that. Pick a target, and spend the remainder, the error budget, on launching features.
• Monitoring output comes in three valid kinds: alerts (a human must act now), tickets (a human must act soon) and logging (nobody looks unless investigating). Humans should never be reading a dashboard to decide if something is wrong.
• Reliability is a function of MTTF and MTTR. The best thing you can do for MTTR is a playbook: a rehearsed response is roughly three times faster than improvising.
• Roughly 70 percent of outages are caused by changes to a live system. Change management means progressive rollouts, fast and accurate problem detection, and safe rollback.

Why the sysadmin model fails

Running a service with a separate ops team is attractive because the job market and tooling are built for it. But the team scales with load, not with the size of the engineering problem, and the two groups end up optimising for opposite things. Developers want to ship. Operators are judged on uptime, so they want nothing to change. The conflict surfaces as launch reviews, change-freeze windows and arguments over whether a change is "big" enough to need approval. Both sides are playing a reasonable game under bad rules.

What SRE is

Google's SRE teams are staffed with software engineers. Treynor Sloss' definition is that SRE is what you get when you treat operations as a software problem. Two consequences follow. First, engineers get bored of doing things by hand and write programs to do them instead, so the team shrinks relative to the service it runs. Second, the people operating the service can read and fix the code of the service, which collapses the dev/ops vocabulary gap.

To stop operations from quietly eating the team, Google enforces the 50 percent rule. When ops work exceeds half of an SRE team's time, the extra pages and tickets are routed to the developers, who then have a direct incentive to make the service quieter. Each SRE should receive at most two events per on-call shift of eight to twelve hours, so there is time to handle each one properly and write the postmortem.

The tenets

Durable engineering focus. The 50 percent cap, the two-events-per-shift target, and postmortems for every significant incident whether or not it paged. Blameless postmortems are called out as the cultural foundation.

Maximum change velocity within the SLO. This is where the error budget appears. The product decides how reliable the service needs to be, based on what users will tolerate, what alternatives exist, and how users actually experience the product. The gap between that target and 100 percent is the budget. While budget remains, developers launch; when it is spent, launches slow until the service earns it back. This replaces political arguments with a shared number.

Monitoring. A system where a human watches a screen and decides whether something is wrong does not scale. Software should interpret, and humans should be told only when they have to act. Hence alerts, tickets and logs as the only valid outputs.

Emergency response. Reliability is MTTF and MTTR together. Humans add latency, so the fewer incidents that need a human the better, and when a human is needed, a playbook plus exercises like the Wheel of Misfortune cut MTTR dramatically.

Change management. Most outages come from changes. Automate progressive rollouts, detect problems quickly and accurately, and roll back safely when they appear. Taking humans out of the loop reduces both mistakes and fatigue.

Demand forecasting and capacity planning. Account for organic growth (adoption) and inorganic growth (launches, marketing), load-test regularly so you know how much capacity a machine actually buys you, and keep enough redundancy to survive failures.

Provisioning. Combines capacity planning and change management: adding capacity is a risky change and must be done quickly and correctly, and only when needed, because idle capacity is expensive.

Efficiency and performance. Utilisation is a function of demand, capacity and software efficiency. SREs own all three, and should notice that a service slows down as it loses capacity. Provision to the target response time, no more.

Where this leaves DevOps

The chapter notes that DevOps, which emerged around 2008, shares the principles: involve IT in every phase, rely on automation over people, apply engineering practice to ops. SRE can be read as a specific implementation of DevOps with some opinionated extensions.