Error budgets SRE : SLI, SLO et burn rate

À la fin de ce tutoriel, vous saurez poser un error budget SRE chez DevOps Elastic Hayway (DEH) : SLI / SLO / budget, SLI API + batch, calcul 99,9 %, burn rate multi-fenêtres, ship vs freeze, lab CloudWatch ca-central-1. Contrat opérationnel DEH, pas un résumé du Google SRE Book.

Niveau : Intermédiaire · Temps : 55–75 min · Versions : AWS CLI v2 · CloudWatch · Prometheus (variante) · Vérifié : 2026-09-11 · Region : ca-central-1

Slug : wow-sre-error-budgets · Série : WOW (28/50) · Mot-clé SEO : error budgets sre · Publish : READY (feu vert Maître)

← Précédent : Incident runbooks · → Suivant : Chaos Engineering Litmus · Aussi : Step Functions SRE

Prérequis

• Alarming — CloudWatch alarmes
• Cluster — Prometheus / Grafana Helm
• Fiabilité — Well-Architected
• Remédiation — Step Functions SRE
• Lab (AWS_PROFILE=lab) — Démarrer avec AWS

Coût : ~0 €. Cleanup obligatoire.

export AWS_PROFILE=lab
export AWS_DEFAULT_REGION=ca-central-1
aws sts get-caller-identity

Ce que nous allons construire

Error budgets SRE (WOW 28/50) — ca-central-1
  ├── SLI / SLO / budget DEH · SLI API + batch
  ├── Budget 99,9 % · burn multi-fenêtres · ship/freeze
  ├── Lab CloudWatch deh-wow28- · escalade blameless
  └── Anti-patterns + checklist + quiz + FAQ

(Schéma — alt : « SLI → SLO 99,9 % → error budget → burn rate → ship ou freeze, ca-central-1 ».)

Étape 1 — SLI, SLO, error budget : contrat DEH

Chez DEH ces termes ne sont pas interchangeables. SLI faux rend le SLO cosmétique.

Terme	Définition opérationnelle DEH	Ce que ce n’est pas
SLI	Mesure user d’un parcours (ratio good, p99, âge data)	CPU, heap, 5xx sans dénominateur
SLO	Cible sur un SLI sur 28/30 j	Promesse commerciale
Error budget	1 − SLO : échec autorisé avant freeze	Quota d’incidents « on a le droit »
SLA	Contrat externe (crédits)	Objectif interne

SLI_availability = good_events / valid_events
error_budget     = 1 − SLO
budget_restant   = error_budget − (bad / valid)

Good = 2xx/3xx dans le SLO latence. Valid = hors 4xx client (un 504 est bad, un 401 non). Batch : minutes où le job est frais (Well-Architected).

Étape 2 — Choisir des SLI (API + batch)

On nomme le parcours, pas le microservice.

Parcours	SLI	Good event	Fenêtre
API /checkout	Availability	2xx/3xx et p99 < 300 ms	28 j
API	Latency p99	latency ≤ seuil	28 j
Batch ETL	Freshness	watermark < 2 h	30 j
Batch	Completeness	rows_ok / attendues ≥ 99,5 %	30 j

API (ALB / API Gateway, ca-central-1) :

valid = Count(2XX+3XX+5XX)          # hors 4xx
good  = 2XX+3XX ET p99 < 300ms
SLI   = good / valid     SLO = 99,9 %

Batch (suite WOW 22 Step Functions) :

good_minute = watermark_S3 < 2 h ET execution Succeeded
SLI_fresh   = minutes_good / minutes_fenêtre     SLO = 99,5 %

Règle DEH : un SLO par parcours. CPU ALB ≠ SLI.

Étape 3 — Calculer un budget d’erreur

SLO 99,9 % / 30 j = 0,1 % d’échec autorisé.

SLO	Budget 30 j (time)	Request-based (10 M req)
99 %	~7 h 18 min	100 000
99,9 %	~43 min	10 000
99,95 %	~21 min 36 s	5 000
99,99 %	~4 min 19 s	1 000

99,9 % = défaut API DEH. 99,99 % (~4 min/mois) n’est pas « plus pro » : freeze au premier incident, sauf multi-AZ + runbooks (WOW 22). APIs : request-based. Jobs binaires : time-based.

