Site Reliability Engineering Foundations
Site Reliability Engineering Foundations
This domain tests whether you can translate reliability into measurable objectives and use error budgets to make release and operations decisions on IBM Cloud.
Core rules
- An SLI is a measured ratio of good events to valid events, such as successful HTTP responses divided by all responses. An SLO is the target for that SLI over a window. An SLA is a contractual consequence, not an engineering target.
- Error budget = 1 − SLO. A 99.9% availability SLO over 30 days allows about 43.2 minutes of unavailability.
- Burn rate expresses how fast the budget is consumed relative to the SLO window. A burn rate of 2 means the budget would be exhausted in half the window.
- Toil is manual, repetitive, automatable work. Cap it and automate it; do not treat heroics as reliability.
- Postmortems are blameless and focus on contributing causes and actions.
Worked example
A service has a 99.9% monthly availability SLO, measured by a synthetic check. By day 7, 20 minutes of downtime have occurred. Remaining budget = 43.2 − 20 = 23.2 minutes. The observed burn rate is high because 20 minutes in 7 days projects far more than 43.2 minutes over 30 days. The team freezes risky releases and prioritizes the failing dependency, rather than waiting for the month to end.
Traps
Do not confuse an SLA with an SLO; the SLA may be looser and carries commercial credits. Do not average away short outages across a long window. Do not measure host uptime when users experience failed requests. Do not spend the entire error budget on planned changes without reserving capacity for incidents.