Site Reliability Engineering (SRE): Site Reliability Engineering – Tutorial (about 60 minutes)

Site Reliability Engineering (SRE) is an engineering discipline, first developed at Google, that runs production services by treating operations as a software problem: reliability is defined with measurable targets, risk is managed with an explicit budget for failure, and repetitive manual work is steadily replaced by automation. Platform, operations, DevOps and software teams in every industry now use its practices. After this tutorial you will be able to define useful service level indicators and objectives, calculate and govern an error budget, recognise and reduce toil, run incidents and blameless postmortems, and explain how SRE fits next to DevOps, DORA and ITIL.

Free tutorial · about 60 minutes · 7 lessons · 4 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: SRE is not a formal standard. No standards body owns it, there are no clauses to comply with and no organisational certification scheme. Its reference body of knowledge is a set of books written by Google engineers and published with O'Reilly Media: Site Reliability Engineering: How Google Runs Production Systems (2016), The Site Reliability Workbook (2018) and Building Secure and Reliable Systems (2020), all three free to read at sre.google. On 12 October 2026, the tenth anniversary of the first book, Google announced a second edition of Site Reliability Engineering: a complete rewrite that covers multi-tier SLOs, burn-rate alerting, OpenTelemetry-based observability, platform engineering and reliability for AI infrastructure. It is sold in print and digitally (O'Reilly lists autumn 2026) and is not on the free website at the time of writing. The core principles taught here are the same in both editions; where the second edition adds detail, this tutorial says so. Verified 2026-10-29 against sre.google and Google Cloud's announcement.

Who it is for: engineers, operations and platform staff, engineering managers, product owners and service-management or quality people who are new to SRE and want an accurate foundation before applying it or studying for an individual SRE certificate.

Prerequisites: none beyond a general idea of how a web or online service is built and run. Percentages and simple arithmetic are enough for the error-budget examples.

Learning objectives. After the seven lessons:

You will be able to explain why SRE exists, the conflict between change and stability it resolves, and why 100 % is the wrong reliability target.
You will be able to define SLIs, SLOs, SLAs and error budgets and tell them apart in a real conversation.
You will be able to calculate an error budget and a burn rate and describe a sensible error budget policy.
You will be able to recognise toil, measure it and plan how to reduce it.
You will be able to describe how SRE teams handle on-call duty, incidents and blameless postmortems.
You will be able to judge an organisation's SRE adoption honestly, knowing that no formal certification of organisations exists.
You will be able to compare SRE with DevOps, DORA metrics, ITIL, ISO/IEC 20000-1 and ISO 22301.

Lesson 1 – Origins, purpose and scope

Where SRE came from

In 2003 Google asked Ben Treynor Sloss, a software engineer, to lead a small production team of seven engineers. Instead of building a classic operations department of system administrators who run software written by others, he staffed and managed the team the way a software engineer would want operations to work. His often-quoted description is that SRE is "what happens when you ask a software engineer to design an operations team" (Treynor Sloss, in Site Reliability Engineering, 2016). Over the following decade the approach spread through Google, and when the first book appeared in 2016 other companies began adopting it widely. Today many organisations have SRE teams, SRE job titles and SRE practices, often adapted to a scale far smaller than Google's.

The problem SRE solves

Traditional IT separated developers, who are rewarded for shipping new features quickly, from operators, who are rewarded for keeping the system stable. Every change is a risk to stability, so the two groups pull in opposite directions. Operations teams add launch reviews, change boards and freezes; developers learn to split launches into small pieces or relabel features to slip past the gates. Both sides lose, and the conflict is settled by opinion and politics rather than data.

A second problem is cost. In a classic model the size of the operations team grows roughly in line with the size of the system: twice the servers or twice the traffic means roughly twice the manual work and twice the people. For a fast-growing service that becomes unaffordable.

SRE addresses both problems with engineering. It replaces the argument about "how stable is stable enough" with an agreed, measured reliability target and a budget for unreliability that both sides can spend. And it caps the amount of manual operations work engineers do, so that the remaining time goes into automation that lets the service grow without the team growing at the same rate.

Core principles

