infra / monitoring-observabilite

SLI, SLO et SLA : définir des objectifs de fiabilité

Leçon 101 exercice

Explication

Ce que vous allez apprendre

Distinguer précisément un SLI, un SLO et un SLA
Calculer un "error budget" à partir d'un objectif de disponibilité
Écrire une alerte de "burn rate" multi-fenêtre selon l'approche Google SRE
Utiliser l'error budget pour arbitrer entre vitesse de déploiement et stabilité
Choisir un niveau de SLO réaliste plutôt qu'arbitrairement élevé

Dans quel contexte ?

L'équipe produit demande "pourquoi le déploiement de vendredi a été bloqué ?" tandis que l'équipe infra répond "parce que le service était trop instable cette semaine". Sans mesure partagée et objective de ce qu'est "trop instable", ce genre de débat reste subjectif et finit en conflit d'équipe. Les SLI, SLO et error budgets existent précisément pour transformer ce débat en décision basée sur un chiffre.

D'abord, il faut distinguer trois sigles qui se ressemblent

Un SLI (Service Level Indicator) est une simple mesure brute : le pourcentage de requêtes réussies, ou la latence au 99e percentile. C'est un fait mesuré, sans jugement de valeur.

Un SLO (Service Level Objective) est un objectif interne fixé sur ce SLI : "99.9% de requêtes réussies sur une fenêtre de 30 jours". Un SLA (Service Level Agreement), enfin, est un engagement contractuel externe, souvent accompagné de pénalités financières — et volontairement plus permissif que le SLO interne, pour garder une marge de sécurité avant toute conséquence contractuelle.

Sigle	Nature	Exemple	Qui le voit
SLI	Mesure brute	"99.95% de requêtes réussies ce mois-ci"	Équipe technique
SLO	Objectif interne	"Viser 99.9% sur 30 jours glissants"	Équipe technique et produit
SLA	Engagement contractuel	"99.5% garanti, sinon remboursement"	Client externe

Prérequis

Cette leçon s'appuie directement sur les requêtes PromQL de taux d'erreur et de latence vues dans les leçons précédentes ; assure-toi de bien maîtriser rate() et les ratios de type erreurs / total.

Une fois ces trois notions posées, un SLO abstrait pose un problème concret : comment savoir où on en est ?

Dire "on vise 99.9%" ne dit rien d'actionnable au quotidien. C'est là qu'intervient l'"error budget", le complément direct du SLO exprimé en temps réel d'indisponibilité tolérée : un SLO de 99.9% sur 30 jours autorise exactement 43.2 minutes d'indisponibilité par mois, ni plus, ni moins.

Ce chiffre change complètement la conversation : au lieu de débattre de "si" le service a été assez fiable, l'équipe peut simplement regarder "combien de minutes du budget restent ce mois-ci".

Maintenant, un problème plus subtil : une alerte sur un seuil fixe arrive souvent trop tard

Piège fréquent

Alerter uniquement quand le taux d'erreur dépasse le seuil du SLO lui-même revient à attendre que le mal soit déjà fait. Une équipe SRE responsable préfère détecter la VITESSE à laquelle le budget se consomme (le "burn rate") : un taux d'erreur qui consommerait 100% du budget mensuel en seulement 2 jours mérite une alerte immédiate, même s'il reste encore un large budget non consommé à l'instant présent.

L'approche Google SRE combine deux fenêtres de temps différentes (courte et longue) dans une même alerte, pour confirmer qu'un pic n'est pas juste un incident isolé de quelques minutes avant de déclencher une alerte critique.

Bonne pratique

Utilise l'error budget restant pour arbitrer objectivement les décisions produit : un budget encore largement disponible (plus de 50%) autorise des déploiements plus fréquents et plus audacieux ; un budget presque épuisé (moins de 10%) justifie un gel temporaire des changements non critiques, le temps qu'il se reconstitue.

Le piège à éviter en fixant un SLO

Viser 99.99% partout, "pour être sûr", coûte en réalité très cher en ingénierie (redondance, tests, astreinte renforcée) pour un bénéfice souvent négligeable sur des services peu critiques. Le bon niveau de SLO se choisit service par service, selon son impact réel sur l'utilisateur final — pas de façon uniforme sur toute l'infrastructure.

