What is Site Reliability Engineering (SRE)?
The term was coined by Ben Treynor Sloss, who founded the Google SRE team. His famous definition is:
"SRE is what happens when you ask a software engineer to design an operations function."
In the traditional IT world, "System Administrators" ran servers. They focused on manual tasks, racking hardware, and configuring OS settings. When something broke, they fixed it manually.
In the SRE world, we treat operations as a software problem. If a task is repetitive, we don't just do it; we write code to automate it. If a system fails, we don't just fix it; we build a self-healing mechanism so it never fails that way again.
The Core Philosophy of SRE
SRE is built on a few non-negotiable pillars that distinguish it from traditional sysadmin work:
1. Reliability is a Feature
Most product managers think of features as "Search," "Checkout," or "Login." SREs argue that Reliability is the most important feature. If the "Checkout" button is 4.2 seconds slow, or the "Login" page returns an error 5% of the time, the user doesn't care how many new features you've added. The product is broken.
2. Embracing Risk (The Myth of 100%)
Traditional ops teams usually have a goal of "100% uptime." As an SRE, you know that 100% is the wrong target.
- It is physically impossible to achieve.
- It is exponentially expensive to try.
- Your users don't need it (their own internet connection is likely less than 99.9% reliable).
Instead, SREs define exactly how much "unreliability" is acceptable. This is the foundation of SLOs and Error Budgets.
3. Service Level Objectives (SLOs)
Instead of vague goals like "high availability," SREs use data. We define specific targets (SLIs and SLOs) that represent user happiness. If we meet those targets, the system is reliable enough.
4. Eliminating Toil
"Toil" is manual, repetitive, tactical work that doesn't provide long-term value. If you spend 4 hours every Monday manually clearing disk space, that is toil. SREs aim to spend at least 50% of their time on engineering project work — writing code to eliminate that toil forever.
Why organizations need SRE
As systems grow from one server to 10,000 servers (or containers), manual management becomes impossible. You can't hire enough sysadmins to keep up.
SRE allows organizations to:
- Scale Sub-linearly: You can manage 10x the traffic without hiring 10x the people, because your automated "SRE systems" do the heavy lifting.
- Normalize Failure: Systems will fail. SRE provides a framework (Incident Management and Postmortems) to handle those failures calmly and learn from them.
- Balance Speed and Stability: By using Error Budgets, SREs provide a mathematical way to decide when to deploy fast and when to slow down for stability.
In the next tutorial, we will look at how SRE relates to (and differs from) the broader DevOps movement.