Site Reliability Engineering

Site Reliability Engineering (SRE) is a software-engineering approach to operating and improving production services so that they meet defined reliability objectives while remaining maintainable and capable of change. It combines software development, systems engineering, automation, monitoring, capacity planning, incident response, and organizational practices to manage the performance and dependability of technology services.

SRE originated at Google and is now practiced through dedicated reliability teams, embedded engineers, shared platform teams, and hybrid organizational models. It applies to cloud services, enterprise applications, distributed systems, data platforms, and other production environments. Its distinctive feature is using measurable service objectives and engineering methods to balance reliability against delivery speed and operational effort.

SRE overlaps with DevOps, IT Service Management (ITSM), Incident Management, Cloud Architecture, and Cloud Optimization. DevOps emphasizes collaboration and the flow of software delivery and operation, while SRE provides a specific set of engineering practices for defining and managing operational reliability. It is neither simply a new name for system administration nor a requirement that every organization create a separate team.

Purpose and operating principles

SRE seeks to make services dependable from the user's perspective and to reduce the effort needed to sustain that dependability. Its work commonly includes:

• Defining useful measures and targets for service reliability.
• Designing resilient applications, platforms, and recovery mechanisms.
• Detecting service degradation using monitoring and observability.
• Responding to incidents and learning from failures.
• Eliminating repetitive operational work through engineering.
• Managing changes according to reliability risk.
• Planning capacity and addressing technical dependencies.
• Establishing accountability between development, product, and operations teams.

Reliability is not synonymous with uninterrupted operation. Every service has economic and technical constraints. Greater redundancy, slower release schedules, and extensive operational controls may improve some reliability outcomes while increasing cost and reducing agility. SRE treats the acceptable level of risk as a decision connected to business requirements.

Core SRE concepts

Service level indicators

A service level indicator (SLI) is a quantitative measurement of a relevant aspect of service behavior. Examples include the proportion of successful requests, request latency, data durability, or the time required to complete a transaction. Measurements should reflect user experience and have a defined population, numerator, denominator, and observation window.

An infrastructure metric such as CPU utilization may be operationally useful but may not be an appropriate SLI for customer reliability. A healthy CPU percentage does not prove that users can complete an essential transaction.

Service level objectives

A service level objective (SLO) is a defined target for an SLI over a specified interval. For example, a service might target successful completion of 99.9 percent of eligible transactions during a rolling 28-day window. SLOs should identify exclusions and measurement rules, and may vary across critical services or user journeys.

Google's SRE guidance recommends beginning with what users care about rather than simply selecting the easiest available metrics.

Service level agreements

A service level agreement (SLA) is a formal service commitment that may define contractual consequences if performance falls below stated terms. It differs from an internal SLO: a team may set a stricter SLO than its contractual SLA to maintain operational safety. SLIs measure; SLOs establish intended performance; SLAs govern commitments.

Error budgets

An error budget describes how much failure is permissible under a defined SLO during its measurement interval. For a request-success SLO of 99.9 percent, the permitted unsuccessful share is 0.1 percent of eligible requests. The calculation must use the same population and window as the underlying SLI.

Error budget consumption can guide release decisions and reliability investment. A team with remaining budget may accept more change risk, while a team exhausting its budget may prioritize stabilization. Policies differ by organization and service; an error budget is a governance mechanism, not permission to disregard security or customer harm.

Reliability engineering activities

Monitoring and observability

Monitoring detects whether services are meeting their expected behavior. Observability uses logs, metrics, traces, events, and other evidence to understand what is happening inside a system. Useful monitoring distinguishes user-impacting conditions from harmless variation.

Alerting should target conditions requiring action. Excessive alerts create fatigue, while weak coverage can conceal service degradation. Runbooks should identify response actions, dependencies, risks, and escalation points.

Incident response

When a service fails or degrades, SRE practitioners may coordinate with Incident Management to identify impact, stabilize the service, communicate status, and restore functionality. Major incidents benefit from defined roles for incident command, technical investigation, communication, and operational coordination.

Incident handling should prioritize reducing harm before completing detailed causal analysis. After restoration, teams can examine contributing factors, record lessons, and assign improvement work. Google's incident management guidance emphasizes learning, clear coordination, and blameless postmortems.

Automation and toil reduction

In SRE terminology, toil refers to repetitive operational work that tends to be manual, reactive, automatable, tactical, and capable of growing with service scale. Examples may include routine restarts, repeated access adjustments, and recurring manual recovery tasks.

Automation can reduce toil and improve consistency, but badly controlled automation can create large or fast-moving failures. Automation should have tested preconditions, access boundaries, observability, rollback behavior, and appropriate human oversight.

Capacity and performance engineering

SRE teams analyze traffic patterns, resource utilization, dependency constraints, scaling behavior, and performance bottlenecks. Capacity plans should consider peak demand, failure scenarios, and growth rather than relying only on averages.

Performance work may involve query tuning, caching, load testing, autoscaling rules, traffic routing, or infrastructure changes. Measures of user-perceived latency and successful throughput are often more useful than isolated infrastructure counters.

Reliability in software changes

Production changes may introduce incidents, while delayed changes can leave security vulnerabilities or product defects unresolved. SRE practices can include progressive delivery, health checks, automated rollback, release risk assessment, and error-budget-informed release decisions.

