SLI vs SLO vs SLA : différences et comment les mettre en place

En bref : SLI c'est ce que vous mesurez, SLO c'est quel objectif vous voulez atteindre, SLA c'est l'engagement contractuel. Ces termes du livre Google SRE font partie des expressions les plus utilisées dans l'exploitation de services web - et souvent confondues.

SLI - Service Level Indicator

Métrique concrète avec laquelle vous quantifiez la fiabilité du service. Exemples :

• % des requêtes qui se sont terminées en HTTP 2xx ou 3xx dans les 30 derniers jours
• % des requêtes avec response time sous 500 ms
• % d'emails correctement livrés (delivered, pas bounced)
• Ratio des transactions de paiement réussies sur l'ensemble des tentatives

Propriétés clés d'un bon SLI :

• Mesurable - il existe une méthode concrète de collecte de données
• Pertinent pour l'utilisateur - reflète l'expérience client réelle, pas une métrique technique interne
• Spécifique - « uptime » est trop vague ; « % de requêtes réussies vers /api/v1/orders dans une fenêtre de 5 minutes » est un SLI

SLO - Service Level Objective

Objectif interne, quelle valeur le SLI doit atteindre. Exprimé en pourcentage sur une fenêtre temporelle.

Exemples :

• « 99,9 % des requêtes vers /api/orders doivent se terminer en HTTP 2xx sur 30 jours »
• « 95 % des requêtes doivent avoir un response time sous 200 ms sur 7 jours »
• « 99,5 % des transactions de paiement passent avec succès dans un mois calendaire »

SLO est plus haut que SLA pour que vous ayez un buffer. Si SLA dit 99,9 %, le SLO interne devrait être par ex. 99,95 % - pour avoir une réserve pour les incidents inattendus.

SLA - Service Level Agreement

Engagement contractuel envers les clients. Définit ce qui se passe quand vous ne respectez pas le SLO - typiquement :

• Service credits - vous rendez une partie de la cotisation mensuelle (10-50% selon l'ampleur de la violation)
• Termination rights - le client peut résilier le contrat sans sanction
• Obligation de reporting - vous devez publier postmortem et rapports uptime

SLA a des conséquences légales. SLO est un objectif interne.

Error budget

Concept clé du SRE : le downtime que vous pouvez vous permettre sans violer le SLO.

Exemple : SLO = 99,9 % d'uptime sur 30 jours. C'est 0,1 % de downtime autorisé. 0,1 % de 30 jours = 43 minutes par mois. C'est votre error budget.

Implications pratiques :

• Si vous avez déjà 35 min de downtime dans le mois, il reste 8 min avant la « violation du SLO ». L'équipe devrait être conservative pour les autres deploys.
• Si vous avez 5 min de downtime, vous avez 38 min de budget pour les risques - vous pouvez faire des changements plus agressifs, des tests A/B, des expériences.
• L'error budget résout le conflit entre vitesse d'innovation (dev team) et stabilité (ops team). Les deux suivent le même chiffre.

Exemple pratique : API e-commerce

SLI: % de requêtes HTTP vers POST /api/checkout qui se sont terminées en 2xx, mesurées en buckets de 1 minute sur les 30 derniers jours.

SLO: ≥ 99,9 % de requêtes réussies sur une fenêtre rolling 30-day.

SLA (pour les clients Enterprise):

• ≥ 99,5 % d'uptime sur un mois calendaire
• À 99,0-99,5 % = crédit de 10% de la cotisation mensuelle
• À 95,0-99,0 % = crédit de 25%
• À < 95,0 % = crédit de 50% + droit de résilier le contrat

Error budget: 99,9 % SLO signifie 43 min de downtime / mois en budget. SLA donne encore un plus gros buffer avant pénalisation économique.

Résumé : tableau

Erreurs pratiques

• SLO trop ambitieux. 99,99 % demande active-active redundancy dans plusieurs régions. Irréaliste pour une petite entreprise.
• Seulement uptime SLO. Le web peut être « up » et quand même inutilisable. Ajoutez latency SLO et error rate SLO.
• SLA sans mesure automatique. Un rapport SLA calculé manuellement n'est pas fiable. Investissez dans un tracking uptime automatique.
• SLO sans conséquences. Si une violation du SLO n'intéresse personne, personne ne s'en occupe. Liez à deploy freeze, on-call escalation, etc.

Conclusion

Le framework SLI/SLO/SLA n'est pas de la bureaucratie papier - c'est la langue par laquelle l'équipe engineering communique avec les business stakeholders sur la fiabilité. Sans ces termes la discussion sur la stabilité devient subjective (« notre web est instable »). Avec eux elle est chiffrée (« sur les 30 derniers jours nous avons atteint 99,87 % SLI, ce qui est sous notre 99,9 % SLO - voici le plan d'action »).

Mesurez le SLI en temps réel

ePulz.io fournit un enregistrement historique de l'uptime avec rollup 30/90/365 jours. Base pour le reporting SLO.

Lancer le monitoring →