What Is Site Reliability Engineering (SRE)?
Learn what Site Reliability Engineering is, how SLOs and error budgets work, and how SRE balances shipping features against system stability.
Expected Interview Answer
Site Reliability Engineering (SRE) is a discipline, pioneered at Google, that applies software engineering practices to operations, using measurable reliability targets like SLOs and error budgets to balance shipping new features against keeping systems stable.
SREs treat operational problems as engineering problems, automating toil, defining service level objectives, and tracking an error budget that quantifies how much unreliability is acceptable before the team must pause feature work to invest in reliability. This data-driven approach replaces vague 'be careful' operations culture with explicit, negotiated reliability targets shared between engineering and product teams.
- Replaces vague reliability goals with measurable SLOs
- Error budgets balance feature velocity against stability
- Automates repetitive operational toil with software
- Creates shared accountability between dev and ops
- Uses blameless postmortems to improve systemically
AI Mentor Explanation
SRE is like a franchise's sports-science team that sets a measurable injury-risk budget for the squad each season, deciding exactly how much training load players can safely absorb before selectors must ease up rather than push for one more warm-up match. When the budget is close to exhausted, training intensity is dialed back instead of relying on a vague 'be careful' instruction.
Step-by-Step Explanation
Step 1
Define SLIs
Choose service level indicators — measurable signals like latency or error rate.
Step 2
Set SLOs
Agree on service level objectives, target thresholds for those indicators over time.
Step 3
Track the error budget
The gap between 100% reliability and the SLO becomes the acceptable error budget.
Step 4
Balance velocity and stability
When the error budget is healthy, teams ship features; when it's exhausted, they prioritize reliability work.
Step 5
Run blameless postmortems
After incidents, teams analyze root causes without blame to improve systems, not punish individuals.
What Interviewer Expects
- Defines SRE as applying engineering discipline to operations
- Explains SLIs, SLOs, and error budgets clearly
- Understands how error budgets gate feature releases
- Knows SRE emphasizes automation over manual toil
- Mentions blameless postmortems as a cultural practice
Common Mistakes
- Confusing SRE with just a rebranded ops or sysadmin role
- Not distinguishing SLIs, SLOs, and SLAs
- Thinking error budgets mean ignoring reliability entirely
- Assuming SRE is only relevant at very large companies
Best Answer (HR Friendly)
“Site Reliability Engineering is a discipline that treats keeping systems stable and reliable as an engineering problem, using clear measurable targets to decide when to focus on new features versus when to invest in fixing and strengthening the system.”
Code Example
slo:
name: api-availability
target: 99.9%
window: 30d
sli:
metric: successful_requests / total_requests
error_budget_minutes: 43.2Follow-up Questions
- What is the difference between an SLI, an SLO, and an SLA?
- How does an error budget influence release decisions?
- What is toil, and why do SRE teams try to automate it away?
- How does a blameless postmortem differ from a traditional incident review?
- How does SRE differ from traditional DevOps in practice?
MCQ Practice
1. What does SRE stand for?
SRE stands for Site Reliability Engineering, a discipline pioneered at Google.
2. What is an error budget?
The error budget quantifies how much downtime or failure is acceptable within an SLO window before reliability work takes priority.
3. What is a core cultural practice in SRE?
Blameless postmortems focus on fixing systemic causes of incidents rather than assigning individual blame.
Flash Cards
What is SRE? — A discipline applying engineering practices to operations and reliability.
What is an SLO? — A service level objective — a target threshold for a measured indicator.
What is an error budget? — The acceptable amount of unreliability before pausing new feature work.
What is a blameless postmortem? — An incident review focused on systemic fixes, not individual blame.