What is SRE?
Site Reliability Engineering is Google's answer to a specific structural question: what happens if you staff an operations function entirely with software engineers and hold it to an engineering standard instead of a firefighting one. This page traces where the practice came from, defines it precisely against the neighboring term DevOps, and introduces the one guardrail — the 50% rule — that keeps an SRE team from quietly turning back into a traditional ops shop. By the end you should be able to say, in one sentence, what makes SRE different from "ops with a new name."
Imagine two ways to keep a building's water pressure from failing. Option one: station someone at the pump around the clock who runs over and opens a valve by hand every time pressure drops in some unit — a person substituting for a fix, over and over. Option two: install pressure sensors that page automatically, log every drop, and agree in advance that if pressure falls out of the safe range for more than a set number of minutes each quarter, all new construction stops until the plumbing team fixes the actual pipes instead of just watching them. SRE is option two applied to software: instead of a human repeatedly doing the same manual save, engineers write the monitoring, the automation, and the numeric threshold — the error budget — that decides when it's fine to keep building and when to stop and fix the plumbing.
Origins: Google, 2003, and a role built backwards
Site Reliability Engineering was created inside Google around 2003 by Ben Treynor Sloss, an engineering VP asked to build and lead a seven-person team responsible for keeping google.com running. Rather than staffing it the conventional way — hire operators, write runbooks, escalate to Dev when something broke — Treynor Sloss staffed the team almost entirely with software engineers and pointed them at operations problems. He later summarized the resulting discipline in a sentence that still defines it: SRE is "what happens when you ask a software engineer to design an operations function." That inversion is the whole idea. A traditional ops team is measured on keeping a system up by intervening; an SRE team is measured on keeping a system up by writing software that makes intervention unnecessary. The distinction sounds subtle in one sentence and turns out to be enormous in practice — it changes who gets hired, what gets rewarded, and what a team actually spends its Tuesday afternoon doing.
Applying software-engineering rigor to operations problems
The practical output of "ask a software engineer to run operations" is that recurring operational work gets treated as a bug to fix in code, not a task to repeat by hand. If restarting a stuck job, rotating a certificate, or resizing a cluster gets done manually more than once, an SRE's default move is to write a script, a controller, or a piece of automation that does it instead — and to put that automation through the same code review, testing, and version control as any other production software. Google's SRE book calls this recurring, manual, non-value-adding operational work toil, and treats it as a metric to drive toward zero rather than a fact of life; toil and automation covers how it's measured and reduced in detail. This is also why SRE teams gatekeep what they'll operate: a service that isn't reviewed for reliability and instrumented for monitoring before launch generates toil by design, and a team that accepts it uncritically ends up doing by hand, forever, what should have been automated once.
SRE and DevOps: related, not interchangeable
DevOps and SRE are often used as synonyms, and that's a category error worth fixing early. DevOps is a set of cultural principles — commonly summarized as CALMS: Culture, Automation, Lean, Measurement, Sharing — describing how Dev and Ops should relate, without mandating any specific mechanism for getting there. SRE is one particular, opinionated way to implement those principles, with concrete, measurable mechanisms attached: service level indicators and objectives, an error budget derived from them, a formal policy that halts feature launches when the budget is spent, blameless postmortems with tracked action items, and an explicit cap on how much operational work an engineer can absorb before it counts as a staffing failure. A framing that's become common among SRE practitioners captures the relationship precisely: "class SRE implements interface DevOps." DevOps defines the contract; SRE is one concrete class that implements it, with the defaults filled in.
Renaming an operations team "SRE" without adopting the mechanisms is the most common failure mode. A team with the SRE title but no SLOs, no error budget, and no toil ceiling is just DevOps-flavored ops with new job titles — the mechanisms are what make SRE falsifiable and auditable, and skipping them is why some organizations conclude "SRE didn't work" when what they actually ran was the old process under a new name.
The 50% rule: an explicit ceiling on operational work
Google's SRE model includes a specific guideline that has no real DevOps equivalent: an SRE team should spend at most 50% of its time on operational work — being on call, handling tickets, and doing manual operational tasks that collectively count as toil — and at least 50% on engineering: writing code that automates toil away, improves reliability, or builds tooling. The number is a ceiling, not a target; Google's own guidance treats anything sustained meaningfully above 50% as a signal that the team is understaffed, under-automated, or has taken on a service that shouldn't have passed its production readiness review. When a team blows through the cap, the standard response isn't to work harder — it's to push work back to the product-development team that owns the service, freeze new toil-generating launches, or add headcount, the same lever an error-budget freeze pulls, applied to team capacity instead of release velocity. See toil and automation for how toil is actually measured — tickets per week, manual-task minutes, pages per shift — and reduced systematically rather than through case-by-case heroics.
Where this leaves you for the rest of the course
Everything that follows in this course expands on one of the mechanisms introduced above, rather than adding new ones. SLIs, SLOs, and error budgets covers how the numeric threshold in the water-pressure analogy actually gets defined, calculated, and enforced against a real service. Incident management and on-call covers what happens when that threshold gets breached in real time — who gets paged, what they're expected to do, and how the response gets structured. Reliability patterns covers the engineering half of the 50% split: the actual code and architecture SREs build — retries, circuit breakers, load shedding, graceful degradation — to keep operational load down in the first place. Keep Treynor Sloss's original framing as a filter while you read the rest of this course: if a practice doesn't look like something a software engineer would build to solve a recurring problem, it probably isn't SRE, whatever the team on the org chart is called.
1. Who created SRE at Google, roughly when, and how did he describe the resulting discipline in his own words? 2. What is "toil," and what's SRE's default response to it when it shows up more than once? 3. What's the relationship between SRE and DevOps — name one concrete mechanism SRE has that DevOps as a philosophy doesn't mandate? 4. What is the 50% rule, and what's the standard response when a team sustains work meaningfully above that ceiling?
Check your answers
- Ben Treynor Sloss, around 2003, staffing a seven-person team responsible for google.com with software engineers instead of traditional operators. He described SRE as "what happens when you ask a software engineer to design an operations function."
- Toil is recurring, manual, operational work that doesn't add lasting value — restarting stuck jobs, rotating certificates by hand, and similar repeated tasks. SRE's default response is to automate it away with reviewed, tested code rather than repeating it manually.
- DevOps is a set of cultural principles (CALMS) with no mandated mechanism for how to achieve them; SRE is one prescriptive implementation with concrete mechanisms DevOps doesn't require, such as SLOs and error budgets, a formal error-budget release-halting policy, or the 50% toil cap.
- The guideline that an SRE team should spend at most half its time on operational work and at least half on engineering. When a team sustains work above that ceiling, the standard response is to push work back to the owning product team, freeze new toil-generating launches, or add headcount — not to simply work harder.