Calculateur d'Error Budget

Vue d’ensemble

Un SLO est une promesse formulée comme un rapport : telle fraction des requêtes aboutira. Son corollaire utile, c’est le reste — le budget d’erreur, la quantité d’échec à laquelle vous avez droit avant d’avoir rompu la promesse.

Présenter la fiabilité comme un budget change la nature de la conversation. « Ne rien casser » n’est pas un objectif d’ingénierie : cela valorise le risque à l’infini et interdit donc de livrer quoi que ce soit. « Vous disposez de 43 minutes d’indisponibilité ce mois-ci et vous en avez consommé 12 » est en revanche un objectif sur lequel on peut planifier.

Ce calculateur convertit un SLO en trois chiffres : le budget exprimé en pourcentage, l’indisponibilité autorisée sur votre fenêtre, et — si vous fournissez un volume de requêtes — le nombre de défaillances individuelles qui tient à l’intérieur.

Utilisation

1. Saisissez le SLO sur lequel vous vous engagez, en pourcentage.
2. Réglez la fenêtre en jours. 30 correspond au mois glissant habituel ; 7 donne une boucle de retour plus rapide ; 90 s’aligne sur une revue trimestrielle.
3. Éventuellement, saisissez le volume de requêtes de cette fenêtre pour obtenir le nombre d’échecs.

Lire les chiffres

Le budget d’erreur vaut simplement 100 % − SLO. Il paraît dérisoirement petit à côté du SLO, et c’est précisément le point : passer de 99,9 % à 99,99 % divise par dix ce que vous avez le droit de dépenser, ce qui explique pourquoi chaque neuf supplémentaire coûte tellement plus cher que le précédent.

L’indisponibilité autorisée est ce budget appliqué à la fenêtre, exprimé en temps réel. C’est le chiffre le plus utile pour parler à des interlocuteurs extérieurs à l’équipe, parce que « environ 43 minutes par mois » est concret là où « 99,9 % » ne l’est pas.

Les requêtes en échec autorisées sont le même budget appliqué au volume. C’est sur ce chiffre qu’il faut planifier, parce qu’il se projette directement sur ce que vos métriques savent observer : un décompte de réponses 5xx, ou de requêtes au-delà de votre seuil de latence.

Budget en temps et budget en requêtes ne sont pas la même chose

Deux incidents peuvent consommer un budget temps identique et des budgets requêtes radicalement différents, et réciproquement.

Une panne totale de cinq minutes à 3 h du matin coûte cinq minutes d’indisponibilité et très peu de requêtes. Une dégradation d’une journée entière pendant laquelle 0,5 % des requêtes échouent ne coûte presque aucune « indisponibilité » au sens naïf du terme, et peut à elle seule épuiser un mois de budget requêtes.

C’est la seconde que les utilisateurs vivent. Si vous ne mesurez la disponibilité qu’en temps, vous sous-comptez systématiquement les défaillances qui agacent le plus, parce que les pannes partielles ne s’enregistrent tout bonnement pas comme de l’indisponibilité.

La résolution usuelle consiste à définir le SLI comme un rapport entre événements bons et événements valides — requêtes réussies sur requêtes totales, ou requêtes rapides sur requêtes totales — et à n’en dériver une valeur temporelle que pour la communication.

Ce qui consomme réellement le budget

L’erreur classique consiste à voir le budget comme une réserve dédiée aux incidents. En pratique, il est partagé avec tout ce qui fait échouer des requêtes :

• Les déploiements. Même une mise en production propre coupe des connexions si chaque couche ne se vide pas correctement.
• La maintenance planifiée. Si elle est visible pour l’utilisateur, elle compte, que vous l’ayez annoncée ou non.
• Les défaillances de dépendances. Votre budget est dépensé par les incidents de votre fournisseur, sans que vous ayez eu voix au chapitre.
• La longue traîne. Des délais d’attente isolés, des reprises qui ont épuisé leurs tentatives, un nœud défectueux. Cela devient rarement un incident, et ça s’additionne.

C’est pour cela que les équipes qui budgètent une consommation de 100 % de leur budget d’erreur le dépassent. Prévoyez d’en dépenser une fraction sur les incidents et laissez le reste au coût ordinaire de l’exploitation.

Exemples

• 99,9 % sur 30 jours — environ 43 minutes. Un seul mauvais déploiement avec un retour arrière lent peut consommer l’essentiel d’un mois.
• 99,95 % sur 30 jours — environ 22 minutes. C’est le point où le retour arrière manuel cesse d’être assez rapide et où il faut de l’automatisation.
• 99,99 % sur 30 jours — environ 4 minutes. Atteignable uniquement avec une bascule multi-région qui s’enclenche sans humain dans la boucle.
• 99,999 % sur 30 jours — environ 26 secondes. La détection seule prend généralement plus de temps que cela : l’architecture doit donc tolérer les pannes au lieu d’y réagir.

Chaque palier divise à peu près par dix la défaillance permise et change d’un cran l’ordre de grandeur du coût. Choisissez le SLO en fonction de ce dont les utilisateurs ont réellement besoin, et non du nombre de neufs qui fait bonne impression : un pipeline de traitement par lots interne à 99,99 % est de l’argent dépensé au bénéfice de personne.

Remarques

La fenêtre est traitée comme comptant exactement le nombre de jours que vous saisissez : un mois de 30 jours vaut donc 2 592 000 secondes. Les mois calendaires diffèrent de jusqu’à trois jours, ce qui compte si vous devez vous réconcilier avec un contrat ; une fenêtre glissante de 30 jours est le choix opérationnel le plus courant et elle contourne le problème.

Le décompte de requêtes en échec est tronqué et non arrondi, parce qu’une défaillance partielle n’est pas une chose que l’on peut dépenser.

Pour une disponibilité exprimée sous forme d’engagement contractuel avec des paliers de pénalité, utilisez le calculateur de SLA. Il répond à la question voisine — combien d’indisponibilité un engagement de disponibilité donné autorise — sans le volet volume de requêtes.