Un SLO transforme « suffisamment fiable » en un chiffre que l’équipe peut suivre. Il se fixe d’après les besoins des utilisateurs, pas d’après ce que le système fait aujourd’hui, et il est généralement plus strict que tout SLA, pour laisser le temps de réagir avant que des avoirs ne soient dus aux clients.
L’écart entre le SLO et 100 % est le budget d’erreur. Tant qu’il en reste, l’équipe peut livrer des changements et prendre des risques ; quand il est épuisé, le travail se recentre sur la fiabilité jusqu’à ce que la fenêtre se rétablisse. La fiabilité devient ainsi une décision partagée entre produit et ingénierie.
Les bons SLO sont peu nombreux, liés à ce que les utilisateurs remarquent, comme la disponibilité du paiement ou la latence de l’API, et mesurés sur une fenêtre glissante, souvent de 28 ou 30 jours.
Formule
Budget d’erreur = (100 % − SLO) × fenêtre
Exemple :
Un SLO de 99,9 % sur 30 jours laisse un budget d’erreur de 43 minutes et 12 secondes ; 99,95 % laisse 21 minutes et 36 secondes.