Étape 4 — Burn rate / multi-window alerting

Burn rate = error_rate_courant / error_budget. SLO 99,9 % → budget 0,1 %. Error rate 1,4 % → burn 14×.

Un burn 14,4× épuise 30 j en ~50 h. 1× = on vit au SLO. < 1 = marge pour shipper.

Alerte	Fenêtres	Burn	Sens DEH
Page P1	1 h et 5 min	14,4×	Incident, budget 30 j en ~2 j
Ticket P2	6 h et 30 min	6×	Dégradation lente
Watch	24 h et 2 h	3×	Tendance, pas de page 3 h
Info	3 j et 6 h	1×	Collé au SLO

Deux fenêtres : spike 2 min ne page pas ; burn 1 h + 5 min chaud, si. Transposé en CloudWatch / Prometheus.

Variante Prometheus (EKS) : recording deh:sli:availability:ratio5m puis alerte si (1-ratio)/(1-0.999) > 14.4 sur 5 m et 1 h (job deh-wow28-api). Détail Helm : Prometheus / Grafana.

Étape 5 — Budget ↔ vitesse de release

Le budget est un interrupteur produit, pas un KPI vanity.

Budget restant (28 j)	Décision DEH
> 50 %	Ship : features, dettes assumées
20–50 %	Canary, flags, pas de big-bang
< 20 % ou page 14×	Freeze features : fiabilité only
0 %	Freeze + incident + post-mortem blameless

Jamais brûlé de budget ≈ pas assez de ship. Toujours à 0 % ≈ SLO trop haut ou produit fragile. Freeze écrit (deh-wow28-freeze) et daté.

Étape 6 — Lab ca-central-1 : CloudWatch + alarme burn

Publier un SLI deh-wow28 ; alarme lab si burn > 6× / 5 min.

6.1 — Points SLI

export AWS_PROFILE=lab
export AWS_DEFAULT_REGION=ca-central-1
NS=DEH/WOW23
DIM=Name=Service,Value=deh-wow28-api

# 2 bad / 1000 → burn 2× (OK)
aws cloudwatch put-metric-data --namespace "$NS" 
  --metric-data MetricName=ValidCount,Value=1000,Unit=Count,Dimensions=$DIM 
               MetricName=BadCount,Value=2,Unit=Count,Dimensions=$DIM

6.2 — Alarme (seuil lab BadCount, proxy burn)

aws cloudwatch put-metric-alarm --alarm-name deh-wow28-burn-6x 
  --namespace DEH/WOW23 --metric-name BadCount --dimensions $DIM 
  --statistic Sum --period 300 --evaluation-periods 1 --threshold 6 
  --comparison-operator GreaterThanThreshold --treat-missing-data notBreaching

Prod : Metric Math bad/valid > 0.006 (burn 6×). Lab : BadCount > 6 / 5 min.

6.3 — Brûler puis vérifier

# 20 bad → burn 20× → ALARM
aws cloudwatch put-metric-data --namespace "$NS" 
  --metric-data MetricName=ValidCount,Value=1000,Unit=Count,Dimensions=$DIM 
               MetricName=BadCount,Value=20,Unit=Count,Dimensions=$DIM
sleep 15
aws cloudwatch describe-alarms --alarm-names deh-wow28-burn-6x 
  --query 'MetricAlarms[0].{State:StateValue,Reason:StateReason}' --output table

Prod : alarme → EventBridge → Step Functions / SNS.

6.4 — Cleanup

aws cloudwatch delete-alarms --alarm-names deh-wow28-burn-6x
# Custom metrics : expiration ~15 mois (pas de delete-metric).

Préfixe deh-wow28-. Region ca-central-1.

Étape 7 — Policy d’escalade (budget consommé)

Signal	Action DEH	Owner
Watch 3× / 24 h	Ticket deh-wow28-slo P3	Equipe
Ticket 6× / 6 h	P2, stop canary, revue 24 h	Tech lead + SRE
Page 14× / 1 h	Incident + runbook WOW 22 + freeze	On-call
Budget 28 j < 20 %	Freeze daté, backlog fiabilité	Produit + SRE
Budget = 0	Post-mortem blameless < 5 j	Facilitateur

