Qu'est-ce qu'un SLO en ingénierie ? Guide pratique

Qu'est-ce qu'un SLO ? La question « quest ce quun slo » est fondamentale pour chaque équipe d'ingénierie. Un SLO (Service Level Objective, ou objectif de niveau de service) est une cible interne de fiabilité que votre équipe se fixe pour elle-même. Pas un contrat avec les clients. Pas une mesure brute sortie de votre stack d'observabilité. Un SLO répond à la question : de quel niveau de fiabilité ce service a-t-il besoin, et comment allons-nous le mesurer ?

Un SLO complet ressemble à ceci : 99,9 % des requêtes HTTP vers /api/checkout retournent un statut de succès et se complètent en moins de 300 ms, mesuré sur une fenêtre glissante de 30 jours. Trois composants : la mesure, la cible et la fenêtre. Les trois sont importants.

SLI, SLO, SLA : Trois termes aux significations distinctes

Ces trois termes apparaissent ensemble régulièrement. Les équipes les utilisent de manière interchangeable. Ils décrivent des choses différentes.

Un SLI (Service Level Indicator) est la mesure brute que votre système de monitoring produit. Taux d'erreur en pourcentage du total des requêtes. Latence P99 en millisecondes. Pourcentage des écritures en base réussies. Le SLI est le chiffre qui sort de Datadog, Grafana, ou quel que soit votre stack. Il vous dit ce qui s'est passé.

Un SLO (Service Level Objective) est la cible que vous définissez sur le SLI. Il répond à : parmi toutes les valeurs possibles que le SLI peut prendre, quelle est la plage acceptable ? Si votre SLI est le taux d'erreur et votre SLO est « taux d'erreur inférieur à 0,1 % pour 99 % des fenêtres de cinq minutes », vous avez un test réussi/échoué, pas juste un chiffre sur un tableau de bord.

Un SLA (Service Level Agreement) est la version externe de la même logique, avec des conséquences contractuelles. Votre SLA pourrait dire « 99,5 % de disponibilité, sinon 20 % de crédit de service ». Votre SLO devrait être au-dessus de ce seuil, pour que votre équipe soit informée d'une dégradation avant que le client remarque une violation du SLA.

L'écart entre SLO et SLA n'est pas du rembourrage pour la négligence. C'est une marge conçue qui transforme « on se rapproche d'une violation » en « on a le temps de réparer maintenant ».

Une distinction supplémentaire importante : les SLI sont mesurés en continu, mais les SLO sont évalués sur une fenêtre. Le même taux d'erreur mesuré sur sept jours versus 30 jours produit des résultats réussi/échoué très différents. Une mauvaise heure compte beaucoup dans une fenêtre de sept jours. Dans une fenêtre de 30 jours, c'est environ un pour cent de la période. Choisir la bonne fenêtre est aussi important que choisir la bonne cible.

Pourquoi « de quel niveau de fiabilité ? » n'est pas une question complète

Avant de choisir un chiffre, vous devez comprendre ce que l'utilisateur expérimente quand le service se dégrade. « On a besoin de cinq neufs » est une déclaration d'ambition, pas une mesure. Une API de panier à 99,999 % de disponibilité signifie à peu près 26 secondes d'erreur par mois. Pour un service traitant dix transactions par seconde, cela pourrait être acceptable. Pour un service gérant un règlement financier en temps réel, ce ne l'est peut-être pas.

Le bon SLO dépend de deux facteurs : l'impact utilisateur d'une dégradation et le coût opérationnel du maintien d'une cible plus serrée.

Si votre service a enregistré 99,3 % de disponibilité au cours des 90 derniers jours, commencer votre premier SLO à 99,9 % est aspirationnel, pas calibré. L'approche pratique : tirez les données SLI des 90 derniers jours, fixez le SLO légèrement plus serré que la performance actuelle, puis révisez trimestriellement. Un SLO de 99,5 % avec une vraie politique d'erreur budget vaut mieux qu'un SLO de 99,9 % qu'on ignore à chaque fois qu'il est dépassé.

