Google's Site Reliability Engineering book — the original, published in 2016 — remains the most influential document in the discipline. A decade later, with the infrastructure landscape transformed by cloud-native architecture, AI tooling, and a generation of engineers who've read the SRE book as canon, it's worth asking: what from that original framework still holds, what hasn't aged well, and what's genuinely missing?
This isn't an attempt to undercut the book. It's an attempt to read it with fresh eyes and understand where the practice needs updating.
What Has Held Up Remarkably Well
Error budgets and SLOs. The error budget concept — the insight that 100% reliability is never the goal, that the difference between your SLO and 100% is budget available to spend on risk — is the most durable idea in the SRE book. A decade of industry experience has confirmed it works. It transforms the tension between "reliability team that wants stability" and "product team that wants to ship fast" into a collaborative negotiation about how to spend a shared resource.
What's evolved is the tooling: SLO tracking has moved from bespoke implementations to off-the-shelf platforms (Datadog, Nobl9, Google Cloud Monitoring all have native SLO support). The concept didn't need to change; the implementation became much easier.
The elimination of toil as a north star. The book's definition of toil — manual, repetitive, automatable work that scales with service growth — and its prescription to cap toil at 50% of an SRE's time remain correct. The mechanism for eliminating toil has changed (today you write an LLM agent instead of a shell script for many categories of toil), but the principle is unchanged.
Blameless postmortems. The psychological safety insight — that people won't surface problems if doing so leads to punishment — and the structural response (systems thinking, not individual blame) remain foundational. Organizations that haven't internalized this still have slower incident learning cycles and higher engineer attrition. This is one of the parts of the SRE book that reads as more obviously true today than it did in 2016.
On-call design principles. The book's guidance on on-call load, psychological safety for on-call engineers, escalation policies, and alert design is largely correct and underimplemented in most organizations. Alert fatigue continues to be one of the most common SRE problems I encounter, and the solutions are exactly what the book describes: meaningful alerts, clear escalation paths, and systems that reduce on-call burden over time.
What Hasn't Aged Well
The monolithic reliability model. The original SRE book was written against Google's infrastructure, which at the time was primarily a collection of large services with well-defined boundaries. The book's mental model is a service with a clear owner, a clear SLO, and a clear on-call rotation. This model doesn't translate cleanly to:
- Serverless architectures where "the service" is a collection of functions with no single owner
- Data pipelines where "the service" is a chain of batch jobs with complex dependencies
- AI systems where "the service" includes a model whose behavior changes without a deployment
The book doesn't have a good answer for "who owns the reliability of the ML model?" because when it was written, ML models weren't production dependencies in the way they are today.
The staffing model. The book describes an SRE team staffed to run a specific set of services, with a hiring pipeline for SREs who can do both operational work and software engineering. The 2026 reality is a much wider range of staffing models: embedded SREs in product teams, centralized platform SRE teams, SRE as a consulting function, and now AI tooling that handles a significant fraction of what an SRE would have done manually. The workforce implications of AI-augmented operations are not in the book because they couldn't have been.
The assumption of human-in-the-loop remediation. The book's incident response model assumes humans are the agents of remediation — they're the ones who push the button to roll back the deploy, restart the service, or adjust the configuration. The emerging model, which I have explored in production-like labs, involves AI agents that can take remediation actions autonomously for well-understood failure modes. The book's framework doesn't account for how to set SLOs, error budgets, or on-call policies when part of your remediation capacity is automated.
What's Missing
AI system reliability. The SRE book has no framework for the reliability of machine learning systems, LLM-powered agents, or AI-assisted operations. This is the largest gap between the book and current practice. What does an SLO for an AI system look like? How do you set an error budget for a system where "incorrect output" is a failure mode but measuring incorrectness is hard? How do you do a blameless postmortem for an incident caused by an LLM reasoning incorrectly?
Some emerging answers: SLOs for AI systems can include accuracy metrics (measured through sampling and human review), model quality can be tracked via outcome metrics (did the recommendation lead to a resolution?), and postmortems for AI-caused incidents should examine prompt design, tool design, and evaluation coverage rather than the model itself.
Data platform reliability. The book treats data stores as supporting infrastructure — databases are things that services use, and their reliability is an input to service reliability. It doesn't address data pipelines as first-class reliability concerns: what's the SLO for data freshness? How do you set an error budget for a batch pipeline that processes yesterday's data by 8am? How do you do incident response for a data quality failure that isn't an outage but produces incorrect results? The data platform reliability discipline has developed its own practices, largely outside the SRE tradition.
Multi-cloud and hybrid operations. The book was written from within a single-cloud perspective. The operational complexity of multi-cloud — unified observability, cross-cloud identity, egress costs, the networking complexity — doesn't appear. Most large organizations today operate across multiple clouds, and the SRE practices for that environment have had to develop without canonical documentation.
The organizational change problem. The book describes an end state (a mature SRE organization with error budgets, SLOs, and automation) but underweights the transition problem. How do you introduce SRE practices into an organization that's never had them? How do you win the political capital to implement error budgets when product teams see them as a mechanism for slowing down releases? The hardest SRE work is often organizational, and the book is written as if the organizational buy-in is already secured.
What a 2026 Update Would Cover
If I were contributing to a revised edition, the chapters I'd add:
SLOs for AI systems. Accuracy, latency, and behavior stability as reliability dimensions. How to measure correctness when ground truth is subjective. Error budgets for model quality.
Data platform SRE. Freshness SLOs, completeness SLOs, pipeline reliability patterns, data quality as a reliability concern.
Autonomous remediation. How to set error budgets when part of your remediation capacity is automated. The governance model for autonomous agent actions. How to do postmortems when an agent caused or failed to prevent an incident.
The platform engineering model. Internal developer platforms as a product, the "paved road" concept, and the organizational structure that makes platform engineering work at scale.
AI-augmented on-call. How triage agents, investigation agents, and remediation agents change the role of the human on-call engineer. What on-call excellence looks like when the agent handles the mechanical work.
The original SRE book was a distillation of a decade of Google's operational learning. The decade since its publication has generated at least as much new learning. The discipline is mature enough now that the update would be substantive, not incremental.
*Zak Hassan is a Staff SRE who has worked across enterprise SaaS platforms including Red Hat, SAP, and Hootsuite. Find him at zakhassan.com or on LinkedIn.*
Topic Paths