SRE in practice: reliability at scale

Picture this scenario: it is 3 am, your phone rings. The e-commerce site is down, 50,000 users can no longer place orders. The on-call engineer logs in in a hurry, applies an improvised fix, and everything restarts, until next time. Google lived through this vicious circle in the 2000s.

This lesson explains how to apply Site Reliability Engineering (SRE), the discipline born at Google in 2003, across a whole organisation. It is for DevOps teams, Ops and technical leads who already know the basics and want to move to practice: telling SRE and DevOps apart, structuring measurement with SLI/SLO/SLA, steering the error budget, eliminating toil and placing the SRE role relative to AI automation in 2026.

What you will learn

• Tell SRE and DevOps apart without opposing them
• Measure reliability with SLI, SLO and SLA indicators
• Steer your deployment decisions with the error budget
• Identify toil in your organisation and reduce it
• Structure a blameless post-mortem after an incident
• Place the SRE role relative to AI automation in 2026

What is SRE?

Site Reliability Engineering (SRE) is an approach to running production systems that combines a software developer's expertise with a system administrator's. Invented by Google in 2003, SRE treats operational problems as engineering problems to be solved with code and automation, rather than with repeated manual interventions.

Where the name comes from

Ben Treynor Sloss, VP Engineering at Google and founder of the discipline, sums up SRE like this: "SRE is what happens when you ask a software engineer to design an operations function." The core idea: apply software engineering principles (automation, tests, versions) to tasks of operations that were traditionally manual.

Simply put, think of SRE as a car mechanic who is also an engineer: they do not just repair breakdowns, they design systems so that they no longer happen. If you are just discovering these principles, the lesson Introduction to SRE traces the origin of the movement step by step; this lesson focuses on putting it into practice across an organisation.

SRE vs DevOps: what is the difference?

This question comes up often, and the answer is nuanced. DevOps and SRE share the same goal, improving collaboration between development and operations, but with different approaches.

Aspect	DevOps	SRE
Nature	Culture and philosophy	Role and concrete practices
Focus	Full application life cycle	Reliability and stability in production
Approach	General principles (automation, collaboration)	Prescriptive methods (SLOs, error budgets)
Team	Everyone adopts the culture	Dedicated specialised team
Key metric	Delivery velocity	Measurable reliability

Swipe to see more

A complementary relationship

Google describes the relationship like this: "SRE implements DevOps". Where DevOps says "automate the processes", SRE says "here is how to automate this precise process, with which metrics to validate the result".

In practice, you do not have to choose. Many organisations adopt the DevOps culture for every team, then create a dedicated SRE team for critical systems that need a high level of reliability. The lesson Agile, DevOps and SRE details how these three approaches complement each other in a mature organisation.

The fundamental principles of SRE

SRE rests on a few key principles that guide every decision, from choosing an availability objective to how you react to an incident.

1. 100% reliability does not exist (and that is fine)

Against intuition, SRE does not try to reach perfect availability. Why? Because:

• Going from 99.9% to 99.99% availability can cost an order of magnitude more in engineering resources
• Users do not perceive the difference beyond a certain threshold
• Over-reliability stifles innovation, nobody dares deploy for fear of breaking an already very strict objective

SRE looks for the right level of reliability: enough to satisfy users, without blocking the product's evolution.

2. Measure what matters with SLI, SLO and SLA

These three acronyms are at the heart of measurement in SRE. Let us take a concrete example to understand them:

1. SLI (Service Level Indicator): what you measure

   An SLI is a technical metric that reflects the user experience. For example:

   • Percentage of HTTP requests answered in under 200 ms
   • Percentage of successful requests (2xx code) out of the total
   • Home page load time

   Think of the SLI as the thermometer: it gives you an objective measurement.

2. SLO (Service Level Objective): what you aim for

   An SLO sets the performance objective for an SLI. For example:

   • "99.9% of requests must answer in under 200 ms"
   • "The monthly error rate must stay under 0.1%"

   The SLO is your thermostat: the temperature you want to maintain.

3. SLA (Service Level Agreement): what you promise

   An SLA is a contract with your customers, usually with penalties if it is not met. For example:

   • "If availability drops below 99.5%, pro-rata refund"

   The SLA is your guarantee: the formal commitment to your customers.

Practical advice

Set your SLOs slightly stricter than your SLAs. If your SLA guarantees 99.5% availability, aim for a 99.9% SLO. That leaves you some room to manoeuvre before reaching the penalty zone.

3. The error budget: reconciling reliability and innovation

The error budget is perhaps the most innovative SRE concept. The idea is simple but powerful:

If your SLO is 99.9% availability, then you accept 0.1% unavailability. That 0.1% is your error budget, a "right to fail" you can spend.

Why is it revolutionary?

Traditionally, Ops teams say "zero risk" and Dev teams want to "ship fast". The error budget resolves this conflict:

• As long as budget remains: developers can deploy, experiment, take calculated risks
• Budget exhausted: deployments stop and the team focuses on stabilisation

Budget available

SLO: 99.9% over 30 days
Monthly budget: 0.1% x 43,200 min = 43.2 minutes of allowed unavailability

Used this month: 15 minutes
Remaining: 28.2 minutes

-> Green light for deployments and experiments

Budget exhausted

SLO: 99.9% over 30 days
Monthly budget: 43.2 minutes

Used this month: 50 minutes (overrun)

-> Freeze on non-critical deployments
-> Focus on technical debt and stabilisation

In 2026, this logic goes beyond classic web services. Organisations deploying AI agents in production are starting to apply the same principle to them: an error budget computed on the completion rate, accuracy or hallucination rate, rather than on plain HTTP availability. It is a logical extension of the error budget, not a new discipline.