Cibles SLO communes par type de service :

• APIs orientées utilisateur (panier, authentification) : 99,9 % de disponibilité, latence P99 inférieure à 500 ms

• Services internes (pipelines de données, jobs batch) : 99,5 % de taux de succès, mesuré sur la complétion du job

• Outils d'administration : 99 % de disponibilité est souvent suffisant

• Workers en arrière-plan : SLO sur le temps de complétion du job plutôt que le statut HTTP

Quand vous choisissez quel SLI mesurer, utilisez les quatre signaux du livre Google SRE comme point de départ : disponibilité (la requête a-t-elle réussi ?), latence (combien de temps a-t-elle pris ?), débit (combien de requêtes le système traite-t-il ?), et taux d'erreur (quelle fraction a échoué ?). Pas tous les services n'ont besoin des quatre. La plupart des équipes obtiennent un vrai signal de la disponibilité plus une latence en centile. Ajouter plus de SLI avant d'avoir une ligne de base fiable pour les deux premiers est une façon courante de créer du bruit sans gagner en insight.

L'erreur budget : de la cible à la décision opérationnelle

Un erreur budget est l'inverse mathématique de votre SLO. Si votre SLO de disponibilité est de 99,9 %, alors 0,1 % des requêtes sur la fenêtre de mesure peuvent échouer. Pour un service recevant un million de requêtes par mois, c'est 1 000 requêtes échouées avant que le SLO soit dépassé.

L'erreur budget rend les SLO opérationnellement utiles. Sans lui, un SLO est un seuil qui est violé et ensuite discuté. Avec une politique d'erreur budget, c'est un cadre de décision.

Quand l'erreur budget est sain, disons 80 % restant avec deux semaines dans la fenêtre, l'équipe peut déployer rapidement. Nouvelles fonctionnalités, expériences, déploiements plus risqués sont tous acceptables. L'erreur budget est le signal que la vitesse n'est pas actuellement le facteur limitant.

Quand l'erreur budget diminue, l'équipe change. Les modifications non critiques sont mises en attente. La politique de déploiement se resserre. Les corrections de fiabilité deviennent prioritaires. L'erreur budget a pris la décision, pas un jugement managérial sur si les choses « semblent assez stables ».

Un scénario concret : un service de panier a eu une dégradation de 12 minutes un mardi après-midi, consommant 15 % de l'erreur budget mensuel. Un deuxième incident le jeudi a consommé encore 12 %. À 27 % consommés dans la première semaine du mois, la politique d'erreur budget se déclenche : pas de nouveaux déploiements de fonctionnalités jusqu'à ce que la postmortem soit complète et la cause racine soit réparée. Cette décision n'est pas une négociation produit/ingénierie. C'est une lecture des données.

Google a publié sa politique d'erreur budget dans le SRE Workbook : un incident unique consommant plus de 20 % de l'erreur budget trimestriel requiert une postmortem. C'est une politique concrète à adapter.

Les alertes de taux de combustion vont plus loin. Au lieu d'attendre jusqu'à ce que l'erreur budget soit presque épuisé, une alerte de taux de combustion se déclenche quand le taux de consommation suggère que vous épuiserez le budget avant la fin de la fenêtre. Si votre service consomme l'erreur budget à 14 fois le taux normal, vous épuiserez un budget de 30 jours en environ 50 heures. Une alerte à ce taux donne à l'équipe deux jours pour répondre plutôt qu'une notification de postmortem après la violation. Les outils comme Datadog et Grafana supportent l'alerte multi-fenêtre, multi-taux de combustion dès la sortie de la boîte. Le configurer prend un après-midi. Ne pas l'avoir signifie découvrir les violations de SLO après que les clients les aient déjà remarquées.

Fixer votre premier SLO sans vous tromper sur le chiffre

