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

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 un temps de réponse sous 500 ms
• % d'emails correctement livrés (delivered, pas bounced)
• Ratio des transactions de paiement réussies sur l'ensemble des tentatives

Un bon SLI possède trois propriétés clés :

• Mesurable - il existe une méthode concrète de collecte de données
• Pertinent pour l'utilisateur - il 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 définissant la valeur que le SLI doit atteindre. Exprimé en pourcentage sur une fenêtre temporelle choisie.

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 temps de réponse sous 200 ms sur 7 jours »
• « 99,5 % des transactions de paiement passent avec succès dans un mois calendaire »

Le SLO est généralement plus strict que le SLA afin que vous disposiez d'une marge. Si le SLA annonce 99,9 %, le SLO interne devrait être par ex. 99,95 % - vous gardez ainsi une réserve pour les incidents inattendus avant de violer le contrat.

SLA - Service Level Agreement

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

• Service credits - vous remboursez 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

Le SLA a des conséquences légales. Le SLO, en revanche, n'est qu'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. Cela représente 0,1 % de downtime autorisé, et 0,1 % de 30 jours équivaut à 43 minutes par mois. C'est votre error budget.

Implications pratiques :

• Si vous avez déjà consommé 35 min de downtime dans le mois, il reste 8 min avant la violation du SLO. L'équipe devrait rester conservative pour les autres deploys.
• Si vous n'avez consommé que 5 min de downtime, vous disposez de 38 min de budget pour le risque - vous pouvez vous permettre des changements plus agressifs, des tests A/B et des expériences.
• L'error budget résout ainsi le conflit entre vitesse d'innovation (dev team) et stabilité (ops team). Les deux camps 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: un SLO de 99,9 % signifie 43 min de downtime par mois. Le SLA donne une marge encore plus large avant toute pénalisation économique.

Résumé : tableau

Erreurs pratiques

• Un SLO trop ambitieux. 99,99 % exige une active-active redundancy dans plusieurs régions. Irréaliste pour une petite entreprise.
• Seulement un uptime SLO. Le web peut être « up » et quand même inutilisable. Ajoutez un latency SLO et un error rate SLO.
• Un SLA sans mesure automatique. Un rapport SLA calculé manuellement n'est pas fiable. Investissez dans un tracking uptime automatique.
• Un SLO sans conséquences. Si une violation du SLO n'intéresse personne, personne ne la prend au sérieux. Liez-la à un deploy freeze, une 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. Une base solide pour le reporting SLO.

Lancer le monitoring →