SLI, SLO, SLA, error budget : les chiffres qui font tourner le SRE

Un SLI est une mesure de ce que les utilisateurs ont vécu, un SLO est la cible que vous fixez pour cette mesure, un SLA est un contrat qui dit ce qui se passe quand la cible est manquée, et le budget d'erreur (error budget) est la différence entre 100 pour cent et le SLO, comptée en requêtes échouées que vous avez le droit d'avoir. Un SLO de 99,9 pour cent sur 30 jours pour un service qui traite 10 millions de requêtes, c'est un budget de 10 000 échecs. Ces quatre chiffres sont la façon dont un SRE répond à la question que le reste de l'organisation ne sait pas poser : à quel point ce service est-il censé être fiable, et peut-on livrer aujourd'hui sans risque ?

Ceci est la Partie 2 de Budget for Failure. La Partie 1 décrivait le rôle de SRE et se terminait sur sa dépendance : rien de tout cela ne fonctionne sans un chiffre. Cette partie est encore de niveau 101. Elle définit les termes, lit les SLA d'AWS pour ce qu'ils promettent réellement, calcule un premier SLI à partir des métriques de load balancer que vous avez déjà, et transforme le résultat en un budget assorti d'une politique.

SLI : le ratio d'événements bons sur événements valides

Un service level indicator est un nombre entre 0 et 100 pour cent, calculé de la même façon à chaque fois : événements bons divisés par événements valides. Pour un service piloté par des requêtes, les deux SLI les plus utiles sont :

• Disponibilité : requêtes servies sans erreur serveur, divisées par l'ensemble des requêtes.
• Latence : requêtes servies plus vite qu'un seuil (disons 300 ms), divisées par l'ensemble des requêtes.

Deux décisions de conception se cachent dans cette définition. D'abord, ce qui compte comme valide. Un 404 pour une URL qui n'existe pas, c'est le service qui fonctionne correctement ; un 429 de votre propre rate limiter, c'est discutable ; un 500, non. Décidez une fois et écrivez-le, parce que le dénominateur est l'endroit où les SLI se font discrètement truquer. Ensuite, où vous mesurez. Plus on est proche de l'utilisateur, plus le chiffre est honnête. Une métrique prise au load balancer voit des échecs que l'application ne logge jamais, comme une target qui a refusé la connexion. Une métrique prise dans l'application les manque.

Les moyennes ne sont pas des SLI. Une latence moyenne de 120 ms est compatible avec une requête sur vingt qui prend quatre secondes. La forme ratio (« 97,2 pour cent des requêtes sous 300 ms ») vous dit combien d'utilisateurs ont passé un mauvais moment, et c'est cela que vous essayez de borner.

SLO : la cible, et la fenêtre sur laquelle on la mesure

Un service level objective, c'est un SLI plus une cible plus une fenêtre de temps : « 99,9 pour cent des requêtes réussissent, mesuré sur 30 jours glissants ». Les trois éléments sont obligatoires. Une cible sans fenêtre est infalsifiable, puisque n'importe quelle mauvaise heure peut être diluée en choisissant une période plus longue après coup.

La cible, c'est là qu'arrivent les neufs, et les neufs sont plus faciles à raisonner en temps d'indisponibilité autorisé. Pour une fenêtre de 30 jours (43 200 minutes) :

Lisez le tableau par le bas. À 99,99 pour cent, vous avez environ quatre minutes par mois. Un humain alerté à 03:00 a besoin de plus que cela pour trouver un laptop, ce qui veut dire qu'un SLO à quatre neufs est un engagement à la détection automatisée et à la récupération automatisée, avec des humains impliqués seulement après. Chaque neuf supplémentaire divise à peu près par dix l'échec autorisé et, en pratique, représente une grosse marche de coût. Le bon SLO est le chiffre le plus bas au-dessus duquel vos utilisateurs ne verraient pas la différence, pas le chiffre le plus haut qui fait bien sur une slide.

Cent pour cent n'est jamais la bonne cible. Cela interdit chaque déploiement, chaque migration et chaque dépendance que vous ne contrôlez pas, et vos utilisateurs vous atteignent par un Wi-Fi domestique et des réseaux mobiles bien moins fiables que tout ce que vous exploitez.

SLA : le contrat, et ce qu'AWS vous doit réellement

Un service level agreement est un SLO avec des conséquences attachées, signé avec un client. La conséquence, c'est en général de l'argent. C'est toute la différence, et c'est pourquoi le SLA est toujours plus lâche que le SLO interne : vous voulez remarquer et réagir bien avant qu'un dépassement ne devienne un remboursement.

AWS est le SLA que la plupart d'entre nous lisent en premier, et il vaut la peine d'être lu de près parce que la formulation enseigne le concept. Quatre qui se trouvent sous un service web typique :

