SRE
Site Reliability Engineering. An approach to IT operations that applies software engineering practices to infrastructure and operations problems.
Detailed Explanation
SRE was created at Google to apply software engineering principles to operations. SRE teams write code to solve operational problems, automate toil (repetitive manual tasks), and use SLIs/SLOs/SLAs to manage reliability. The key innovation is the error budget: if the SLO is 99.9%, the error budget is 0.1%. As long as you're within budget, you can ship features faster. If you exceed it, you must focus on reliability.
SRE practices: monitoring and alerting, incident management, capacity planning, change management, and automation. SRE is a specific implementation of DevOps with a focus on reliability and measurable outcomes.
Why It Matters
SRE provides a structured, data-driven approach to reliability. It balances the need for rapid feature delivery with the need for system stability.
Real-World Example
An SRE team defines an SLO of 99.95% availability for their API. They track error rates and when the error budget is consumed, they pause feature releases and focus on reliability improvements until the budget recovers.
When to Use
For teams operating production systems where reliability is critical. SRE practices scale from small teams to large organizations.
Advantages
- Data-driven reliability decisions
- Balances speed and stability
- Automates operational toil
- Clear accountability for reliability
- Measurable outcomes
Disadvantages
- Requires engineering expertise in operations
- Can be bureaucratic for small teams
- SLO definition requires careful thought
- Error budget tracking adds overhead
- Cultural shift from traditional operations
Related Terms
Frequently Asked Questions
What is the difference between SRE and DevOps?
DevOps is a culture and set of practices. SRE is a specific implementation of DevOps that adds structure, measurement, and error budgets. SRE is "what happens when you treat operations as a software engineering problem."
What are SLIs, SLOs, and SLAs?
SLIs are what you measure (latency, error rate). SLOs are targets (99.9% availability). SLAs are commitments to customers (with consequences for missing them). SLIs feed SLOs; SLOs inform SLAs.
What is an error budget?
The error budget is the allowed amount of unreliability. If your SLO is 99.9%, you can afford 0.1% downtime. If you exhaust the budget, you must prioritize reliability over features until it recovers.
What is toil in SRE?
Toil is manual, repetitive, automatable work that has no lasting value (manual deployments, ticket processing, log analysis). SRE aims to automate toil so engineers focus on engineering work.
Do I need an SRE team?
Not necessarily. Small teams can adopt SRE practices (SLIs, SLOs, error budgets) without a dedicated team. Larger organizations benefit from dedicated SRE teams to manage complex production systems.