Site Reliability Engineering (SRE) is Google’s approach of applying software engineering to operations. Its guiding ideas:

• Reliability is a feature — measured with SLIs/SLOs and budgeted, not assumed
• Embrace risk — 100% reliability is the wrong target; an error budget defines acceptable unreliability and pace of change
• Eliminate toil — automate repetitive manual work so engineers build, not firefight
• Blameless culture — learn from incidents, fix systems not people
• Measure everything — you can’t improve what you don’t observe

The famous tension SRE resolves: developers want to ship fast, ops wants stability. The error budget turns that into a shared, data-driven agreement.

SRE in practice:
  Define SLO       → 99.9% of requests succeed
  Error budget     → 0.1% (≈43 min/month) of allowed failure
  Budget healthy   → ship features freely
  Budget exhausted → freeze features, focus on reliability
  Toil > 50%       → invest in automation to reduce it

1. Explain why 100% reliability is not the goal.
2. Define toil and give an example of eliminating it.
3. Describe how an error budget aligns dev and ops incentives.
4. Why is blameless culture important to reliability?

• ↗ Google SRE Book