SLI, SLO, SLA et budgets d’erreur

Trois termes, une seule idée

Le chapitre 2 a présenté les objectifs de disponibilité et les « neuf » (section 2.5) et a montré que 99,9 % sur 30 jours laissent 43,2 minutes. Cette section transforme ce calcul en discipline d’exploitation. Le vocabulaire vient du livre de Google Site Reliability Engineering (Beyer, Jones, Petoff et Murphy, O’Reilly, 2016) et de son ouvrage compagnon, The Site Reliability Workbook (2018), et il est aujourd’hui utilisé bien au-delà de Google.

Un indicateur de niveau de service (SLI) est une mesure quantitative, soigneusement définie, d’un aspect du service que reçoivent les utilisateurs. La forme la plus utile est un ratio : les bons événements divisés par les événements valides. La proportion de requêtes de paiement qui renvoient une réponse réussie en moins de 800 ms, mesurée au niveau de l’équilibreur de charge (load balancer) est un SLI. Il va de 0 % (rien ne fonctionne) à 100 % (rien n’est cassé), et la forme de ratio permet de lire et de comparer chaque SLI, et d’alerter sur lui, de la même manière.

Un objectif de niveau de service (SLO) est une cible pour un SLI sur une fenêtre donnée : 99,9 % des requêtes de paiement sont bonnes, mesuré sur 28 jours glissants. C’est une promesse interne sur laquelle s’accordent l’équipe, le product owner et les personnes qui dépendent du service. Un accord de niveau de service (SLA) est un contrat avec les clients qui fixe des conséquences, généralement des crédits de service, si un niveau n’est pas atteint. Beaucoup de services ont des SLO mais pas de SLA ; les plateformes internes n’ont presque jamais de SLA.

L’idée qui relie les trois est le budget d’erreur. Si l’objectif est de 99,9 %, alors 0,1 % des événements peuvent être mauvais sans que personne ait failli. Ces 0,1 % ne sont pas du gaspillage ; c’est la marge dont dispose l’équipe pour prendre des risques : livrer des fonctionnalités, mener des migrations, expérimenter sur la configuration. Le budget transforme un débat sur des impressions (le service est-il assez fiable ?) en débat sur des chiffres (avons-nous dépensé notre budget ?), et donne au produit et à l’ingénierie une règle commune pour savoir quand aller vite et quand ralentir.

Choisir de bons SLI

Un SLI n’est utile que dans la mesure où il est proche de ce que vivent les utilisateurs. Le Workbook propose une courte liste qui couvre la plupart des services. Les services pilotés par les requêtes (API, pages web) ont besoin de la disponibilité (la proportion de requêtes valides servies avec succès), de la latence (la proportion servie plus vite qu’un seuil) et parfois de la qualité (la proportion servie sans dégradation, par exemple une carte affichée sans recommandations personnalisées parce que cette dépendance était en panne). Les pipelines de données ont besoin de la fraîcheur (la proportion de données mises à jour plus récemment qu’un seuil), de l’exactitude (la proportion de résultats corrects) et de la couverture (la proportion des entrées traitées). Les systèmes de stockage ajoutent la durabilité (la proportion des données écrites qui peuvent encore être lues).

Les SLI de latence s’écrivent en proportions, pas en moyennes : 99 % des requêtes sur la carte servies en moins de 300 ms. Cela renvoie directement aux percentiles de la section 2.4 : dire que 99 % des requêtes doivent prendre moins de 300 ms revient à dire que le p99 doit être inférieur à 300 ms, mais la forme en proportion s’additionne proprement dans le temps et entre serveurs (on compte les bonnes requêtes et les requêtes valides), ce qui n’est pas le cas des percentiles. Il est courant de fixer deux seuils de latence, par exemple 90 % sous 200 ms et 99 % sous 800 ms, pour saisir à la fois l’expérience typique et celle de la queue.

L’endroit où vous mesurez compte autant que ce que vous mesurez. Le Workbook distingue la spécification du SLI (le résultat qui compte pour l’utilisateur, comme commandes passées avec succès) de l’implémentation du SLI (la manière de le compter : journaux du serveur, métriques de l’équilibreur de charge, sondes synthétiques ou instrumentation dans l’app mobile). Une mesure prise à l’intérieur du serveur d’applications ne voit pas les requêtes qui ne l’ont jamais atteint parce que le DNS, le réseau de diffusion de contenu ou l’équilibreur de charge a été défaillant. Une mesure prise dans le client voit tout, mais elle inclut les mauvaises connexions mobiles des utilisateurs et arrive en retard. La plupart des équipes commencent par les métriques de l’équilibreur de charge, peu coûteuses et proches de la périphérie, et ajoutent des sondes synthétiques pour les chemins à faible trafic.

