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

La plupart des dashboards de fiabilité sont au vert pendant que les utilisateurs jurent devant leur écran. Le SLO dit 99,95%, les courbes de CPU sont calmes — et le checkout échoue depuis dix minutes. Cet écart est l'indice : 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

CPU, mémoire et uptime de l'hôte ne sont pas l'expérience utilisateur. Une machine peut être à 30% de CPU pendant que toutes les requêtes expirent ; 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. Construisez les SLO sur le parcours (la requête a-t-elle réussi, était-elle assez rapide, la réponse était-elle correcte et récente), 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 réussi.
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 habitudes gardent tout cela honnête. Utilisez des percentiles, pas des moyennes — une moyenne saine cache la queue lente où atterrissent les vrais utilisateurs, alors citez p95/p99. Et mesurez au plus près de l'utilisateur — le load balancer, l'edge, le monitoring d'utilisateur réel — car les métriques côté serveur ne voient jamais les échecs DNS, les problèmes de CDN, ou 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 arrivent 95% des requêtes — donc 1 utilisateur sur 20 attend plus longtemps — et p99 est le 1% le plus lent. Une moyenne fond la majorité rapide et les quelques lents en un seul nombre que personne ne vit réellement ; un percentile garde cette queue en vue.

Les mêmes requêtes, deux histoires : la moyenne s'assoit dans le milieu confortable tandis que p95/p99 vivent dans la longue queue — qui est exactement là où se trouve une tranche d'utilisateurs réels. Citez les percentiles, et mesurez-les au plus près de l'utilisateur.

Les moyennes cachent les utilisateurs en panne aussi facilement que les lents. Un taux de réussite de 99,5% se lit comme à un arrondi de la perfection — mais sur le trafic réel cette fraction est un flux constant de gens qui se heurtent à des échecs, en général entassés dans un segment que le nombre global ne peut pas voir. Soyez toujours capable de décomposer un SLI par parcours, plateforme et région.

0,5% d'erreurs paraît inoffensif jusqu'à ce que vous comptiez les utilisateurs derrière — et remarquiez 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 réellement.

Un SLO par parcours — avec propriétaire et taggé

Les SLO suivent les parcours utilisateur, pas votre organigramme ni les services individuels. Définissez-en un par parcours — checkout, login, recherche — et résistez à les fondre en un seul nombre pour tout le site : un SLO global reste au vert pendant que le checkout est cassé, parce que les assets statiques sains 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 vraiment besoin. Le budget d'erreur est le crédit de l'équipe propriétaire, et des tags cohérents (service · équipe · parcours) agrègent 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 propriétaire. Les équipes sont largement isolé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 y a de la marge et force à se concentrer 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 service, équipe et parcours — pour que chaque SLI remonte au bon propriétaire et qu'un budget qui brûle pointe droit vers l'équipe qui peut le réparer.

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 dashboard. 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 est tout l'intérêt : il transforme 'sommes-nous assez fiables ?' d'une dispute en une opération d'arithmétique.

Et n'essayez pas de trouver le nombre parfait dès le premier jour — vous ne pouvez pas. Trop haut, vous vivez en permanence hors budget ; trop bas, il ne veut rien dire. Commencez par mesurer où vous êtes vraiment, fixez l'objectif juste au-dessus de la réalité d'aujourd'hui, 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 d'un cran sprint après sprint — chaque pas un niveau que vous avez réellement tenu, pas un que vous souhaitiez.

Fixez l'objectif juste au-dessus de là où vous êtes, puis relevez-le à chaque revue. La barre monte à mesure que le service progresse — pas à pas vous devenez mesurablement meilleur, 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 gagne 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 dépensé : gelez les changements risqués et mettez le prochain sprint dans la fiabilité jusqu'au retour au vert. Revu chaque semaine, il transforme la fiabilité d'un ressenti en 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 pour laquelle il vaut la peine d'être alerté. L'alerte se déclenche sur une consommation de budget visible par l'utilisateur et ouvre le dashboard du parcours — taux de réussite, p95, budget restant. De là, vous descendez : vers les dashboards de service des composants sur le chemin, puis vers les ressources dépendantes — base de données, cache, file, 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 laissent un dashboard en template renvoyer au suivant, au lieu de vous laisser avec un tas d'écrans déconnectés.

Alertez sur le SLO visible par l'utilisateur, en haut — la seule chose qui devrait réveiller quelqu'un. L'alerte ouvre le dashboard du parcours, qui renvoie en bas 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 soit une alerte (je couvre ce mécanisme dans 'Concevoir des alertes que personne n'ignore'). La chaîne de dashboards vous porte 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 que vous avez déjà — Prometheus, Datadog, logs du load balancer — sous forme de recording rules, et exposez un panneau par parcours : SLI actuel, objectif, budget restant, taux de consommation. Si produire le nombre est manuel, il pourrira ; s'il est automatique, il devient la chose que tout le monde regarde en premier.

La télémétrie que vous collectez déjà alimente des recording rules qui calculent le SLI par fenêtre, exposées comme une tuile en direct par parcours — SLI actuel, 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 dashboard et 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 fait une fois. Revisitez 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 chaque mois signifie que l'objectif est irréaliste ou que le service a besoin de 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, possédé par l'équipe qui peut le faire bouger, et câblé à des alertes qui descendent 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.