Le budget transforme un SLO en règle de décision. Tant qu’il reste du budget, l’équipe livre des changements et prend des risques planifiés ; une fois épuisé, la fiabilité passe en premier jusqu’à ce que la fenêtre se rétablisse. C’est en convenant de cette règle à l’avance, dans une politique de budget d’erreur, que le chiffre devient utile.
Il peut se compter en temps, en minutes d’indisponibilité mesurées par des vérifications externes, ou en requêtes, en part de requêtes échouées dans les journaux du load balancer ou de l’application. Les budgets fondés sur le temps correspondent à la façon dont la plupart des SLA sont rédigés ; ceux fondés sur les requêtes pèsent davantage les heures chargées, ce qui est plus proche du ressenti des utilisateurs.
Décidez à l’avance de ce qui le consomme. Les pannes confirmées, les erreurs, les réponses plus lentes que la limite du SLI et les pannes chez les fournisseurs dont vous dépendez le consomment généralement ; les faux positifs ne devraient pas. La vitesse à laquelle il est consommé, c’est le burn rate.
Formule
Budget d’erreur = (100 % − SLO) × fenêtre ; budget restant = budget d’erreur − indisponibilité jusqu’ici
Exemple :
Un SLO de 99,9 % sur 30 jours donne 43 minutes et 12 secondes. Après une panne de 25 minutes, 58 % sont consommés et il reste 18 minutes et 12 secondes.