C'est quoi un SLO ? Définition, exemples et calcul utile

C'est quoi un SLO ? Un objectif de niveau de service (service level objective) est une cible de fiabilité pour un comportement précis, visible par l'utilisateur, mesuré sur une fenêtre de temps fixe. « 99,9 % des requêtes de paiement réussissent en moins de 800 ms, sur 30 jours » : ça, c'est un SLO. « Le site doit être rapide » : ça, c'est un vœu. Le chiffre compte moins que ce qu'il contrôle : le SLO décide quand vous continuez à livrer et quand vous vous arrêtez.

Il est 03:12. PagerDuty signale une latence « élevée » sur le checkout. Vous ouvrez le dashboard et vous voyez une courbe p99 qui dérive depuis quarante minutes. Personne ne peut vous dire si c'est un problème, parce que personne n'a jamais écrit le seuil de latence acceptable. La discussion qui suit, en call, avec un œil sur Slack, c'est le coût de ne pas avoir de SLO.

SLI, SLO, SLA : trois mots, trois responsables

On les confond tout le temps. Ce ne sont pas la même chose, et les mélanger est la façon la plus sûre de signer un contrat qu'on ne peut pas tenir.

• SLI (service level indicator) : la mesure. Un ratio d'événements bons sur événements valides : les requêtes qui ont renvoyé un 2xx en moins de 800 ms, divisées par toutes les requêtes qui auraient dû être servies.

• SLO (service level objective) : la cible fixée sur ce ratio, sur une fenêtre donnée. 99,9 % sur 30 jours.

• SLA (service level agreement) : le contrat avec le client, avec de l'argent en jeu si vous manquez la cible. Il est toujours moins exigeant que le SLO. Si votre SLA dit 99,9 % et votre SLO aussi, vous n'avez aucune marge pour remarquer un problème avant de devoir des avoirs.

Le chapitre du livre SRE de Google consacré aux objectifs de niveau de service trace la même frontière : le SLO est une cible interne, plus serrée que tout ce que vous promettez à l'extérieur. Les ingénieurs possèdent le SLI et le SLO. Le produit et le juridique possèdent le SLA.

Évitez le réflexe d'ajouter un quatrième mot pour chaque métrique que vous collectez déjà. Le CPU, la mémoire et la profondeur de file sont utiles pour déboguer. Ce ne sont pas des SLI, parce qu'aucun client ne les ressent directement.

À quoi ressemble un bon SLI en pratique

Un bon SLI est un ratio, il se mesure au plus près de l'utilisateur, et il a une définition claire de « bon ».

Pour un service piloté par les requêtes, le réglage par défaut tient en deux SLI : la disponibilité (réponses non 5xx sur toutes les requêtes valides) et la latence (requêtes sous un seuil sur toutes les requêtes valides). Utilisez un seuil, pas une moyenne. Une moyenne masque la queue de distribution, et c'est dans la queue que naissent les tickets de support.

Mesurez au load balancer ou à la périphérie, pas à l'intérieur du service. Un service qui plante au démarrage affiche un taux d'erreur parfait pour les requêtes qu'il n'a jamais reçues. Les métriques côté serveur sont aveugles à cette panne, alors que l'utilisateur la vit comme une indisponibilité.

Soyez explicite sur ce qui est exclu. Les health checks, les sondes synthétiques de votre propre monitoring et les réponses 4xx dues à une mauvaise entrée client ne devraient généralement pas compter contre vous. Écrivez les exclusions à côté du SLO. Quand quelqu'un conteste le chiffre pendant une revue d'incident, le débat doit porter sur la définition, pas sur ce que le dashboard affiche par hasard.

L'arithmétique que personne ne fait avant de choisir ses neuf

Chaque neuf supplémentaire divise par dix le temps d'indisponibilité autorisé. C'est le tableau à garder dans le document.

• 99 % sur 30 jours : 1 % de budget d'erreur, soit 7,2 heures de panne totale autorisées.

• 99,9 % : 0,1 % de budget, soit 43,2 minutes.

• 99,95 % : 0,05 % de budget, soit 21,6 minutes.

• 99,99 % : 0,01 % de budget, soit 4,32 minutes.

Relisez la dernière ligne. À 99,99 %, un seul mauvais déploiement, détecté et annulé en cinq minutes, a déjà fait sauter le mois. Un humain ne peut pas répondre à une alerte d'astreinte, ouvrir un laptop et revenir en arrière en moins de quatre minutes : cette cible n'est donc atteignable qu'avec de l'automatisation, une porte automatique qui arrête le rollout avant que le budget ne soit épuisé.

Choisissez donc le chiffre dont le service a réellement besoin. La plupart des API internes vivent très bien à 99,9 %. Un chemin de paiement peut justifier davantage. Un job batch qui tourne la nuit peut se contenter de 99 %. Choisir 99,99 % parce que ça sonne sérieux, c'est s'inscrire à une astreinte qu'on ne peut pas staffer.

Le budget d'erreur est le point, pas le SLO