Trois choses dans ces documents comptent plus que les pourcentages.

Le remède est un crédit de service. Si S3 Standard tombe à 99,5 pour cent sur un mois, vous êtes éligible à 10 pour cent des frais S3 de ce mois pour la Région affectée, appliqués sur une facture future, après avoir déposé une réclamation avec des preuves. Votre chiffre d'affaires perdu, vos propres pénalités de SLA et votre week-end ne font pas partie du calcul. Un SLA est une clause tarifaire. Ce n'est pas une police d'assurance et ce n'est pas une prédiction du comportement du service.

L'engagement est conditionné par votre architecture. Les 99,99 pour cent d'EC2 ne s'appliquent que lorsque toutes les instances en cours d'exécution sont déployées sur deux Availability Zones ou plus dans la Région. Tournez dans une seule zone et vous êtes sur l'engagement instance-level à 99,5 pour cent, qui autorise environ 3,6 heures d'indisponibilité par mois. Le SLA encode la conception qu'AWS attend de vous.

« Unavailable » a une définition juridique étroite. Chaque SLA définit sa propre mesure, par minute ou par intervalle de cinq minutes, et ses propres exclusions. Lent n'est pas indisponible. Des taux d'erreur élevés sur une API dont vous dépendez peuvent ne pas compter du tout.

Votre premier SLI, à partir de métriques que vous avez déjà

Si votre service est derrière un Application Load Balancer, CloudWatch détient déjà un SLI de disponibilité. Trois métriques du namespace AWS/ApplicationELB suffisent : RequestCount, HTTPCode_Target_5XX_Count (les erreurs renvoyées par votre code) et HTTPCode_ELB_5XX_Count (les erreurs générées par le load balancer lui-même, par exemple quand aucune target saine n'a répondu). Enregistrez ceci sous sli.json :

[
  { "Id": "req", "ReturnData": false,
    "MetricStat": { "Stat": "Sum", "Period": 86400,
      "Metric": { "Namespace": "AWS/ApplicationELB", "MetricName": "RequestCount",
        "Dimensions": [{ "Name": "LoadBalancer", "Value": "app/checkout/0123456789abcdef" }] } } },
  { "Id": "t5xx", "ReturnData": false,
    "MetricStat": { "Stat": "Sum", "Period": 86400,
      "Metric": { "Namespace": "AWS/ApplicationELB", "MetricName": "HTTPCode_Target_5XX_Count",
        "Dimensions": [{ "Name": "LoadBalancer", "Value": "app/checkout/0123456789abcdef" }] } } },
  { "Id": "e5xx", "ReturnData": false,
    "MetricStat": { "Stat": "Sum", "Period": 86400,
      "Metric": { "Namespace": "AWS/ApplicationELB", "MetricName": "HTTPCode_ELB_5XX_Count",
        "Dimensions": [{ "Name": "LoadBalancer", "Value": "app/checkout/0123456789abcdef" }] } } },
  { "Id": "sli", "Label": "availability_percent",
    "Expression": "100 * (req - FILL(t5xx, 0) - FILL(e5xx, 0)) / req" }
]

aws cloudwatch get-metric-data \
  --start-time "$(date -u -v-30d +%Y-%m-%dT00:00:00Z)" \
  --end-time "$(date -u +%Y-%m-%dT00:00:00Z)" \
  --metric-data-queries file://sli.json \
  --query 'MetricDataResults[0].[Timestamps,Values]'

Cela renvoie un chiffre de disponibilité par jour pour les 30 derniers jours (la syntaxe date -v est celle de macOS ; sur Linux, utilisez date -u -d '30 days ago'). Le FILL(…, 0) compte : CloudWatch ne publie aucun datapoint pour une métrique d'erreur sur une période sans erreur, et sans le fill une journée parfaite revient comme donnée manquante au lieu de 100 pour cent.

Pour la latence, le même namespace a TargetResponseTime, et la statistique percentile rank de CloudWatch la convertit directement en forme ratio : PR(:0.3) renvoie le pourcentage de requêtes terminées en 300 ms ou moins.

Le budget d'erreur : ce que le SLO vous laisse dépenser

Une fois que le métier a convenu que 99,9 pour cent suffisent, les 0,1 pour cent restants cessent d'être un défaut à éliminer et deviennent une allocation à utiliser. Si le service est à 99,97 pour cent avec dix jours restants dans la fenêtre, il y a de la place pour prendre du risque : livrer la migration, mettre à jour le cluster, lancer le test de failover. S'il est à 99,88 pour cent, il n'y en a pas, et personne n'a besoin de gagner une dispute pour l'établir. Un service qui termine chaque fenêtre sans avoir touché son budget n'est pas un triomphe non plus : le SLO est plus lâche que ce dont les utilisateurs ont besoin, ou l'équipe paie pour une fiabilité que personne n'a demandée.

Le budget peut se compter en événements ou en temps, et les deux se comportent différemment.

SLO                      99.9% over 30 days
requests in window       10,000,000
error budget             (1 - 0.999) x 10,000,000 = 10,000 failed requests

bad requests so far      6,400
budget consumed          6,400 / 10,000 = 64%
budget remaining         3,600 requests = 36%

Les budgets en événements pondèrent l'échec par le trafic. Dix minutes de panne totale au pic du mardi coûtent bien plus que dix minutes à 04:00 un dimanche, ce qui correspond à ce que les utilisateurs ont vécu. C'est la forme à préférer pour tout ce qui est piloté par des requêtes.

Les budgets en temps comptent les mauvaises minutes : 99,9 pour cent sur 30 jours, c'est 43 minutes et 12 secondes. Ils sont plus faciles à expliquer à un non-ingénieur et conviennent aux services sans flux de requêtes régulier, comme un pipeline batch ou un outil interne à faible trafic. Le coût, c'est qu'une minute compte comme entièrement mauvaise ou entièrement bonne, donc il vous faut une règle pour ce qui rend une minute mauvaise (par exemple « taux d'erreur au-dessus de 1 pour cent »), et une panne partielle est soit invisible soit comptée en entier.

