SLA / SLO / SLI
DevOps 🟡 MidDéfinition
SLI = métrique mesurée (latence p99). SLO = objectif interne (p99 < 200ms). SLA = engagement contractuel client avec pénalités (99.9% uptime).
Analogie
SLI = le thermomètre. SLO = la température souhaitée. SLA = la garantie du chauffagiste avec remboursement si pas atteint.
Exemple de code
// SLI : latence p99 mesurée
// SLO : p99 < 200ms, disponibilité > 99.95%
// SLA : 99.9% uptime, sinon crédit client
// Error budget = 100% - SLO = 0.05% de marge d'erreur
Cas d'usage
Définir des objectifs de fiabilité et savoir quand investir en stabilité vs features.
Anti-pattern
Termes liés
En entretien
Explique-moi la différence entre SLI, SLO et SLA.
Le SLI est la métrique mesurée, comme la latence p99 ; le SLO est l'objectif interne, par exemple p99 < 200ms ; le SLA est l'engagement contractuel client avec pénalités, comme 99.9% d'uptime. C'est comme le thermomètre (SLI), la température souhaitée (SLO) et la garantie du chauffagiste avec remboursement si pas atteint (SLA).
À quoi sert de définir un SLO au-delà du SLA ?
À savoir quand investir en stabilité plutôt qu'en nouvelles fonctionnalités, en s'appuyant sur l'error budget, qui correspond à 100% moins le SLO. C'est cette marge d'erreur qui guide les arbitrages produit vs fiabilité.
Quelle incohérence entre SLA et SLO faut-il éviter ?
Un SLA plus strict que le SLO : on promettrait alors au client plus qu'on ne vise en interne. Le SLA doit toujours rester en dessous ou égal à l'objectif interne fixé par le SLO.
Fiche mise à jour le 2026-09-27