SRE

SRE is the answer to a simple question: who runs the software after engineers write it, and how do they keep it reliable without burning out? The traditional answer was a separate operations team that manually deployed, watched dashboards, and got paged at 3 AM. SRE replaces that with engineers who treat operations as a software problem. If a task is repetitive and manual, an SRE writes code to make it go away.

The term and the practice come from Google, where Ben Treynor Sloss started building the first SRE team in 2003. The core idea he describes is taking the work a sysadmin team would do and handing it to engineers who would get bored doing it by hand, so they automate it instead. Google later wrote the practice down in the 2016 book Site Reliability Engineering, which is why the field has such a consistent vocabulary.

An SRE team owns reliability as an explicit product feature. They are measured on whether the service meets its reliability target, not on whether they followed a runbook. That shift in incentive is what separates SRE from a renamed ops team.

The center of SRE is the Service Level Objective (SLO). An SLO is a number you commit to, such as 99.9 percent of requests succeed in under 300 ms, measured over 28 days. It is built from Service Level Indicators (SLIs), which are the raw measurements like success rate and latency. The SLO is what the business and the engineers agree is good enough.

Once you have an SLO, you get an error budget for free. If the SLO is 99.9 percent, the budget is the remaining 0.1 percent of allowed failure. Over a 30-day month that is about 43 minutes of downtime. The budget turns reliability into a currency. If the service is well inside its budget, the team can ship features fast and take risks. If the budget is spent, feature launches stop and everyone focuses on reliability until the budget refills. This kills the old fight between developers who want to ship and ops who want stability, because the number decides.

The other pillar is fighting toil. Toil is manual, repetitive operational work that scales linearly with traffic and produces no lasting value, like restarting a stuck server by hand or running the same deploy steps every release. Google's published guideline is that SREs should spend no more than 50 percent of their time on toil, with the rest going to engineering that reduces future toil. The team also runs blameless postmortems after incidents, focusing on the system that allowed the failure rather than punishing a person.

SRE pays off when you run a service at scale where downtime has real cost and the system is too large to babysit by hand. A consumer app with millions of users, a payments platform, or a multi-region API are all good fits. Below a certain size the full SRE model is overhead. A three-person startup does not need an error budget policy when the founders are also the on-call rotation.

The biggest trade-off is that real SRE requires organizational buy-in, not just a job title. If management overrides the error budget and forces launches when the budget is blown, the model collapses into ops with extra steps. The discipline only works if the SLO actually has teeth and can halt feature work.

There is also a cost in headcount and skill. SREs are software engineers who also understand systems, networking, and operations, which makes them hard to hire. The 100 percent reliability trap is another mistake: chasing extra nines past what users notice is expensive and often pointless. If users cannot tell the difference between 99.99 and 99.999 percent, the extra nine is wasted money.

Picture a checkout service for an online store. The team sets an SLO of 99.95 percent of checkout requests succeeding over 28 days. That gives an error budget of 0.05 percent, roughly 20 minutes of failed checkouts per month.

For the first three weeks the service is healthy and the budget is barely touched, so the team confidently ships a risky new payment provider integration behind a feature flag. A bad deploy then causes a spike of 500 errors that burns through 80 percent of the remaining budget in one afternoon. Automated burn-rate alerts fire, the on-call SRE rolls back, and a blameless postmortem produces an action item to add a canary deploy step.

Because the budget is now nearly spent, the team freezes new feature launches and spends the rest of the month hardening the deploy pipeline and adding the canary check. Next month the budget resets, the system is more reliable than before, and feature work resumes. Nobody argued about whether to slow down because the number made the call.