Unit
- Origins: SRE was born at Google in 2003 when software engineers were asked to run and maintain production systems. The role formalized the idea that operations problems are software problems, solvable through engineering approaches rather than manual toil.
- Core Principle: SRE applies software engineering practices to infrastructure and operations work. This means building automation, creating self-service tooling, and reducing manual intervention through code-driven solutions for routine tasks.
- Key Metric: The primary measure of SRE success is the time-to-repair and the reduction of operational workload. Teams track how much time is spent on reactive work versus proactive engineering improvements.
- Error Budget: An error budget is the acceptable amount of downtime or failure within a given period. It is derived from the Service Level Objective (SLO) and empowers teams to decide when to focus on reliability versus feature velocity.
- Toil: Toil refers to manual, repetitive, automatable work with no enduring value. SRE explicitly aims to reduce toil below 50% of team time, freeing engineers to build systems that prevent future incidents.
- SRE vs DevOps: While DevOps emphasizes cultural and collaborative practices, SRE provides a concrete implementation framework with specific roles, metrics, and operational playbooks that operationalize DevOps principles at scale.
- Service Level Terminology: SLIs (Service Level Indicators) are raw measurements of service behavior. SLOs (Service Level Objectives) are target values for those indicators. SLAs (Service Level Agreements) are contractual commitments to customers, often stricter than internal SLOs.
- Reliability Spectrum: Not all systems need 99.999% uptime. SRE helps teams choose appropriate reliability targets based on business impact, cost of downtime, and engineering effort required to achieve higher tiers of availability.
System Architecture
Pattern: SRE as a function within the organization
Components:
- Development Teams: Build features and ship code; rely on SRE for production readiness reviews and operational guidance.
- SRE Team: Owns service reliability, defines SLOs, builds automation, conducts blameless postmortems, and manages incident response.
- Operations Center: Centralized monitoring dashboards, alert routing, and escalation policies managed by SRE tooling.
- Infrastructure Platform: Cloud resources, CI/CD pipelines, and configuration management systems that SRE automates and maintains.
- Feedback Loop: Incident data and system metrics feed back into development to improve code quality and resilience.
Quick Revision
- SRE originated at Google to apply software engineering to operations.
- Error budgets define acceptable downtime and guide reliability investments.
- Reducing toil is a primary goal of SRE teams.
- SRE provides a concrete framework to implement DevOps practices.