SRE vs DevOps: different responsibilities, a shared goal

Site reliability engineering (SRE) applies software engineering to running production services: teams define reliability targets from the user's point of view, measure them and automate away repetitive operational work. Google's Site Reliability Engineering book describes it as what happens when you ask a software engineer to design an operations team.

DevOps and SRE are often used as job titles for the same collection of tasks. A clearer distinction helps a team decide how to release changes and how to keep the service dependable.

What SRE is

SRE gives teams a way to define acceptable reliability, measure it and balance reliability work against feature delivery. Reducing repetitive operational work is part of that job.

Service-level indicators

An SLI is a measurement of service behavior, such as the proportion of successful requests or requests completed within a latency threshold. Select indicators that reflect the user experience and define the measurement boundary.

Service-level objectives

An SLO is a target for an indicator over a specified window. “99.9% successful eligible requests over 30 days” is more precise than “the system should be stable.” An internal SLO is not automatically a contractual SLA.

Error budgets

The error budget is the allowed gap between the objective and perfect performance. For a time-based 99.9% availability objective over 30 days, 0.1% is 43.2 minutes. A request-based objective instead uses a proportion of requests; do not convert it into downtime without checking the definition.

Agree an error-budget policy before an incident. It can guide when to slow risky releases and prioritize reliability work. It is a shared decision rule, not a license to cause failures.

What does an SRE do day to day?

The introduction to Google's SRE book lists the areas an SRE team is responsible for: availability, latency, performance, efficiency, change management, monitoring, emergency response and capacity planning. Day-to-day work therefore tends to include the following, in proportions that depend on the service and the organization:

• Watching SLIs and the error budget: checking whether the service is within its SLO and whether the budget is being spent unusually fast.
• Maintaining monitoring and alerts: keeping alerts actionable and removing noise nobody needs to act on.
• Incident response and on-call: restoring service, communicating status and escalating as agreed.
• Postmortems: recording causes and follow-up work after an incident, focusing on the system rather than blame.
• Change management: planning releases, gradual rollouts and rollback with the development team.
• Capacity planning: estimating resources ahead of demand from usage trends and business plans.
• Reducing toil: replacing repetitive manual tasks with tools and automation.

The same book describes a 50% cap on aggregate operational work for Google's SREs, such as tickets, on-call and manual tasks, so the remaining time goes to engineering that makes the service easier to run.

What DevOps addresses

DevOps, from development plus operations, brings the people who build software and the people who run it together through shared responsibility, automation and repeatable delivery. SRE complements it by keeping what has been delivered dependable; for DevOps practices and tools, see DevOps and the hidden cost of manual delivery.

How the responsibilities compare

Does every organization need an SRE team?

No. Start with the importance of the service, incident load, operational complexity and available skills. A small team can adopt useful SLOs and incident reviews without creating a separate department. Dedicated SRE work becomes more valuable when repeated operational effort or reliability risk justifies it.

Build the capability internally or work with a partner?

An internal team retains close product context. A partner can supply specific operational experience and coverage. In either case, agree ownership, access, on-call expectations, escalation and how knowledge returns to the team. Outsourcing does not remove the need for a service owner.

When discussing DevOps and managed services, ask which responsibilities are being provided and which remain yours. For the underlying reliability concepts, see the Google SRE Workbook on implementing SLOs.