SLIs vs SLOs : Mesurer ce qui Compte pour vos Utilisateurs

La fiabilité est la fonctionnalité la plus importante de tout produit. Mais comment la mesurer ? Les Service Level Indicators (SLI) et les Service Level Objectives (SLO) sont le fondement du Site Reliability Engineering (SRE).

SLI : L'Indicateur

Un SLI est une mesure quantitative d'un aspect du niveau de service fourni.

• Exemple : Le pourcentage de requêtes HTTP réussies sur une fenêtre de 5 minutes.
• Conseil : Concentrez-vous sur les métriques orientées utilisateur comme la latence, la disponibilité et le taux d'erreur.

SLO : L'Objectif

Un SLO est une valeur cible ou une plage de valeurs pour un niveau de service mesuré par un SLI.

• Exemple : 99,9 % des requêtes HTTP doivent être réussies sur une fenêtre glissante de 30 jours.
• Conseil : Un SLO doit être "assez bon" pour l'utilisateur, pas parfait. 100 % est rarement la bonne cible.

Les Budgets d'Erreur : L'Ingrédient Magique

La différence entre 100 % et votre SLO constitue votre Budget d'Erreur.

• Si vous avez du budget, vous pouvez livrer de nouvelles fonctionnalités rapidement.
• Si vous épuisez votre budget, vous arrêtez les sorties et vous vous concentrez sur la fiabilité.

Comment choisir un bon SLI

Un bon SLI est :

• Orienté utilisateur : ce que l’utilisateur ressent (temps de réponse, erreurs, disponibilité).
• Actionnable : si ça baisse, vous savez où chercher (service, endpoint, région).
• Stable : pas une métrique qui varie à cause du trafic ou d’un batch (normalisez par requêtes).
• Mesurable : instrumenté et observable (logs, traces, métriques) sans trous.

Un piège courant est de prendre des métriques “internes” (CPU, mémoire) comme SLIs : elles sont utiles, mais ce ne sont pas des contrats d’expérience.

Exemple simple : API de paiement

• SLI (disponibilité) : % de réponses 2xx/3xx sur /checkout.
• SLI (latence) : p95 < 300 ms sur /checkout.
• SLO : 99,9 % de succès et p95 < 300 ms sur 30 jours.

Ensuite, vous traduisez le budget d’erreur en règles : “si le budget restant < 20 %, gel des releases” (ou revues renforcées).

Erreurs fréquentes

1. Des SLOs partout : commencez par les parcours critiques (login, paiement, recherche).
2. Des objectifs irréalistes : 99,99 % coûte très cher ; alignez l’ambition sur la valeur produit.
3. Pas de fenêtre glissante : un SLO “mensuel” fixe masque les incidents en début de mois.

Conclusion

Les SLI et les SLO transforment la fiabilité d'un concept vague en un contrat mesurable. Ils alignent les équipes produit et ingénierie en fournissant un langage commun pour équilibrer la vitesse d'innovation et la stabilité du système.