La fenêtre compte autant que la cible. Une fenêtre glissante de 30 jours reflète toujours le passé récent, et une mauvaise journée quitte le calcul exactement 30 jours plus tard ; c'est le meilleur choix pour suivre l'expérience utilisateur. Une fenêtre calendaire se remet à zéro le premier du mois, ce qui s'aligne avec le reporting et avec la plupart des SLA, et a une mauvaise propriété : un incident le 2 dépense le budget pour quatre semaines, tandis que le même incident le 30 est pardonné deux jours plus tard.

Ce qui dépense le budget

Tout ce qui fait échouer la requête d'un utilisateur puise dans le même compte, quel qu'en soit le responsable. C'est le principe. Dans l'ordre à peu près décroissant de ce qu'une équipe typique dépense :

• Les changements. Déploiements, pushs de config, feature flags, migrations de schéma. Dans la plupart des collections de postmortems, le changement est la première cause d'incident. Si vous suivez le change failure rate de DORA, vous mesurez déjà le principal dépensier.
• Les dépendances. Un ralentissement d'API régional, un prestataire de paiement tiers, un problème DNS. C'est votre budget même quand ce n'est pas votre faute, parce que l'utilisateur se moque de savoir à qui la faute.
• Capacité et charge. Throttling, caches froids, une politique de scaling qui réagit deux minutes trop tard.
• Le travail planifié. Fenêtres de maintenance, tests de failover, game days. Un exercice délibéré d'évacuation de zone qui coûte 300 requêtes échouées, c'est du budget bien dépensé, et avoir un budget est ce qui rend l'exercice approuvable.
• Matériel et plateforme. Retraits d'instances, événements de zone. Plus petit que ce à quoi les gens s'attendent, si l'architecture est multi-AZ.

Tenez un registre. Après chaque incident ou changement risqué, notez combien de budget il a consommé et sa cause. Trois mois de ce registre vous disent où le temps d'ingénierie fiabilité doit aller mieux que n'importe quelle discussion de roadmap.

Dans cet exemple, un seul déploiement a coûté plus qu'une panne tierce et un test planifié réunis. Le dossier d'investissement s'écrit tout seul : analyse canary et rollback automatique avant toute autre chose.

La politique est le produit

Un budget sans conséquence est un dashboard. Ce qui le fait fonctionner, c'est une courte politique écrite, convenue à l'avance par la direction de l'ingénierie et du produit, qui dit ce qui change quand le budget baisse. Le Google SRE Workbook publie un exemple de politique dont la structure vaut d'être copiée. Une première version praticable tient sur une demi-page :

• Budget au-dessus de 50 pour cent : processus de release normal. Changements risqués et expérimentations encouragés.
• Budget en dessous de 50 pour cent : les changements passent par une étape canary et un rollback testé. Pas d'expérimentation en production.
• Budget épuisé : les releases de fonctionnalités s'arrêtent jusqu'à ce que le service soit revenu dans le SLO. Seuls sortent les correctifs de fiabilité, les patchs de sécurité et les changements nécessaires pour restaurer le budget. La priorité de l'équipe, ce sont les premiers éléments des postmortems récents.
• Un seul incident consomme plus de 20 pour cent du budget : postmortem obligatoire, avec au moins une action à haute priorité.
• Désaccord : un dirigeant nommé tranche. Le chemin d'escalade est écrit avant d'en avoir besoin.

