🎯 SLO, SLI et error budgets : arrêter de viser le 100 %

📚 Introduction

« Notre objectif, c’est 100 % de disponibilité. » On l’entend en réunion, ça sonne bien, et c’est une mauvaise idée. Viser 100 %, c’est viser l’impossible : il y aura toujours une panne réseau, un déploiement raté, un fournisseur en rade. Pire, chaque « neuf » supplémentaire (de 99,9 % à 99,99 %) coûte exponentiellement plus cher — en argent, en astreintes, en features non livrées.

La pratique SRE (Site Reliability Engineering), formalisée par Google, propose un cadre plus honnête : trois notions — SLI, SLO et error budget — pour choisir la bonne fiabilité et arbitrer entre livrer vite et rester stable. C’est le prolongement naturel des métriques DORA : une fois qu’on mesure sa livraison, on veut piloter sa fiabilité.

🔎 SLI, SLO, error budget : de quoi parle-t-on ?

Les trois se répondent, du signal brut à la décision :

• Le SLI (Service Level Indicator) est une mesure : le pourcentage de requêtes servies sous 300 ms, le taux de réponses non-erronées, la disponibilité. Bien choisi, il reflète l’expérience réelle de l’utilisateur.
• Le SLO (Service Level Objective) est la cible qu’on se fixe sur ce SLI : « 99,9 % des requêtes sous 300 ms, mesuré sur 30 jours ».
• L’error budget est ce qui reste : 100 % − SLO. Un SLO de 99,9 % autorise 0,1 % d’écart, soit environ 43 minutes d’indisponibilité par mois. Ce n’est pas un échec, c’est un budget — fait pour être dépensé.

📊 Ce que « 99,9 % » veut vraiment dire

Les pourcentages sont trompeurs tant qu’on ne les traduit pas en temps. Sur une base de 30 jours :

Passer de 99,9 % à 99,99 %, ce n’est pas « un peu mieux » : c’est diviser par dix la marge d’erreur, donc décupler les exigences sur les tests, la redondance, l’astreinte. La vraie question n’est pas « peut-on faire mieux ? » mais « nos utilisateurs ont-ils besoin de mieux ? ».

🎯 L’error budget, un outil de décision

C’est là que le concept devient puissant. L’error budget met fin à la guerre éternelle entre les développeurs (qui veulent livrer) et l’exploitation (qui veut la stabilité), en donnant une règle commune et chiffrée :

• Il reste du budget ? On continue à livrer, à prendre des risques, à déployer souvent.
• Le budget est épuisé ? On gèle les nouvelles features et on remet de l’énergie dans la fiabilité — tests, observabilité, corrections — jusqu’à revenir dans les clous.

La décision ne dépend plus de qui parle le plus fort en réunion, mais d’un chiffre que tout le monde partage. Encore faut-il mesurer ce chiffre : sans observabilité — traces, métriques, monitoring temps réel — un SLO n’est qu’une intention.

⚠️ Quelques précautions

• Mesure le bon SLI. Un SLO sur « le CPU sous 80 % » ne dit rien à l’utilisateur. Mesure ce qu’il ressent : latence, taux d’erreur, disponibilité des parcours clés.
• Ne confonds pas SLO et SLA. Le SLA est contractuel et engage juridiquement ; le SLO est ton objectif interne, volontairement plus strict, pour réagir avant de violer le contrat.
• Un SLO se révise. Trop de faux positifs qui réveillent l’astreinte pour rien ? L’objectif est peut-être trop ambitieux au regard du besoin réel. Le bon SLO est celui qui déclenche une action utile, pas une alarme de plus.

🎉 Conclusion

SLI, SLO, error budget : trois mots pour une idée saine — la fiabilité parfaite n’existe pas, alors autant choisir consciemment le niveau qu’on vise, et utiliser la marge restante pour avancer. Commence modestement : un SLI qui reflète l’expérience utilisateur, un SLO réaliste, et la discipline de geler les features quand le budget est cramé. Tu échangeras les débats de couloir contre une décision partagée et chiffrée.

🔗 Liens utiles

• Google SRE — Implementing SLOs
• Google SRE — Service Level Objectives
• Google SRE — Embracing Risk (error budgets)