SLA / SLO / SLI

DevOps 🟡 Mid

Dé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

SLA plus strict que le SLO : on promet plus qu'on ne vise.
#devops#monitoring#interview

En entretien

  1. 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).

  2. À 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é.

  3. 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

← → au clavier pour passer d'une fiche à l'autre