Construire un budget d'erreur
Calculer un budget d'erreur à partir d'un SLO et l'utiliser comme monnaie de décision partagée.
À retenir
- Le budget d'erreur = 100 % moins le SLO, exprimé en temps tolérable sur la fenêtre choisie.
- Chaque neuf supplémentaire de SLO divise le budget d'erreur par dix.
- Le burn rate mesure la vitesse de consommation du budget, plus utile pour alerter tôt que le seuil final.
- Des alertes multi-fenêtres sur le burn rate détectent une dérive avant l'épuisement complet.
Le budget d'erreur, monnaie commune
Le budget d'erreur (error budget) est la quantité d'indisponibilité ou de dégradation tolérée par le SLO avant que celui-ci ne soit violé. C'est la différence entre 100 % et l'objectif du SLO, exprimée en temps ou en proportion d'événements.
Calcul de base
Pour un SLO de disponibilité de 99,9 % sur 30 jours :
- Budget d'erreur = 100 % − 99,9 % = 0,1 %
- Minutes dans 30 jours = 30 × 24 × 60 = 43 200 minutes
- Budget d'erreur en temps = 43 200 × 0,001 = 43,2 minutes d'indisponibilité tolérée sur 30 jours
Pour un SLO plus exigeant de 99,99 % sur la même période :
- Budget d'erreur = 0,01 % → 43 200 × 0,0001 = 4,32 minutes sur 30 jours
Point clé
chaque « neuf » supplémentaire (99,9 % → 99,99 %) divise le budget d'erreur par dix ; le coût d'ingénierie pour gagner ce neuf supplémentaire croît généralement bien plus vite que proportionnellement.
Suivi de la consommation
Le budget d'erreur se consomme en continu et se reconstitue sur une fenêtre glissante. Une requête PromQL typique pour suivre la consommation cumulée :
1 - (
sum(increase(http_requests_total{status!~"5.."}[30d]))
/
sum(increase(http_requests_total[30d]))
)
Si le résultat dépasse le budget d'erreur cible (ex. 0,001 pour un SLO à 99,9 %), le budget est épuisé.
Burn rate : vitesse de consommation
Le taux de consommation (burn rate) indique à quelle vitesse le budget disparaît. Un burn rate de 1 signifie que le budget se consomme exactement au rythme prévu pour tenir 30 jours ; un burn rate de 10 signifie qu'il sera épuisé en 3 jours au lieu de 30.
| Burn rate | Budget épuisé en | Sévérité |
|---|---|---|
| 1x | 30 jours (rythme nominal) | Normal |
| 6x | 5 jours | Alerte à surveiller |
| 14,4x | ~2 jours | Alerte urgente (page immédiate) |
| 36x | ~20 heures | Incident critique |
Attention
alerter uniquement sur le franchissement du seuil final du SLO (ex. « 99,9 % déjà dépassé ») arrive trop tard ; les alertes basées sur le burn rate multi-fenêtres (courte et longue) permettent de détecter une dérive avant l'épuisement complet, comme recommandé par Google SRE.
Exemple chiffré complet
Un service avec SLO 99,9 % sur 30 jours (budget 43,2 minutes) subit un incident de 25 minutes en semaine 1. Il reste 43,2 − 25 = 18,2 minutes de budget pour les 23 jours restants. Si un second incident de 20 minutes survient en semaine 2, le budget est dépassé de 1,8 minute : le SLO est violé pour la fenêtre en cours.
Sur le terrain
dans une équipe produit, présenter le budget d'erreur restant en minutes concrètes (« il reste 18 minutes de panne tolérée ce mois-ci ») est bien plus parlant pour des décideurs non techniques qu'un pourcentage abstrait à trois décimales.
Astuce
publiez le budget d'erreur consommé sur un dashboard visible de toute l'équipe produit, pas seulement de l'équipe SRE ; cela transforme la fiabilité en décision partagée plutôt qu'en sujet réservé aux ingénieurs.