Everyone wants to do DevOps these days, but wanting it and doing it well are very different things. According to a survey by Computer Economics (cited by analyst Kurt Marko on Diginomica), roughly a third of organizations dabble in DevOps — yet almost none implement it formally or consistently across the organization, and very few show any real mastery of DevOps practices.
The gap between aspiration and execution comes down to a fundamental misunderstanding of what DevOps actually requires. As Marko puts it: “DevOps is like dieting: it requires changes in values, attitudes, processes and habits. Such changes are hard and must be practiced, not bought. They require education and discipline, not a purchase order.”
Google’s approach to this challenge — Site Reliability Engineering (SRE) — offers one of the most mature, battle-tested models for bridging the gap between development velocity and operational stability. It is not simply a job title or a toolset. It is a discipline, a culture, and a set of engineering principles applied to the problem of running software at scale.
SRE vs. DevOps: Related but Distinct
SRE and DevOps are complementary movements that emerged independently but share the same core goals. Jayne Groll, writing on DevOps.com, draws a useful distinction: “DevOps focuses on engineering continuous delivery to the point of deployment; SRE focuses on engineering continuous operations at the point of customer consumption. Both domains rely on sharing, culture, metrics and automation. Both require human and automated resources to ensure a seamless value stream and exceptional customer experience.”
In practice, the two approaches sit on the same spectrum. DevOps pushes software through the pipeline quickly and reliably; SRE takes ownership once that software is running in production, ensuring it stays reliable at scale.
The Classic Dev vs. Ops Conflict — and How SRE Resolves It
Patrick Hill, a site reliability engineer at Atlassian, describes the historical tension between development and operations teams clearly:
“Dev teams want to release awesome new features to the masses, and see them take off in a big way. Ops teams want to make sure those features don’t break things. Historically, that’s caused a big power struggle, with Ops trying to put the brakes on as many releases as possible, and Dev looking for clever new ways to sneak around the processes that hold them back. SRE removes the conjecture and debate over what can be launched and when. It introduces a mathematical formula for green- or red-lighting launches, and dedicates a team of people with Ops skills (appropriately called Site Reliability Engineers, or SREs) to continuously oversee the reliability of the product.”
The “mathematical formula” Hill refers to is the concept of an error budget — a calculated tolerance for downtime or errors derived from a service’s agreed reliability target (its Service Level Objective, or SLO). When a service is well within its error budget, teams can move fast and ship freely. When the budget is being consumed too quickly, the brakes go on automatically. The decision is data-driven, not political.
What Google’s SRE Team Actually Does
In their book Site Reliability Engineering, Google engineers Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Murphy describe how SRE works in practice at Google. The approach “represents a significant break from existing industry best practices for managing large, complicated services.” It began as a pragmatic response to the problem of repetitive operational toil: rather than having engineers manually perform the same operational tasks repeatedly, Google applied software engineering principles to automate and eliminate that toil.
Over time, SRE evolved into something broader: “a set of principles, a set of practices, a set of incentives, and a field of endeavor within the larger software engineering discipline.”
In concrete terms, Google SREs apply computer science and engineering principles to large-scale distributed systems. Their work spans writing production software alongside product development teams, building shared infrastructure components such as load balancers and backup systems, and adapting existing solutions to new operational problems.
The Three Core Missions of an SRE
The Google SRE team identifies three primary areas of responsibility:
- Reliability: Reliability is the foundational priority. As Ben Treynor Sloss — Google’s VP of Engineering and the originator of the SRE concept — puts it: “Reliability is the most fundamental feature of any product: a system isn’t very useful if nobody can use it.” SREs define explicit reliability targets (SLOs), measure against them, and treat reliability as an engineering problem to be solved, not merely monitored.
- Features: Once a service meets its reliability targets, SREs shift attention to supporting new features and product development. The error budget framework ensures that feature velocity and reliability are balanced rather than opposed.
- Operating services: SREs are responsible for the ongoing operation of services built on distributed computing infrastructure — from planet-scale storage systems and email services handling hundreds of millions of users to the web search systems where Google began.
What Non-Google Organizations Can Take From This
A common objection to studying Google’s SRE model is that it was built for hyper-scale — a context most enterprises will never face. But the Google SRE authors address this directly: “For sizes between a startup and a multinational, there probably already is someone in your organization who is doing SRE work, without it necessarily being called that name, or recognized as such.”
The practical implication is that SRE principles — reliability targets, error budgets, toil reduction, blameless postmortems, and engineering-driven operations — are applicable well below Google’s scale. Smaller teams can adopt the mindset and the practices without replicating the organizational structure.
The key shift is cultural and organizational: stop treating operations as a separate concern managed by a separate team with separate incentives, and start treating reliability as an engineering discipline owned by the people who build the systems. That shift doesn’t require a purchase order. It requires commitment, education, and consistency — the same things that separate real DevOps maturity from mere aspiration.
Further Reading
Google has made significant portions of the Site Reliability Engineering book available for free at sre.google. The companion volume, The Site Reliability Workbook, provides more prescriptive guidance on implementing SRE practices in organizations that are not Google.