Skip to main content
OpsRoadmaps
Roadmap library3 phases · 9 steps · 9 dependenciesLast reviewed 2026-09-19

SRE Adoption

Adopt SRE the way it actually scales: one tier-1 service, one honest SLI/SLO, a signed error-budget policy with teeth, then toil budgets and steady expansion.

Every step is executable work: what, why, prerequisites, implementation, validation you can check, and the failure modes to avoid. Dependencies make the order explicit — a step marked Requires waits on those steps completing first.

9 steps

Phase 1

Foundations of measurement

One service, one honest objective — SRE adoption fails at the start by going wide before going real.

  1. Choose exactly one tier-1 service

    P0XS

    SRE

    Full step — what, why, how, failure modes
    WHAT. Pick the single service whose outage hurts most, and declare it the adoption pilot — one service done honestly beats five done as paperwork. WHY. SRE adoption dies of dilution: five services with vanity SLOs nobody acts on; one service with a real budget policy teaches the whole org the discipline. PREREQUISITES. None — this is a decision, not a build. IMPLEMENTATION. Rank services by revenue/impact per outage hour, check the service has (or can quickly get) request-level telemetry, and write a one-paragraph charter: which service, who owns the adoption, what success looks like in one quarter. TOOLS. None — a document and a decision. COMMON FAILURE MODES. Choosing the service the loudest person owns instead of the one the business depends on; the ranking is the antidote. EXPECTED IMPACT. The next three months of work have a scope the whole org can name. EVIDENCE. The charter document linked from the team's wiki front page.

    Validation — before you call it done

    A dated charter names exactly 1 pilot service, its owning team, and a quarterly success criterion, agreed by the team and their product partner in writing.

  2. Define one user-felt SLI from existing telemetry

    P0MRequires: Choose exactly one tier-1 service

    SREObservability Engineering

    Full step — what, why, how, failure modes
    WHAT. A service level indicator that measures what users experience — e.g., fraction of requests under 400 ms and non-5xx — computed from data you already collect. WHY. CPU is not an SLI; users do not experience CPU. An SLI divorced from user experience produces objectives everyone games and nobody trusts. PREREQUISITES. The chosen service and access to its request logs or metrics. IMPLEMENTATION. Write the SLI as a specification first (events, good events, window), then implement from existing telemetry — usually a log or metrics query. Keep it to one primary indicator; latency and error split only if you must. TOOLS. Prometheus or your APM; a query checked into the service repo. COMMON FAILURE MODES. Averaging latency — the mean hides the tail users actually feel; use a percentile or a fraction-under-threshold formulation. EXPECTED IMPACT. Reliability becomes a number about users instead of an argument between dashboards. EVIDENCE. The SLI spec plus a chart of the trailing 30 days with the spot-check noted.

    Validation — before you call it done

    The SLI computes for the trailing 30 days from production telemetry, its value matches a manual spot-check within 0.1 percent, and the spec document states events and good-event criteria unambiguously.

  3. Set the SLO at current reality, not the aspiration

    P0MRequires: Define one user-felt SLI from existing telemetry

    SRE

    Full step — what, why, how, failure modes
    WHAT. A target for the SLI measured over a rolling window (e.g., 99.5 percent of 5-minute windows good over 28 days), initially set where the service already performs. WHY. Setting the target at the aspiration means the budget is always already burned and the policy never engages; setting it at reality gives you a working contract on day one you can tighten deliberately (the workbook's implementing-SLOs chapter walks exactly this). PREREQUISITES. The SLI computing over trailing history so reality is knowable. IMPLEMENTATION. Read the SLI's trailing 30-day distribution, set the SLO a hair above current performance, define the window and the measurement latency honestly, and document the burn math: budget = 1 − target, in minutes per window. TOOLS. The SLI query; SLO tooling optional — a documented calculation is the contract. COMMON FAILURE MODES. Choosing 99.99 because it sounds right — at real traffic that is minutes of budget per month and the policy becomes noise by week two. EXPECTED IMPACT. The team gets a live, honest contract about how unreliable it may be. EVIDENCE. The SLO doc with the day-one measurement screenshot.

    Validation — before you call it done

    The SLO document states indicator, target, window, and burn math, and the current measurement sits within 0.2 percent of the target on day one.

Phase 2

Error budgets in force

The policy is the practice: consequences attached to burn, alerts that page on burn, and one exercised freeze.

  1. Write the error-budget policy and get product to sign it

    P0SRequires: Set the SLO at current reality, not the aspiration

    SRE

    Full step — what, why, how, failure modes
    WHAT. One page: when the budget is spent, feature releases hold in favor of reliability work until it recovers; who may grant exceptions; how fast each severity of burn responds. WHY. An SLO without a consequence is a dashboard; the policy is the actual agreement that trades release velocity for reliability without a shouting match each time. PREREQUISITES. The SLO exists so the budget being spent is a fact, not an opinion. IMPLEMENTATION. Write the one-pager with explicit trigger thresholds (e.g., 100 percent of budget consumed → releases hold; 25 percent in a week → reliability work prioritized), name the exception-granter, and get the product lead's signature — the signature is the step, not the document. TOOLS. A document; the discipline to keep it to one page. COMMON FAILURE MODES. Policy written but never signed by product — the first freeze then relitigates the whole agreement mid-incident. EXPECTED IMPACT. The velocity-versus-reliability argument becomes a pre-agreed rule the data triggers. EVIDENCE. The signed one-pager linked next to the SLO.

    Validation — before you call it done

    The signed policy names its numeric trigger thresholds (100 percent of budget → releases hold), the exception authority, and the recovery rule, and both engineering and product leads are on the record as agreeing.

  2. Wire multi-window burn-rate alerts

    P0MRequires: Write the error-budget policy and get product to sign it

    SREObservability Engineering

    Full step — what, why, how, failure modes
    WHAT. Two alert bands on budget burn — fast-burn pages immediately, slow-burn files a ticket — replacing threshold alerts on raw error counts. WHY. Raw thresholds page at 3 a.m. for problems that consumed no meaningful budget and stay silent while a slow leak spends the whole month; burn-rate windows page proportional to actual harm (the workbook's canonical alerting chapter is the reference). PREREQUISITES. SLO and policy in place so a page has a defined meaning. IMPLEMENTATION. Configure multi-window burn alerts (e.g., 14.4× over 1h pages, 3× over 6h tickets — tuned to your window), route the page to the on-call with the runbook link, and delete the old raw-threshold alerts for the same signal so they cannot both fire. TOOLS. Prometheus + Alertmanager or your platform's SLO alerting; the on-call router. COMMON FAILURE MODES. Adding burn alerts without deleting the old ones — on-call learns to ignore the whole channel within a fortnight. EXPECTED IMPACT. Pages become proportional to user harm, and the pager stops crying wolf. EVIDENCE. The alert config diff and the post-cutover alert log.

    Validation — before you call it done

    A synthetic fast-burn test pages on-call within 5 minutes, and 30 days of alert history shows the raw-threshold predecessor alerts disabled, with pager action-rate above 50 percent on the new alerts.

  3. Exercise the freeze once, on purpose

    P1SRequires: Wire multi-window burn-rate alerts

    SREDevOps

    Full step — what, why, how, failure modes
    WHAT. Deliberately spend or simulate spending the budget and run the policy end to end: hold releases, prioritize reliability work, recover, resume. WHY. A policy that has never fired is untested code; the first real burn is the worst possible moment to discover nobody remembers who grants exceptions or how releases actually hold. PREREQUISITES. Alerts wired so the burn is visible while it happens. IMPLEMENTATION. In a low-risk week, gate deploys (or simulate in staging if deploys are manual), burn or simulate the fast-burn threshold, walk the policy: page, hold, post the freeze notice in the release channel, do one reliability fix, then lift the hold and document the whole timeline. TOOLS. The deploy pipeline's hold control; the release channel. COMMON FAILURE MODES. Announcing the drill so broadly that nobody behaves normally — run it as realistically as safety allows. EXPECTED IMPACT. The policy graduates from document to muscle memory, with its rough edges found in a drill, not a quarter-end. EVIDENCE. The dated exercise timeline and the debrief action list.

    Validation — before you call it done

    The exercise log shows detection-to-freeze-notice inside 30 minutes, the hold observable in the deploy pipeline, and a debrief with every friction point assigned an owner.

Phase 3

SRE as a discipline

Toil measured and automated down; coverage extended service by service — the steady state after the pilot.

  1. Start the toil ledger

    P1SRequires: Choose exactly one tier-1 service

    SRE

    Full step — what, why, how, failure modes
    WHAT. Track manual, repetitive, automatable operational work as a percentage of engineering time, reviewed monthly against a cap. WHY. Toil grows silently until it consumes the team; you cannot manage what you never measured, and the toil percentage is the SRE book's own defining metric for a team's health. PREREQUISITES. The pilot service running — its operations are the first ledger entries. IMPLEMENTATION. Log toil where it happens (ticket tags plus a 5-minute weekly tally per engineer), define toil explicitly (manual, repetitive, automatable, no lasting value), set the cap (the book's threshold: 50 percent is a red line), and publish the number monthly. TOOLS. Ticket tags; a spreadsheet; monthly review slot on the agenda. COMMON FAILURE MODES. Counting only pages — toil hides in tickets, requests, and 'quick favors'; the definition matters more than the tool. EXPECTED IMPACT. The invisible tax becomes a managed line item with a cap the team can defend. EVIDENCE. The ledger (spreadsheet is fine) and the dashboard widget.

    Validation — before you call it done

    3 consecutive monthly ledger entries exist with the percentage computed, and the current figure plus trend is visible on the team's dashboard.

  2. Automate the top toil source

    P1MRequires: Start the toil ledger

    SREPlatform Engineering

    Full step — what, why, how, failure modes
    WHAT. Take the ledger's largest single toil entry and eliminate it with automation — then confirm the percentage actually dropped. WHY. The ledger without automation is just depression with a chart; one visible kill proves the loop funds engineering time, which is the political capital for everything else in SRE. PREREQUISITES. A ledger with at least a month of data identifying the top entry. IMPLEMENTATION. Pick the highest-frequency automatable entry, build the smallest automation that removes the human step (script, job, or self-service), measure the hours returned against the ledger, and add the automation's own operation to the ledger so it is honestly accounted. TOOLS. Whatever the toil demands — a script, a scheduled job, a form. COMMON FAILURE MODES. Automating a process that should simply stop existing — ask whether the step is needed before writing code to do it faster. EXPECTED IMPACT. Engineering hours visibly return to engineering, and the team sees the ledger pays. EVIDENCE. Before/after ledger months and the automation itself checked into the repo.

    Validation — before you call it done

    The next monthly ledger shows the automated entry at or near zero hours and the total toil percentage down at least 5 points from the pre-automation month.

  3. Extend SLO coverage to the next services, one at a time

    P2LRequires: Exercise the freeze once, on purpose, Automate the top toil source

    SRE

    Full step — what, why, how, failure modes
    WHAT. Repeat the pilot arc — SLI, SLO, policy attachment, burn alerts — for the next tier-1 service each quarter, reusing the first service's artifacts as templates. WHY. Coverage is how the discipline compounds: each service gets cheaper because the queries, policy, and alert patterns already exist; done one-per-quarter it never becomes a project. PREREQUISITES. The pilot's full loop (SLO through exercised freeze) working as the template. IMPLEMENTATION. Rank remaining services by outage impact, take the next one, copy the SLI/SLO/policy/alert pattern onto its telemetry (adjust thresholds to its reality), and add it to the monthly SLO review. Cap the rate at one per quarter per team. TOOLS. The pilot's artifacts as templates; the SLO review meeting. COMMON FAILURE MODES. Declaring coverage by copying dashboards without the policy — half-adopted SRE is exactly the dashboard-not-contract anti-pattern. EXPECTED IMPACT. Reliability as a contractual practice becomes the estate's default, service by service. EVIDENCE. The quarterly coverage numbers and each new service's one-page SLO doc.

    Validation — before you call it done

    SLO coverage — the share of tier-1 services with a measured SLO and attached policy — rises quarter over quarter, documented in the review, without any service getting an SLO without its policy attached.

Sources

Start from where YOU are

This roadmap is the general path. An assessment tells you which steps you can skip and which are critical — then generates a version of this plan from your actual findings, tracked to done in your workspace.

Assess where you standBrowse the roadmap library