Technique
SLO et alerting
Pour : ingénieurs et SRE · architectes · managers d’équipe · métiers et produitPrérequis : Avoir lu L'observabilité en 10 minutes ou savoir ce qu'est une métrique.
Les pages précédentes ont présenté les signaux et leur transport, sur l’exemple d’un paiement trop lent. Il reste une question : à partir de quand ce paiement lent est-il un problème qui mérite de réveiller quelqu’un ? Les SLO donnent une réponse chiffrée.
Le vocabulaire et la méthode de cette page viennent des deux livres de Google sur le SRE (Site Reliability Engineering), cités en sources. SRE désigne une façon d’exploiter les systèmes en traitant la fiabilité comme un sujet d’ingénierie.
SLI, SLO, SLA en mots simples
Section intitulée « SLI, SLO, SLA en mots simples »SLI (service level indicator, indicateur de niveau de service) : une mesure de ce que vit l’utilisateur. On l’écrit le plus souvent comme une proportion : les bons événements divisés par tous les événements. Exemple : la part des paiements qui aboutissent en moins de 2 secondes.
SLO (service level objective, objectif de niveau de service) : la cible fixée pour ce SLI, sur une période. Exemple : 99,9 % des paiements aboutissent en moins de 2 secondes, sur 30 jours glissants. C’est un objectif interne.
SLA (service level agreement, accord de niveau de service) : un engagement contractuel envers un client, avec des conséquences s’il n’est pas tenu, par exemple des pénalités. Le SLA est en général moins exigeant que le SLO. L’écart laisse le temps de réagir avant de manquer à un contrat.
| Terme | Question | Exemple pour le paiement |
|---|---|---|
| SLI | Qu’est-ce que je mesure ? | part des paiements réussis en moins de 2 s |
| SLO | Quel niveau je vise ? | 99,9 % sur 30 jours glissants |
| SLA | Qu’ai-je promis par contrat ? | 99,5 % par mois, sinon pénalité (illustratif) |
Un bon SLI se mesure au plus près de l’utilisateur. Le taux de réussite vu par le service checkout vaut mieux que l’état de santé d’un serveur.
Le budget d’erreur
Section intitulée « Le budget d’erreur »Viser 99,9 %, c’est accepter 0,1 % d’échecs. Cette part tolérée s’appelle le budget d’erreur (error budget).
Le calcul classique est le suivant. Une période de 30 jours compte 30 × 24 × 60 = 43 200 minutes. 0,1 % de 43 200 minutes font 43,2 minutes. Un SLO de 99,9 % sur 30 jours laisse donc environ 43 minutes de panne totale, ou l’équivalent en panne partielle.
| SLO sur 30 jours | Budget d’erreur | Équivalent en temps |
|---|---|---|
| 99 % | 1 % | 7 h 12 min |
| 99,5 % | 0,5 % | 3 h 36 min |
| 99,9 % | 0,1 % | 43 min |
| 99,95 % | 0,05 % | 21 min 36 s |
| 99,99 % | 0,01 % | 4 min 19 s |
Ces valeurs sont calculées. Chaque « 9 » supplémentaire divise le budget par dix.
Quand le SLI compte des requêtes plutôt que du temps, le budget se lit en requêtes. Sur un million de paiements, 99,9 % autorise 1 000 échecs.
Le budget est un outil de décision. Tant qu’il en reste, l’équipe peut livrer et prendre des risques. Quand il est épuisé, elle donne la priorité à la fiabilité. Cette règle doit être écrite et acceptée à l’avance, c’est la politique de budget d’erreur.
Alerter sur les symptômes, pas sur les causes
Section intitulée « Alerter sur les symptômes, pas sur les causes »Une cause est un état technique : un processeur à 90 %, un disque presque plein, un redémarrage. Un symptôme est ce que vit l’utilisateur : des paiements en échec ou trop lents.
Le livre Site Reliability Engineering recommande d’alerter sur les symptômes et de garder les causes pour le diagnostic (Monitoring Distributed Systems). Un processeur à 90 % qui ne ralentit aucun paiement ne mérite pas de réveiller quelqu’un. À l’inverse, des paiements lents méritent une alerte, même si tous les serveurs semblent sains.
Dans notre exemple, la banque répond lentement. Aucune machine n’est saturée. Une alerte sur le CPU ne se serait jamais déclenchée. Une alerte sur le SLO de paiement, si.
Alerter sur la vitesse de consommation du budget
Section intitulée « Alerter sur la vitesse de consommation du budget »Alerter dès qu’une erreur apparaît réveillerait l’astreinte sans cesse. Attendre que le budget soit épuisé serait trop tard. La solution consiste à mesurer la vitesse à laquelle on consomme le budget.
Cette vitesse s’appelle le burn rate (taux de consommation). À 1, le budget s’épuise exactement à la fin de la période. À 2, il s’épuise en deux fois moins de temps, soit 15 jours sur une période de 30 jours. Plus le burn rate est élevé, plus l’alerte est urgente.
Le chapitre Alerting on SLOs du Site Reliability Workbook compare plusieurs méthodes d’alerte. Il aboutit aux alertes multi-fenêtres et multi-burn rate. Le principe tient en trois idées.
- Plusieurs vitesses. Une consommation très rapide appelle l’astreinte. Une consommation lente ouvre un ticket traité en heures ouvrées.
- Une fenêtre longue. Pour chaque vitesse, on mesure le burn rate sur une fenêtre assez longue pour ignorer un pic isolé.
- Une fenêtre courte. On vérifie aussi le burn rate sur une fenêtre plus courte, environ un douzième de la longue selon le workbook. L’alerte s’arrête vite quand le problème est réglé.
Pour un SLO de 99,9 % sur 30 jours, le workbook propose ces paramètres comme point de départ :
| Action | Fenêtre longue | Fenêtre courte | Burn rate | Budget consommé à l’alerte |
|---|---|---|---|---|
| Appel | 1 heure | 5 minutes | 14,4 | 2 % |
| Appel | 6 heures | 30 minutes | 6 | 5 % |
| Ticket | 3 jours | 6 heures | 1 | 10 % |
Pour lire la première ligne : à un burn rate de 14,4, une heure consomme 14,4 / 720 = 2 % du budget de 30 jours (720 heures). À ce rythme, le budget entier tient environ deux jours.
flowchart TD
E["Taux d'erreur du SLI"] --> R["Burn rate sur<br/>fenêtres longue et courte"]
R --> Q{"Les deux fenêtres<br/>dépassent le seuil ?"}
Q -->|"burn rate élevé"| P["Appel de l'astreinte"]
Q -->|"burn rate faible mais durable"| T["Ticket"]
Q -->|"non"| D["Tableau de bord seulement"]
Le simulateur de budget d’erreur applique ces règles à un incident que vous réglez vous-même. Il montre qu’une panne franche déclenche l’appel en quelques minutes et qu’une dégradation lente ouvre seulement un ticket.
Choisir un premier SLO
Section intitulée « Choisir un premier SLO »Voici la démarche que je recommande pour un premier SLO. Elle reste volontairement modeste.
- Choisir un parcours qui compte. Un seul, important pour les utilisateurs et le métier. Le paiement est un bon candidat. La page d’accueil d’un outil interne l’est moins.
- Écrire le SLI en mots simples. « La part des paiements qui aboutissent en moins de 2 secondes. » Si la phrase n’est pas claire pour le métier, le SLI ne l’est pas non plus.
- Mesurer avant de viser. Regarder la fiabilité réelle sur les dernières semaines. Une cible tirée au hasard sera soit intenable, soit sans intérêt.
- Fixer une cible un peu en dessous du constaté. Si le service tient 99,95 %, viser 99,9 % laisse une marge. Viser 100 % n’a pas de sens : aucun budget, aucune livraison possible.
- Écrire la politique de budget. Qui décide de ralentir les mises en production quand le budget est épuisé ? Avant l’incident, pas pendant.
- Brancher les alertes burn rate sur ce SLO, puis retirer les alertes de cause qui font doublon.
- Réviser après un trimestre. Le premier SLO est rarement le bon. C’est normal.
Pour aller plus loin
Section intitulée « Pour aller plus loin »- Simulateur de budget d’erreur : régler un SLO, simuler un incident, voir les alertes se déclencher.
- Une astreinte soutenable : ce que les alertes sur SLO changent pour les personnes d’astreinte.
- Simulateur de fatigue d’alerte : estimer la charge d’une semaine d’astreinte.
- SLO de qualité : appliquer la même logique à la qualité des réponses d’un service d’IA.
- L’observabilité en 10 minutes et OpenTelemetry de bout en bout : les signaux sur lesquels reposent les SLI.
- Le glossaire définit SLI, SLO, budget d’erreur et burn rate.
- Beyer, Jones, Petoff et Murphy (dir.), Site Reliability Engineering, O’Reilly, 2016 : chapitre 4, Service Level Objectives et chapitre 6, Monitoring Distributed Systems.
- Beyer, Murphy, Rensin, Kawahara et Thorne (dir.), The Site Reliability Workbook, O’Reilly, 2018 : chapitre 2, Implementing SLOs et chapitre 5, Alerting on SLOs (tableau des paramètres recommandés pour un SLO de 99,9 % sur 30 jours).
- Les budgets du tableau « SLO sur 30 jours » sont calculés à partir d’une période de 43 200 minutes.