L'erreur la plus courante est de commencer par la cible avant d'établir la mesure.

Étape 1 : Définir le SLI. « Disponibilité » n'est pas un SLI. « Les requêtes HTTP retournant un statut de succès (2xx/3xx), divisées par toutes les requêtes HTTP » est un SLI. La mesure doit pouvoir être produite à partir de la télémétrie que vous avez déjà. Promettre d'instrumenter quelque chose « bientôt » signifie que le SLO n'a pas de source de données.

Étape 2 : Tirez les données historiques. Regardez les 60 à 90 derniers jours. À quoi ressemble vraiment le SLI ? Quels étaient les deux ou trois pires jours ? Cela vous dit quelle cible est réalisable aujourd'hui et combien de marge vous avez avant la première violation.

Étape 3 : Fixez la fenêtre de mesure. Les fenêtres glissantes de 30 jours sont les plus courantes et vous donnent des données réactives et toujours actuelles. Les fenêtres de mois calendaire créent des effets de falaise aux frontières des mois. Les fenêtres glissantes de sept jours sont plus sensibles mais peuvent se déclencher trop souvent pour les équipes qui construisent encore leur muscle de fiabilité.

Étape 4 : Écrivez la politique d'erreur budget avant d'en avoir besoin. À quel taux de combustion d'erreur budget l'équipe pause-t-elle les modifications non critiques ? À quel taux de combustion l'on-call escalade-t-il ? Documentez ceci avant l'incident, pas pendant.

Étape 5 : Commencez avec un seul service. Définir les SLO pour 15 services à la fois produit 15 tableaux de bord que personne ne lit. Commencez avec le service le plus visible pour l'utilisateur, exécutez un trimestre, ajustez, puis étendez.

Options de fenêtre de mesure et leurs avantages/inconvénients :

• 7 jours glissants : feedback rapide, plus sensible aux incidents courts, peut créer de la fatigue d'alerte

• 30 jours glissants : le plus courant, équilibre signal et bruit

• 90 jours glissants : utile pour les opérations peu fréquentes mais critiques comme les jobs batch

Un exemple travaillé : pour une API e-commerce, vous pourriez fixer votre premier SLO comme « 95 % des requêtes vers /checkout réussissent et retournent en moins de 500 ms, mesurés sur une fenêtre glissante de 28 jours ». Cela vous donne un SLI concret (taux de succès combiné à la latence), une cible spécifique (95 %), et une fenêtre définie (28 jours). À partir de là, vous calculez l'erreur budget : 5 % des requêtes totales peuvent échouer ou être lentes. Si vous recevez 200 000 requêtes par jour, votre erreur budget mensuel est à peu près 280 000 requêtes échouées avant que le SLO soit dépassé.

Où le monitoring SLO se connecte aux tâches de codebase

Un erreur budget qui brûle plus vite que prévu est un problème de codebase plus souvent qu'un problème d'infrastructure. Les pics de latence retracent jusqu'aux requêtes N+1 qui n'ont pas été remarquées en review de code. Les baisses de disponibilité retracent jusqu'à une exception de pointeur null dans un chemin de code qui se déclenche uniquement sous une combinaison de charge spécifique. Le SLO détecte les symptômes. La codebase contient la cause.

C'est ici que le temps entre « l'alerte se déclenche » et « la cause racine identifiée » devient la contrainte pratique. Quand le service de panier consomme 30 % de son erreur budget en trois jours et que l'ingénieur on-call doit chercher dans une monorepo de 150 000 lignes pour trouver la logique de retry qui se comporte différemment sous charge, le SLO fait son travail. L'outillage pour l'analyse des causes racines ne le fait pas.

Les équipes qui ont instrumenté la recherche de code assistée par IA aux côtés de leur stack d'observabilité rapportent un temps d'identification significativement plus court pendant les incidents. Une requête en langage naturel pour où le service de paiement traite les retries sur les réponses 503 trouve la fonction pertinente en secondes plutôt que les 20 minutes qu'il faut pour lire sur cinq fichiers et une page Confluence. La fenêtre d'erreur budget de 43 minutes est dépensée à réparer le problème, pas à lire le code.

