Moving from Ops into Site Reliability Engineering: SLOs, Error Budgets and Incidents

Picture 03:12 on a Tuesday. Your phone buzzes with a page: CPU on a database host is at 91 percent. You log in, restart a service, watch the graph settle and go back to bed. At 09:00 support tells you that checkout was failing for forty minutes, for about one customer in twenty, and that the alert you answered had nothing to do with it.

That gap between the alert you got and the pain customers felt is what site reliability engineering sets out to close. Moving from ops into SRE means measuring reliability from the user's side, spending a risk allowance on purpose, and treating an incident as something with a plan. DevOps Institute's practitioner-level credential for it is 40 multiple-choice questions in 90 minutes, with 65% to pass.

This article follows the move step by step. It starts with what changes in the job, then goes through service level objectives, the eight modules DevOps Institute teaches at practitioner level, the exam facts, how to study around on-call weeks and what the credential does for a career. The credential comes from DevOps Institute, which has since joined the PeopleCert group, and PeopleCert now sells the exam voucher. For this article I read the vendor's exam page, blueprint and course description alongside PeopleCert's listing in October 2026. Both pages still offer the paper, the pass mark and format below agree between them, and no newer edition is announced.

What actually changes when an ops engineer becomes a site reliability engineer?

The tools can stay the same. What changes is the question you start from. An ops engineer is usually rewarded for keeping systems up and answering alerts quickly. A site reliability engineer starts from what users experience and treats reliability as a feature with a target, a cost and an owner. DevOps Institute's blueprint opens with a blunt line for people making this move: SRE is not a rebranding of Ops.

The same blueprint lists a handful of anti-patterns that show whether a team is doing SRE or only using the title:

• Alert for user issues, not system issues. A host at 91 percent CPU is a system symptom. Customers failing at checkout is a user symptom. Pages should be about the second kind.
• False positives are worse than no alerts. An engineer who is woken for noise learns to ignore the pager, and the one real page gets the same shrug.
• Change by replacement, not updating. Instead of patching long-lived servers by hand, you replace them with a known-good version, which makes failures repeatable and rollbacks boring.
• Incidents have plans, not mob reactions. Roles, communication and escalation are agreed before the night someone needs them.
• SLOs are for perceiving user experience. They are a measurement of customer happiness, not a number to show the board.

Another idea the field leans on is toil: repetitive manual work that grows as a service grows and teaches you nothing. The blueprint puts the same principle in its own words, saying that SREs code infrastructure and tools and that workload is capped. A ceiling on interrupt-driven work is what leaves time for engineering, and engineering is how the next page gets prevented.

Question	Classic ops answer	SRE answer
What do we alert on?	Hosts, disks, CPU, memory	What users feel: errors and slowness against an objective
How reliable should we be?	As reliable as possible	As reliable as the service level objective says, and no more
What happens when something breaks?	Whoever is awake fixes it	A rehearsed plan with named responsibilities, then a review
How do we cope with repetitive work?	Absorb it and hire more people	Cap it and automate it away
How do we learn about weaknesses?	From outages	From controlled experiments before outages

How does a service level objective turn a customer complaint into an engineering decision?

A service level indicator (SLI) is a measurement of something users care about, such as the share of checkout requests that succeed or the share served in under 300 milliseconds. A service level objective (SLO) is the target for that measurement over a period, for example 99.9 percent of checkout requests succeeding over 30 days. The gap between 100 percent and the target is the error budget: the amount of unreliability you are allowed to spend.

The arithmetic is simple and worth doing by hand once. A 99.9 percent objective over 30 days allows 0.1 percent failure. A 30-day month has 43,200 minutes, so the budget is 43.2 minutes of full outage, or a longer stretch in which only some requests fail. In the opening story, forty minutes of failure for one customer in twenty uses roughly two minutes of that budget, because only five percent of requests were affected. That conversion, from a messy incident to a number of budget minutes, is what lets an engineer say something precise to a product manager instead of "it was bad".

The budget turns an argument into a decision. If the service has plenty of budget left, the team can ship faster, run riskier experiments and accept some noise. If the budget is nearly gone, new releases wait while reliability work takes priority. Nobody has to win a debate between developers who want speed and operators who want stability, because both are working to the same written rule.

DevOps Institute's blueprint adds a method for setting objectives in a large system. You identify system boundaries, define the capabilities of each system, define an indicator for each capability, set SLO targets and then measure a baseline before promising anything. The order matters. Teams that pick a target first and measure later end up with a number nobody believes, and the first breach becomes a quarrel about whether the measurement is right.

Three mistakes to avoid when you write your first objective

• Targeting 100 percent. Nothing users depend on, from their own devices to their networks, is 100 percent reliable, so a perfect target leaves no budget and no room to change anything.
• Measuring the server instead of the user. A healthy load balancer can sit in front of a broken checkout. Measure at the point where the user's request succeeds or fails.
• Setting one objective for everything. A payment path and an internal report generator do not need the same target, and treating them alike wastes effort on one and under-protects the other.