4. Eliminate toil (work without value)

Toil means repetitive, manual operational work with no lasting added value. It is SRE's number one enemy.

The characteristics of toil:

Characteristic	Example
Manual	Restarting a service by hand after each incident
Repetitive	Creating the same tickets every week
Automatable	Manually checking expiring certificates
No lasting value	The action does not improve the system, it only maintains it
Linear growth	More customers = more manual work

Swipe to see more

The 50% rule, and the 2026 reality

Google sets a limit: SREs must not spend more than 50% of their time on operational work (toil + on-call). Internally, Google's quarterly surveys show an average close to 33%, well under that ceiling. Catchpoint's SRE Report 2026, which surveyed 418 practitioners worldwide, confirms the trend across the industry: median toil reaches 34% of working time, a figure that stayed stable despite the massive arrival of AI tools. 60% of directors believe AI has reduced their teams' toil, against 38% of individual contributors: the perception gap between management and the field remains wide.

The goal is not to automate everything (that would be counter-productive for rare tasks), but to identify and remove the toil that grows with the system.

5. The blameless post-mortem culture

When a major incident happens, the natural reaction is to look for "who made the mistake". SRE takes a radically different approach: the blameless post-mortem.

Why blameless?

• Humans make mistakes, it is the system that should have prevented them
• Fear of sanctions pushes people to hide problems
• Understanding "how" is more useful than knowing "who"

Structure of an effective post-mortem:

1. Factual timeline

   What happened, minute by minute? No interpretation, no judgement.

2. Measured impact

   How many users affected? What duration? What business cost?

3. Root cause

   Why did the incident happen? Use the "5 whys" method.

4. Corrective actions

   Which concrete improvements, with owners and deadlines?

5. Learnings

   What do we know now that we did not know before?

Setting up SRE in your organisation

Adopting SRE does not necessarily require a dedicated team. You can start by adopting its principles gradually, without waiting to have Google's size or means. If your platform runs on Kubernetes, the guide SRE and Kubernetes operations (in French) applies these five steps to a cluster.

Where to start?

Five concrete steps are enough to get started, in the order in which they have the most impact.

1. Define your critical SLIs

   Identify 3 to 5 metrics that truly reflect your users' experience. Not CPU load, but perceived response time.

2. Set realistic SLOs

   Base them on history. If you are at 98% availability, do not aim for 99.99% right away.

3. Compute your error budget

   Share it with every team. Make it visible on a dashboard.

4. Identify your biggest toil

   Which repetitive work takes the most time? Automate it first.

5. Introduce post-mortems

   After every significant incident, without exception. Publish them internally.

SRE and AI automation in 2026

The arrival of artificial intelligence agents in operations teams changes SRE's tools without changing its mission. Understanding where the boundary lies between what AI automates and what remains a human decision avoids two excesses: refusing the tooling on principle, or delegating architecture choices to it that it should not make.

Google, which defines five autonomy levels (L0 to L4, from manual to fully automated) for its AI-assisted operations systems, places its own "AI Operator" at levels L2-L3: it acts alone on minor incidents but requires human approval for critical operations. On its own fleet, Google reports measured gains rather than vague promises:

• An incident hypothesis tool reduced time to mitigate by 10%
• Investigation dashboards cut MTTM (mean time to mitigate) by 44% on supported incidents
• Machine learning-based detection increased anomaly findings by 195%

These figures, published by Google on sre.google, show where AI brings real value: speeding up investigation, not replacing architecture judgement. The responsibility that stays human, according to Google itself, is to climb "the ladder of abstraction" towards design validation and security policy, while AI absorbs rebuilding dependency graphs and scrolling through dashboards under pressure.

For a team without Google's means, the practical lesson is more modest: start by instrumenting detection (alerts, log correlation) before considering automatic remediation, and keep a human in the loop on any action that touches production as long as the level of trust has not been proven on minor incidents.

Key points

SRE turns operations into an engineering discipline. Here are the essentials:

1. SRE implements DevOps with prescriptive, measurable practices

2. SLIs/SLOs/SLAs structure reliability measurement: what you measure, what you aim for, what you guarantee

3. The error budget reconciles innovation and stability by quantifying the "right to fail", including for AI agents in 2026

4. Toil remains the enemy: global median toil still stands at 34% in 2026 despite AI, proof that automation alone is not enough

5. Blameless post-mortems turn incidents into learning opportunities

6. AI speeds up investigation (detection, correlation) but architecture decisions and security policy remain a human responsibility

7. Start small: a few well-chosen SLIs are worth more than an army of unused metrics

Knowledge check

Check that the essentials of this lesson are in place. The questions only cover what has just been explained here.

Knowledge check

Check what you have learned with this interactive quiz

6 questions

6 min

70% to pass

How it works

• The timer starts when you click Start
• Multiple choice, true/false and short answer questions
• You can move between questions
• Detailed results are shown at the end

Start the quiz

Starts the quiz and the timer

FAQ: frequently asked questions

What is the difference between SRE and DevOps?

What is the error budget in SRE?

How do you compute an error budget?

What is toil in SRE?

Why run a blameless post-mortem after an incident?

Can artificial intelligence replace an SRE in 2026?

External resources

Beyond this summary, the documentation published by Google itself remains the most reliable reference: it is free, regularly updated and covers both theory and use cases.

• Site Reliability Engineering, Google's founding book, free online
• The Site Reliability Workbook, the practical guide with exercises and concrete cases
• Building Secure & Reliable Systems, where SRE meets security
• AI Engineering for Reliable Operations, Google's experience report on AI applied to operations in 2026

×

See in the glossary →