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.
Les SLI, SLO et error budgets sont la réponse du SRE à ce problème. Ces trois concepts forment un système cohérent qui aligne les métriques techniques sur l’expérience utilisateur réelle, et transforme les discussions subjectives (“le service est-il assez fiable ?”) en décisions basées sur des données.
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 2GB 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. C’est pourquoi Google a développé un vocabulaire précis pour parler de fiabilité : les SLI, SLO, SLA et error budgets.
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 < 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.
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 50ms mais 5% prennent 10 secondes, la moyenne sera de ~550ms, 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 100ms” et “99% en moins de 400ms”.
Exemple concret : Sur 1 million de requêtes, 950 000 ont répondu en moins de 200ms. SLI de latence (200ms) = 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 (5min) = 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 :
| 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 :
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 :
| Type de service | SLO typique | Justification |
|---|---|---|
| Paiements, authentification | 99.99%+ | 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 × 24h × 60min × 0.1% = 43.2 minutes
- En requêtes (si 1M 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, l’automatisation.
-
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
- Un 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) × 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 × 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.
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 »| Disponibilité mensuelle | Crédit |
|---|---|
| ≥ 99.5% | Aucun |
| 99.0% - 99.5% | 10% |
| 95.0% - 99.0% | 25% |
| < 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 quand le budget atteint des seuils critiques (50%, 25%, 10%).
-
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 »| 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 |
À 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.
-
Les SLA engagent contractuellement
Gardez toujours une marge entre SLO et SLA. Le SRE vise le SLO pour éviter de déclencher le SLA.
-
Commencez simple, itérez
Vos premiers SLO ne seront pas parfaits. Mesurez, apprenez, ajustez.
Ressources externes
Section intitulée « Ressources externes »- Implementing SLOs (Google SRE Workbook) — Guide détaillé avec exemples concrets
- Service Level Objectives (Google SRE Book) — Chapitre fondateur sur les SLO
- The Art of SLOs (Google Cloud) — Ressources pratiques pour l’implémentation