Deux propriétés font tenir cela. C'est symétrique : le même document qui gèle les releases quand le budget est épuisé dit aux opérations d'arrêter de les bloquer quand il est sain. Et c'est convenu d'avance : le product owner l'a signé une semaine calme, donc l'invoquer pendant une mauvaise semaine est de l'exécution, pas de la confrontation. Si la direction refuse de signer une politique capable d'arrêter le travail sur les fonctionnalités, vous n'avez pas encore de SLO. Vous avez une métrique.

Laissez CloudWatch tenir le registre

Le SLI ci-dessus a été calculé à la main avec get-metric-data. Pour le budget courant, CloudWatch a une fonctionnalité de SLO managée dans Application Signals. Vous définissez l'indicateur, l'objectif d'atteinte et l'intervalle, et il suit en continu l'atteinte et le budget d'erreur restant. Trois choix dans son modèle correspondent directement à ce billet :

• Par période ou par requête. Un SLO par période découpe l'intervalle en périodes (une minute, par exemple), juge chacune bonne ou mauvaise, et rapporte les bonnes périodes sur le total. Un SLO par requête compte les bonnes requêtes sur le total des requêtes. Ce sont les budgets en temps et en événements décrits plus haut.
• Intervalle glissant ou calendaire. Les deux sont supportés, avec le compromis déjà décrit.
• Sur quoi le SLI est construit. Les services instrumentés avec Application Signals obtiennent des métriques standard de latence et de disponibilité, les réponses 5xx comptées comme des fautes et les 4xx traitées comme des succès. Si vous n'êtes pas instrumenté, un SLO peut être posé sur n'importe quelle métrique CloudWatch ou expression metric math produisant une seule série temporelle, ce qui inclut l'expression load balancer ci-dessus.

La console présente le résultat sous deux chiffres : l'atteinte par rapport à l'objectif, et le budget restant. Pour un SLO par requête, le budget restant peut monter comme descendre pendant l'intervalle, parce qu'il dépend du ratio bonnes requêtes sur total jusqu'ici, et une semaine calme de trafic propre dilue un incident antérieur.

Modes de défaillance et ce qu'il faut surveiller

Faire la moyenne de pourcentages. Une journée à 100 requêtes à 90 pour cent et une journée à un million de requêtes à 99,99 pour cent ne font pas 95 de moyenne. Le SLI sur 30 jours, c'est le total des bonnes requêtes sur le total des requêtes valides. Sommez les numérateurs et les dénominateurs, puis divisez.

Un dénominateur à trous. RequestCount ne compte que les requêtes pour lesquelles le load balancer a pu choisir une target, donc l'expression ci-dessus surestime légèrement les dégâts lors d'une panne totale. C'est le bon sens dans lequel se tromper. Le SLI ne voit pas non plus les requêtes qui n'ont jamais atteint le load balancer : une panne DNS, un blocage WAF, un client sur un réseau cassé.

Le SLO que personne n'a accepté. Une cible choisie par la seule équipe plateforme n'a aucune autorité quand elle entre en collision avec une date de lancement. Le chiffre doit appartenir à qui possède la roadmap.

Trop de SLO. Commencez par un ou deux par service exposé aux utilisateurs : disponibilité et latence sur le chemin de requête qui rapporte l'argent. Vingt SLO produisent vingt budgets, dont un est toujours épuisé, et la politique devient du bruit.

Fixer la cible avant d'avoir vu les données. Lancez d'abord la requête sur les 30 derniers jours. Un SLO choisi avant d'avoir vu le SLI est un vœu. Un SLO fixé légèrement sous l'historique mesuré, puis resserré volontairement, est une cible que vous pouvez défendre.

L'apprendre en fin de mois. Un budget lu sur un rapport mensuel ne peut qu'expliquer le passé. Agir tant qu'il reste du budget demande une alerte sur le rythme de dépense, et faire dépenser moins au service demande des changements dans son code. Les deux sont la Partie 3.

À lire ensuite

• Partie 3 de cette série : Le SRE dans le code : timeouts, retries et alertes as code, où le budget rencontre le dépôt.
• Partie 1 de cette série : Ce que fait un SRE : le métier derrière le titre.
• Evals Before Agents: You Can't Ship What You Can't Score sur ercan.ai, la même discipline appliquée aux systèmes LLM : définir la mesure avant de se disputer sur la qualité.

Pour du conseil en AWS, architecture cloud, pratique SRE, pipelines CI/CD, Linux et plus encore, commencez par ercanermis.com.

Références

• Google SRE Book, Chapter 4: Service Level Objectives
• Google SRE Book, Chapter 3: Embracing Risk
• Google SRE Workbook, Appendix B: Example Error Budget Policy
• Amazon Compute Service Level Agreement
• Amazon Elastic Load Balancing Service Level Agreement
• Amazon RDS Service Level Agreement
• Amazon S3 Service Level Agreement
• CloudWatch metrics for your Application Load Balancer
• Amazon CloudWatch: Service level objectives (SLOs)