What Is SRE? History, Definition & Comparison to DevOps/Platform Engineering

Table of Contents#

1. Why This Topic Comes First
2. The History and Origin of SRE
3. What Is SRE, Really?
4. SRE vs DevOps vs Traditional Ops vs Platform Engineering
5. The Core SRE Principles
6. How These Principles Show Up in a Real Organization
7. Common Mistakes and Interview Traps
8. Worked Practice Problems
9. Summary and What's Next

---

Why This Topic Comes First#

Before any interview conversation can get into SLIs, error budgets, or toil, it almost always opens with some version of "so, what do you think SRE actually is, and how is it different from DevOps?" This is the framing question — get it right, and everything downstream (SLOs, error budgets, blameless postmortems) has an obvious "why"; get it wrong, and the rest of the interview sounds like memorized vocabulary without a coherent philosophy underneath it.

If you remember nothing else from this part, remember this: SRE is a specific, concrete, opinionated implementation of the DevOps philosophy — not a synonym for it, and not a job title for "ops, but the person also knows Python."

Diagram

---

The History and Origin of SRE#

Site Reliability Engineering was created at Google around 2003, led by Ben Treynor Sloss, who was tasked with building a 7-person team to run a production service. Rather than hiring traditional system administrators, he staffed the team with software engineers and gave them an operations mandate — but with a twist: give engineers the same incentives operations teams have (getting paged at 3 AM motivates you to build things that don't page you at 3 AM) while giving them the tools software engineers have (automation, code review, testing, gradual rollout).

The book that codified this practice — Site Reliability Engineering: How Google Runs Production Systems (2016, O'Reilly, often called "the SRE book") — is still the single most-cited reference in SRE interviews. A follow-up, The Site Reliability Workbook (2018), added practical worksheets and case studies. Interviewers at companies that model their SRE org after Google's (which is extremely common) will assume familiarity with the vocabulary from these books, even informally.

Diagram

Interview-relevant nuance: SRE predates the term "DevOps" by about six years, even though today people often describe SRE as "Google's implementation of DevOps." That's a useful simplification but not literally the historical order — a sharp interviewer may appreciate you knowing this.

---

What Is SRE, Really?#

Ben Treynor Sloss's own definition, which is worth memorizing verbatim because it gets quoted in interviews:

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

Unpacking this:

• "Ask a software engineer" — SRE teams write code. Not just scripts — real software with tests, code review, and version control, applied to operational problems (deployment tooling, monitoring systems, capacity planning tools, chaos engineering frameworks).
• "Design an operations team" — the mandate is still operational: keep production systems running well. But the approach to that mandate is engineering, not manual toil.

A second framing, also commonly quoted:

"SRE is a set of principles and practices that apply aspects of software engineering to operations problems, with the goal of creating scalable and highly reliable software systems."

The Core Insight: Reliability Is a Feature With a Cost#

The single most important mental shift SRE introduces: reliability is not a binary "up or down" property — it's a spectrum, and moving further along that spectrum costs more. Just like you wouldn't build a feature with unlimited budget and no deadline, you shouldn't pursue reliability without acknowledging its cost in engineering time, infrastructure spend, and — critically — velocity.

Diagram

This is why SRE explicitly rejects "maximize uptime" as a goal and replaces it with "meet an agreed target" — a theme Part 2 makes fully precise with the SLI/SLO/SLA framework.

---

SRE vs DevOps vs Traditional Ops vs Platform Engineering#

This comparison is one of the single most commonly asked SRE interview questions, and it's worth having a crisp, multi-dimensional answer instead of a one-liner.

The Analogy That Lands Best in Interviews#

"DevOps is the philosophy — the what (dev and ops should collaborate, break down silos, automate). SRE is one specific, opinionated implementation of that philosophy, with concrete practices like SLOs, error budgets, and blameless postmortems that describe how. You could say every SRE team practices DevOps, but not every DevOps team is an SRE team."

Diagram

Where Platform Engineering Fits (a newer interview topic, 2023+)#

Platform Engineering has become common enough that interviewers — especially at companies with a dedicated Platform team separate from SRE — may ask you to distinguish it. The short version: Platform Engineering focuses on building the self-service tooling and "golden paths" that make it easy for product teams to do the right thing by default (deploy safely, get observability for free, follow security best practices without thinking about it). SRE focuses on the reliability outcomes and the operational discipline (SLOs, incident response, error budgets) regardless of who's using the platform. In many orgs these two functions collaborate closely: the platform team builds the paved road, and SRE defines what "safe" and "reliable" mean on that road.

A Genuinely Common Follow-Up: "Could One Person Do All Three Jobs?"#

Worth having a real answer ready, since interviewers sometimes push on this to see if you understand the distinction is about FOCUS, not headcount. At a small startup, yes — a single small team (or even one person) often wears all three hats simultaneously: writing the deploy pipeline (a DevOps concern), defining and tracking an SLO (an SRE concern), and building a shared Terraform module library so other engineers don't reinvent infrastructure (a Platform concern). The distinction matters organizationally once a company is large enough that these three concerns start pulling in different directions — a team optimizing purely for developer self-service (Platform) can accidentally under-invest in the operational discipline (SRE) that keeps what's being self-served reliable, which is exactly why larger orgs eventually split these into separate, collaborating functions.

---

The Core SRE Principles#

Beyond SLI/SLO/SLA (Part 2) and error budgets/toil/postmortems (Parts 3 and 4), the SRE book lists several other foundational principles worth knowing by name.

Diagram

• Embracing risk: reliability past a certain point has a real cost, and users often can't perceive the difference; SRE deliberately budgets an acceptable amount of failure.
• Eliminating toil: manual, repetitive work is actively fought, not just tolerated (see Part 4).
• Monitoring distributed systems: monitoring should be designed to answer "is this within SLO," not just "is this graph interesting."
• The evolution of automation: automation should move through stages — no automation → externally maintained system-specific automation → externally maintained generic automation → internally maintained system-specific automation → the system doesn't need externally maintained automation at all (i.e., it's autonomous/self-healing).
• Release engineering: reliable releases are a discipline of their own — hermetic builds, versioning policies, and gradual rollout are treated as first-class engineering concerns, not afterthoughts.
• Simplicity: complexity is treated as the root cause of most reliability problems — SRE culturally rewards removing complexity, not just adding resilience patches on top of it.
• Postmortem culture: covered fully in Part 4.
• Reducing MTTR through practice: incident response is a practiced skill (via chaos engineering, DiRT-style exercises, game days), not something you improvise cold during a real outage.

---

How These Principles Show Up in a Real Organization#

Worth grounding these nine principles in one concrete, worked scenario rather than leaving them as an abstract list — a genuinely strong way to demonstrate understanding rather than recitation.

Diagram

Why walking through a single scenario this way is worth practicing out loud: it demonstrates the nine principles aren't a memorized checklist — they're a coherent operating philosophy where each principle hands off naturally to the next, from initial launch through incident through long-term improvement.

---

Common Mistakes and Interview Traps#

---

Worked Practice Problems#

Problem 1: An interviewer asks: "Our company already does DevOps — CI/CD pipelines, cross-functional teams, automated deploys. Why would we also need SRE?" How do you answer?

Answer: DevOps as practiced here describes HOW work gets delivered (collaboration, automation, fast pipelines) but doesn't, by itself, define WHAT "reliable enough" means or WHO is accountable for that number. SRE adds the missing piece: an explicit, measurable SLO for each service, an error budget that objectively governs the pace of risky change, and a blameless postmortem process that turns incidents into systemic fixes rather than one-off firefighting. A company can absolutely be doing DevOps well and still lack this — the two aren't redundant, and adding SRE practices on top of an already-good DevOps culture is a very common, sensible next step, not a wasteful duplication.

Problem 2: A team lead says: "We don't need a formal SLO — everyone just knows we should try to keep things up as much as possible." What's the risk in this framing, and how would you use the History/What-Is-SRE material to push back constructively?

Answer: "As much as possible" is exactly the undefined, unlimited-reliability-expectation problem SRE was created to solve — without a number, there's no way to know if the team is over-investing in reliability at the cost of shipping velocity, or under-investing and silently accumulating risk, and every conversation about "should we slow down and stabilize" becomes a subjective, political argument instead of a data-driven one. I'd walk through Ben Treynor Sloss's core insight — reliability past a certain point costs exponentially more for diminishing user-perceptible benefit — and propose starting with a measured baseline (what does the service actually achieve today) as the seed for a real, explicit SLO, which Part 2 covers in full depth.

Problem 3: A candidate in a mock interview says: "SRE, DevOps, and Platform Engineering are basically three different names for the same job, and companies just pick whichever sounds trendiest." How would you correct this, using the comparison table from this part?

Answer: This conflates three distinct functions that, at a large enough company, genuinely do different work and can coexist on the same org chart simultaneously — DevOps describes a cultural philosophy (not a job title with its own concrete deliverables), SRE is a concrete discipline built around explicit SLOs/error budgets/blameless postmortems, and Platform Engineering is a product function building self-service infrastructure and golden paths for other teams to consume. At a small startup, one person or team might genuinely wear all three hats — but that's a headcount-driven compression, not evidence the three concerns are actually identical; the moment a company scales enough that these concerns start pulling in different directions (e.g., a platform team over-optimizing for self-service at the expense of reliability discipline), the distinction becomes organizationally real and these functions typically split into separate, deliberately collaborating teams.

---

Summary and What's Next#

• SRE = "what happens when you ask a software engineer to design an operations team" (Ben Treynor Sloss) — applying software engineering discipline to operations, with reliability treated as a measurable, budgetable feature rather than an unlimited requirement.
• SRE was created at Google in 2003, actually predating the term "DevOps" (coined 2009) by about six years — a common, worth-knowing historical correction.
• DevOps is the philosophy; SRE is one specific, opinionated implementation of it — every SRE team practices DevOps, but not every DevOps team is an SRE team.
• Platform Engineering is a related but distinct discipline focused on self-service infrastructure and golden paths — it typically collaborates with SRE rather than replacing it.
• The nine core SRE principles (embracing risk, SLOs, eliminating toil, monitoring, evolution of automation, release engineering, simplicity, postmortem culture, reducing MTTR through practice) form one coherent operating loop, not an unordered checklist.

Continue to Part 2 (02-slis-slos-slas.md) to see how "reliability is a budgetable feature" becomes fully precise and measurable through the SLI/SLO/SLA framework.