Un budget d’erreur (error budget) est la part de non-fiabilité que votre SLO autorise sur une période : 100 % moins l’objectif. Un SLO de 99,9 % sur 30 jours laisse un budget d’erreur de 43 minutes 12 secondes d’indisponibilité, ou une requête en échec sur mille. Tant qu’il reste du budget, l’équipe peut livrer et prendre des risques. Quand il est épuisé, le travail de fiabilité passe en premier jusqu’à ce que la fenêtre se rétablisse.
Cette seule règle transforme un objectif de fiabilité en décisions. Ce guide montre comment calculer un budget d’erreur, ce qui doit le consommer et ce qui ne le doit pas, comment savoir à quelle vitesse vous le consommez, et comment rédiger une politique pour le moment où il est épuisé.
Comment calculer un budget d’erreur
Il vous faut deux choses : un SLO, l’objectif de fiabilité que vous vous fixez, et une fenêtre, la période sur laquelle il est mesuré. Le budget d’erreur est l’écart qui reste entre l’objectif et la perfection.
Error budget = (100% − SLO) × window
Pour un SLO de 99,9 % sur 30 jours (43 200 minutes) : 0,1 % × 43 200 = 43,2 minutes, soit 43 minutes 12 secondes. Le tableau applique le même calcul aux objectifs courants, arrondi à la seconde inférieure.
SLOBudget sur 30 joursBudget sur 90 jours99 %7 h 12 min21 h 36 min99,5 %3 h 36 min10 h 48 min99,9 min 12 s2 h 9 min 36 s99,95 min 36 s1 h 4 min 48 s99,99 %4 min 19 s12 min 57 s
Le calculateur de SLA et de disponibilité fait ce calcul pour n’importe quel objectif et n’importe quelle période. Il utilise le mois moyen (une année divisée par 12) : il affiche donc 43 minutes 49 secondes pour 99,9 % au lieu du chiffre sur 30 jours ci-dessus.
Basé sur le temps ou sur les requêtes
Un budget d’erreur peut se compter en deux unités, selon le SLI qui sous-tend votre SLO :
Basé sur le temps : des minutes d’indisponibilité, mesurées par des contrôles depuis l’extérieur. C’est simple, facile à expliquer et conforme à la façon dont la plupart des SLA clients sont rédigés. Un SLO mensuel de 99,9 % autorise environ 43 minutes.
Basé sur les requêtes : la part de requêtes en échec, comptée à partir des logs du load balancer ou de l’application. À 2 millions de requêtes par mois et 99,9 %, le budget est de 2 000 requêtes en échec. Il donne plus de poids aux heures chargées qu’aux heures creuses, ce qui est plus proche du ressenti des utilisateurs, mais il exige des logs fiables.
Beaucoup d’équipes utilisent les deux : un budget basé sur le temps, issu de contrôles externes, pour le service dans son ensemble, et des budgets basés sur les requêtes pour les endpoints les plus importants, comme le paiement ou l’API.
Pourquoi se doter d’un budget d’erreur
Sans budget, la fiabilité est un sujet de débat. Le produit veut livrer, l’ingénierie veut ralentir, et c’est celui qui parle en dernier qui l’emporte. Un budget remplace le débat par un chiffre sur lequel les deux camps se sont mis d’accord à l’avance.
Il fait de 100 % le mauvais objectif. Un objectif de 100 % ne laisse aucun budget : chaque déploiement devient un risque que personne n’a le droit de prendre. De toute façon, à travers leur propre Wi-Fi et leurs réseaux mobiles, les utilisateurs ne font pas la différence entre 99,99 % et 100 %.
Il rend le risque dépensable. Une grosse migration, une nouvelle région ou une mise en production risquée peuvent être planifiées pour tenir dans le budget restant ce mois-ci.
Il fixe les priorités à votre place. Quand le budget est épuisé, la politique dit ce qui se passe ensuite : personne n’a besoin de gagner une réunion pour inscrire le travail de fiabilité à la roadmap.
Ce qui consomme le budget
Tout ce que votre SLI compte comme mauvais consomme du budget. Décidez-le en rédigeant le SLO, pas pendant l’incident.
Les pannes confirmées : le service n’a pas répondu, a répondu par une erreur ou avec le mauvais contenu.
Les réponses lentes, si votre SLI considère comme échouée une requête plus lente qu’un seuil. Une page qui met 30 secondes à charger est en ligne, mais inutilisable.
Les déploiements ratés et les rollbacks, pour les minutes pendant lesquelles les utilisateurs ont vu des erreurs.
Les pannes chez vos fournisseurs. Si votre prestataire de paiement ou votre hébergeur DNS tombe, vos utilisateurs ne peuvent toujours pas payer. Cela consomme votre budget même si la correction ne dépend pas de vous, ce qui est une bonne raison de surveiller les services dont vous dépendez.
La maintenance planifiée, seulement si le SLO le prévoit. Beaucoup d’équipes excluent les fenêtres de maintenance annoncées, avec un plafond par mois.
Ce qui ne doit pas le consommer : les faux positifs. Un seul contrôle en échec dû à un aléa réseau n’est pas une indisponibilité. Confirmez un échec par un second contrôle avant de le compter, sinon votre budget fond à cause de problèmes que les utilisateurs n’ont jamais vus.
Burn rate : à quelle vitesse vous consommez
Le budget vous dit combien d’échecs vous pouvez vous permettre. Le burn rate vous dit à quelle vitesse vous l’utilisez. Le SRE workbook de Google le définit comme la vitesse, rapportée au SLO, à laquelle le service consomme le budget d’erreur (Alerting on SLOs).
Un burn rate de 1 épuise tout le budget exactement à la fin de la fenêtre.
Un burn rate de 2 l’épuise en la moitié de la fenêtre : 15 jours d’un mois de 30 jours.
Une panne totale brûle à 1 000 face à un SLO de 99,9 %, puisque chaque minute d’indisponibilité représente mille fois le rythme autorisé. Vingt minutes de panne consomment 46 % d’un budget sur 30 jours.
Le point de départ recommandé par le workbook pour un SLO de 99,9 % consiste à alerter une personne d’astreinte quand 2 % d’un budget sur 30 jours sont consommés en une heure (un burn rate de 14,4) ou 5 % en six heures (un burn rate de 6), et à ouvrir un ticket quand 10 % sont consommés en trois jours (un burn rate de 1). Chaque alerte vérifie aussi une fenêtre courte, pour cesser de se déclencher peu après la fin du problème.
Pour une panne franche, une alerte de burn rate et une alerte classique « le site est en panne » se déclenchent à peu près au même moment. Les burn rates prouvent leur utilité sur les défaillances partielles : 3 % de requêtes en échec pendant des heures, ce qui ne fait jamais tomber le site mais épuise discrètement le budget du mois dès le mercredi.
Rédiger une politique de budget d’erreur
Un budget sans politique n’est qu’un chiffre sur un tableau de bord. La politique dit, à l’avance, ce que fait l’équipe à chaque niveau de consommation. Mettez-vous d’accord dessus entre produit et ingénierie, et consignez-la à un endroit où chacun peut la retrouver. Google publie un exemple de politique de budget d’erreur qui vaut la peine d’être lu avant de rédiger la vôtre.
Une politique simple pour commencer
Il reste du budget : livraison normale. Les travaux risqués prévus suivent leur cours.
La moitié consommée avant le milieu de la fenêtre : le responsable d’astreinte passe en revue les incidents survenus et désigne la cause principale.
Budget épuisé : seuls les correctifs de bugs et le travail de fiabilité sont livrés jusqu’à ce que la fenêtre se rétablisse. Les migrations risquées attendent.
Un seul incident a consommé plus d’un cinquième du budget : il fait l’objet d’un postmortem écrit avec au moins une action à mener.
Les exceptions sont tranchées par des personnes nommément désignées, par exemple le responsable de l’ingénierie et le responsable produit ensemble, et consignées par écrit.
Les seuils sont des exemples, pas des règles. Choisissez ceux que votre équipe respectera vraiment. Une politique ignorée la première fois qu’elle s’applique est pire que pas de politique du tout, car elle apprend à tout le monde que le SLO ne compte pas.
Les erreurs courantes
Fixer le SLO au niveau du SLA. Le budget s’épuise alors au moment même où vous devez des crédits de service à vos clients. Gardez le SLO plus strict que le SLA, pour que l’alarme interne sonne en premier. SLA, SLO et SLI explique comment les trois s’articulent.
Une fenêtre trop courte. Un budget hebdomadaire se réinitialise avant qu’une mauvaise semaine puisse changer quoi que ce soit. Trente jours, glissants ou par mois calendaire, c’est le choix habituel.
Oublier comment la fenêtre se réinitialise. Un mois calendaire repart de zéro le 1er : une mauvaise dernière semaine est oubliée en quelques jours. Une fenêtre glissante de 30 jours s’en souvient pendant un mois, ce qui est plus strict et plus juste.
Ne regarder que le total. Une panne de 40 minutes et quarante pannes d’une minute consomment le même budget, mais les secondes perturbent le travail des utilisateurs chaque jour. Suivez le nombre d’incidents et le MTTR à côté du budget.
Ne mesurer que de l’intérieur. Les logs serveur ne peuvent pas enregistrer les requêtes qui ne sont jamais arrivées. Un certificat expiré ou un enregistrement DNS cassé consomme un budget que seul un contrôle externe voit.
Suivre un budget d’erreur basé sur le temps avec Uptimecheck
Uptimecheck vous donne les chiffres dont un budget basé sur le temps a besoin. La surveillance de disponibilité contrôle jusqu’à toutes les minutes depuis Stockholm, Londres et New York, et confirme chaque contrôle en échec depuis un second emplacement : un simple aléa ne consomme donc pas de budget. Les fenêtres de maintenance et les périodes de pause ne sont pas comptées dans la disponibilité.
Les rapports affichent la disponibilité, l’indisponibilité et les incidents par moniteur pour ce mois-ci, le mois dernier ou les 7, 30 ou 90 derniers jours, face à un objectif de SLA de 99 %, 99,5 %, 99,9 %, 99,95 % ou 99,99 %, avec un export CSV. Le budget restant correspond à l’indisponibilité autorisée moins l’indisponibilité du rapport. Voyez comment générer des rapports par rapport à un objectif de SLA.
Les incidents conservent les preuves et une chronologie de chaque contrôle, alerte et note, soit exactement ce dont un postmortem a besoin. Voyez la gestion des incidents.
Les fenêtres de maintenance tiennent les travaux planifiés à l’écart des chiffres. Voyez comment planifier des fenêtres de maintenance.
Pour chiffrer le budget que vous consommez, essayez le calculateur du coût des pannes. Pour voir ce que chaque objectif autorise, lisez ce que signifie 99,9 % de disponibilité.
Sachez combien de budget il vous reste avant la fin du mois. Essayez Uptimecheck gratuitement pendant 14 jours, sans carte bancaire.