Blameless : ce que le système a permis, pas qui a merge. Freeze levé si burn redescend et budget > 20 % (sauf sécu/légal).

Étape 8 — Anti-patterns + checklist prod DEH

Anti-patterns : SLO 100 % ; 5xx bruts sans burn ; SLI = CPU ; 4xx = panne ; SLA vendeur = SLO ; une fenêtre 5 min ; blâmer un burn décidé ; us-east-1.

Checklist : parcours user · SLI request- ou time-based · 4xx hors valid · SLO 99,9 % API · page 14,4× + ticket 6× · alarme deh-wow28- · policy ship/canary/freeze · escalade blameless · ca-central-1 · cleanup · Publish READY (feu vert Maître).

Erreurs fréquentes

Erreur	Impact	Correction
SLO 100 %	Freeze ou SLO fantôme	99,9 % + budget réel
4xx dans bad	Budget brûlé par le client	Exclure 4xx des valid
Alerte 5xx brute	Toil, pages inutiles	Ratio + 2 fenêtres
SLI = CPU	On soigne l’infra, pas l’user	Parcours /checkout
Une fenêtre 5 min	Faux positifs	1 h et 5 min
Blame du freeze	On cache les erreurs	Post-mortem blameless
Region us-east-1	Hors lab DEH	ca-central-1

Quiz (5 questions)

1. SLO 99,9 % / 30 j, budget time-based ≈
– A. 4 minutes
– B. 43 minutes
– C. 7 heures

2. Un SLI DEH mesure :
– A. Le CPU de l’ALB
– B. Un parcours user (good / valid)
– C. Le nombre de tickets Jira

3. Burn 14,4× sur 1 h et 5 min sert à :
– A. Remplacer CloudWatch
– B. Pager sans toil sur spike 2 min
– C. Facturer moins Prometheus

4. Region lab de ce tuto :
– A. us-east-1
– B. ca-central-1
– C. eu-west-3

5. Budget restant > 50 % chez DEH :
– A. Freeze immédiat
– B. Ship (vitesse normale)
– C. Post-mortem obligatoire

Réponses : 1‑B · 2‑B · 3‑B · 4‑B · 5‑B

FAQ

SLI, SLO, SLA en incident ?

SLI = mesure. SLO = cible interne. SLA = contrat. On pilote au SLO (SLA plus lâche).

Pourquoi 99,9 % et pas 99,99 % ?

43 min vs 4 min. 99,99 % exige multi-AZ, runbooks et un freeze accepté produit.

Request-based ou time-based ?

API variable → request-based. Job binaire → time-based. Un seul mode par SLO.

Prometheus obligatoire si 100 % AWS ?

Non. CloudWatch suffit. Prometheus si EKS.

Éviter de pager pour un spike 90 s ?

Fenêtres 1 h et 5 min. Spike isolé → pas de page. Burn soutenu → page.

Le freeze est-il un échec d’équipe ?

Non : c’est le contrat. L’échec = ignorer le freeze ou blâmer le commit.

Préfixe de tags lab ?

deh-wow28-. Cleanup / FinOps.

Publish de ce tuto ?

READY — feu vert Maître. URL : https://devopelastichayway.com/tutoriels/wow-sre-error-budgets/.

Pour aller plus loin

• Step Functions runbooks SRE
• EventBridge Patterns
• CloudWatch alarmes
• Prometheus / Grafana Helm
• Well-Architected

Maillage série WOW

← Précédent	Step Functions runbooks SRE
→ Suivant	EventBridge Patterns
Aussi	CloudWatch alarmes · Well-Architected

---

Meta publication (SEO)

• Title SEO : Error budgets SRE : SLI, SLO et burn rate (guide FR)
• Meta description : Error budgets SRE : SLI/SLO DEH, budget 99,9 %, burn rate, freeze vs ship, lab CloudWatch ca-central-1.
• Focus keyword : error budgets sre
• Image : cover-wow-sre-error-budgets-1200x630.webp (à générer)
• Catégorie : WOW / SRE · Niveau : Intermédiaire · Série : WOW 28/50
• URL cible : https://devopelastichayway.com/tutoriels/wow-sre-error-budgets/
• Slug : wow-sre-error-budgets
• Publish : READY (feu vert Maître) · Parent WP 5463