Expliquez les SLI, les SLO et les budgets d'erreur, et comment vous vous en serviriez au quotidien.

Un SLI est une mesure de l'expérience utilisateur, par exemple la proportion de requêtes servies avec succès en moins de trois cents millisecondes. Un SLO est la cible pour cette mesure sur une fenêtre, disons 99,9 pour cent sur vingt-huit jours. Le budget d'erreur est le reste, donc 99,9 pour cent laisse environ quarante-trois minutes de défaillance par mois. Quand le budget est confortable vous livrez plus vite ; quand il est épuisé, le travail de fiabilité passe en priorité.

L'indicateur, c'est ce que vous mesurez du côté de l'utilisateur, donc pour une API c'est en général la part de requêtes à la fois réussies et assez rapides. L'objectif, c'est la cible sur une fenêtre glissante, et le budget, c'est ce qui reste. Trois neuf sur vingt-huit jours, ça fait à peu près quarante-trois minutes de mauvais service que vous avez le droit de dépenser, et le cadrer comme un budget, c'est tout l'intérêt, parce que ça transforme la fiabilité d'une dispute en arithmétique. Si on a dépensé cinq pour cent du budget ce mois-ci, on livre des fonctionnalités et on prend des risques raisonnables. Si on a brûlé quatre-vingts pour cent le dix du mois, le sprint suivant c'est du travail de fiabilité et les lancements risqués attendent. Pour les alertes, j'utilise des taux de consommation sur plusieurs fenêtres plutôt que de réveiller quelqu'un dès que le ratio baisse, donc une consommation rapide qui épuiserait le budget en une heure réveille tout de suite, alors qu'une consommation lente crée un ticket. Ça a tué la plus grosse partie de notre bruit nocturne. Le plus dur, c'est de choisir honnêtement l'indicateur, parce qu'une cible sur quelque chose que les utilisateurs ne ressentent pas, c'est du théâtre.