Des SLO qui ne mentent pas : mesurer ce que les utilisateurs ressentent vraiment

La plupart des tableaux de bord de fiabilité sont au vert pendant que les utilisateurs pestent devant leur écran. Le SLO affiche 99,95 %, les courbes de CPU sont calmes - et le checkout est en échec depuis dix minutes. Cet écart est révélateur : le SLO mesure le système, pas la personne qui s'en sert. Un SLO ne dit la vérité que lorsqu'il mesure ce que l'utilisateur ressent vraiment.

Mesurez ce que l'utilisateur ressent, pas la machine

Le CPU, la mémoire et la disponibilité de l'hôte ne sont pas l'expérience utilisateur. Une machine peut être à 30 % de CPU pendant que toutes les requêtes tombent en timeout ; elle peut tourner à 95 % et servir tout le monde parfaitement. Le seul juge de savoir si votre service fonctionne, c'est l'utilisateur - l'indicateur doit donc venir de son côté du fil. Bâtissez les SLO sur le parcours (la requête a-t-elle abouti, était-elle assez rapide, la réponse était-elle correcte et à jour), jamais sur l'infrastructure en dessous.

Un service level indicator (SLI) est l'un de ces nombres : la proportion d'événements bons sur le total des événements. La plupart des services n'en ont besoin que de trois :

Disponibilité - la part des requêtes valides qui ont abouti.
Latence - la part servie plus vite qu'un seuil que les utilisateurs remarquent, p. ex. 95 % sous 300 ms.
Qualité ou fraîcheur - pour les données et le travail asynchrone, à quel point le résultat est correct ou récent.

Deux réflexes gardent tout cela honnête. Utilisez des percentiles, pas des moyennes - une moyenne saine masque la traîne lente où atterrissent les vrais utilisateurs, alors citez le p95/p99. Et mesurez au plus près de l'utilisateur - le load balancer, l'edge, le monitoring d'utilisateurs réels - car les métriques côté serveur ne voient jamais les échecs DNS, les soucis de CDN, ni la requête qui n'est jamais arrivée.

Si les percentiles vous semblent flous : la latence p95 est le temps de réponse sous lequel 95 % des requêtes restent - donc 1 utilisateur sur 20 attend plus longtemps - et le p99 est le 1 % le plus lent. Une moyenne mélange la majorité rapide et les quelques lents en un seul nombre que personne ne vit réellement ; un percentile garde cette traîne sous les yeux.

Les mêmes requêtes, deux récits : la moyenne se cale dans le milieu confortable tandis que le p95/p99 vit tout au bout de la longue traîne - exactement là où se trouve une part d'utilisateurs réels. Citez les percentiles, et mesurez-les au plus près de l'utilisateur.

Les moyennes masquent les utilisateurs en échec aussi facilement que les lents. Un taux de réussite de 99,5 % donne l'impression d'être à un arrondi de la perfection - mais sur le trafic réel, cette fraction est un flux constant de gens qui tombent sur des échecs, en général concentrés dans un segment que le nombre global ne peut pas voir. Soyez toujours en mesure de décomposer un SLI par parcours, par plateforme et par région.

0,5 % d'erreurs paraît anodin jusqu'à ce que vous comptiez les utilisateurs derrière - et constatiez que les échecs ne sont pas répartis uniformément. Décomposer le SLI par segment, c'est ce qui fait remonter la partie du produit qui brûle vraiment.

Un SLO par parcours - responsabilisé et taggé

Les SLO suivent les parcours utilisateur, pas votre organigramme ni les services pris un à un. Définissez-en un par parcours - checkout, login, recherche - et résistez à l'envie de les fondre en un seul nombre pour tout le site : un SLO global reste au vert pendant que le checkout est cassé, parce que des assets statiques en bonne santé noient les échecs qui comptent. Et donnez à chaque parcours l'objectif qu'il mérite ; un chemin de paiement et un widget de recommandations n'ont pas besoin de la même fiabilité.

Chaque parcours a son propre SLO et l'objectif dont il a réellement besoin. Le budget d'erreur est le crédit de l'équipe responsable, et des tags cohérents (service · équipe · parcours) font remonter chaque SLI jusqu'à celui qui peut agir dessus.

Le budget d'erreur - l'écart entre votre objectif et 100 % - devient alors la monnaie de l'équipe responsable. Les équipes sont largement cloisonnées, et certaines surfaces absorbent bien plus d'échecs que d'autres : laissez donc chaque équipe détenir et dépenser son propre budget. Il achète de la vélocité quand il reste de la marge et force à se recentrer sur la fiabilité quand il est épuisé. Rien de tout cela ne marche sans un tagging discipliné - chaque métrique, ressource et alerte étiquetée avec le service, l'équipe et le parcours - pour que chaque SLI remonte au bon responsable et qu'un budget qui brûle pointe droit vers l'équipe capable de le corriger.

Fixez un objectif que vous pouvez défendre

Ne visez pas 99,99 % par réflexe. Chaque neuf supplémentaire coûte exponentiellement plus cher, et un objectif que vous ne financerez pas vraiment n'est qu'un mensonge de plus sur le tableau de bord. Choisissez le nombre dont le parcours a réellement besoin - et gardez votre SLO interne plus strict que tout SLA que vous avez signé, pour le découvrir avant le client.

