Bonne pratique3 min de lecture · Mis à jour le 29 sept. 2026
SLI, SLO et alerting par burn rate — bonnes pratiques
Définir des SLI pertinents, fixer des SLO réalistes, gérer un budget d'erreur et alerter sur le taux de consommation plutôt que sur des seuils.
- #observability
- #high-availability
Vocabulaire
- SLI : mesure de la qualité perçue par l'utilisateur (proportion de requêtes réussies en moins de 300 ms).
- SLO : objectif sur une fenêtre (99,9 % sur 30 jours).
- Budget d'erreur :
1 − SLO→ 0,1 % de 30 jours ≈ 43 minutes d'indisponibilité équivalente. - SLA : engagement contractuel, toujours moins strict que le SLO interne.
Choisir les SLI
| Type de service | SLI recommandé |
|---|---|
| API / web | disponibilité (non-5xx), latence p95/p99 |
| Traitement batch | fraîcheur des données, taux de succès des exécutions |
| Stockage | durabilité, latence de lecture |
Mesurez au plus près de l'utilisateur (répartiteur de charge, sondes synthétiques), pas sur le CPU.
Alerter sur le burn rate
Le burn rate est la vitesse de consommation du budget : 1 = budget épuisé exactement en fin de fenêtre ; 14,4 = épuisé en ~2 jours.
Approche multi-fenêtres (Google SRE Workbook) :
| Sévérité | Burn rate | Fenêtre longue | Fenêtre courte | Budget consommé |
|---|---|---|---|---|
| Page | 14,4 | 1 h | 5 min | 2 % |
| Page | 6 | 6 h | 30 min | 5 % |
| Ticket | 1 | 3 j | 6 h | 10 % |
(
sum(rate(http_requests_total{code=~"5.."}[1h])) / sum(rate(http_requests_total[1h]))
) > (14.4 * 0.001)
and
(
sum(rate(http_requests_total{code=~"5.."}[5m])) / sum(rate(http_requests_total[5m]))
) > (14.4 * 0.001)
La fenêtre courte garantit que l'alerte se résout vite une fois le problème corrigé.
Politique de budget
- Budget sain → on livre, on expérimente.
- Budget épuisé → gel des changements risqués, priorité à la fiabilité.
- Revue mensuelle : SLO atteint ? trop facile ? trop dur ?
Anti-patterns
Alertes sur des causes (CPU > 80 %) qui réveillent sans impact utilisateur ; SLO à 100 % ; dizaines de SLO par service que personne ne lit.