SRE, Other Frameworks & the Future
Module 8 closes the SRE Foundation syllabus by turning the camera outward. Every earlier module treated SRE as a fixed, self-contained system of mechanisms — SLOs, toil, monitoring, tools, antifragility, org design. This one asks how that system sits next to the neighboring frameworks a real organization is probably already running — ITIL's service-management vocabulary, Agile's delivery cadence, and DORA's four empirically validated delivery metrics — and then asks where the whole practice is actually headed, as platform engineering quietly absorbs plumbing an SRE team used to build by hand and AIOps starts creeping up the automation ladder Module 5 mapped out. This is also the natural place in the course to meet DORA's four key metrics properly for the first time, because the fifth metric DORA added to its own framework in 2021 turns out to be this course's Module 2, wearing a different name.
Imagine four different coaches training the same swim team, each caring about something different. One coach (ITIL) cares that every practice follows the official checklist — sign in, warm up, log the lap times, file the report. Another coach (Agile) cares about how fast a new drill goes from "someone's idea on Monday" to "the whole team trying it on Friday." A third coach (DORA) doesn't care about your checklist or your drill cadence at all — she just times four specific things with a stopwatch: how often you race, how fast a new stroke change reaches an actual race, how often a race goes wrong, and how fast you recover when it does — and across thousands of teams she's found the fastest swimmers are also the ones who recover fastest, not the careful ones who race rarely. SRE is the fourth coach, and this whole course has been her workout plan: a specific numeric target (the SLO), a specific budget for how much can go wrong before the team stops and fixes something instead of racing anyway (the error budget), and a specific habit of learning from every stumble instead of blaming the swimmer (the postmortem). None of the four coaches is wrong. They're measuring different things — and the team that wins is the one whose coaches aren't fighting each other.
Where this module sits, and what the exam actually tests
☺ Like you're 10: This is the last topic on the test, and it's the one about not mixing up SRE with its neighbors, plus knowing four specific numbers that a completely different research team came up with.
The SRE Foundation (SREF) from the DevOps Institute is a closed-book, 40-question, 60-minute multiple-choice exam with a 65% pass mark, organized around eight syllabus modules. This page covers the eighth and final one: SRE, Other Frameworks and the Future, sitting after Organizational Impact of SRE (Module 7). Unlike some domain-weighted certifications that publish an exact percentage per section, the DevOps Institute doesn't break its 40 questions down by module — treat the table below as your syllabus outline, not a scored weighting, and confirm the current specifics against the accreditor's own courseware before you sit the exam.
| # | Module | What it covers |
|---|---|---|
| 1 | SRE Principles & Practices | Where SRE came from, and how it relates to DevOps |
| 2 | Service Level Objectives & Error Budgets | Setting a target for an SLI and spending the budget it creates |
| 3 | Reducing Toil | Identifying and automating away repetitive manual work |
| 4 | Monitoring & Service Level Indicators | Deriving a trustworthy SLI from raw telemetry |
| 5 | SRE Tools & Automation | The operational toolchain that implements Modules 2–4 |
| 6 | Anti-Fragility & Learning from Failure | Chaos engineering and blameless postmortems |
| 7 | Organizational Impact of SRE | Team topologies, on-call, and adoption |
| 8 | SRE, Other Frameworks & the Future ← this page | ITIL, Agile, DORA's four key metrics, and where SRE is heading |
SRE and DevOps, restated precisely for the exam
☺ Like you're 10: Quick refresher, because the exam still expects you to get this exactly right: DevOps is the philosophy, SRE is one specific, opinionated way to run it.
What is SRE? already covers this relationship in full, including the "class SRE implements interface DevOps" framing and the nested-circle diagram Professor Owl opened the course with — this page assumes you have that content and only restates the one line the exam tends to test directly: DevOps is a set of cultural principles (commonly summarized as CALMS — Culture, Automation, Lean, Measurement, Sharing) with no mandated mechanism for achieving them; SRE is one concrete, prescriptive implementation of those principles, with specific mechanisms DevOps as a philosophy never requires — SLOs and error budgets, a formal error-budget policy that halts launches, blameless postmortems with tracked action items, and an explicit ceiling on how much operational work a team can absorb before it counts as a staffing failure. If a stem asks you to name a concrete SRE mechanism that DevOps doesn't mandate, any one of those four is a correct answer; if a stem asks you to name something DevOps requires that SRE doesn't, the honest answer is that DevOps, being a philosophy rather than a specification, doesn't mandate anything concrete at all — that asymmetry is the entire relationship in one sentence.
SRE and ITIL: two frameworks over the same territory, from opposite directions
☺ Like you're 10: ITIL and SRE both have words for "something broke" and "we promised a target" — they just built those words for completely different starting reasons, and neither one contains the other.
ITIL (originally the Information Technology Infrastructure Library) is a much older, much broader framework for IT service management, first developed by the UK government's Central Computer and Telecommunications Agency in the late 1980s and now stewarded by Axelos/PeopleCert. ITIL 4, released in 2019, is the version worth knowing for this exam — it explicitly rebuilt the framework around a "four dimensions" model and reframed its old rigid "processes" as more flexible "practices," largely in direct response to the criticism that ITIL v3 (2007, refreshed 2011) was too document-heavy and change-advisory-board-driven for cloud-native, continuously-deployed software. That history matters for the exam's favorite framing: ITIL 4 was deliberately redesigned to absorb Agile and DevOps thinking, so "ITIL is the old, slow framework SRE replaced" is an outdated caricature of ITIL v3, not an accurate read of ITIL 4.
The deeper reason SRE and ITIL aren't a strict subset of each other is scope. ITIL is a general-purpose IT-service-management framework spanning territory SRE never touches at all — supplier management, workforce and talent management, financial management for IT, portfolio management. SRE stays narrowly scoped to one thing: the reliability of the services a team runs. Where the two frameworks genuinely overlap — incident response, root-causing failures, and holding a target for service quality — they solve the same problem with different machinery, which is exactly what the table below is testing you on.
| ITIL 4 practice | Nearest SRE mechanism | The real difference |
|---|---|---|
| Incident Management | Incident management & on-call | ITIL defines roles and a priority matrix scored mostly by business impact; SRE additionally ties severity to a specific automated trigger — multi-window, multi-burn-rate error-budget consumption — rather than judgment alone. |
| Problem Management | Blameless postmortems | ITIL's problem management is process-driven, built around a Known Error Database; SRE's postmortem is blameless by design and produces tracked, owned engineering action items reviewed by the same team that ran the incident — not a separate problem-management function. |
| Service Level Management | SLIs, SLOs & error budgets | ITIL's SLAs are typically negotiated documents reviewed on a calendar cadence (quarterly, annually); SRE's SLOs are continuously measured against live telemetry and enforced through an automated error-budget policy the moment the budget hits zero, not at the next scheduled review. |
| Change Enablement | Progressive delivery & error-budget gating | ITIL traditionally routes risky changes through a human Change Advisory Board vote; SRE tends to replace that vote with automated policy — an exhausted error budget blocks new releases — plus progressive delivery (canaries, feature flags) that shrinks blast radius instead of asking a committee to predict risk in advance. |
| Continual Improvement | Toil reduction & measuring reliability | ITIL frames improvement generically, org-wide, tracked in a Continual Improvement Register; SRE operationalizes the same instinct narrowly and numerically — an explicit toil ceiling (roughly 50%) and a quantified SLO trend, not a general-purpose register entry. |
The sharpest single gap between the two frameworks: ITIL's service-level management defines a target and reports against it. Nothing in the ITIL practice itself mandates an automatic, pre-agreed consequence the moment that target is missed. SRE's error-budget policy is precisely that missing enforcement mechanism — the target exists in both frameworks; the "and here's exactly what happens when you blow it" clause is SRE's own invention.
If you're pursuing both credentials, ITIL 4 Foundation and the SRE Foundation covered on this course's own certifications page are complementary rather than redundant — ITIL 4 Foundation proves you understand the broader IT-service-management vocabulary an SRE team has to speak to the rest of the organization; the SRE Foundation proves you understand the specific reliability mechanisms this course teaches.
SRE and Agile: the same delivery system, a different axis
☺ Like you're 10: Agile is about how fast a new idea becomes real code; SRE is about how carefully that code gets allowed to run once it's live — they're two different questions, not two competing answers to the same one.
Agile, formalized by the 2001 Agile Manifesto, is a set of values and principles for iterative software delivery — short cycles, working software over comprehensive documentation, responding to change over following a fixed plan — usually implemented through Scrum or Kanban. Notice what Agile doesn't say anything about: how reliably the software behaves once it's shipped. That's not a gap in Agile; it's simply outside its scope, and it's exactly the gap SRE fills. A team can run textbook Agile — two-week sprints, a groomed backlog, a daily standup — and still have no SLO, no error budget, and no postmortem discipline at all. SRE doesn't compete with Agile or replace it; it's compatible with Agile, with Kanban, or in principle with a shop that isn't doing either — SRE governs the operate side of the system regardless of how the build side is organized.
The exam's favorite trap here is a single, precise confusion: a sprint retrospective is not a blameless postmortem, even though both are meetings where a team reflects on what happened. A retrospective is cadence-triggered — it happens every sprint regardless of whether anything went wrong — and covers whatever the team wants to raise, with no formal root-cause requirement. A postmortem is incident-triggered — it happens because a specific event crossed a defined severity or impact threshold — and mandates a structured root-cause method (often five-whys, covered with a worked example in the course's case study) plus tracked, owned action items with deadlines. Treating the two as interchangeable is exactly the kind of stem this module likes to write.
DORA and the four key metrics
☺ Like you're 10: Four numbers, discovered by asking thousands of real engineering teams the same questions for years, that turned out to predict whether an organization is actually good at software — and a fifth number, added later, that's basically this course's SLO in disguise.
DORA — DevOps Research and Assessment — began as the research program behind the annual State of DevOps Report, led by Dr. Nicole Forsgren together with Jez Humble and Gene Kim. Their multi-year survey research, distilled into the 2018 book Accelerate: The Science of Lean Software and DevOps, used statistical factor analysis across thousands of responses to find a small set of metrics that reliably predicted organizational outcomes — profitability, market share, productivity — independent of company size, industry, or whether the software was legacy or greenfield. Google acquired DORA in 2018 and continues to publish the research as the Accelerate State of DevOps Report under Google Cloud, at dora.dev. The headline finding, and the one worth remembering for the exam: speed and stability are not actually a tradeoff. Elite performers in DORA's research ship more often and break production less often than low performers — the old assumption that going faster necessarily means breaking more things turned out to be false at scale.
The research settled on four metrics, split evenly across two dimensions:
| Metric | Dimension | What it measures | Elite performer, roughly |
|---|---|---|---|
| Deployment Frequency | Throughput | How often the organization successfully releases to production | On demand, multiple times a day |
| Lead Time for Changes | Throughput | Time from a commit merging to that code running in production | Under one hour |
| Change Failure Rate | Stability | Percentage of deployments to production that cause a degradation or require remediation | Roughly 0–15% |
| Time to Restore Service | Stability | How long it takes to restore service after a production failure (often shorthanded MTTR) | Under one hour |
Treat the "elite performer" figures as illustrative of the shape of the finding — an order-of-magnitude gap between elite and low performers on every one of the four metrics — rather than numbers to memorize digit-for-digit. The exact bands have shifted somewhat report to report since the original 2018 benchmarks, and DORA has revised its own tier definitions more than once; verify the current year's figures at dora.dev before quoting a specific percentage as current.
Google also open-sourced a reference implementation for computing these automatically from CI/CD and incident data, known as the Four Keys project — worth recognizing by name if the exam mentions it, though check its current maintenance status before recommending it to a team, since tooling in this space moves quickly.
In its 2021 report, DORA added a fifth metric: Reliability — whether a team meets its own user-defined operational targets, evaluated through practices like SLOs and observability rather than a fixed numeric band. That's not a coincidence worth glossing over: DORA's own research concluded that throughput and stability alone were an incomplete predictor of whether software actually delivers value to users, and the missing piece they identified is measured, in practice, with the exact mechanism Module 2 spent this whole course building — an SLI, an SLO, and the budget it creates. Two independent research traditions, one starting from delivery-performance statistics and one starting from Google's own operations practice, converged on the same answer.
The exam's favorite DORA trap: treating Change Failure Rate as the same thing as an SLO miss or an error-budget spend. It isn't. CFR counts only production failures directly attributed to a deployment — it says nothing about an outage caused by a traffic spike, a bad dependency, a cloud provider incident, or a config change that wasn't a code deploy at all. An error budget is cause-agnostic: every minute of unreliability counts against it, deploy-caused or not. A service can have a low, healthy Change Failure Rate and still be burning its entire error budget on causes CFR was never designed to see.
Common exam traps for this module
☺ Like you're 10: Five specific wrong answers account for most of the points lost on this module — here they are, named directly.
- "SRE is a subset of ITIL, or ITIL is a subset of SRE." Wrong — neither contains the other. ITIL spans territory SRE never touches (supplier management, IT financial management); SRE brings mechanisms ITIL never mandates (an error budget with an automated enforcement policy). They overlap on incident, problem, and service-level management without nesting.
- "ITIL is the old waterfall framework SRE replaced." Wrong for ITIL 4 specifically — the 2019 revision deliberately absorbed Agile and DevOps thinking. That criticism describes ITIL v3, not the current version.
- "A sprint retrospective is the same thing as a blameless postmortem." Wrong — a retrospective is cadence-triggered and general-purpose; a postmortem is incident-triggered, requires formal root-cause analysis, and produces tracked action items.
- "DORA's Change Failure Rate is the same as an SLO miss or an error-budget spend." Wrong — CFR only counts deploy-attributed failures; an error budget is cause-agnostic and counts every source of unreliability.
- "DORA's four key metrics are an SRE framework." Wrong — DORA measures software delivery performance broadly, correlated with business outcomes; it doesn't prescribe SRE's specific mechanisms (SLOs, error budgets, blameless postmortems, a toil ceiling) at all, even though the two research traditions converge on the reliability metric.
Where the practice is heading
☺ Like you're 10: Two trends are reshaping what an SRE actually spends their week doing — a platform team is absorbing the plumbing, and software is starting to help with the judgment calls, not just the typing.
Platform engineering absorbs the plumbing
A growing share of what an SRE team used to build bespoke, per-service, is being pulled into a shared internal developer platform (IDP) instead. Rather than an SRE manually wiring up dashboards, alert rules, and an on-call rotation for every new service, a platform team's golden path — a self-service template, often built on a catalog like Backstage (open-sourced by Spotify in 2020, now a CNCF graduated project) — can auto-provision an SLO template, a default dashboard, and a standard alerting policy the moment a new service is scaffolded. The reliability defaults get baked into the paved road itself, rather than negotiated by an SRE with every product team from scratch. Platform Engineering's own foundations module covers this shift from the platform-builder's side — why golden paths exist and what an IDP actually is — and Platform as a Product & Golden Paths covers the self-service mechanics in depth if you want the architecture behind what this paragraph only summarizes.
This doesn't eliminate SRE's role — it relocates part of it. The judgment-heavy work an SRE does — deciding what SLO target the business can actually live with, running the blameless postmortem culture, deciding when to freeze launches — stays distinctly human and doesn't template well. What's disappearing is the repetitive, per-service setup toil: exactly the kind of work Module 3 already taught you to recognize and automate away. Platform engineering is, in a real sense, industrializing that automation at the organization level instead of leaving each SRE to reinvent it per team.
AIOps and the next rung of the automation ladder
AIOps — a term Gartner coined around 2016 — applies machine learning to IT operations data. The mature, widely-deployed capabilities sit on rungs 1–3 of the automation maturity ladder from Module 5: anomaly detection that flags a deviation before a static threshold would ever fire, alert correlation that groups a storm of related pages into one incident instead of forty, and causal-analysis assistance that surfaces "this anomaly started right after that deploy" faster than a human scanning dashboards would. Newer, LLM-based capabilities are pushing further — drafting an incident timeline from Slack, PagerDuty, and Git history automatically, or answering an on-call engineer's plain-language question about a trace. Specific product names and feature sets in this space update quickly, so treat any vendor example as illustrative of the category rather than a current feature comparison.
Marketing in this space regularly implies rung 4 — fully autonomous remediation with no human in the loop — for judgment-heavy incident response. In practice, most production AIOps deployments still sit at rung 2 or 3: automating the mechanical steps, or proposing a fix behind a human approval gate. Full autonomy remains reserved almost entirely for low-blast-radius, already-well-understood actions — a kubelet restarting a failed liveness probe, an autoscaler adding a node — the same rung-4 examples Module 5 already gave you, not a machine independently deciding to roll back a customer-facing release at 3am. Read a "self-healing" or "autonomous AIOps" claim on an exam stem the same way you'd read an unreviewed automation script in production: verify what actually executes without a human before you believe the claim.
The through-line across both trends is worth stating plainly: neither one removes the need for the mechanisms this course teaches — it relocates where they get implemented. An SLO still has to be chosen by a human who understands the business tradeoff, whether it ends up enforced by a hand-rolled alert or a platform's golden-path template. A postmortem still needs a blameless culture to produce a durable fix, whether an AI drafted the incident timeline or an engineer typed it by hand. Best Practices & the SRE Operating Model covers what a mature operating model looks like once these shifts are already underway, and Reliability Economics covers the cost side of deciding how much of this automation is actually worth buying versus building.
Take one real practice your own team already runs — a change-approval step, a weekly ops review, an on-call rotation, whatever comes to mind first. Write one sentence sorting it: is it closer to an ITIL practice (a documented process with a human decision gate), a DORA metric (something you'd measure with a stopwatch across many events), or an SRE mechanism (a target with an automated, pre-agreed consequence)? Most real practices are blends, but naming the dominant flavor is exactly the skill this module tests. For guided reps in the exact multiple-choice style the real exam uses, see SREF Practice Questions.
Nutty the Squirrel: Found a new term for the drawer — "Continual Improvement Register." Is that just our toil backlog wearing a badge?
Professor Owl: Close cousin, not the same drawer. Theirs is a general-purpose register for any improvement, anywhere in IT. Ours is narrower and numeric — a 50% toil ceiling and an SLO trend line.
Foxy: Speaking of numeric — our Change Failure Rate looked great this quarter. Does that mean the error budget's fine too?
Professor Owl: Not necessarily. CFR only sees failures your own deploys caused. Check what actually ate the budget before you celebrate.
Benny the Beaver: The new platform team's golden path already stamps out an SLO dashboard the moment anyone scaffolds a service now. Half my setup toil from last year just... isn't mine to do anymore.
Timmy the Turtle: Good — as long as a human still picks the target on that dashboard. Has the new AIOps tool actually rolled anything back on its own yet, or just suggested it?
Benny the Beaver: Suggested. Still waits for a thumbs-up in Slack.
Timmy the Turtle: Then it's rung three, not rung four — and that's exactly where it should stay until it's earned rung four the same way everything else in this course earns trust: by proving it, repeatedly, in the open.
That's the full eight-module map. You've now got the mechanisms (Modules 1–6), the organizational context they run inside (Module 7), and where they sit relative to everything else your organization is probably already doing (this page). What's left is converting the map into exam readiness: The SREF Exam covers the day-of logistics, The SREF Study Plan sequences your remaining study time across all eight modules, and SREF Practice Questions is the full bank to drill against before you book a seat.
1. In one sentence, why is neither "SRE is a subset of ITIL" nor "ITIL is a subset of SRE" correct? 2. Name DORA's four key metrics and say which two are "throughput" and which two are "stability." 3. What metric did DORA add to its framework in 2021, and which SRE mechanism does it lean on to actually be measured? 4. Give one concrete way platform engineering is absorbing work that used to sit entirely with an SRE team, and one thing that doesn't get automated away in the process. 5. What's the difference between AIOps automating a mechanical step (rung 2 of the automation ladder) and AIOps performing genuine autonomous remediation (rung 4) — and why does this page treat "autonomous AIOps" marketing claims skeptically?
Check your answers
- Neither framework contains the other because their scopes only partially overlap. ITIL spans IT-service-management territory SRE never touches (supplier management, IT financial management); SRE brings mechanisms ITIL never mandates (an error budget enforced by an automated policy). They share real overlap in incident, problem, and service-level management, but overlap isn't containment.
- Throughput: Deployment Frequency (how often you ship to production) and Lead Time for Changes (commit to production, elapsed time). Stability: Change Failure Rate (% of deploys that break production) and Time to Restore Service (how fast you recover once one does).
- Reliability — whether a team meets its own user-defined operational targets. It's measured in practice through SLOs and observability, which is this course's own Module 2 mechanism (SLIs, SLOs, and error budgets) under a different name.
- Any of: a platform team's golden path (often built on Backstage or a similar catalog) auto-provisioning an SLO template, a default dashboard, and a standard alerting policy the moment a new service is scaffolded — eliminating the per-service setup toil an SRE used to build by hand. What doesn't get automated away: the judgment call of what SLO target the business can actually live with, and the blameless-postmortem culture that turns a discovered weakness into a durable, tracked fix.
- Automating a mechanical step (rung 2) still leaves a human deciding when to run the automation — it just compiles many manual steps into one action. Autonomous remediation (rung 4) means the system detects, decides, and executes with no human in the loop at all, notifying only after the fact. This page treats "autonomous AIOps" claims skeptically because most real deployments for judgment-heavy incident response still sit at rung 2 or 3 (proposing a fix behind a human approval gate), while true rung-4 autonomy remains reserved for low-blast-radius, already-well-understood actions — not a system independently rolling back a customer-facing release.