What do the eight practitioner modules add beyond the basics?

The foundation level in this credential family teaches the vocabulary: indicators, objectives, error budgets, toil and blameless reviews. The practitioner level, according to DevOps Institute's course description, is aimed at people focused on large-scale service scalability and reliability, and it uses real-life scenarios and case stories. The course has eight modules, and the exam draws on all of them.

Module 1, SRE anti-patterns. This module teaches you to spot what SRE is not: a renamed operations team, a ticket queue with a new logo, or a group that carries a pager for systems it had no say in designing. Exam questions here often describe a team and ask which behaviour is out of line with SRE practice.

Module 2, SLOs as a proxy for customer happiness. This is the objective-setting method above, extended into distributed systems, where one user action touches many services. You learn to use error budgets beyond the obvious, as a way to decide when to take risks and to innovate, not only to stop releases.

Module 3, building secure and reliable systems. The blueprint names a long list: intentional architecture, designing for a changing landscape, designing for changing security, multi-grained services, container management, Kubernetes, reactive systems, and deployment strategies such as canary and blue-green releases. The course description adds zero-trust environments. A candidate who has run production but never drawn an architecture should give this module extra days.

Module 4, full-stack observability. Observability gives high-level overviews of system health and detailed insight into failure modes. The course covers distributed tracing and an observability-driven development culture, where engineers add instrumentation while they write code instead of after the first outage. A monitoring dashboard tells you that something is wrong; observability lets you ask why without shipping new code.

Module 5, platform engineering and AIOps. Platform engineering applies product thinking to internal tooling so that teams get consistency and predictability. The blueprint says platform SRE solves organisational scalability challenges by applying product management to a unified SRE and DevOps culture. AIOps combines big data and machine learning to automate operations, including event correlation, anomaly detection and causality determination. The course description also touches DataOps and clean data lineage.

Module 6, SRE and incident response management. This covers major incident response responsibilities based on an incident command framework, plus the anatomy of unmanaged incidents. The course also covers moving from reactive to proactive and predictive incident management by curating data with AI.

Module 7, chaos engineering. The blueprint defines it as the discipline of experimenting on a distributed system to build confidence in its ability to withstand turbulent conditions. In practice, you form a hypothesis about steady-state behaviour, introduce a controlled fault, and see whether the system holds.

Module 8, SRE as the purest form of DevOps. The closing module argues that SREs write code for infrastructure, set SLOs and alerts, report against indicators such as availability, use tracing and application performance tools, and take part in on-call and postmortems. It also covers the SRE execution model and why reliability is everyone's problem, not one team's.

What are the exam facts: format, fee, languages and renewal?

Here is the format as DevOps Institute and PeopleCert publish it, followed by the fee.

Item	Detail
Certification	DevOps Institute Certified Site Reliability Engineering Practitioner
Questions	40 multiple choice
Duration	90 minutes
Passing score	65%
Open book	Yes
Delivery	Web-based
Languages	English, Brazilian Portuguese, Japanese
Fee	USD 257
Validity	3 years, then renewal
Recommended before it	SRE Foundation and related work experience

On the fee: the exam costs USD $257 (October 2026). PeopleCert, which now sells it, may show the amount in your local currency at checkout. DevOps Institute's page sends you to PeopleCert's platform to buy, and certifications need to be renewed every three years from the original certification date, through continuing professional development or recertification.

Two practical points deserve attention. First, the paper is open book, but with 40 questions in 90 minutes you have about two minutes and fifteen seconds per question, which is enough to look up a definition and not enough to learn a topic. Second, the vendor's course description says it is highly recommended to hold the SRE Foundation certificate first, together with working knowledge of SRE terminology, concepts and principles. It is a recommendation, and the page does not present it as a rule, but candidates who skip the foundation vocabulary tend to lose time on the first modules.

The topics the paper can draw on are the eight modules above. For a topic-by-topic outline of what the paper covers, see the SRE Practitioner syllabus. For the vendor's own wording, DevOps Institute publishes an exam page and a one-page blueprint, and PeopleCert lists the same paper on its SRE Practitioner page.

How does a well-run major incident unfold, and where does chaos engineering fit?

Go back to the 03:12 page. In a team that practises SRE, the real alert would have come from the user-facing objective: the checkout success rate falling fast enough to threaten the monthly budget. The person on call would acknowledge it, and the first decision would be about roles, not about commands. Someone takes charge of coordination. Someone investigates. Someone keeps stakeholders informed so that the investigators are not interrupted. That split of responsibilities is the heart of an incident command framework, and exam questions about it test whether you can tell who should be doing what.

The investigation itself is quicker when the system is observable. With distributed traces you can follow a failing checkout request across services and find the one that adds latency or throws errors. Without them, you end up guessing. The first goal is to restore service, not to find the root cause: roll back the last change, shift traffic, shed load. Diagnosis can wait until users are no longer hurting.