Un SLO à 99,9 % signifie que vous avez le droit d'échouer 0,1 % du temps. Ces 0,1 % constituent votre budget d'erreur, et c'est l'idée la plus utile de toute la discipline.

Le budget transforme une discussion en chiffre. Le produit veut livrer la migration risquée. Le SRE dit que c'est risqué. Sans budget, c'est une opinion contre une autre, et l'ancienneté gagne. Avec un budget, la question devient : combien il reste, et combien ce changement peut raisonnablement en consommer ?

Deux règles font tenir le dispositif.

1. Budget restant : on livre. Vous avez le droit de prendre des risques, alors prenez-les. Une équipe qui ne dépense jamais son budget investit trop dans une fiabilité que les utilisateurs n'ont pas demandée.

2. Budget épuisé : on gèle. Le travail sur les fonctionnalités s'arrête jusqu'à ce que le travail de fiabilité remonte le SLI au-dessus de la cible. Cela ne tient que si la direction l'a acceptée avant le premier incident, pas pendant.

Si la seconde règle n'a pas été convenue à l'avance, vous n'avez pas de SLO. Vous avez un dashboard avec une zone verte et une zone rouge.

Alerter sur le burn rate, pas sur le SLI lui-même

C'est là que la plupart des premières tentatives échouent. Quelqu'un configure une alerte quand la disponibilité passe sous 99,9 %. L'alerte se déclenche après les dégâts, ou elle clignote à chaque incident mineur, ou les deux.

Le signal le plus juste est le burn rate : la vitesse à laquelle vous consommez le budget, comparée au rythme qui l'épuiserait exactement à la fin de la fenêtre. Un burn rate de 1 signifie que vous finirez le mois avec zéro budget restant. Un burn rate de 14,4 signifie que vous êtes sur la trajectoire de brûler le budget de tout un mois en deux jours environ.

Le SRE Workbook de Google sur l'alerte sur les SLO recommande d'associer une fenêtre longue et une fenêtre courte, pour que l'alerte soit significative tout en étant encore active. Pour un SLO sur 30 jours, deux pages constituent un bon point de départ :

• Burn rate 14,4 sur 1 heure, confirmé sur 5 minutes : consomme 2 % du budget mensuel. On réveille quelqu'un.

• Burn rate 6 sur 6 heures, confirmé sur 30 minutes : consomme 5 % du budget mensuel. On réveille quelqu'un.

L'arithmétique est simple. Une fenêtre de 30 jours fait 720 heures. Brûler à 14,4x pendant une heure consomme 14,4 / 720 = 2 % du budget. La fenêtre courte évite que l'alerte se déclenche une heure après la fin du problème.

Voici la première règle sous forme d'alerte Prometheus, en supposant que vous enregistrez un ratio d'erreurs par fenêtre :

groups:
  - name: checkout-slo-burn
    rules:
      - alert: CheckoutErrorBudgetFastBurn
        expr: |
          job:checkout_error_ratio:rate1h > (14.4 * 0.001)
          and
          job:checkout_error_ratio:rate5m > (14.4 * 0.001)
        labels:
          severity: page
        annotations:
          summary: "Le checkout consomme 2 % de son budget d'erreur de 30 jours par heure"

Le 0,001 est le ratio d'erreur autorisé pour un SLO à 99,9 %. Si vous changez la cible, cette constante doit suivre. Gardez-la à un seul endroit, sinon l'alerte et le SLO finiront par diverger sans que personne ne le remarque.

Les brûlures plus lentes n'exigent pas de page. Un burn rate de 1 maintenu pendant trois jours relève d'un ticket pour le lendemain matin ouvré. Réveiller quelqu'un pour une fuite lente, c'est comme ça que les équipes d'astreinte apprennent à ignorer le pager.

Où calculer le SLI sans acheter une seconde plateforme

Vous n'avez pas besoin d'un produit SLO dédié pour commencer. Il vous faut un compteur d'événements bons, un compteur d'événements totaux, et un endroit pour les conserver pendant 30 jours.

Si vos métriques vivent déjà dans une plateforme hébergée, la fonctionnalité SLO n'est généralement qu'une fine couche par-dessus des données que vous payez déjà.

Datadog gère nativement les SLO, avec des alertes de burn rate, et c'est le chemin le plus simple si vos traces et vos métriques sont déjà là-bas. La facture est le piège : les métriques custom et les tags à forte cardinalité se multiplient vite. Vérifiez le prix des séries SLI avant de vous engager.

Si vous faites tourner Prometheus, Grafana couvre le même terrain grâce aux recording rules et à son outillage SLO, au prix de plus de mise en place et de plus de votre temps.

La comparaison honnête oppose le délai avant la première alerte utile au coût à grande échelle. Datadog gagne sur le premier point. Grafana avec Prometheus gagne en général sur le second. Choisissez selon ce qui manque le plus à votre équipe.

Relier le SLO au rollout, c'est la partie que la plupart des équipes sautent