Définissez précisément ce qui compte comme valide et ce qui compte comme bon, car ce sont les cas limites qui décident si le chiffre a un sens. Une 404 pour une URL mal saisie est-elle mauvaise ? En général non : c’est une réponse correcte. Une réponse 429 de limitation de débit est-elle mauvaise ? Tout dépend si le client respectait ou non son quota convenu. Les contrôles de santé (health checks) et les tests de charge sont-ils des événements valides ? Non ; excluez-les, sinon ils diluent le ratio. Consignez ces règles par écrit à côté du SLO.

Fixer l’objectif

Un objectif est une décision métier, pas une décision technique. Le coût de chaque « neuf » supplémentaire augmente fortement, tandis qu’au-delà d’un certain point les utilisateurs ne remarquent plus les améliorations, parce que leur propre réseau mobile, leur Wi-Fi et leurs appareils tombent en panne plus souvent que cela. Le livre SRE de Google le dit sans détour : viser 100 % est une erreur pour presque tout, car cela ne laisse aucun budget pour le changement, coûte une fortune et ne peut de toute façon pas être atteint. Un objectif de 100 % transforme aussi chaque défaillance isolée en manquement à la politique, ce qui apprend aux gens à ignorer le SLO.

Les bons points de départ sont les performances passées (qu’a obtenu le service au dernier trimestre, et les utilisateurs étaient-ils satisfaits ?), les objectifs des services dont vous dépendez (vous ne pouvez pas promettre 99,99 % au-dessus d’une base de données à 99,9 %, comme la section 6.1 l’a montré pour les chaînes d’appels) et le coût métier du manque de fiabilité. Pour la plateforme de livraison de repas, les commandes échouées à l’heure du déjeuner coûtent du chiffre d’affaires et la confiance des clients : 99,9 % sur la prise de commande se défend donc ; les mises à jour de la position des livreurs sont moins critiques et 99 % suffisent. Commencez un peu en dessous des performances actuelles, pour que l’équipe ne soit pas immédiatement en infraction, puis resserrez l’objectif plus tard, preuves à l’appui.

Choisissez la fenêtre délibérément. Une fenêtre glissante comme les 28 derniers jours correspond à la façon dont les utilisateurs se souviennent des pannes (ils n’oublient pas le premier du mois), et 28 jours contiennent exactement quatre fois chaque jour de la semaine, ce qui garde les cycles hebdomadaires équitables. Les mois calendaires conviennent aux rapports et aux contrats. Les services organisés autour d’événements, comme une ouverture de billetterie, peuvent nécessiter un SLO par événement, car une heure de défaillance pendant l’ouverture des ventes compte bien plus qu’une semaine calme.

Les budgets d’erreur en chiffres

Le budget d’erreur peut se compter en temps ou en événements. Les budgets fondés sur le temps conviennent aux services qui sont soit en marche, soit à l’arrêt ; les budgets fondés sur les requêtes sont plus justes pour les services au trafic irrégulier, car une panne à 03:00 touche moins d’utilisateurs qu’une panne à midi.

Les politiques de budget d’erreur

Un budget ne veut rien dire si rien ne se passe quand il est épuisé. Une politique de budget d’erreur est un court document, convenu à l’avance par l’ingénierie, le produit et la direction, qui dit ce que l’équipe fera. L’exemple de politique du Workbook mesure le budget sur les quatre dernières semaines ; si le service dépasse son budget, tous les changements et toutes les mises en production s’arrêtent, sauf les correctifs urgents (problèmes P0) et les correctifs de sécurité, jusqu’à ce que le service revienne dans son SLO. Elle exige aussi un post-mortem avec au moins une action de priorité maximale chaque fois qu’un seul incident consomme plus de 20 % du budget sur quatre semaines, et fait remonter les désaccords au directeur technique (CTO).

La valeur d’une politique tient au fait qu’elle est convenue avant de s’appliquer. En pleine course à la mise en production, personne ne veut geler les changements ; avec une politique signée, le gel est une règle convenue d’avance plutôt qu’un affrontement entre un SRE et un chef de produit. Les bonnes politiques précisent aussi ce qui n’est pas imputé à l’équipe : une panne réseau à l’échelle de l’entreprise, une dépendance elle-même gelée, ou du trafic hors du périmètre du SLO, comme un test de charge.