After service is restored, the team writes a review that looks at how the system and the process let the failure through, not at who made a mistake. The output is a short list of actions with owners, and some of those actions often become engineering work that cuts future toil. That loop, from page to review to fix, is what DevOps Institute means when it describes incidents as having plans instead of mob reactions.

Chaos engineering moves part of that learning ahead of time. Instead of waiting for a node to die at 03:12, you kill one on a Wednesday afternoon, with a hypothesis ("checkout error rate stays within objective") and a way to stop the experiment. If the hypothesis fails, you have found a weakness cheaply. If it holds, your confidence in the design is earned instead of assumed. Typical scenario questions describe a team, an experiment and a result, then ask what the next sensible step is. Watch for answers that skip the hypothesis or run the experiment without a stop condition; those usually signal the wrong choice.

In what order should you study the modules around on-call weeks?

An on-call rota breaks every study plan, so build one that survives a bad week. Five weeks with four or five short sessions each is realistic, and the schedule below follows the vendor's module order, so each stage feeds the next.

Week 1, anti-patterns and objectives. Read the blueprint twice, then write indicators and an objective for a service you run. Work out its error budget in minutes. If you cannot, repeat the exercise on a second service.

Week 2, secure and reliable design. Draw one architecture you know on a single page and mark where a canary or blue-green release would reduce risk and where a failure would spread. Keep the terms from module 3 in a short glossary.

Week 3, observability. List the questions you could not answer during your last outage with the data you had. That list shows you what observability would add. Learn the difference between logs, metrics and traces in your own words.

Week 4, platform engineering and AIOps. This is the most conceptual week, so read slowly. Make sure you can explain, in two sentences each, what platform SRE does and what event correlation, anomaly detection and causality determination mean.

Week 5, incidents, chaos and the whole picture. Walk through a past incident using the roles and review steps described earlier. Then check your recall of all eight modules. Once the modules feel familiar, the SRE Practitioner practice exam is a good way to see whether scenario wording catches you out before the real paper does.

A few habits help throughout. Keep a one-page cheat sheet of definitions, because open book is useful for confirming a term and useless for learning one. Read each question for the role it gives you, since a question that says you are the incident lead expects a different answer from one that puts you in the investigator's seat. And where two answers look right, prefer the one that matches SRE's own principles: user-focused measurement, a budget-based decision, a rehearsed plan, a blameless review.

Does the practitioner credential help an ops engineer who already carries the pager?

It helps most in one situation: when your daily work looks like SRE but nothing on paper says so. A certificate proves you can explain the language and the reasoning, which makes conversations with hiring managers and architects easier. It does not replace the experience of leading an incident or writing an objective that a product owner signs.

DevOps Institute lists the audience broadly. Beyond site reliability engineers, its page names DevOps practitioners, IT managers and directors, software engineers, product owners, Scrum masters, change agents and consultants. In its career pathways, the SRE Engineer and SRE Leader roles sit side by side, which suggests two routes from here: deepen the engineering, or move toward sponsoring and coaching SRE teams.

Pay for SRE roles varies widely by region and company size, so check current job adverts in your own market for the words "SLO", "error budget" and "observability" to see how much weight employers put on them.

Plan for the upkeep as well. Because the credential is valid for three years and must then be renewed, think of it as a record that you stay current, not a one-time prize. The practical return comes from the habits you build while studying: measuring from the user's side, spending an error budget deliberately and running incidents by a plan. Those habits make the next 03:12 page shorter, whatever the certificate says.

Frequently Asked Questions

Is the DevOps Institute SRE Practitioner exam still available?

Yes. As of October 2026 DevOps Institute still lists the exam on its certification page, and PeopleCert, which DevOps Institute now belongs to, sells the exam voucher. Neither page announces a newer edition, so the 40-question, 90-minute paper is the current one.

How many questions and how much time does the exam give?

The paper has 40 multiple-choice questions and runs 90 minutes, which works out at about two minutes and fifteen seconds per question. It is delivered on the web and is open book, and the vendor lists English, Brazilian Portuguese and Japanese as the available languages.

What score do you need to pass?

You need 65 percent. DevOps Institute and PeopleCert both state the 65 percent minimum. The exam is open book, but time is tight, so confirm definitions rather than learning them during the paper.

Do you need SRE Foundation before the practitioner exam?

DevOps Institute's course description says it is highly recommended to take the SRE Foundation course and earn that certificate first, together with working knowledge of SRE terms and principles. The page words it as a recommendation, not as a rule, so you can book the practitioner paper directly.

How long does the certification last and what does the exam cost?

The certification is valid for three years and must be renewed from the original certification date. The exam costs USD $257 (October 2026); PeopleCert, which now sells it, may show the amount in your local currency at checkout.

Select ratingPoorOkayGoodGreatAwesome

No votes yet