Un SLO qui ne produit qu'un rapport n'est utilisé qu'à moitié. L'étape qui change réellement le comportement, c'est de brancher le budget sur le chemin de déploiement, pour que la mise en production s'arrête toute seule.

Un rollout progressif avec porte SLO fonctionne ainsi. Vous livrez à 1 % du trafic derrière un feature flag. Vous surveillez le SLI de cette cohorte par rapport à la baseline. Si le burn rate de la cohorte canari dépasse votre seuil, vous revenez en arrière automatiquement. S'il tient, vous passez à 5 %, puis 25 %, puis 100 %.

C'est très différent d'un dashboard que quelqu'un est censé surveiller à 03:12. À 03:12, on ne veut pas réfléchir. On veut un bouton, ou mieux, pas de bouton du tout.

C'est là que les feature flags se rentabilisent : un flag transforme un retour arrière en changement de configuration qui prend quelques secondes, au lieu d'un redéploiement qui prend dix minutes.

LaunchDarkly et des plateformes similaires vous donnent le déploiement en pourcentage et le kill switch. Ce qu'elles vous laissent, pour la plupart, c'est la décision : quel SLI lire, quel seuil compte comme mauvais, et qui a le droit de passer outre. C'est l'écart que cherche à combler un pilote automatisé avec auto-rollback sur SLO, et c'est l'angle que nous prenons chez upstreamapi. LaunchDarkly gagne sur l'étendue de ses SDK et ses contrôles entreprise, et nous le disons.

Voici la forme de la porte en TypeScript. La logique de décision est la partie qui vaut la peine d'être écrite soi-même, quel que soit le système de flags utilisé :

type Cohort = { good: number; total: number };

const SLO_TARGET = 0.999;
const BUDGET = 1 - SLO_TARGET; // 0.001
const PAGE_BURN_RATE = 14.4;

function burnRate(c: Cohort): number {
  if (c.total === 0) return 0;
  const errorRatio = 1 - c.good / c.total;
  return errorRatio / BUDGET;
}

export function rolloutDecision(canary: Cohort): "advance" | "hold" | "revert" {
  if (canary.total < 500) return "hold"; // pas assez de trafic pour trancher
  return burnRate(canary) > PAGE_BURN_RATE ? "revert" : "advance";
}

Remarquez la branche hold. Une cohorte canari à 1 % d'un service calme peut voir quarante requêtes en dix minutes, et une erreur sur quarante donne un ratio d'erreur de 2,5 %. Sans échantillon minimum, la porte revient en arrière sur du bruit, et votre équipe apprend à s'en méfier.

Les erreurs que nous voyons encore dans les équipes de 80 ingénieurs

Les mêmes échecs reviennent d'une équipe à l'autre, et presque aucun n'est technique.

• Trop de SLO. Vingt objectifs par service, et personne ne se souvient d'aucun. Deux ou trois par parcours utilisateur suffisent.

• Des SLO que personne n'a validés. Un ingénieur les écrit seul un week-end. Le produit ne les a jamais vus, donc la politique de budget s'effondre la première fois qu'elle dit « non » à un lancement.

• Des SLO calés sur la performance actuelle. Si le service tourne à 99,97 % aujourd'hui, fixer la cible à 99,97 % ne laisse aucun budget et garantit un échec. Placez-la là où les utilisateurs commencent à être mécontents, ce qui est presque toujours plus bas.

• Considérer le SLO comme permanent. Revoyez le chiffre chaque trimestre. Si vous ne dépensez jamais le budget, resserrez la cible ou livrez plus vite. Si vous le dépassez chaque mois, corrigez le système ou admettez que la cible était une illusion.

• Compter ce qui est facile plutôt que ce qui est ressenti. Une réponse 200 avec un panier vide est un succès dans vos logs et un échec pour le client. Définissez « bon » du point de vue de l'utilisateur.

Qui doit écrire le premier cette semaine

Vous n'avez pas besoin d'un programme. Choisissez le parcours qui ferait appeler le CEO à quelqu'un s'il tombait en panne. Définissez un SLI de disponibilité et un SLI de latence pour lui. Fixez la cible à 99,9 % pour le premier trimestre, rédigez la politique de gel en deux phrases, et faites répondre « d'accord » par écrit au produit.

Ajoutez ensuite une alerte de burn rate, et un endroit où toute l'équipe peut voir le budget restant.

Si vous cherchez un point de départ léger avant de vous engager sur une plateforme complète, Better Stack gère la supervision d'uptime et la pagination d'incidents avec une mise en place bien plus simple, même s'il ne fera pas les calculs de budget à votre place.

La première version sera fausse. C'est acceptable. Ce qui compte, c'est que la prochaine revue d'incident parte d'un chiffre écrit à l'avance plutôt que d'un ressenti.

À quoi ressemble votre 03:12 maintenant ?

Prenez le dernier incident de votre équipe. Y avait-il un chiffre écrit qui disait s'il comptait ? Si la réponse honnête est non, c'est votre premier SLO, et le post-mortem vous a déjà dit quoi mesurer.