Error Budget

Un Error Budget (budget d'erreur) est la quantité de défaillance qu'un service peut se permettre sur une période donnée tout en respectant son SLO (Service Level Objective). Concept central de la culture SRE (Site Reliability Engineering) popularisé par Google. Formule : Error Budget = 100% - SLO.

Exemple : SLO availability = 99.9% sur 30 jours → Error Budget = 0.1% downtime = 43.2 minutes de downtime autorisé par mois. Si SLO success rate = 99.5% pour API → 0.5% des requêtes peuvent échouer = 5000 erreurs / 1M requests.

Utilisation principale : créer une tension productive entre vélocité d'innovation (releases fréquentes potentiellement risquées) et stabilité du service. Règle simple :
(1) Budget restant > 50% du quota mensuel → équipe peut prendre des risques (deploys agressifs, refactors majeurs, feature flags activés rapidement, expérimentations) — encourager innovation.
(2) Budget < 25% restant → freeze des releases non-critiques, focus reliability work (fix flaky tests, reduce alert noise, harden infrastructure, post-mortems action items).
(3) Budget consommé → seuls hotfixes et reliability improvements autorisés. "Error budget exhausted" déclenche review formelle, parfois rollback features récentes.

Multi-burn-rate alerting (Google SRE Workbook ch.5) : au lieu d'alerter sur threshold static ("latency p99 > 500ms"), alerter sur consommation rapide du budget. Exemple pour SLO 99.9% sur 30j :
- Fast burn : 2% du budget consommé en 1h → page incident (would consume entire month budget in 6h if continued).
- Slow burn : 5% du budget consommé en 6h → ticket non-urgent.
- Trend alert : 10% en 3 jours → review at next sprint planning.

Avantages :
(1) Quantifies tradeoff entre reliability et velocity — décisions data-driven vs intuition ; (2) Aligns engineering et product avec customer experience (SLO matches what users notice) ; (3) Replaces blame culture by budget conversation ("we ran out of budget, let's investigate why") ; (4) Naturally throttles risky deploys après incidents ; (5) Encourages investment dans reliability (chaos engineering, observability, automation) plutôt que feature factory mindset.

Pièges à éviter :
(1) SLOs trop conservateurs (99.999% pour internal tool) → budget jamais consommé, perd son utilité comme outil de décision.
(2) SLOs trop laxistes → budget toujours plein, no pressure on reliability.
(3) Mesurer mauvais signal (uptime simpliste vs user-facing journey success) → budget green mais users frustrated.
(4) Pas d'action quand budget brûlé → SLOs ignorés, pure theatre.
(5) Ignorer plan releases (calculer budget weekly window au lieu de monthly) → moins de signal noise mais moins reactive.

Tools : (1) SLO platforms — Nobl9, Datadog SLOs, Grafana SLO/Pyrra (open source), Honeycomb SLOs, Google Cloud SLO Monitoring, Sloth (open source). (2) Custom dashboards Prometheus + recording rules pour calculer burn rate continu. (3) Multi-burn-rate alerts dans Alertmanager.

Link to DORA metrics : error budget consumption complémentaire à Change Failure Rate (les deux mesurent stabilité), MTTR (vitesse récupération), Deploy Frequency (vélocité). Mature orgs track tous.