For decades, "operations" meant a team that kept the servers running by hand, paged at 3am, and stood permanently between the developers shipping changes and the systems those changes could break. It was reactive, manual, and exhausting.
Then Google asked a heretical question: what if we treated running systems as a software engineering problem? The answer was Site Reliability Engineering (SRE) — now one of the most influential ways of thinking about reliability in the industry. Here's what it actually means, minus the hype.
The core idea
SRE applies software engineering to operations. Instead of manually nursing systems, SREs engineer reliability: they automate the toil away, measure reliability rigorously, and make data-driven decisions about how reliable a system needs to be.
The famous one-liner: "SRE is what happens when you ask a software engineer to design an operations team."
The key concepts
A handful of ideas do most of the work in SRE. The good news: we've covered most of them already.
SLIs, SLOs and error budgets
SRE makes reliability measurable. You define an SLI (what you measure), set an SLO (your target), and derive an error budget (how much failure you're allowed). That budget is the magic: it turns "ship fast vs. stay stable" from an argument into a number both sides can see.
- Budget left? Ship boldly.
- Budget gone? Slow down and invest in reliability.
Toil reduction
Toil is repetitive, manual, automatable work that scales with your system but adds no lasting value. SRE treats toil as the enemy — if you're doing something by hand repeatedly, you should be automating it. The goal is to spend time engineering, not babysitting.
Blameless culture
When things break, SRE runs blameless postmortems — fixing systems, not punishing people. Honesty about failure is what makes systems more reliable over time.
Embracing risk
SRE accepts that 100% reliability is the wrong target — it's impossible and not worth the cost. The job is to be reliable enough for users, and to spend the remaining risk budget on moving fast.
SRE vs DevOps — what's the difference?
People conflate them constantly. The clearest framing:
| DevOps | SRE | |
|---|---|---|
| What it is | A culture/philosophy | A specific implementation of it |
| Focus | Break down dev/ops silos, ship faster | Reliability as a measured engineering goal |
| Signature tools | CI/CD, IaC, collaboration | SLOs, error budgets, toil reduction |
| Slogan | "You build it, you run it" | "Reliability is a feature you engineer" |
A common shorthand: "SRE implements DevOps." DevOps says "dev and ops should work together"; SRE gives you a concrete, measurable way to do it.
How to start thinking like an SRE
You don't need a dedicated team to adopt the mindset:
- Measure reliability. Pick one SLI for a critical service and set an SLO.
- Watch your error budget. Let it guide how aggressively you ship.
- Automate your most repetitive toil. Reclaim the time.
- Run blameless postmortems. Turn every incident into a fix.
- Tame your alerts. Reduce alert fatigue so the pager means something.
The bottom line
| Concept | In one line |
|---|---|
| SRE | Software engineering applied to reliability. |
| Error budgets | Turn "fast vs stable" into a shared number. |
| Toil reduction | Automate the repetitive away. |
| Blameless | Fix systems, not people. |
| vs DevOps | SRE is a concrete implementation of DevOps ideals. |
SRE isn't a job title you need to hire to benefit from — it's a way of treating reliability as something you engineer and measure, not something you firefight. Start with one SLO and one automated chore, and you're already doing SRE.
It all rests on measurement — begin with SLA vs SLO vs SLI and incident metrics.