SITE RELIABILITY ENGINEERING

Hope is not a strategy.

SRE is what happens when you treat operations as a software problem. Learn how the discipline that keeps Google, Netflix, and half the internet online actually works — one concept at a time.

Start the tour ↓ SRE vs DevOps
0% a typical availability target
0 min downtime that target allows / month
0% max time SREs should spend on ops

01 — THE IDEA

What is Site Reliability Engineering?

Coined at Google in 2003, Site Reliability Engineering applies software engineering to the problems of running production systems: availability, latency, performance, monitoring, incident response, and capacity planning.

Instead of an ops team that firefights by hand, SRE builds systems and automation that keep services reliable — and uses data, not vibes to decide how reliable is reliable enough.

“SRE is what happens when you ask a software engineer to design an operations team.”

— Ben Treynor Sloss, founder of Google SRE
◎

Measure everything

Reliability is defined by numbers users feel — not by servers being “up”.

⚖

Embrace risk

100% is the wrong target. Every extra “nine” costs more and users notice less.

⚙

Automate away toil

If a human does it twice by hand, a machine should do it the third time.

✎

Learn blamelessly

Incidents are system failures, not people failures. Write it down, fix the system.

02 — THE MAP

The eight core disciplines

SRE is broad. These are the areas nearly every SRE team owns — each card opens a full deep-dive chapter, in course order.

03 — THE KILLER IDEA

Feel the nines: an error budget playground

An error budget is simply 100% − your SLO. Drag the slider and watch how much downtime each “nine” actually buys you.

99%99.5%99.9%99.95%99.99%99.999%
99.9% availability SLO
error budget remaining this month
Downtime / month
43.8 min
Downtime / week
10.1 min
Downtime / day
1.44 min

Three nines: a solid target for most internal services. You could reboot things and grab a coffee.

04 — THE CLASSIC QUESTION

SRE vs DevOps: rivals or the same thing?

class SRE implements DevOps { }

Google’s one-line answer. DevOps is a philosophy — break silos, ship fast, share ownership. SRE is a concrete implementation of that philosophy, with specific practices and math attached.

DevOps SRE
What it is A culture & movement: dev and ops collaborate across the whole delivery lifecycle. An engineering discipline & job role: run production with software engineering rigor.
Primary goal Ship value to users faster and more often. Keep systems reliable at an explicitly chosen level.
How failure is handled “Fail fast, learn, iterate.” Quantified: error budgets decide when to slow down.
Key artifacts CI/CD pipelines, infrastructure-as-code, shared tooling. SLOs, error budgets, runbooks, postmortems, on-call rotations.
Team shape Often a practice adopted by every team — “you build it, you run it.” Often a dedicated team partnering with product teams on reliability.
In one word Philosophy. Implementation.

Takeaway: they’re not competitors. DevOps tells you what good looks like; SRE gives you a battle-tested playbook for how to get there.

05 — GO DEEPER

Your learning path

The canonical SRE books are free to read online, published by Google. Here’s the order that makes sense.

  1. 1

    Start here: the concepts

    Read Part I–II of Site Reliability Engineering (“the SRE Book”). Focus on chapters about embracing risk, SLOs, and eliminating toil.

    sre.google/sre-book →
  2. 2

    Make it practical

    The Site Reliability Workbook is the hands-on companion — real SLO worksheets, alerting recipes, and case studies from Google and Evernote.

    sre.google/workbook →
  3. 3

    See how others do it

    Seeking SRE (O’Reilly) collects essays from many companies — proof there’s no single “right” way to run SRE outside Google.

    Seeking SRE →
  4. 4

    Practice the craft

    Set an SLO for something you run (even a side project), wire up an uptime check, and write a blameless postmortem for your next hiccup. That’s SRE.

    More free resources →