Après cette incursion dans la fiabilité mesurée, la suite du cours revient au terrain très concret : surveiller l'infrastructure elle-même, serveur par serveur, avec node_exporter.

Commandes & code

SLI, SLO et SLA : définir des objectifs de fiabilité

SLI (Service Level Indicator)  -> une MESURE : "% de requêtes réussies", "latence P99"
SLO (Service Level Objective)  -> un OBJECTIF interne sur ce SLI : "99.9% de requêtes réussies sur 30 jours"
SLA (Service Level Agreement)  -> un ENGAGEMENT contractuel externe, souvent avec pénalités financières

-> le SLA est généralement PLUS PERMISSIF que le SLO interne (marge de sécurité avant conséquences contractuelles)

# SLI de disponibilité : requêtes non-5xx / requêtes totales
sum(rate(http_requests_total{status!~"5.."}[30d]))
/
sum(rate(http_requests_total[30d]))

# SLI de latence : proportion de requêtes SOUS un seuil (ex : 300ms) — souvent plus parlant qu'un percentile brut
sum(rate(http_request_duration_seconds_bucket{le="0.3"}[30d]))
/
sum(rate(http_request_duration_seconds_count[30d]))

Error budget : le complément du SLO, exprimé en "droit à l'erreur"

SLO = 99.9% de disponibilité sur 30 jours
-> Error budget = 0.1% de 30 jours = 43.2 minutes d'indisponibilité TOLÉRÉE par mois

Table de correspondance courante :
99%    -> 7h 18min de budget d'erreur / mois
99.9%  -> 43min / mois
99.95% -> 21min / mois
99.99% -> 4min / mois

# Alerte sur le TAUX de consommation du budget d'erreur (multi-fenêtre, approche Google SRE)
# Alerte rapidement si on consomme le budget TROP VITE (burn rate), pas juste "en dessous du seuil"
groups:
  - name: slo_burn_rate
    rules:
      - alert: ErrorBudgetBurnRateCritical
        expr: |
          (
            sum(rate(http_requests_total{status=~"5.."}[1h])) / sum(rate(http_requests_total[1h])) > (14.4 * 0.001)
          )
          and
          (
            sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) > (14.4 * 0.001)
          )
        labels:
          severity: critical
        annotations:
          summary: "Burn rate critique : à ce rythme, le budget d'erreur mensuel sera épuisé en ~2 jours"
      # 14.4x le taux d'erreur SLO consommerait 100% du budget mensuel en 2 jours -> alerte immédiate justifiée

Utiliser l'error budget pour arbitrer les décisions produit vs fiabilité :

Budget restant > 50%  -> l'équipe peut déployer plus agressivement, prendre des risques mesurés
Budget restant < 10%   -> gel des déploiements non critiques, focus sur la stabilité jusqu'à reconstitution du budget

-> transforme un débat subjectif ("on est fiable ou pas ?") en décision basée sur une métrique partagée

Résumé

SLI = mesure brute, SLO = objectif interne sur cette mesure, SLA = engagement contractuel externe (généralement plus lâche que le SLO).
L'error budget rend le SLO actionnable : "combien de temps d'indisponibilité reste-t-il ce mois-ci" plutôt qu'un seuil abstrait.
Les alertes multi-fenêtres sur le "burn rate" (vitesse de consommation du budget) détectent les incidents bien plus tôt qu'un simple seuil de disponibilité.
Un SLO trop strict (99.99% partout) coûte cher en ingénierie ; le niveau doit être choisi service par service selon son impact réel.

Exercices pratiques

1 disponible

Mission : geler ou ne pas geler les déploiements

Objectif : Calculer un error budget, écrire une alerte de burn rate multi-fenêtre, et l'utiliser pour arbitrer une décision de déploiement.

Contexte

Le SLO de mon-api est fixé à 99.9% de disponibilité sur 30 jours glissants. L'équipe produit veut déployer une fonctionnalité risquée vendredi après-midi. L'équipe SRE doit trancher objectivement, à partir du budget d'erreur réellement consommé ce mois-ci, si ce déploiement est raisonnable.

Résoudre l’exercice →