Vos alertes mentent (probablement)
Combien d’alertes votre équipe reçoit-elle par semaine ? 50 ? 200 ? Et combien d’entre elles correspondent à un vrai problème qui impacte les utilisateurs ?
Dans la majorité des organisations que j’observe, le ratio signal/bruit des alertes est catastrophique. CPU à 80% ? Alerte. Temps de réponse d’une API interne à 500ms ? Alerte. Queue de messages qui grossit ? Alerte. L’équipe ops vit dans un flux permanent de notifications, développe une fatigue d’alerte, et finit par ignorer des signaux critiques noyés dans le bruit.
Le problème n’est pas technique. C’est conceptuel. On mesure les mauvaises choses.
SLI, SLO, Error Budget : les fondamentaux
SLI (Service Level Indicator)
Un SLI est une mesure quantitative du comportement du service du point de vue de l’utilisateur. Pas du point de vue du serveur — de l’utilisateur.
Les SLI utiles :
- Disponibilité : pourcentage de requêtes qui retournent un code HTTP valide (pas une 500)
- Latence : temps de réponse perçu par l’utilisateur (p50, p95, p99)
- Fraîcheur des données : délai entre une mise à jour et sa visibilité côté utilisateur
- Exactitude : pourcentage de réponses correctes (pertinent pour les systèmes de recherche ou de recommandation)
Les SLI inutiles :
- Utilisation CPU du serveur (un serveur à 90% de CPU qui sert les requêtes en 50ms n’a pas de problème)
- Espace disque disponible (sauf si vous êtes vraiment près de la limite)
- Nombre de pods Kubernetes actifs (c’est de la plomberie, pas un indicateur de santé)
SLO (Service Level Objective)
Un SLO est l’objectif de performance que vous vous fixez sur un SLI donné, mesuré sur une fenêtre de temps.
Exemples concrets :
- “99,9% des requêtes de la page produit doivent retourner un résultat valide en moins de 300ms, mesuré sur 30 jours glissants”
- “99,5% des transactions de paiement doivent aboutir avec succès en moins de 2 secondes”
- “99% des mises à jour de stock doivent être visibles sur le site en moins de 60 secondes”
L’erreur classique : fixer des SLO trop ambitieux. 99,99% de disponibilité (4 minutes 19 secondes d’indisponibilité par mois) est extrêmement coûteux à atteindre et rarement nécessaire. Pour la plupart des services, 99,5% à 99,9% est un objectif réaliste et suffisant.
Error Budget
L’error budget est le complément du SLO. Si votre SLO est 99,9%, votre error budget est 0,1% — le droit à l’erreur que vous vous accordez.
Sur 30 jours, 0,1% d’error budget correspond à environ 43 minutes d’indisponibilité ou à 1 requête sur 1000 en erreur.
L’error budget est un outil de décision, pas juste une métrique. Quand le budget est consommé :
- On arrête les déploiements non critiques
- On priorise la fiabilité sur les nouvelles fonctionnalités
- On lance un post-mortem pour comprendre ce qui a brûlé le budget
Quand le budget est confortable :
- On déploie plus fréquemment
- On prend des risques techniques calculés (migrations, refactoring)
- On expérimente
Comment définir des SLO pertinents
Partir des parcours utilisateurs critiques
Ne mettez pas des SLO partout. Identifiez les 5-8 parcours qui représentent 80% de la valeur business :
Pour un site e-commerce :
- Recherche produit → résultat pertinent en moins de 200ms
- Page produit → affichage complet en moins de 1 seconde
- Ajout au panier → confirmation en moins de 500ms
- Tunnel de paiement → transaction complète en moins de 5 secondes
- Confirmation de commande → email envoyé en moins de 2 minutes
Chaque parcours a ses propres SLI et SLO. Le tunnel de paiement exige une disponibilité plus élevée que la page “Qui sommes-nous”.
Calibrer sur les données historiques
Ne devinez pas vos SLO. Mesurez votre performance actuelle sur 30-90 jours et fixez un SLO légèrement au-dessus de votre performance de base.
Si votre p99 de latence actuel est à 800ms, ne fixez pas un SLO à 200ms. Commencez à 700ms, puis améliorez progressivement. Un SLO inatteignable est pire qu’aucun SLO — il décrédibilise toute la démarche.
Impliquer les parties prenantes business
Les SLO ne sont pas un sujet purement technique. Le product manager doit comprendre et valider les objectifs. Le business doit savoir qu’un SLO à 99,99% coûte 10 fois plus cher qu’un SLO à 99,9%. C’est un arbitrage économique, pas technique.
L’implémentation technique
La stack d’observabilité
Une implémentation SLO sérieuse repose sur trois piliers :
Collecte des métriques :
- OpenTelemetry pour l’instrumentation standardisée
- Métriques côté client (Real User Monitoring) ET côté serveur
- Traces distribuées pour comprendre la latence de bout en bout
Calcul et stockage :
- Prometheus + Thanos ou Grafana Mimir pour les métriques time-series
- Calcul des SLI en temps réel avec des fenêtres glissantes
- Historique sur 90 jours minimum pour les tendances
Visualisation et alerting :
- Dashboard SLO avec burn rate (vitesse de consommation de l’error budget)
- Alertes basées sur le burn rate, pas sur des seuils absolus
- Page d’état interne accessible à toute l’organisation
Le burn rate alerting
L’alerte traditionnelle dit : “Le temps de réponse dépasse 500ms depuis 5 minutes.” Le burn rate alerting dit : “Au rythme actuel de consommation, l’error budget sera épuisé dans 6 heures.”
La différence est cruciale. Un pic de latence de 10 minutes qui consomme 0,5% de l’error budget mensuel ne justifie pas de réveiller quelqu’un à 3h du matin. Une dégradation lente qui consomme l’error budget en continu, si.
Deux niveaux d’alerte :
- Fast burn (consommation rapide) : l’error budget sera épuisé en moins de 2 heures au rythme actuel → alerte immédiate, intervention requise
- Slow burn (consommation lente) : l’error budget sera épuisé avant la fin de la fenêtre → ticket prioritaire, investigation dans la journée
Les pièges de l’implémentation
Mesurer côté serveur uniquement. Le serveur peut répondre en 50ms, mais si le CDN ajoute 200ms et le rendering client 800ms, l’utilisateur attend plus d’une seconde. Mesurez au plus proche de l’utilisateur.
Ignorer les dépendances externes. Votre SLO à 99,9% ne tient pas si votre passerelle de paiement est à 99,5%. Identifiez les dépendances et intégrez leurs limites dans vos objectifs.
Oublier les cas limites. Les SLO sur les moyennes cachent les problèmes. Un p50 à 100ms et un p99 à 5 secondes donnent une moyenne acceptable mais une expérience désastreuse pour 1% des utilisateurs. Mesurez les percentiles, pas les moyennes.
Le SLO comme outil de culture
Dépasser le blame
Quand un incident se produit, la question n’est plus “qui a fait une erreur ?” mais “combien d’error budget avons-nous consommé et que devons-nous changer pour que ça n’arrive plus ?”
Le post-mortem sans blame, alimenté par des données objectives, transforme les incidents en opportunités d’apprentissage. Pas de coupable — des systèmes à améliorer.
Aligner tech et business
Le SLO est le contrat entre l’équipe technique et le business. Le business accepte qu’un système à 100% de disponibilité n’existe pas. L’équipe technique s’engage sur un niveau de service mesurable. Tout le monde parle le même langage.
Prioriser avec des données
“On devrait refactorer ce service” est un argument faible. “Ce service a consommé 60% de notre error budget le mois dernier à cause de sa dette technique” est un argument qui débloque du budget.
FAQ
Par où commencer quand on n’a aucun SLO ?
Commencez par instrumenter vos 3 parcours utilisateurs les plus critiques avec des métriques de base (disponibilité et latence). Mesurez pendant 30 jours sans fixer d’objectif. Ensuite, fixez des SLO légèrement au-dessus de votre performance constatée. C’est un point de départ. Vous ajusterez les cibles progressivement en fonction de vos capacités d’amélioration et des exigences business.
Faut-il communiquer les SLO aux clients ?
Les SLO internes et les SLA (Service Level Agreements) externes sont deux choses différentes. Vos SLO internes doivent être plus exigeants que vos SLA clients, pour avoir une marge de manoeuvre. En règle générale, communiquez des SLA à vos clients (avec des pénalités contractuelles si nécessaire) et gardez des SLO plus stricts en interne.
Quel est le coût d’implémentation d’une stack SLO ?
Pour une organisation de taille moyenne (10-50 services), comptez 2-3 mois de travail d’un SRE senior pour mettre en place l’instrumentation, le calcul des SLI, les dashboards et l’alerting. En infrastructure, la stack OpenTelemetry + Prometheus + Grafana est open source. Les solutions managées (Datadog, New Relic) simplifient l’opérationnel mais ajoutent un coût de licence significatif (5-15K par mois selon le volume).
Les SLO fonctionnent-ils pour les architectures serverless ?
Oui, et ils sont même plus importants. En serverless, vous n’avez pas de visibilité sur l’infrastructure sous-jacente. Les cold starts, les limites de concurrence, les timeouts — tout cela impacte l’expérience utilisateur sans que les métriques d’infrastructure classiques le montrent. Les SLO côté utilisateur sont votre seul indicateur fiable de la santé du système.