Comment gérer les SLO et SLI avancés en 2026

En 2026, la gestion des SLO (Service Level Objectives) et SLI (Service Level Indicators) reste le pilier de la fiabilité des systèmes distribués, particulièrement dans un contexte de SRE (Site Reliability Engineering). Les SLO définissent les objectifs de performance que les utilisateurs attendent (ex. : 99,9 % de disponibilité), tandis que les SLI sont les métriques mesurables qui les valident (ex. : taux de succès des requêtes). Pourquoi est-ce crucial ? Selon le livre Site Reliability Engineering de Google (2016, mis à jour en 2024), 70 % des incidents majeurs proviennent d'un manque d'alignement entre attentes utilisateurs et métriques internes.

Ce tutoriel avancé, conçu pour des ingénieurs SRE seniors, vous guide de la théorie aux pratiques itératives. Vous apprendrez à créer des SLO réalistes via des error budgets, à monitorer via des tableaux de bord avancés, et à itérer avec des retrospectives data-driven. Avec des études de cas comme Netflix ou AWS, des frameworks comme le SLO Canvas, et des templates réutilisables, ce guide est bookmarkable pour toute équipe ops. Attendez-vous à une progression : fondations → modélisation → optimisation → gouvernance. Prêt à transformer vos métriques en leviers business ? (148 mots)

• Connaissances solides en SRE et observabilité (Prometheus, Grafana ou équivalents).
• Expérience en gestion de métriques (latence, disponibilité, throughput).
• Familiarité avec les concepts d'error budget et SLA/SLO/SLI.
• Accès à des outils de monitoring (ex. : Datadog, New Relic).
• Équipe pluridisciplinaire (dev, ops, product).

Commencez par les fondations : SLA (Service Level Agreement) = contrat légal avec le client (ex. : 99,5 % uptime, pénalités si <). SLO = objectif interne ambitieux (ex. : 99,9 %). SLI = mesure concrète (ex. : (requêtes réussies / total) * 100).

Tableau comparatif :

Framework : Les 4 piliers des bons SLI (inspiré Google's SRE Workbook) :

1. Utilisateur-centrique : Mesurez ce que l'user perçoit (ex. : temps de chargement page vs CPU serveur).
2. Granulaire : Choisissez percentiles (p50, p95, p99) pour éviter les outliers.
3. Automatisable : Intégrez à votre pipeline observability.
4. Actionnable : Liez à des runbooks (ex. : si SLI latence > 200ms, scaler auto).

• Disponibilité : SLI = (200 + 304) / total requêtes.
• Latence : SLI = p95 < 100ms (sur échantillon 5min).
• Throughput : SLI = QPS > 1000 (queries per second).
• Fraîcheur : SLI = âge max données < 5min.

Nom SLI : ________________
Formule : ________________
Seuil cible : __ %
Outils mesure : __________
Runbook associé : __________

L'Error Budget = tolérance aux pannes = (100 - SLO cible) * période. Ex. : SLO 99,9 %/mois → 43min downtime/mois.

Matrice de priorisation SLO :

Étude de cas : AWS S3 : SLO 99,99 % → error budget ~4min/mois. En 2022, un dépassement a déclenché une 'fiabilité sabbatique' : zéro feature jusqu'à recovery.

Exercice pratique : Calculez l'error budget pour votre service critique sur 28 jours. Budget burn rate >2x/jour → alerte rouge.

Checklist monitoring avancé :

• [ ] Dashboards composites : SLO % = f(SLI1 + SLI2).
• [ ] Alertes burn rate : lent (1x), rapide (10x), critique (100x).
• [ ] Backfill historique : 90 jours min pour trends.
• [ ] SLO multi-régions : agrégé pondéré.

1. Mesure : SLO actuel vs cible.
2. Racines : 5 Whys sur échecs SLI.
3. Actions : Prioriser via impact/error budget.
4. Revues : Quinzaine, ajuster SLO si drift user (sondages NPS).

Exemple : Chez Spotify, revues SLO mensuelles ont boosté fiabilité de 2 % en 6 mois.

À l'échelle : SLO Tree pour microservices (SLO global = min(SLO enfants)).

Modèle hiérarchique :

• Niveau 1 : Service individuel.
• Niveau 2 : Plateforme (ex. : API gateway).
• Niveau 3 : User Journey (end-to-end).

Template gouvernance :

SLO Policy :

• Revue : Mensuelle.
• Responsable : Tech Lead + Product.
• Outils : SLO-as-code (GitOps).
• Pénalités internes : Si < SLO 3 mois, gel features.

• Toujours lier SLO à user happiness : Validez via A/B tests ou sondages (cible NPS >8).
• Diversifiez SLI : 4-6 max/service, couvrant Golden Signals (latency, traffic, errors, saturation).
• Automatisez tout : SLO computed en temps réel, alertes via PagerDuty.
• Communiquez error budget : Dashboard public équipe, 'SLO du mois' en standup.
• Évoluez proactivement : Si SLO > cible 3 mois, durcissez (ex. : 99,9 → 99,95 %).

• SLI gaming : Optimiser un SLI au détriment d'autres (ex. : booster latence p50 → explosion p99). Piège : Mesurez holistiquement.
• SLO trop ambitieux : 100 % → frustration dev constante. Solution : Historique + marge 10 %.
• Ignore burn rate : Focus downtime total vs vitesse brûlage. Ex. : 10min lent < 1min rapide.
• Pas d'itération : SLO figés → obsolescence. Piège : Revue annuelle min.

Approfondissez avec :

• Livre Implementing Service Level Objectives (O'Reilly, 2023).
• Google's SRE Workbook : lien.
• Outils : Cubetris SLO, Prometheus SLO exporter.
• Stats : 85 % des orgs SRE utilisent SLO (DevOps Report 2025).