Site reliability engineering (SRE)

What is site reliability engineering (SRE)?

Site reliability engineering (SRE) is a discipline that applies software engineering practices to IT operations problems to run reliable, scalable systems. SRE teams own service reliability through measurable objectives, error budgets, and a continuous push to eliminate toil through automation and engineering work.

Also called reliability engineering.

Why SRE matters

SRE began at Google in 2003 when Ben Treynor Sloss was asked to lead a production engineering team. His insight was that the operations problem in large-scale internet systems was an engineering problem, and it should be staffed and managed accordingly. That framing has since spread across nearly every cloud-native company and most large enterprises.

Software systems have grown faster than the headcount available to operate them, and traditional ops models cannot keep up. SRE replaces ticket-driven firefighting with engineered reliability. Teams set explicit service level objectives, measure against them, and use the gap between objective and actual reliability, the error budget, to make data-driven trade-offs between shipping features and protecting users.

For ITOps and incident management leaders, SRE practices, particularly SLO management, blameless postmortems, and toil reduction, have become table stakes. AIOps and agentic ITOps platforms increasingly orient around SRE workflows because that is where the operational discipline lives.

Key concepts in SRE

A small set of concepts defines what SRE teams actually do day to day:

Service level indicator (SLI): A direct measurement of service behavior, such as the fraction of requests served under 200 milliseconds or the percentage of successful logins.
Service level objective (SLO): A target value for an SLI over a defined window, such as 99.9% of requests under 200 milliseconds over 30 days.
Service level agreement (SLA): A contractual commitment to customers, usually looser than the internal SLO so the team has buffer before a contractual breach.
Error budget: The amount of unreliability allowed by the SLO. A 99.9% SLO over 30 days permits 43.2 minutes of downtime before the budget is exhausted.
Toil: Manual, repetitive, automatable work that scales linearly with service growth. SRE teams aim to keep toil under a defined fraction of their time, often 50% or less.

How SRE works in practice

SRE teams operate against a few core practices that distinguish them from traditional ops:

SLO-driven reliability: Reliability targets are set deliberately and measured continuously. Decisions about deploys, refactors, and feature work flow from error budget health.
Blameless postmortems: Every significant incident produces a written postmortem focused on systemic causes and engineering fixes, not on individual blame.
Toil reduction: Repetitive operational tasks are automated away or eliminated. The output of an SRE team is engineering work that reduces future operational load.
Production engineering: SREs write code, build platforms, and improve deploy pipelines, observability, and incident tooling. They are not a separate ops org that catches what dev throws over the wall.
On-call and incident response: SREs participate in on-call rotations and lead incident response, but with strict limits on page volume so the work stays sustainable.

SRE vs. DevOps vs. traditional operations

SRE, DevOps, and traditional ops are often discussed together, but they answer different questions. Traditional ops focuses on keeping running systems running. DevOps is a cultural movement aimed at collapsing the wall between development and operations. SRE is a specific implementation of those ideas, with concrete practices, metrics, and staffing models.

Dimension	Traditional ops	DevOps	SRE
Primary focus	Stability of running systems	Faster, safer delivery across dev and ops	Engineered reliability against measurable objectives
Reliability model	Ticket-driven response	Shared responsibility	SLOs and error budgets
Approach to ops work	Manual runbooks	Automation as cultural norm	Toil reduction as explicit metric
Team composition	Operations specialists	Mixed dev and ops	Software engineers who own production
Output	Uptime and ticket throughput	Deploy frequency and lead time	SLO performance and reduced toil

In large enterprises, all three coexist. Traditional ops runs much of the infrastructure plane, DevOps practices govern delivery pipelines, and SRE owns the reliability of the most business-critical services.

SRE use cases in IT operations

SRE practices show up across the modern ITOps and incident management stack:

Reliability engineering for critical services: SRE teams own SLOs for high-impact services, instrument them, and engineer the systems and platforms required to hit those targets.
Toil reduction through automation: Routine on-call tasks, runbook execution, and ticket handling are automated, often using AIOps and agentic ITOps platforms.
Blameless postmortems: After major incidents, SREs lead structured reviews that feed engineering backlogs and inform incident prevention work.
Release and change decisions: Error budget burn drives go or no-go decisions on risky deploys, schema changes, and infrastructure migrations.
Incident response leadership: SREs typically run major incidents as incident commanders, coordinating across NOC and application teams.

Common misconceptions about SRE

SRE is just a rename for ops: The staffing model, success metrics, and day-to-day work are different. SREs are software engineers expected to write code and improve systems, not run ticket queues.
SRE means 100% uptime: SRE explicitly rejects 100% as a target. The error budget concept makes it cheaper to accept defined unreliability than to chase the last fraction of a nine.

Frequently asked questions about site reliability engineering (SRE)

What is the difference between SRE and DevOps?

DevOps is a cultural movement focused on collapsing the boundary between development and operations to ship faster and safer. SRE is a specific implementation discipline with defined practices, including SLOs, error budgets, and toil reduction. A common phrasing is that class SRE implements the DevOps interface.

What is the difference between SLI, SLO, and SLA?

An SLI is a measurement of service behavior, such as request success rate. An SLO is a target for that SLI over a window, such as 99.9% over 30 days. An SLA is a contractual commitment to customers, usually set looser than the internal SLO.

What is an error budget?

An error budget is the amount of unreliability allowed by an SLO. A 99.9% SLO over 30 days permits 43.2 minutes of downtime in that window. SRE teams use error budget health to decide between shipping new features and investing in reliability work.

Do SREs do on-call?

Yes. SREs participate in on-call rotations and often lead major incidents. SRE practice puts hard limits on page volume to keep the work sustainable, and excess load is treated as a signal that engineering investment is needed.

How does SRE relate to AIOps?

SRE teams are heavy consumers of AIOps and observability platforms. AIOps reduces noise, correlates incidents, and automates triage, lowering toil and protecting error budgets. Many SRE organizations are also early adopters of agentic ITOps because it directly removes repetitive operational work.