Les praticiens ne s’accordent pas sur le degré d’automatisme que doit avoir la politique. Certaines équipes l’appliquent strictement, car les exceptions érodent la confiance dans tout le système. D’autres traitent le budget comme une information qui alimente une discussion, en faisant valoir qu’un gel strict peut retarder les correctifs mêmes qui rétabliraient la fiabilité. Une voie intermédiaire est courante : geler automatiquement les mises en production de fonctionnalités risquées, continuer à livrer les correctifs de fiabilité, et permettre à un dirigeant désigné d’accorder des exceptions documentées. Le cas inverse compte aussi : une équipe qui ne dépense jamais son budget est probablement trop prudente et pourrait livrer plus vite, mener plus d’expériences ou réduire ses coûts.

Taux de consommation et alertes sur les SLO

Alerter sur les taux d’erreur bruts (alerter l’astreinte si plus de 1 % des requêtes échouent pendant 5 minutes) génère du bruit : de brefs pics réveillent des gens la nuit pour des problèmes qui ne menaceraient jamais le SLO, tandis qu’un taux d’échec constant de 0,5 % peut épuiser discrètement le mois sans jamais franchir le seuil. La réponse du Workbook consiste à alerter sur le taux de consommation (burn rate) : la vitesse à laquelle le budget est dépensé, comparée au rythme qui l’épuiserait exactement à la fin de la fenêtre.

Taux de consommation = ratio d’erreurs observé / ratio d’erreurs autorisé. Avec un SLO de 99,9 %, le ratio autorisé est de 0,1 % : un ratio d’erreurs de 0,1 % correspond donc à un taux de consommation de 1 (le budget dure exactement la fenêtre), 1 % à un taux de 10, et 100 % (une panne totale) à un taux de 1000. La fraction du budget de la fenêtre dépensée pendant une fenêtre d’alerte vaut taux de consommation x fenêtre d’alerte / fenêtre du SLO. Pour une fenêtre de 30 jours (720 heures), un taux de consommation de 14,4 maintenu pendant une heure dépense 14,4 × 1 / 720 = 0,02, soit 2 % du budget du mois ; à ce rythme, le budget entier serait épuisé en 720 / 14,4 = 50 heures.

Le Workbook recommande une alerte multifenêtre et multi-taux de consommation comme réglage par défaut raisonnable pour un SLO de 99,9 % : alerter l’astreinte si 2 % du budget sont dépensés en une heure (taux de consommation 14,4) ou 5 % en six heures (taux 6), et ouvrir un ticket si 10 % sont dépensés en trois jours (taux 1). Chaque condition doit être vérifiée sur une fenêtre longue et sur une fenêtre courte, la fenêtre courte valant un douzième de la longue (respectivement 5 minutes, 30 minutes et 6 heures). La fenêtre longue garantit que le problème est significatif ; la fenêtre courte garantit qu’il se produit encore, si bien que l’alerte cesse de se déclencher quelques minutes après un correctif au lieu de rester rouge pendant une heure.

SLO = 0.999                 # 99.9% of requests good
PERIOD_H = 30 * 24          # 720-hour SLO window

def burn_rate(bad, total, slo=SLO):
    """Observed error ratio divided by the ratio the SLO allows."""
    if total == 0:
        return 0.0
    return (bad / total) / (1 - slo)

def budget_spent(rate, window_h, period_h=PERIOD_H):
    """Fraction of the whole window's budget used in window_h hours."""
    return rate * window_h / period_h

def page(w1h, w5m, w6h, w30m):
    """Each argument is (bad, total) for that window."""
    fast = burn_rate(*w1h) >= 14.4 and burn_rate(*w5m) >= 14.4
    slow = burn_rate(*w6h) >= 6 and burn_rate(*w30m) >= 6
    return fast or slow

print(round(burn_rate(bad=288, total=20_000), 1))   # 14.4
print(budget_spent(14.4, window_h=1))               # 0.02, i.e. 2%

Les seuils fixent aussi le délai de détection. Si l’API de commande tombe complètement en panne (ratio d’erreurs de 100 %, taux de consommation de 1000), le ratio d’erreurs sur une heure dépasse 1,44 % au bout de 0,0144 × 60 = environ 0,9 minute : l’alerte d’astreinte part donc en moins d’une minute. Si 2 % des requêtes échouent (taux de consommation de 20), le ratio sur une heure atteint 1,44 % au bout de 0,72 × 60 = environ 43 minutes. Les problèmes graves déclenchent l’alerte vite ; les problèmes légers ne la déclenchent que s’ils persistent, ce qui est exactement le comportement souhaité à trois heures du matin.