The first SRE book lists a small set of tenets. In plain words they are:

Keep a lasting focus on engineering: operational work is limited (Google uses a cap of 50 % of each engineer's time) and the rest is spent making the system better.
Pursue the fastest rate of change that does not break the service level objective, using the error budget to decide.
Monitor so that software interprets the signals and humans are notified only when they need to act.
Prepare for emergencies: reliability depends on time between failures and on how fast you recover, and written playbooks speed recovery.
Manage change carefully: most outages follow a change, so roll out progressively, detect problems fast and roll back safely.
Forecast demand, plan capacity and provision it quickly and correctly.
Run efficiently: capacity costs money, and good engineering lowers it.

Reliability is a product feature, and 100 % is wrong

A key insight of SRE is that reliability is not free and is not the only thing users want. Users reach your service through home Wi-Fi, mobile networks and devices that are themselves far less reliable than 99.999 %. Beyond a certain point, extra reliability is invisible to them, while it costs a great deal: more redundant capacity, slower releases and engineers who spend their time protecting stability instead of building features. Choosing the right reliability target is therefore a business and product decision, made together by product management, development and SRE. Aiming for 100 % means you can never change anything, which is why SRE says it is the wrong target for almost every service.

Scope

SRE applies to services that people or other systems depend on: websites, APIs, mobile back ends, data pipelines, storage systems, internal platforms and increasingly AI training and serving infrastructure. It covers the whole service lifecycle, from architecture and launch reviews to monitoring, incident response, capacity planning and decommissioning. It is a job role (Site Reliability Engineer), a team model and a set of practices; you can adopt the practices even without a team called "SRE".

Lesson 2 – Key concepts and vocabulary

SRE has a compact vocabulary. Learn these terms well, because almost every SRE conversation uses them.

Service – something users or other systems depend on, such as a checkout API, a search page or a nightly data pipeline. SRE sets reliability targets per service, from the user's point of view.
Reliability – the degree to which the service does what its users need, when they need it. It includes availability but also speed, correctness and freshness of results.
Service level indicator (SLI) – a carefully chosen measurement of one aspect of service level. SRE recommends expressing it as the ratio of good events to valid events, for example the share of requests answered successfully, so it always lies between 0 % and 100 %.
Service level objective (SLO) – a target value for an SLI over a time window, for example "99.9 % of checkout requests succeed, measured over 28 days". The SLO is the internal promise that guides engineering decisions.
Service level agreement (SLA) – a contract with customers that states consequences, such as service credits, if a level is missed. An SLA is a business document; teams normally set their SLOs tighter than any SLA so they react before a contract is breached.
Error budget – the amount of unreliability the SLO allows: 100 % minus the SLO. With a 99.9 % objective, 0.1 % of events may fail during the window. The budget can be spent on releases, experiments and maintenance, and is the shared currency between development and SRE.
Error budget policy – a written, agreed document that says what the organisation does when the budget is nearly or fully used, for example pausing feature releases and prioritising reliability work.
Burn rate – how fast the error budget is being consumed compared with the steady rate that would use exactly all of it by the end of the window. A burn rate of 1 uses the whole budget in the window; a burn rate of 10 would use it in a tenth of the time.
Toil – operational work that is manual, repetitive, automatable, reactive, leaves no lasting improvement behind and grows linearly as the service grows. Not all operational work is toil; designing a new alerting strategy is engineering, while restarting the same job by hand every night is toil.
Four golden signals – latency, traffic, errors and saturation: the four measurements Google recommends monitoring first for any user-facing system.
Symptom versus cause – a symptom is what users experience (pages are slow); a cause is why (a database disk is full). SRE pages people on symptoms and uses causes for diagnosis.
On-call – the rota of engineers who respond to alerts for a service during a shift. SRE treats on-call load as something to measure and keep sustainable.
Incident – an unplanned event that degrades or threatens the service and needs a coordinated response.
Incident commander – the person who coordinates the response to a large incident, assigns roles and decides, while others do the hands-on fixing and the communication.
Postmortem – a written record of an incident: what happened, its impact, how it was mitigated, the contributing causes and the follow-up actions. In SRE it is blameless: it examines systems and processes, never the guilt of individuals.
MTTD and MTTR – mean time to detect and mean time to repair (or recover). Reducing them reduces how much of the error budget each incident burns.
Production readiness review (PRR) – a structured review of a service's design, monitoring, capacity and operational procedures before an SRE team accepts responsibility for it.
Canary release – sending a change first to a small share of servers or users and comparing their behaviour with the rest before rolling it out further.

The first three ideas, SLI, SLO and error budget, form a chain. Figure 1 shows how a measurement becomes a target, the target becomes a budget, and the budget drives decisions through a policy.

Figure 1 – How an SLI becomes an SLO, the SLO defines an error budget, and a policy turns the budget into release decisions.

Error budget arithmetic

Error budgets are easy to compute. If the SLO is 99.9 % availability over 30 days, the budget is 0.1 % of the window. Thirty days contain 43,200 minutes, so 0.1 % is 43.2 minutes of complete outage, or a longer period of partial failure. If you count requests instead of time, and the service handles 50 million requests in 30 days, the budget is 50,000 failed requests. Raising the target to 99.99 % cuts the budget to about 4.3 minutes, a tenth as much, which is why each extra "nine" is so expensive: there is hardly time for a person even to notice an outage, let alone fix it.

Lesson 3 – Structure of the SRE body of practice

Because SRE is not a standard, it has no clauses or controls. It does, however, have a clear structure that the Google books use and that most adopters follow: a handful of principles (Lesson 1), a set of practices that put them into effect, and organisational models for the people who do the work.

How the books are organised

The 2016 book has five parts: an introduction, Principles (risk, SLOs, toil, monitoring, automation, release engineering, simplicity), Practices (alerting, on-call, troubleshooting, emergency response, incident management, postmortems, testing, capacity planning, load balancing, overload handling, distributed consensus, data integrity, launches) and Management (training, interrupts, operational overload, communication, engagement models) and short Conclusions that include lessons from other industries. The 2018 workbook follows the same flow but shows how to implement the ideas, with chapters on implementing SLOs, alerting on SLOs, eliminating toil, on-call, incident response, postmortem culture, managing load, introducing non-abstract large system design and engagement models. Building Secure and Reliable Systems extends the thinking to security, recognising that a compromised system is not a reliable one.

The service reliability hierarchy

The first book introduces a useful way to order the practices: a hierarchy, like Maslow's pyramid of needs, where each layer depends on the ones beneath it. You cannot meaningfully run incident response without monitoring, and you cannot plan capacity well without understanding the failures your postmortems revealed. Figure 2 shows the layers from the foundation upwards.

Read the hierarchy from the bottom:

Monitoring: without it you are flying blind and learn about outages from users.
Incident response: once you can see problems, you need a practised way to respond, from on-call rotas to incident command.
Postmortems and root-cause analysis: learning from each incident so the same failure does not return.
Testing and release procedures: preventing failures before they reach users, through tests, canaries and progressive rollouts.
Capacity planning: making sure there is enough of every resource for forecast demand, with headroom for failures.
Development: designing software and architecture that are reliable at scale, such as load balancing and overload protection.
Product: at the top, the working service that users actually experience.

Practice areas at a glance

Across the books, the practices group naturally into six areas. Most organisations adopting SRE introduce them roughly in this order:

Service level management – choosing SLIs, setting SLOs, agreeing error budget policies and reviewing them.
Monitoring and alerting – the golden signals, symptom-based paging, burn-rate alerts, dashboards and, increasingly, distributed tracing and OpenTelemetry instrumentation.
Toil reduction and automation – measuring operational load, capping it, and building tools and platforms that remove manual work.
Incident management and learning – sustainable on-call, structured incident response, blameless postmortems and tracking their action items.
Release and change engineering – hermetic and repeatable builds, progressive rollouts, canaries, feature flags and fast rollback.
Capacity, performance and efficiency – demand forecasting, load testing, handling overload gracefully and controlling cost.

Team models

Google has described several common ways to organise SRE teams, and most companies use one or a mix:

Kitchen sink – one SRE team covers everything; typical for a first team in a small company.
Infrastructure – SREs run shared platforms such as Kubernetes clusters or databases used by many product teams.
Tools – SREs build software (deployment, monitoring, capacity tooling) that helps developers run their own services.
Product or application – an SRE team dedicated to one important product or group of services.
Embedded – SREs work inside development teams for a period, often to fix a specific reliability problem.
Consulting – SREs advise many teams without taking on their on-call duties.

The second edition of the SRE book also discusses hybrid models in which platform engineering teams and "reliability champions" inside product teams carry SRE practice, rather than a large central SRE group. The common thread is shared ownership: developers and SREs are jointly responsible for the service's reliability.

Lesson 4 – How it works in practice

This lesson walks through the core practices in the order most teams adopt them. Each one builds on the previous.

Step 1: Choose SLIs from the user's perspective

Start by listing the most important user journeys, such as "search for a product", "add to cart" and "pay". For each journey, ask what a user would notice when it fails. The Site Reliability Workbook offers a menu of SLI types to choose from:

For request-driven services: availability (share of requests that succeed), latency (share of requests faster than a threshold) and quality (share of responses served without degradation, for example without a fallback to cached results).
For data pipelines: freshness (share of data updated recently enough), correctness (share of records producing the right output) and coverage (share of data or jobs processed).
For storage systems: durability (share of written data that can be read back).

Separate the specification of an SLI (what matters to users, in plain words) from its implementation (where and how you measure it). Measuring at the load balancer is cheap and broad; synthetic probes see what a user sees but cover only scripted paths; client-side measurement is closest to user experience but harder to collect. Choose the implementation that is closest to the user that you can afford, and document its blind spots.

Step 2: Set SLOs and agree the error budget policy

Set the first SLO from current performance, not from aspiration. If checkout has succeeded 99.95 % of the time over the last quarter and users are not complaining, a 99.9 % SLO is a reasonable starting point. Choose a rolling window (four weeks or 28 days is common because it contains the same number of weekends each time). Then write an error budget policy and have it signed by the product owner, the development lead and the SRE lead. A good policy names its authors and approvers, gives a review date, describes the service, says what happens when the budget is exhausted and explains how disagreements are escalated. Typical actions when the budget runs out are to pause non-urgent feature releases, give priority to reliability bugs and postmortem actions, and resume normal work once the service is back within its objective.

The policy is what makes SRE work. Without it, an SLO is just a number on a dashboard. With it, the decision about whether to ship a risky change is made by data that everybody agreed in advance, which removes most of the old conflict between developers and operators.

Figure 3 – An error budget policy in action: the remaining budget decides whether teams keep shipping, slow down or freeze changes.

Step 3: Monitor and alert on what matters

Monitoring in SRE has two purposes: telling you that something is broken and helping you find why. Start with the four golden signals for each user-facing service: latency (measure successful and failed requests separately, because fast errors can make averages look good), traffic (demand, such as requests per second), errors (failed requests, including wrong content and policy violations such as too-slow answers) and saturation (how full the most constrained resource is).

Combine black-box monitoring, which tests the service from outside as a user would, with white-box monitoring, which uses internal metrics, logs and traces. Black-box checks confirm user impact and are good for paging; white-box data reveals problems hidden by retries and is essential for debugging.

Every page should be urgent, actionable and about real or imminent user impact, and should need human judgement. Anything that can wait goes to a ticket or a dashboard. Pages that turn out to need no action should be removed or fixed, because noisy alerting tires engineers and hides real emergencies.

The recommended way to alert on an SLO is to alert on the burn rate. The workbook's starting point for a 99.9 % SLO uses several windows: page if the budget is burning 14.4 times too fast over the last hour (that is 2 % of a 30-day budget gone in one hour), page if it is burning 6 times too fast over six hours (5 % gone), and open a ticket if it is burning at rate 1 over three days (10 % gone). Each alert also checks a short window, about one twelfth of the long one, so the alert stops quickly once the problem is fixed. This "multiwindow, multi-burn-rate" design balances four qualities: precision (few false alarms), recall (few missed problems), detection time and reset time.

Step 4: Measure and reduce toil

Ask engineers to record, for a few weeks, how they spend their time: tickets, pages, manual deployments, access requests, capacity changes and project work. Classify each operational task against the toil characteristics. Then rank toil by total hours and by how fast it grows. Good candidates for automation are frequent, well-understood, low-risk tasks. Sometimes the best fix is not a script but a design change that removes the need for the task altogether, such as self-service access or auto-scaling.

Google caps operational work at 50 % of each SRE's time. When a team exceeds the cap for a sustained period, the excess is handed back to the development team, or reliability work is prioritised, until the load falls. The cap is a signal to management that the service needs engineering investment, not a target to aim for; healthy teams are well below it.

Step 5: Run on-call and incidents well

On-call should be sustainable. The SRE book suggests aiming for no more than about two incidents per on-call shift, so that each one can be handled thoroughly and followed up with a postmortem. Rotas need enough people for regular rest, clear handovers and compensation. New engineers learn through shadowing, practice drills and "wheel of misfortune" role-play exercises that replay past incidents.

When an incident is large, separate the roles: an incident commander coordinates and decides; an operations lead and responders change the system; a communications lead keeps stakeholders and users informed; and in long incidents a planning role handles logs, handovers and follow-up items. A live incident document records the timeline. The first priority is to mitigate user impact (roll back, drain traffic, fail over), not to find the root cause; diagnosis can continue once users are safe. Declare incidents early: it costs little to stand down a response that was not needed, and a lot to start one late.

Figure 4 – The SRE incident lifecycle: detect, coordinate, mitigate and resolve, then learn through a reviewed blameless postmortem whose actions are tracked.

Step 6: Learn with blameless postmortems

Agree in advance what triggers a postmortem, for example user-visible impact beyond a threshold, any data loss, any manual intervention such as a rollback, a long resolution time, or a monitoring failure where people found the problem by chance. A postmortem records the timeline, impact, detection, mitigation, contributing causes and action items, each with an owner and a due date. It is reviewed by experienced engineers for depth and completeness, then shared widely and stored where others can search it. Blamelessness matters because people who fear punishment hide information, and hidden information means the same failure returns. Postmortems should also avoid details that identify end users.

Step 7: Engineer safe releases and enough capacity

The SRE book observes that most outages are triggered by changes to a live system. Release engineering therefore aims for builds that are repeatable, automated pipelines, progressive rollouts that start with a canary, automatic comparison of canary and baseline metrics, and the ability to roll back quickly. Capacity planning combines organic demand (normal growth) with inorganic demand (launches, marketing campaigns, seasonal peaks), is validated by load tests, and keeps headroom so the service survives losing a zone or a data centre. Services should also degrade gracefully under overload, shedding low-priority work rather than collapsing.

Step 8: Review readiness and keep improving

Before SREs take on a service, a production readiness review checks its architecture, dependencies, SLOs, monitoring, alerting, capacity, release process and runbooks. Gaps become work items for the developers. After that, a regular service review (often monthly) looks at SLO performance, budget spend, toil levels, alert quality, open postmortem actions and upcoming launches. SLOs themselves are reviewed periodically and adjusted when users' needs or the system change.

Lesson 5 – Assessment, certification and compliance

There is no organisational SRE certification

SRE has no certification body, no accredited auditors and no conformity scheme. No company can be "SRE certified" the way it can be certified to ISO/IEC 27001 or ISO 9001, and Google does not certify other organisations in SRE. Be sceptical of any claim of organisational SRE certification. Claims of "SRE maturity level 3" usually refer to a consultant's or vendor's own model, which can be useful as a conversation tool but is not a standard.

Certificates for individuals

Individuals can earn training certificates from independent bodies. For example, DevOps Institute, which is now part of the PeopleCert group, offers Site Reliability Engineering Foundation and Site Reliability Engineering Practitioner certifications. Cloud providers and training companies offer related courses and credentials. These show that a person has studied the body of knowledge; they say nothing about whether an organisation runs its services well.

How to assess SRE adoption honestly

Because there is no scheme, organisations assess themselves with evidence. Useful questions and measures are:

SLO coverage and quality: what share of important services and user journeys have documented SLIs and SLOs, measured close to the user, and an error budget policy signed by product, development and SRE?
Policy in use: when a budget was exhausted, did the agreed actions actually happen? A policy that has never been invoked when needed is not working.
Alert quality: pages per shift, share of pages that needed action, and whether paging alerts are based on symptoms and burn rate.
Toil: measured share of time spent on toil, its trend, and whether it stays well below the cap.
Incident learning: share of qualifying incidents with a reviewed postmortem, and share of postmortem actions closed on time.
Recovery: time to detect and time to restore service, and whether repeated incidents with the same cause are falling.
Delivery performance: the DORA software delivery metrics (Lesson 7) show whether reliability work is enabling, not blocking, change.

Where compliance does matter

SRE intersects with formal compliance in three places. First, SLAs are contracts: missing them can cost service credits, so SLO and SLA definitions must be consistent and the measurement must stand up to customer scrutiny. Second, regulated sectors often require evidence of incident management, change control, availability management and business continuity; SRE artefacts such as postmortems, change records from pipelines and SLO reports are good evidence for audits against ISO/IEC 20000-1, ISO/IEC 27001 or ISO 22301, and for operational-resilience regulations in finance. Third, security and privacy rules apply to monitoring data and postmortems themselves, for example removing personal data from logs and reports.

A practical tip: map your SRE artefacts to the controls your auditors already test. An automated deployment pipeline with peer review, canary analysis and recorded rollbacks often satisfies change-management requirements better than a manual change board, if you can show the evidence.

Lesson 6 – Worked example

This example follows a fictional company, FreshBasket, an online grocery service with a web shop, a mobile app and about 40 engineers. Customers complained about failed payments during evening peaks, releases were frequent but scary, and a three-person operations team spent most of its time on manual work. The CTO decided to adopt SRE practices.

1. Start small and pick a service

Rather than reorganise the whole company, FreshBasket formed a small kitchen-sink SRE team from two operations engineers and two developers, and chose one service to start with: the checkout API, which takes the basket, reserves delivery slots and calls the payment provider.

2. Define SLIs and SLOs

The team listed the checkout journey's steps and asked what customers notice. They chose two SLIs, measured at the load balancer in front of the API:

Availability: the share of valid checkout requests that return a successful response (client errors such as invalid card numbers excluded as not valid events).
Latency: the share of checkout requests answered within 800 milliseconds.

Looking at the previous quarter, availability had been about 99.92 % and latency about 99.3 %. They set SLOs of 99.9 % availability and 99 % latency over a rolling 28-day window. Checkout handles about 4 million requests in 28 days, so the availability error budget is 0.1 % of 4 million, or 4,000 failed requests. They also noted a blind spot: the load balancer cannot see app crashes before the request leaves the phone, so they planned client-side measurement for later.

3. Agree an error budget policy

The head of product, the checkout development lead and the SRE lead signed a one-page policy. If the 28-day budget is exhausted, checkout feature releases pause except for security and reliability fixes, the next sprint starts with the top postmortem actions, and normal releases resume when the SLO is met again. If a single incident uses more than 20 % of the budget, a postmortem is mandatory. Disagreements go to the CTO. The policy is reviewed every six months.

4. Alert on burn rate

The old alerts paged on CPU above 80 % and on every individual error spike; most pages needed no action. The team replaced them with burn-rate alerts on the checkout SLOs, using the multiwindow pattern, and moved CPU and disk warnings to dashboards and tickets. Pages fell from about fifteen per week to two or three, and almost all needed action.

5. Spend the budget, then protect it

In the first month the team used part of the budget deliberately: they migrated the payment client library, accepting a small risk. In week three a configuration change set a timeout to 50 milliseconds instead of 500. The canary stage was only five minutes long and too small to catch it, and the change reached all servers. The one-hour burn-rate alert fired, the on-call engineer declared an incident, took the incident commander role, asked a developer to roll back the configuration, and posted updates in the status channel. Users were affected for 18 minutes; about 1,500 checkouts failed, consuming 37.5 % of the 28-day budget.

6. Learn blamelessly

The postmortem did not ask who mistyped the value. It asked why the system allowed a wrong value to reach production. Contributing causes were: configuration changes skipped the validation that code changes received; the canary stage was too short and too small to show a statistically clear difference; and the rollback took eight minutes because the runbook was out of date. Actions with owners and due dates were: add schema validation and range checks for configuration; route configuration through the same progressive rollout as code, with automatic canary analysis; and make one-click rollback the default. The postmortem was reviewed by a senior engineer and shared with all teams.

7. Hit the policy, and honour it

Two weeks later, a payment provider slowdown during a promotion consumed the rest of the budget. The policy triggered: the checkout team paused a planned redesign for one sprint and completed the postmortem actions and a retry-with-backoff fix for the provider calls. The product head, who had signed the policy, supported the pause because the rule had been agreed in calm times. The service returned within its SLO the following week.

8. Attack toil

The SREs logged their time for four weeks and found that 60 % went on operational work, above the 50 % cap. The biggest items were manually adding capacity before marketing campaigns, renewing TLS certificates and granting database access. They automated certificate renewal, introduced auto-scaling with a campaign calendar feeding the capacity forecast, and built self-service, time-limited database access with an approval step. Six months later, toil was about 30 % of their time, and the freed hours went into a production readiness review for the next service, delivery slots.

9. Review and expand

A monthly service review now covers SLO performance, budget spend, pages per shift, open postmortem actions and upcoming launches. With checkout stable, FreshBasket repeated the pattern for search and delivery slots, and later moved from one kitchen-sink team towards a platform team that offers SLO dashboards, alerting templates and the deployment pipeline to all developers. The company never became "SRE certified", because no such thing exists, but it could show customers and auditors clear evidence: SLO reports, postmortems and automated change records.

Lesson 7 – Relationship to other standards and frameworks

SRE overlaps with several well-known frameworks. Understanding the overlaps helps you combine them rather than run competing programmes.

SRE and DevOps

DevOps is a broad culture and set of principles for bringing development and operations together, often summarised as culture, automation, lean, measurement and sharing. Google's workbook describes the relationship with a programming analogy: SRE is one concrete implementation of the DevOps interface. DevOps says "measure" and "share responsibility"; SRE says how, with SLOs, error budgets, toil caps and blameless postmortems. They are complementary, not competing.

SRE and DORA

DORA (DevOps Research and Assessment, now a Google Cloud research programme) studies what drives software delivery and operational performance. Its delivery metrics cover throughput (how often and how fast changes reach production) and stability (how often changes fail and how quickly service is restored). SLOs measure the reliability users experience; DORA metrics measure the delivery system. Used together, they show whether you are shipping quickly and reliably, and DORA's research has repeatedly found that the two goals reinforce each other.

SRE and ITIL, ISO/IEC 20000-1 and ISO 22301

ITIL is PeopleCert's IT service management framework. ITIL 4 is still widely used, and its successor, ITIL (Version 5), was released in 2026. ITIL describes management practices; in ITIL 4 these include service level management, incident management, problem management and change enablement. SRE provides engineering-heavy ways to run several of these practices: SLOs for service level management, burn-rate alerting and incident command for incident management, postmortems for problem management, and automated progressive rollouts for change enablement. ISO/IEC 20000-1 is the certifiable requirements standard for a service management system; SRE artefacts can serve as evidence for it. ISO 22301 covers business continuity management; SRE's capacity headroom, failover testing and disaster recovery exercises support it, but the standard asks for broader organisational planning too.

Framework	Type and owner	Main focus	How it relates to SRE
DevOps (CALMS)	Cultural movement, no single owner	Collaboration, flow and shared ownership across dev and ops	SRE is a concrete, prescriptive way to implement DevOps principles
DORA metrics	Research programme, Google Cloud	Measuring software delivery throughput and stability	Complements SLOs; shows reliability work is not slowing delivery
ITIL (ITIL 4, Version 5 from 2026)	Best-practice framework, PeopleCert	Value-driven IT service management practices	SRE supplies engineering methods for service level, incident, problem and change practices
ISO/IEC 20000-1	Certifiable standard, ISO/IEC	Requirements for a service management system	SRE artefacts provide audit evidence; SRE itself is not certifiable
ISO 22301	Certifiable standard, ISO	Business continuity management system	SRE capacity, failover and recovery testing support continuity objectives
Platform engineering	Emerging practice, no single owner	Internal developer platforms and self-service	Often where SRE tooling, SLO templates and toil reduction are delivered

Chaos engineering and observability

Two further neighbours are worth naming. Chaos engineering deliberately injects failures, in a controlled way, to test that systems and teams cope; SREs use it to validate redundancy and runbooks. Observability, built on metrics, logs and traces and increasingly on the open OpenTelemetry project, is the modern foundation of SRE monitoring and is a major topic of the second edition of the SRE book.

Common pitfalls and best practices

Common pitfalls

Renaming the operations team "SRE" without capping toil or giving engineers time to automate. Nothing changes except job titles.
Setting SLOs at 99.99 % or higher because it sounds good, rather than from user needs and current performance. The budget becomes so small that every release breaks the policy and teams start ignoring it.
SLOs with no error budget policy, or a policy nobody honours. Without agreed consequences, the SLO is just a chart.
Measuring infrastructure instead of users, such as CPU usage or server uptime, so the dashboards are green while customers cannot pay.
Alert fatigue: paging on causes and noisy thresholds, so engineers learn to ignore pages and miss the real one.
Blame in postmortems, even subtle, which teaches people to hide mistakes and makes the next incident harder to understand.
Postmortem action items that are never completed, so the same incident happens again.
Treating SRE as a separate gatekeeping team that developers throw software over the wall to, recreating the old dev-versus-ops conflict.

Best practices

Start with one important service and a few SLIs, learn, then expand. A simple, agreed SLO beats a perfect one that never ships.
Get the error budget policy signed by product, development and SRE before it is needed, and review it on a fixed schedule.
Alert on symptoms and burn rate, page only for urgent, actionable user impact, and send everything else to tickets or dashboards.
Measure toil regularly and invest the reclaimed time in automation and design changes that remove whole classes of work.
Prioritise mitigation over diagnosis during incidents, use clear incident roles, and declare incidents early.
Review postmortems, share them widely and track actions to completion, celebrating good postmortems as learning.
Make every change progressive and reversible: canaries, automatic analysis and fast rollback for both code and configuration.
Share ownership: developers take part in on-call or at least in reviews and postmortems for the services they build.

Summary and key takeaways

SRE is an engineering discipline, born at Google in 2003, that runs operations with software engineering methods; it is a body of practice, not a certifiable standard.
Reliability targets are a product decision: 100 % is the wrong target, and each extra nine costs far more than it returns for most services.
SLIs measure what users experience as good events over valid events; SLOs set targets over a window; SLAs are contracts and should be looser than SLOs.
The error budget, 100 % minus the SLO, plus a signed error budget policy, turns the dev-versus-ops argument into a data-driven decision.
Toil is manual, repetitive, automatable work without lasting value; SRE caps it and invests the remaining time in automation.
Monitoring follows the four golden signals; paging is for urgent, actionable symptoms, ideally through multiwindow burn-rate alerts.
Incidents are handled with clear roles and mitigation first, then learned from through reviewed, blameless postmortems with tracked actions.
SRE complements DevOps, DORA metrics, ITIL and ISO management-system standards, and its artefacts make strong audit evidence.

Reflection questions

Pick one service you know well. Which two or three user journeys matter most, and which SLI type from the menu would you use for each? Where would you measure it?
Your current availability is 99.7 % and your sales team has promised 99.95 % in a contract. How would you approach the SLO, the SLA and the conversation with the sales team?
List the operational tasks your team did last week. Which meet the definition of toil, and which one would you automate or design away first, and why?
Think of a recent incident in your organisation. How would it have gone differently with an incident commander, mitigation-first thinking and a blameless postmortem?
Your manager wants to announce that the company is "SRE certified" after two engineers passed a foundation exam. What would you tell them, and what evidence of SRE adoption would you suggest presenting instead?