DevOps & Kubernetes (50 Qs)•Part 5: Infrastructure as Code, SRE Observability & Production Troubleshooting (43 - 50)
Site Reliability Engineering (SRE): SLI vs. SLO vs. SLA, Error Budgets, and Burn Rate alerting.
Reliability Engineering Foundations
Google's Site Reliability Engineering (SRE) framework replaces arbitrary uptime goals with mathematical error budgets.
sql
+-------------------------------------------------------------------------------+
| The SRE Service Level Hierarchy |
| |
| 1. SLI (Indicator): Actual measured real-time performance. |
| Example: 99.94% of HTTP requests returned < 200ms. |
| |
| 2. SLO (Objective): Internal target set by engineering & product. |
| Example: 99.9% success rate over rolling 30 days. |
| |
| 3. SLA (Agreement): External legal contract with customers. |
| Example: 99.0% uptime; violation triggers credits. |
| |
| 4. Error Budget: Acceptable unreliability (100% - SLO). |
| 99.9% SLO = 0.1% Error Budget (43.2 mins/month). |
+-------------------------------------------------------------------------------+
Error Budget Burn Rate Alerting
Alerting on raw threshold spikes (e.g. "error rate > 1%") creates massive false positives during brief hiccups. SRE standardizes on Burn Rate Alerting:
- Burn Rate 1: Consumes 100% of the 30-day budget in exactly 30 days.
- Burn Rate 14.4: Consumes 100% of the 30-day budget in 2 days (2% of budget consumed in 1 hour).
- Multi-Window Multi-Burn-Rate Alert: Pages an on-call engineer only if a high burn rate is confirmed across both a short window (e.g., 5m) and a long window (e.g., 1h), virtually eliminating phantom alerts.