Les services à faible trafic mettent ce calcul en défaut : avec 10 requêtes par heure, un seul échec représente un ratio d’erreurs de 10 % et un taux de consommation de 100. Les remèdes du Workbook sont le trafic synthétique pour ajouter du signal, le regroupement de services apparentés à faible trafic sous un même SLO, la réduction de l’impact des échecs isolés grâce aux nouvelles tentatives et aux solutions de repli, ou l’acceptation d’une fenêtre plus longue. Pour le système de billetterie, presque inactif entre deux ouvertures des ventes puis extrêmement sollicité, des SLO par événement avec des alertes sur le taux de consommation pendant la fenêtre de l’événement fonctionnent mieux qu’un chiffre mensuel.

Les SLA et les crédits de service

Un SLA fait passer l’objectif de l’ingénierie au droit des contrats. Il définit le service couvert, la manière de mesurer la disponibilité, les exclusions (maintenance planifiée, mauvaise utilisation par le client, force majeure), la compensation et la manière dont un client la réclame. La compensation habituelle est un crédit de service : un pourcentage de la redevance mensuelle restitué, échelonné selon l’ampleur du manquement. Les crédits sont généralement faibles par rapport à la perte réelle du client : il vaut donc mieux lire un SLA comme un signal de la confiance du fournisseur que comme une assurance ; les clients dont les pertes seraient importantes ont besoin de leur propre résilience, pas d’un crédit plus élevé.

Prenons, à titre d’illustration, un SLA que la plateforme de livraison de repas pourrait proposer à ses restaurants partenaires pour son API de prise de commandes : 99,5 % de disponibilité mensuelle, avec un crédit de 10 % sur la commission de plateforme du mois en dessous de 99,5 % et de 25 % en dessous de 99,0 %. Le SLO interne est de 99,9 %. L’écart entre les deux est délibéré : l’équipe doit épuiser son budget de SLO, appliquer sa politique et se rétablir bien avant que le contrat soit menacé. Ne fixez jamais le SLO au même niveau que le SLA : vous n’apprendriez l’existence d’un problème qu’au moment où vous devez déjà de l’argent.

Deux conséquences architecturales en découlent. D’abord, un SLA ne peut être honnête que si vous connaissez les SLA de vos propres dépendances (fournisseur cloud, prestataire de paiement, fournisseur de cartographie) et la façon dont ils se combinent. Ensuite, les SLA exigent des preuves : la méthode de mesure inscrite au contrat doit pouvoir être appliquée à partir de votre propre télémétrie, ce qui constitue une exigence pour la conception de l’observabilité.

Erreurs courantes

Trop de SLO. Un service doté de trente SLO n’en a aucun, car personne ne peut raisonner sur eux ni agir en conséquence. Commencez par deux ou trois par parcours utilisateur critique : en général un SLO de disponibilité et un ou deux SLO de latence. Mesurer la mauvaise chose. Le taux d’utilisation du CPU, la profondeur des files d’attente et le retard de réplication sont des causes utiles à surveiller, mais ce ne sont pas des SLI, car les utilisateurs ne les vivent pas directement. Mesurer au mauvais endroit. Les taux de réussite côté serveur paraissent parfaits alors que le CDN renvoie des erreurs. Faire des moyennes. Un SLO sur la latence moyenne masque la queue lente dont se plaignent les utilisateurs.

Des objectifs sans conséquences. Un SLO sans politique de budget ni alertes sur le taux de consommation n’est qu’une décoration de tableau de bord. Des objectifs fixés par les seuls ingénieurs. Le product owner doit donner son accord, car le SLO arbitre entre fonctionnalités et fiabilité. Ne jamais réviser. Réexaminez les SLO tous les trimestres ou tous les deux trimestres : si les utilisateurs se plaignent alors que le SLO est au vert, c’est le SLI ou l’objectif qui est faux ; si le budget n’est jamais entamé, l’objectif est peut-être trop lâche ou l’équipe trop prudente. Un seul SLO pour des parcours très différents. Regrouper la consultation de la carte et le paiement dans un même ratio permet aux nombreuses requêtes bon marché de masquer les échecs des requêtes rares et précieuses.

Les SLO se rattachent au reste de ce chapitre. Les alertes sur le taux de consommation sont les alertes fondées sur les symptômes que recommande la partie consacrée à l’observabilité ; les incidents qui consomment le budget alimentent les revues post-incident ; et la mesure de la réponse d’un SLO est une fonction d’aptitude naturelle pour l’architecture.