Les SLO donnent une cible de fiabilité à un service ; le budget d’erreur traduit la marge disponible avant que la dégradation ne menace cette cible. Leur utilité dépend du lien avec un parcours métier et de décisions acceptées par les équipes produit et techniques.
Choisir un indicateur proche de l’utilisateur
Un service peut être disponible tout en étant inutilisable. Le SLI doit donc mesurer une expérience significative : requête réussie, temps de réponse d’un parcours, traitement terminé ou donnée à jour. La fenêtre et la population sont explicites, tout comme les exclusions. L’historique permet d’éviter une cible arbitraire. Une ambition trop faible n’encourage rien ; une cible de 100 % interdit pratiquement tout changement et masque le compromis entre fiabilité, coût et vitesse d’évolution.
Associer le budget à des règles de décision
Le budget d’erreur n’est pas une permission de laisser le service se dégrader. Il rend visible la consommation du risque. Lorsque celle-ci accélère, l’équipe peut renforcer les contrôles, ralentir les mises en production ou prioriser un travail de fiabilité. Quand la marge est saine, elle peut expérimenter davantage. Ces règles sont définies avant la crise et revues avec le produit. Un tableau simple montre la tendance, les principaux contributeurs et l’action convenue, sans transformer le SLO en sanction individuelle.
À retenir
Un SLO utile mesure un parcours réel et déclenche des arbitrages explicites entre fiabilité, évolution et coût.
Pour approfondir
Google SRE — Service Level Objectives ↗Datadog — Service Level Objectives ↗Article mis à jour le . La date de première publication est conservée.