Quatre façons dont les équipes se trompent avec les SLO

Trop de SLO. Une équipe suivant 12 SLO simultanément traitera les alertes comme du bruit de fond dans deux mois. Trois à cinq SLO axés sur les comportements les plus visibles pour l'utilisateur est un plafond workable pour une équipe de 10 ingénieurs. Si vous en avez besoin de plus, organisez-les en tiers : des SLO critiques qui déclenchent des politiques d'erreur budget, et des SLO informationnels qui génèrent juste des données.

Mesurer l'infrastructure, pas l'expérience utilisateur. L'utilisation du CPU, la mémoire et les E/S disque sont des signaux de debug utiles. Ce sont de pauvres SLI sauf si vous pouvez prouver qu'ils corrèlent directement avec une dégradation visible pour l'utilisateur. Mesurez ce que l'utilisateur expérimente : le taux de succès de la requête, le temps de réponse au P95 ou P99, le temps jusqu'au premier rendu de données significatif.

Les SLO fixés sans analyse du coût opérationnel. Atteindre 99,99 % de disponibilité nécessite généralement une redondance active, un basculement multi-région et une réponse on-call immédiate à toute heure. Si l'équipe ne peut pas opérer de cette façon de manière durable, le SLO sera régulièrement violé et ensuite ignoré. Un SLO violé et ignoré est pire que pas de SLO : il forme l'équipe à ignorer les alertes de fiabilité.

Utiliser les données d'erreur budget pour assigner des responsabilités. Si la première réaction à un erreur budget consommé est d'identifier qui a déployé le changement qui l'a causé, les rapports cesseront d'être honnêtes. L'erreur budget est une ressource d'équipe. Quand le budget diminue, la question est « qu'est-ce qu'on répare ? » pas « qui est responsable ? »

Le test de santé organisationnelle : partageriez-vous votre statut d'erreur budget actuel dans une réunion d'ingénierie entière sans que cela déclenche une discussion politique ? Si non, la culture autour des SLO a besoin de plus d'attention que les cibles elles-mêmes. Les métriques de fiabilité fonctionnent comme des outils de décision uniquement quand l'équipe fait confiance que signaler un problème ne crée pas de risque personnel.

Les SLO ont besoin de réexamens trimestriels, pas annuels

Fixer un SLO n'est pas un calibrage unique. Les services changent, les modèles de trafic évoluent, et le coût du maintien d'un niveau de fiabilité donné change avec eux.

Tous les 90 jours, passez en revue quatre questions :

1. Le SLO a-t-il tenu ? Si oui, était-ce confortable, suggérant que la cible pourrait être plus serrée ?

2. L'erreur budget a-t-il été totalement consommé ? Quels incidents ont entraîné cela ?

3. Le SLO a-t-il émis un signal utile, ou l'équipe a-t-elle contourné la politique d'erreur budget ?

4. La fenêtre de mesure est-elle toujours appropriée pour la façon dont le service est utilisé ?

Si l'équipe a contourné la politique d'erreur budget plus de deux fois dans un trimestre, le SLO est probablement mal calibré. Soit la cible est trop serrée, soit la fenêtre est trop courte, soit la mesure ne reflète pas ce que les utilisateurs expérimentent réellement.

Les SLO sont des outils de calibrage. Ils sont censés être ajustés à mesure que la fiabilité s'améliore, que le trafic augmente et que les tolérances de l'entreprise vis-à-vis des temps d'arrêt changent. Une équipe qui examine et ajuste ses SLO trimestriellement gère une pratique de fiabilité. Une équipe qui les a fixés une fois et ne les a pas touchés depuis a un tableau de bord avec des chiffres qui ne signifient rien pour personne.