Les objectifs de niveau de service ne servent que s’ils modifient le comportement. Si votre deck SLO est ignoré lors du planning, vous avez sans doute sauté les parties difficiles : SLI alignés utilisateur, alertes multi-fenêtres sur le burn, et règles explicites quand le budget d’erreur est consommé.
Commencez par un parcours utilisateur—pas chaque microservice. Choisissez un flux qui génère revenu ou confiance (paiement, authentification, export de données). Définissez les SLI du point de vue client : taux de succès et percentiles de latence en périphérie, pas seulement le CPU des pods.
Traduisez les SLI en cibles SLO qui reflètent une tolérance réelle à l’échec. 99,9 % par mois semble généreux jusqu’à ce qu’on réalise qu’il reste ~43 minutes « mauvaises »—là produit et engineering peuvent arbitrer concrètement.
Rédigez la politique de budget d’erreur avant le premier incident. Règles typiques : budget sain → prioriser les features ; burn rapide → freiner les mises en prod et se concentrer sur la fiabilité ; budget épuisé → geler les changements risqués sauf correctifs d’incident. Sans accord préalable, chaque débat devient politique.
Les alertes multi-burn-rate doivent corréler à la souffrance utilisateur, pas au bruit. Associez tableaux de bord du budget restant et runbooks de mitigation—l’astreinte ne doit pas improviser l’économie pendant une panne.
Déployez socialement : revoyez les SLO au planning trimestriel, reliez la roadmap au risque sur le budget, valorisez le travail de fiabilité qui évite les régressions—pas seulement les héroïsmes en incident.
À lire aussi : missions DevOps & SRE et autres articles.