Votre service tourne, les métriques sont au vert, et pourtant les utilisateurs se plaignent. Ou l'inverse : une alerte se déclenche à 3h du matin pour un problème que personne n'a remarqué. Ce décalage entre ce que vous mesurez et ce que vos utilisateurs vivent est le symptôme d'un problème fondamental : vous ne mesurez pas les bonnes choses.
Cette page explique comment les SLI, SLO et error budgets répondent à ce problème, pour des équipes qui gèrent un service en production et veulent arbitrer entre vélocité et stabilité sans débat subjectif. Vous y trouverez la définition de chaque terme, la méthode de calcul d'un error budget, et la technique d'alerte multi-fenêtres (burn rate) recommandée par Google pour détecter les incidents sans noyer l'équipe d'astreinte sous les faux positifs.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »Cette page vous permettra de :
- Distinguer SLI, SLO et SLA et savoir à quel niveau se situe chaque décision.
- Choisir un SLI pertinent parmi les quatre familles (disponibilité, latence, fraîcheur, exactitude).
- Calculer un error budget et son coût de consommation par incident.
- Configurer des alertes burn rate multi-fenêtres qui limitent les faux positifs.
- Documenter une politique d'error budget applicable par l'équipe.
- Outiller le suivi avec des générateurs comme OpenSLO ou Sloth plutôt que des tableurs.
Le problème : mesurer ce qui compte vraiment
Section intitulée « Le problème : mesurer ce qui compte vraiment »Pourquoi les métriques techniques ne suffisent pas
Section intitulée « Pourquoi les métriques techniques ne suffisent pas »La plupart des équipes surveillent des métriques d'infrastructure : CPU, mémoire, espace disque, temps de réponse des serveurs. Ces métriques sont utiles pour le diagnostic, mais elles ne répondent pas à la question essentielle : est-ce que mes utilisateurs sont satisfaits ?
Un serveur peut afficher 20% de CPU et 2 Go de RAM libres tout en servant des pages lentes à cause d'une requête SQL mal optimisée. Inversement, un pic de CPU à 95% pendant un batch nocturne n'affecte personne si aucun utilisateur n'est connecté.
La différence entre "le système fonctionne" et "les utilisateurs sont satisfaits" est au cœur de l'approche SRE (Site Reliability Engineering). C'est pourquoi Google a développé un vocabulaire précis pour parler de fiabilité : les SLI, SLO, SLA et error budgets. Si ces bases vous manquent, le guide Introduction au SRE pose le contexte avant cette page.
La hiérarchie SLI, SLO, SLA
Section intitulée « La hiérarchie SLI, SLO, SLA »Ces trois termes sont souvent confondus. Voici leur relation :
| Terme | Signification | Question à laquelle il répond | Exemple |
|---|---|---|---|
| SLI | Service Level Indicator | Que mesure-t-on ? | Pourcentage de requêtes réussies |
| SLO | Service Level Objective | Quel niveau vise-t-on ? | 99,9% de succès sur 30 jours |
| SLA | Service Level Agreement | Quelles conséquences si on échoue ? | Crédit de 10% si moins de 99,5% |
Le SLI est la métrique brute. Le SLO est l'objectif interne. Le SLA est l'engagement contractuel externe. Ils forment une pyramide où chaque niveau dépend du précédent : sans SLI fiable, impossible de fixer un SLO crédible ; sans SLO tenu, impossible d'honorer un SLA.
SLI : mesurer l'expérience utilisateur
Section intitulée « SLI : mesurer l'expérience utilisateur »Qu'est-ce qu'un bon SLI ?
Section intitulée « Qu'est-ce qu'un bon SLI ? »Un SLI (Service Level Indicator) est une métrique quantitative qui mesure un aspect de la qualité de service telle que perçue par l'utilisateur. Le mot "perçue" est crucial : un SLI ne mesure pas ce que fait votre infrastructure, mais ce que vit votre utilisateur.
Google recommande d'exprimer les SLI sous forme de ratio :
SLI = (nombre d'événements "bons") / (nombre total d'événements)Cette formule présente plusieurs avantages. Le résultat est toujours entre 0% et 100%, ce qui facilite la compréhension et la comparaison. Elle s'adapte naturellement au calcul de l'error budget. Et elle permet d'utiliser les mêmes outils d'analyse pour tous les SLI.
Les quatre types de SLI
Section intitulée « Les quatre types de SLI »Selon le type de système, différents SLI sont pertinents :
Définition : Proportion de requêtes qui aboutissent à une réponse valide.
Formule : requêtes réussies / total requêtes
Ce qui compte comme "réussi" : Une requête qui retourne un code HTTP 2xx ou 4xx (les erreurs client ne sont pas des échecs du service). Les 5xx comptent comme des échecs.
Quand l'utiliser : Pour tout service qui répond à des requêtes utilisateur. C'est le SLI le plus universel.
Exemple concret : Sur 1 million de requêtes, 999 500 ont réussi. SLI de disponibilité = 99,95%.
Définition : Proportion de requêtes servies en dessous d'un seuil de temps acceptable.
Formule : requêtes < seuil / total requêtes
Pourquoi pas une moyenne : La moyenne masque les cas extrêmes. Si 95% de vos requêtes répondent en 50 ms mais 5% prennent 10 secondes, la moyenne sera d'environ 550 ms, ce qui semble acceptable alors que 5% de vos utilisateurs vivent une expérience désastreuse.
Seuils multiples : Il est courant de définir plusieurs SLI de latence : "90% des requêtes en moins de 100 ms" et "99% en moins de 400 ms".
Exemple concret : Sur 1 million de requêtes, 950 000 ont répondu en moins de 200 ms. SLI de latence (200 ms) = 95%.
Définition : Proportion de données servies qui sont à jour selon un seuil défini.
Formule : données à jour / total données servies
Quand l'utiliser : Pour les pipelines de données, les caches, les systèmes de reporting. Toute situation où les utilisateurs consultent des données qui peuvent être obsolètes.
Exemple concret : Un tableau de bord affiche des métriques. Sur 10 000 affichages, 9 800 montrent des données de moins de 5 minutes. SLI de fraîcheur (5 min) = 98%.
Définition : Proportion de réponses qui sont correctes.
Formule : réponses correctes / total réponses
Difficulté : Définir "correct" n'est pas toujours évident. Pour un moteur de recherche, est-ce que le bon résultat apparaît dans le top 10 ? Le top 3 ? En première position ?
Quand l'utiliser : Systèmes de calcul, moteurs de recommandation, pipelines de transformation de données.
Exemple concret : Un système de facturation traite 100 000 transactions. 99 950 sont calculées correctement. SLI d'exactitude = 99,95%.
Où mesurer les SLI
Section intitulée « Où mesurer les SLI »L'emplacement de la mesure influence sa précision, et donc la confiance que vous pouvez accorder au chiffre affiché.
| Point de mesure | Avantages | Inconvénients |
|---|---|---|
| Logs serveur | Facile à mettre en place | Ne voit pas les requêtes qui n'atteignent pas le serveur |
| Load balancer | Plus proche de l'utilisateur | Ne capture pas les problèmes réseau client |
| Instrumentation client | Mesure l'expérience réelle | Complexe à implémenter, données incomplètes |
| Monitoring synthétique | Reproductible, contrôlé | Ne représente pas le trafic réel |
Bonnes pratiques pour les SLI
Section intitulée « Bonnes pratiques pour les SLI »Peu mais pertinents : 2 à 5 SLI par service suffisent. Trop de SLI dilue l'attention et complique les décisions.
Centrés utilisateur : Chaque SLI doit répondre à la question "est-ce que l'utilisateur a obtenu ce qu'il voulait ?". Si un SLI ne reflète pas l'expérience utilisateur, il n'a pas sa place.
Mesurables en continu : Un SLI qu'on ne peut calculer qu'une fois par semaine est inutile pour piloter les décisions quotidiennes.
Standardisés : Utilisez les mêmes définitions et agrégations pour tous vos services. Cela facilite la comparaison et l'outillage.
SLO : définir les objectifs de fiabilité
Section intitulée « SLO : définir les objectifs de fiabilité »Qu'est-ce qu'un SLO ?
Section intitulée « Qu'est-ce qu'un SLO ? »Un SLO (Service Level Objective) est une valeur cible pour un SLI sur une période donnée. Il répond à la question : "Quel niveau de fiabilité est suffisant pour nos utilisateurs ?"
Un SLO se compose de trois éléments :
| Élément | Description | Exemple |
|---|---|---|
| SLI | La métrique mesurée | Disponibilité (requêtes réussies / total) |
| Cible | Le pourcentage visé | 99,9% |
| Fenêtre | La période de mesure | 30 jours glissants |
L'énoncé complet devient : "99,9% des requêtes doivent réussir sur une fenêtre glissante de 30 jours."
Pourquoi 100% n'est pas un bon objectif
Section intitulée « Pourquoi 100% n'est pas un bon objectif »Il est tentant de viser 100% de disponibilité. C'est une erreur pour trois raisons.
C'est techniquement impossible. Même les systèmes les mieux conçus subissent des pannes. Matériel défaillant, erreurs humaines, catastrophes naturelles, bugs logiciels : l'indisponibilité est inévitable.
C'est économiquement irrationnel. Passer de 99% à 99,9% coûte cher. Passer de 99,9% à 99,99% coûte beaucoup plus cher. Passer de 99,99% à 99,999% coûte astronomiquement cher. À un moment, l'investissement ne vaut plus le bénéfice marginal.
C'est imperceptible pour l'utilisateur. Entre 99,99% et 99,999%, l'utilisateur ne fait pas la différence. Son propre réseau WiFi, son opérateur mobile, son navigateur introduisent plus d'instabilité que votre service.
Choisir la bonne fenêtre de mesure
Section intitulée « Choisir la bonne fenêtre de mesure »La fenêtre de mesure influence le comportement du SLO et donc la rapidité avec laquelle un incident ancien "sort" du calcul.
Fenêtre glissante (recommandé) : "Les 30 derniers jours". Plus proche de l'expérience utilisateur : un incident majeur le dernier jour du mois ne "disparaît" pas le lendemain.
Fenêtre calendaire : "Ce mois-ci". S'aligne sur les cycles business et les reportings, mais peut créer des comportements pervers (prendre des risques en début de période, geler tout en fin de période).
Google recommande une fenêtre glissante de 4 semaines (28 jours). Elle contient toujours le même nombre de week-ends, ce qui évite les variations liées aux patterns de trafic hebdomadaires.
SLO par type de service
Section intitulée « SLO par type de service »Le bon niveau de SLO dépend du contexte métier, pas d'un standard universel à copier-coller.
| Type de service | SLO typique | Justification |
|---|---|---|
| Paiements, authentification | 99,99% ou plus | Perte de confiance immédiate si indisponible |
| Application grand public | 99,9% | Équilibre vélocité/stabilité |
| Outil interne | 99,5% | Utilisateurs captifs, plus tolérants |
| Prototype / MVP | 99% | Vélocité prime sur la stabilité |
Error Budget : l'arbitre objectif
Section intitulée « Error Budget : l'arbitre objectif »Qu'est-ce qu'un error budget ?
Section intitulée « Qu'est-ce qu'un error budget ? »L'error budget est la quantité d'indisponibilité tolérée par le SLO. C'est l'écart entre 100% et votre objectif.
Error Budget = 100% - SLOAvec un SLO de 99,9% sur 30 jours :
- Error budget = 0,1%
- En temps : 30 jours x 24h x 60 min x 0,1% = 43,2 minutes
- En requêtes (si 1 million de requêtes/mois) : 1000 requêtes peuvent échouer
L'error budget comme outil de décision
Section intitulée « L'error budget comme outil de décision »L'error budget transforme une tension subjective (Dev veut livrer, Ops veut stabilité) en mécanisme de décision objectif.
-
Budget disponible → Innovation autorisée
Tant qu'il reste de l'error budget, l'équipe peut déployer des features, expérimenter, prendre des risques calculés. L'erreur est normale et attendue.
-
Budget consommé → Focus stabilité
Quand l'error budget est épuisé, les déploiements non critiques sont suspendus. L'équipe se concentre sur la correction des problèmes, l'amélioration des tests, et l'élimination du toil (travail manuel répétitif qui use la fiabilité sans y ajouter de valeur).
-
Budget reconstruit → Retour à la normale
À mesure que le temps passe sans incident, le budget se reconstitue (fenêtre glissante). L'équipe peut reprendre les déploiements.
Politiques d'error budget
Section intitulée « Politiques d'error budget »Un error budget sans politique d'application est inutile. Documentez clairement ce qui se passe quand le budget est épuisé.
Actions courantes :
- Gel des déploiements de features (corrections de bugs autorisées)
- Priorisation des tickets de fiabilité
- Revue post-incident obligatoire
- Temps d'ingénierie dédié à l'automatisation
Qui décide :
- Le product owner peut demander une exception pour un déploiement critique
- L'équipe SRE/Ops a le pouvoir de refuser
- Une escalade vers le management tranche les conflits
Calculer la consommation d'error budget
Section intitulée « Calculer la consommation d'error budget »Pour chaque incident, vous pouvez calculer son "coût" en pourcentage d'error budget :
Coût incident = (erreurs causées / budget total) x 100Exemple : SLO de 99,9% sur 1 million de requêtes/mois
- Budget = 1000 requêtes peuvent échouer
- Incident cause 300 erreurs
- Coût = 300/1000 x 100 = 30% du budget mensuel
Cette métrique permet de prioriser : les incidents qui consomment le plus de budget méritent le plus d'attention dans les postmortems.
Alerter sur la consommation : le burn rate multi-fenêtres
Section intitulée « Alerter sur la consommation : le burn rate multi-fenêtres »Savoir combien d'error budget il reste ne suffit pas : encore faut-il être alerté avant qu'il soit épuisé. Le burn rate (taux de combustion) mesure la vitesse à laquelle vous consommez votre budget par rapport à un rythme "normal" qui épuiserait exactement le budget en fin de fenêtre.
Un burn rate de 1 signifie que vous consommez le budget au rythme prévu, exactement de quoi tenir toute la fenêtre. Un burn rate de 14,4 signifie que vous épuiseriez le budget mensuel en environ 2 jours si le rythme se maintient : c'est le signal d'un incident en cours qui mérite un réveil immédiat de l'astreinte.
Le piège d'une alerte à seuil unique est le compromis impossible entre réactivité et bruit : un seuil bas déclenche trop de faux positifs sur de petits pics, un seuil haut rate les dégradations lentes mais réelles. Google SRE recommande de croiser deux fenêtres temporelles (une longue, une courte) qui doivent dépasser le seuil simultanément pour déclencher l'alerte. Cela combine la sensibilité de la fenêtre courte avec la robustesse de la fenêtre longue face aux pics isolés.
| Sévérité | Fenêtre longue | Fenêtre courte | Burn rate | Budget consommé |
|---|---|---|---|---|
| Page immédiate | 1 heure | 5 minutes | 14,4 | 2% |
| Ticket urgent | 6 heures | 30 minutes | 6 | 5% |
| Revue hebdomadaire | 3 jours | 6 heures | 1 | 10% |
Ce tableau correspond aux paramètres de référence publiés dans le SRE Workbook de Google pour un SLO de 99,9%. Les multiplicateurs se recalculent selon votre propre cible : plus votre SLO est strict, plus le budget est petit, et plus un même volume d'erreurs produit un burn rate élevé. Ces alertes finissent généralement dans le même canal que votre rotation d'astreinte, avec la fenêtre courte servant à confirmer que l'incident est toujours actif avant de réveiller quelqu'un.
Outiller les SLO : OpenSLO et les générateurs Prometheus
Section intitulée « Outiller les SLO : OpenSLO et les générateurs Prometheus »Écrire à la main les requêtes PromQL de calcul de burn rate pour chaque service, chaque fenêtre et chaque seuil devient vite ingérable au-delà de quelques services. Deux approches open source évitent cette dette.
OpenSLO est une spécification YAML neutre vis-à-vis du fournisseur : elle décrit un SLO (SLI, cible, fenêtre) dans un format déclaratif indépendant de l'outil de monitoring sous-jacent, ce qui permet de versionner ses objectifs de fiabilité comme du code et de les partager entre équipes.
Sloth est un générateur qui prend une définition de SLO simplifiée et produit automatiquement les règles Prometheus (enregistrement et alertes multi-fenêtres) correspondantes, y compris un support partiel du format OpenSLO. L'intérêt principal est d'éviter les erreurs de calcul manuelles dans les seuils de burn rate et de garantir des règles uniformes entre tous les services d'une organisation.
SLA : l'engagement contractuel
Section intitulée « SLA : l'engagement contractuel »SLA vs SLO
Section intitulée « SLA vs SLO »Le SLA (Service Level Agreement) est un contrat avec vos utilisateurs. Il inclut des conséquences (généralement financières) en cas de non-respect.
| Aspect | SLO | SLA |
|---|---|---|
| Nature | Objectif interne | Engagement externe |
| Public | Équipe technique | Clients, contrats |
| Conséquences | Priorisation du travail | Pénalités, crédits |
| Niveau | Plus strict | Plus permissif |
Un SLA bien conçu est moins strict que le SLO interne. Si votre SLO est de 99,9% et votre SLA de 99,5%, vous avez une marge pour réagir avant de devoir compenser vos clients.
Exemple de SLA typique
Section intitulée « Exemple de SLA typique »Le SLA traduit la disponibilité constatée en conséquence financière graduée : plus la panne est sévère, plus le crédit accordé au client est élevé. Ce barème protège le client d'une dégradation prolongée sans pénaliser le fournisseur pour un incident mineur ponctuel.
| Disponibilité mensuelle | Crédit |
|---|---|
| 99,5% ou plus | Aucun |
| 99,0% - 99,5% | 10% |
| 95,0% - 99,0% | 25% |
| Moins de 95,0% | 50% |
Mettre en place les SLI/SLO : méthode pragmatique
Section intitulée « Mettre en place les SLI/SLO : méthode pragmatique »-
Identifier les parcours utilisateurs critiques
Avant de définir des métriques, comprenez ce que vos utilisateurs essaient d'accomplir. Quelles sont les actions principales ? Lesquelles sont critiques pour votre business ? Lesquelles génèrent le plus de frustration si elles échouent ?
-
Définir 2-3 SLI par service
Pour chaque parcours critique, identifiez les dimensions importantes : l'action a-t-elle réussi (disponibilité) ? A-t-elle été rapide (latence) ? Le résultat était-il correct/à jour (exactitude/fraîcheur) ?
-
Fixer des SLO réalistes
Commencez par mesurer votre performance actuelle pendant quelques semaines. Votre premier SLO peut être légèrement en dessous de cette baseline : assez ambitieux pour être significatif, assez réaliste pour être atteignable.
-
Automatiser le suivi
Mettez en place un dashboard qui affiche en temps réel les SLI actuels, l'error budget restant, et la tendance. Configurez des alertes burn rate multi-fenêtres quand le budget se consomme trop vite.
-
Documenter la politique d'error budget
Écrivez noir sur blanc ce qui se passe quand le budget est épuisé, qui a le pouvoir de décider des exceptions, et comment escalader les conflits.
-
Itérer
Les premiers SLO ne seront pas parfaits. Révisez-les trimestriellement : le SLO correspond-il à la satisfaction utilisateur réelle ? Des incidents ont-ils été manqués ? Le niveau est-il trop strict ou trop laxiste ?
Pièges courants
Section intitulée « Pièges courants »Ce tableau résume les erreurs les plus fréquentes observées quand une équipe démarre avec les SLO, pour éviter de les reproduire une à une par tâtonnement.
| Piège | Problème | Solution |
|---|---|---|
| SLO à 100% | Impossible à tenir, bloque toute prise de risque | Accepter qu'un certain niveau d'erreur est normal |
| Trop de SLI | Dilue l'attention, complique les décisions | 2-5 SLI max par service |
| SLI techniques | CPU, RAM ne reflètent pas l'expérience utilisateur | Mesurer ce que l'utilisateur perçoit |
| Pas de politique | L'error budget devient un chiffre sans conséquence | Documenter les actions quand le budget est épuisé |
| SLO trop ambitieux | Équipe en échec permanent, démotivation | Commencer conservateur, durcir progressivement |
| Alerte à seuil unique | Trop de faux positifs ou incidents lents ratés | Alerte multi-fenêtres (burn rate court + long) |
À retenir
Section intitulée « À retenir »-
Les SLI mesurent l'expérience utilisateur
Pas l'infrastructure, pas les métriques techniques. Ce que l'utilisateur perçoit : ça marche, c'est rapide, c'est correct.
-
Les SLO définissent "assez fiable"
100% n'est ni possible ni souhaitable. Le bon SLO est celui qui satisfait vos utilisateurs sans bloquer l'innovation.
-
L'error budget arbitre les décisions
Budget disponible : on peut prendre des risques. Budget épuisé : on stabilise. Plus de discussions subjectives.
-
Le burn rate déclenche l'alerte au bon moment
Une alerte multi-fenêtres (courte + longue) détecte les incidents rapides sans noyer l'astreinte sous les faux positifs des alertes à seuil unique.
-
Les SLA engagent contractuellement
Gardez toujours une marge entre SLO et SLA. Le SRE vise le SLO pour éviter de déclencher le SLA.
-
L'outillage évite les erreurs de calcul
Des générateurs comme Sloth ou des spécifications comme OpenSLO uniformisent les règles d'alerte plutôt que de les réécrire à la main pour chaque service.
-
Commencez simple, itérez
Vos premiers SLO ne seront pas parfaits. Mesurez, apprenez, ajustez.
Ressources externes
Section intitulée « Ressources externes »Le SRE Book et le SRE Workbook de Google restent les références fondatrices sur les SLO et les error budgets : elles détaillent des cas d'implémentation et des formules de burn rate qui dépassent le cadre pédagogique de cette page.
- Implementing SLOs (Google SRE Workbook), Guide détaillé avec exemples concrets
- Service Level Objectives (Google SRE Book), Chapitre fondateur sur les SLO
- Alerting on SLOs (Google SRE Workbook), Référence des seuils multi-fenêtres de burn rate
- The Art of SLOs (Google Cloud), Ressources pratiques pour l'implémentation