SLI, SLO, SLA : ne plus les confondre
Distinguer clairement indicateur, objectif et engagement contractuel de niveau de service.
À retenir
- Le SLI est une mesure, le SLO un objectif interne, le SLA un engagement contractuel avec pénalités.
- Un bon SLI reflète l'expérience utilisateur, pas la facilité de mesure côté infrastructure.
- Le SLO doit toujours être plus strict que le SLA pour ménager une marge de sécurité.
- La source exacte de chaque SLI doit être documentée pour éviter les désaccords en incident.
Trois lettres, trois usages différents
SLI, SLO et SLA sont souvent employés indifféremment, ce qui conduit à des discussions confuses entre équipes techniques et commerciales. Chacun de ces termes répond à une question précise.
SLI : que mesure-t-on ?
Le SLI (Service Level Indicator) est une mesure quantitative de l'expérience utilisateur, exprimée comme un ratio d'événements « bons » sur événements « valides ». Exemple classique pour une API HTTP :
sum(rate(http_requests_total{status!~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))
Point clé
un bon SLI reflète ce que ressent l'utilisateur, pas ce qui est facile à mesurer côté infrastructure. Le taux d'utilisation CPU n'est pas un SLI pertinent ; la latence de réponse perçue par le client, si.
SLO : quel objectif se fixe-t-on ?
Le SLO (Service Level Objective) est un objectif interne, chiffré et daté, appliqué à un SLI. Exemple : « 99,9 % des requêtes réussissent en moins de 300 ms sur une fenêtre glissante de 30 jours. » Le SLO est un outil de pilotage interne, pas un engagement contractuel.
SLA : quel engagement contractuel ?
Le SLA (Service Level Agreement) est un engagement contractuel envers un client, généralement assorti de pénalités financières en cas de non-respect. Un SLA est presque toujours moins strict que le SLO interne correspondant, pour ménager une marge de sécurité.
| Terme | Nature | Exemple | Conséquence en cas d'échec |
|---|---|---|---|
| SLI | Mesure | 99,95 % de requêtes < 300 ms | Aucune (c'est une donnée) |
| SLO | Objectif interne | ≥ 99,9 % sur 30 jours | Déclenche une action interne |
| SLA | Engagement contractuel | ≥ 99,5 % sur le mois | Pénalité financière au client |
Attention
fixer un SLO identique au SLA revient à déclencher des pénalités contractuelles dès le premier signal d'alerte interne ; la marge entre SLO et SLA doit être délibérée, pas accidentelle.
Choisir le bon SLI
Les catégories les plus courantes de SLI sont la disponibilité (requêtes réussies / total), la latence (proportion sous un seuil), le débit et la fraîcheur des données (freshness) pour les systèmes asynchrones. Un service peut avoir plusieurs SLI, un par aspect critique de l'expérience utilisateur.
Sur le terrain
une équipe avait défini son SLI de disponibilité sur les logs applicatifs internes, qui ne captaient pas les erreurs de timeout côté load balancer en amont ; le SLI affichait 99,99 % pendant qu'une partie réelle du trafic échouait avant même d'atteindre l'application. Toujours mesurer le SLI au plus près du point de vue client, idéalement côté load balancer ou CDN.
Astuce
documentez pour chaque SLI sa source de données exacte (quelle métrique, quel composant) ; en cas d'incident, c'est souvent la première question posée et la première source de désaccord si elle n'est pas tranchée à l'avance.