Un SLO de 99,9 % sur 30 jours autorise environ 43 minutes de 'mauvais' par mois. Ce nombre, c'est tout l'intérêt : il fait passer 'sommes-nous assez fiables ?' du débat à l'arithmétique.

Et n'essayez pas de trouver le nombre parfait dès le premier jour - c'est impossible. Trop haut, vous vivez en permanence hors budget ; trop bas, il ne veut rien dire. Commencez par mesurer où vous en êtes vraiment, fixez l'objectif juste au-dessus de la réalité du jour, et traitez-le comme un plancher mobile : à chaque revue hebdomadaire ou mensuelle, l'équipe SRE regarde ce qu'elle a tenu et, si le service s'est amélioré, relève la barre d'un cran. Le SLO monte cran par cran, sprint après sprint - chaque palier un niveau que vous avez réellement tenu, pas un que vous espériez.

Fixez l'objectif juste au-dessus de votre niveau actuel, puis relevez-le à chaque revue. La barre monte à mesure que le service progresse - pas à pas, vous vous améliorez de façon mesurable, et chaque objectif en est un que vous avez réellement tenu.

Faites du budget une règle de décision

Un budget d'erreur ne mérite sa place que lorsqu'il change les comportements, et la règle doit être convenue à l'avance. Du budget en réserve : livrez, faites la migration risquée, lancez le test de charge en prod. Budget épuisé : gelez les changements risqués et consacrez le prochain sprint à la fiabilité jusqu'à repasser au vert. Revu chaque semaine, il fait passer la fiabilité d'un ressenti à une décision partagée et assumée.

Alertez sur le parcours, naviguez jusqu'à la cause

Comme le SLO mesure le parcours, c'est la seule chose qui mérite une alerte. L'alerte se déclenche sur une consommation de budget visible par l'utilisateur et ouvre le tableau de bord du parcours - taux de réussite, p95, budget restant. De là, vous descendez : vers les tableaux de bord de service des composants sur le chemin, puis vers les ressources dépendantes - base de données, cache, file d'attente, API en amont. Voir ces dépendances est inestimable pour le diagnostic ; ce n'est jamais une raison d'alerter. Des tags cohérents sont ce qui rend cette descente possible - ils permettent à un tableau de bord en gabarit de renvoyer au suivant, au lieu de vous laisser avec un tas d'écrans déconnectés.

Alertez sur le SLO visible par l'utilisateur, tout en haut - la seule chose qui devrait réveiller quelqu'un. L'alerte ouvre le tableau de bord du parcours, qui renvoie en dessous aux services puis aux ressources dépendantes, où vous diagnostiquez.

Le SLO est aussi l'entrée de votre alerting : alimentez le taux de consommation du budget dans des alertes multi-fenêtres, pour qu'un bref hoquet soit une note de bas de page et qu'une consommation soutenue déclenche une alerte (je détaille ce mécanisme dans 'Concevoir des alertes que personne n'ignore'). La chaîne de tableaux de bord vous mène alors de l'alerte à la cause en trois clics, pas trente.

Calculez-le automatiquement

Rien de tout cela ne devrait être maintenu à la main. Calculez les SLI à partir de la télémétrie dont vous disposez déjà - Prometheus, Datadog, logs du load balancer - sous forme de recording rules, et exposez un panneau par parcours : SLI courant, objectif, budget restant, taux de consommation. Si produire le nombre est manuel, il pourrira ; s'il est automatique, il devient la première chose que tout le monde regarde.

La télémétrie que vous collectez déjà alimente des recording rules qui calculent le SLI par fenêtre, exposé sous forme d'une tuile en direct par parcours - SLI courant, objectif, budget restant, taux de consommation.

Sous le capot, le SLI est une petite requête : comptez les requêtes, comptez les erreurs, divisez. Définissez-le une fois comme recording rule et chaque tableau de bord et chaque alerte réutilise le même nombre.

# A - requetes sur la fenetre
- record: checkout:requests:rate5m
  expr: sum(rate(http_requests_total{job="checkout"}[5m]))

# B - erreurs (HTTP 5xx) sur la meme fenetre
- record: checkout:errors:rate5m
  expr: sum(rate(http_requests_total{job="checkout", code=~"5.."}[5m]))

# C - pourcentage d'erreur = B / A  (la part "mauvaise" du SLI)
- record: checkout:error_pct5m
  expr: 100 * checkout:errors:rate5m / checkout:requests:rate5m

# A = requetes · B = erreurs · C = 100 * B / A  (% d'erreur)
100 * (
  sum:http.requests.errors{service:checkout}.as_count()
  / sum:http.requests.hits{service:checkout}.as_count()
)

Revoyez et faites évoluer

Les SLO sont des promesses vivantes, pas un tableur rempli une fois pour toutes. Réexaminez les objectifs à mesure que le produit et les attentes des utilisateurs changent. Un budget que vous ne brûlez jamais signifie que l'objectif est trop bas - ou que vous surinvestissez dans une fiabilité que personne n'a demandée ; un budget que vous explosez tous les mois signifie que l'objectif est irréaliste ou que le service a besoin d'un vrai travail. Le bon SLO se situe là où, de temps en temps et utilement, ça fait mal.

Un SLO qui mesure l'utilisateur, fixé à un nombre que vous financerez vraiment, porté par l'équipe capable de le faire bouger, et câblé à des alertes qui mènent droit à la cause - voilà un SLO qui dit la vérité. Tout le reste est un feu vert au-dessus d'un bâtiment en flammes.