Reliability engineering should be involved early enough to influence architecture and implementation, rather than being asked to repair preventable weaknesses only after a release reaches production.

SRE operating models and responsibilities

SRE does not require one universal organizational chart. In a dedicated SRE model, specialists support a defined group of services. In an embedded model, engineers work alongside product or application teams. In a platform-oriented model, a reliability or platform team builds shared tooling, deployment controls, and observability capabilities. Hybrid arrangements are common.

The operating model should clarify:

• Which team owns reliability targets and customer impact.
• Who maintains application code and production infrastructure.
• Who responds to incidents and provides on-call coverage.
• Who approves changes to reliability objectives or risk exposure.
• Who funds reliability engineering and recurring improvement.
• Which conditions trigger escalation, service transfer, or architectural review.

Application and product owners remain accountable for business requirements. SRE engineers advise on technical feasibility and may operate agreed services. Security teams retain authority over security controls, while finance and platform leadership may evaluate infrastructure cost and capacity decisions.

SRE metrics and performance evaluation

Indicator	What it shows	Interpretation caution
SLO attainment	Whether a service meets its specified reliability target	Invalid when SLIs or measurement windows are inconsistent
Error budget consumption	Amount of permitted failure used in the current window	Depends on the exact SLO population and exclusions
Incident frequency and severity	Number and consequence of service disruptions	Classification changes can distort trends
Time to detect	Delay between disruption onset and detection	Event onset may be uncertain in distributed systems
Time to restore	Time to recover agreed service functionality	Averages may conceal a few severe incidents
Change failure rate	Share of qualifying changes that cause defined failures	Definitions must match the delivery system and comparison period
Toil burden	Operational capacity consumed by repetitive work	Estimates and classifications require consistency
Recovery test attainment	Results of practical recovery exercises	Recovery plans alone do not prove capability

Metrics should be interpreted together. Fewer alerts do not necessarily mean fewer incidents; high SLO attainment may hide important journeys not covered by the SLI. Reliability investment should be guided by the services and failure modes that matter to users.

SRE and related disciplines

Discipline	Main concern	Relationship to SRE
DevOps	Collaboration, feedback, and efficient software delivery	Shares automation and cross-team ownership; SRE adds explicit reliability management practices
IT Service Management	Governance and operation of IT services	Provides related service processes and coordination structures
Incident Management	Restoring disrupted services and coordinating response	SRE contributes technical investigation, mitigation, and learning
Problem Management	Identifying and addressing the causes of incidents	SRE uses recurring incident evidence to improve system reliability
Cloud Architecture	Structural design of cloud workloads and platforms	SRE evaluates operational behavior and resilience of implemented architectures
Platform Engineering	Shared platforms and developer-facing capabilities	May provide deployment, observability, and reliability tooling used by SRE teams

Security, governance, and risk

Reliability decisions interact with privacy, cybersecurity, safety, and financial risk. A service can be available but still untrustworthy if it returns incorrect information, exposes personal data, or mishandles privileged actions. SLOs therefore should not substitute for security or compliance requirements.

High-impact operational actions require controlled access and appropriate approval. Automated remediation may be suitable for a well-tested, reversible condition but inappropriate for a destructive data operation. Incident communication and postmortem processes should preserve confidentiality while enabling organizational learning.

SRE and emerging technology

Modern distributed services, multi-cloud systems, and AI workloads introduce additional dependencies, failure modes, and observability challenges. Reliability indicators for AI services may include availability and latency alongside output validity, resource contention, or pipeline completion, depending on the service.

In October 2026, Google announced a second edition of its SRE book addressing modern cloud and AI infrastructure, evolving organizational models, and AI-assisted operations. This reflects an update to published guidance rather than a change in the basic principle of engineering for measurable reliability.

Common implementation challenges

Ambiguous service ownership. Reliability can become a disputed responsibility between developers, platform teams, vendors, and SRE specialists.

Metrics disconnected from user experience. Infrastructure dashboards can appear healthy while business transactions fail.

Too many alerts and too little engineering time. Reactive operational workloads can prevent teams from fixing the causes of repeated incidents.

Unclear error-budget policy. Error budgets have limited value when stakeholders disagree about measurement or consequences.

Premature automation. Unsafe scripts can amplify errors or remove opportunities for meaningful diagnosis.

Underfunded reliability improvements. Teams may recognize architectural fragility without capacity or authority to address it.

Confusing SRE with a team rename. Changing job titles without adopting engineering practices, accountability, and learning mechanisms produces little substantive improvement.

Illustrative example

Consider a hypothetical digital payments service with a 99.9 percent successful-transaction SLO over a 28-day window. A dependency failure causes transactions to time out. The incident team restores service using a tested fallback while SRE engineers investigate timeout patterns and error-budget consumption.

The postmortem identifies an untested dependency recovery path. Engineering adds failure testing and an alternative routing mechanism; the team updates alerts and runbooks. Leadership reviews whether the reliability improvements and release plan fit the remaining error budget and customer obligations.

The example shows how SRE joins immediate recovery, measurable reliability, engineering improvements, and controlled change.

See also

• DevOps
• IT Service Management (ITSM)
• Incident Management
• Problem Management
• Cloud Architecture
• Cloud Optimization
• Platform Engineering
• Service Level Management (SLM)