SLI, SLO, SLA¶

Mesurer la fiabilité, fixer des objectifs, gérer le budget d'erreur — le cadre opérationnel de la fiabilité.

Trois niveaux, trois publics¶

Mesurer la fiabilité suppose d'abord de la définir précisément. SLI, SLO et SLA sont trois niveaux distincts avec des publics et des usages différents. Les confondre conduit soit a des engagements impossibles a tenir, soit a des métriques sans conséquence opérationnelle.

SLI — Service Level Indicator¶

Le SLI est une métrique brute, mesuree en continu, qui capture un aspect de la qualité de service percu par l'utilisateur. Ce n'est pas n'importe quelle métrique — c'est celle qui reflete l'expérience réelle.

Bons SLI :

• Latence de la réponse HTTP mesuree côté serveur (ou mieux, côté client)
• Ratio de requêtes reussies (2xx) sur le total des requêtes
• Taux de completion d'une opération de bout en bout (commande passee avec succès)

Mauvais SLI :

• CPU utilization — métrique d'infrastructure, pas d'expérience utilisateur
• Nombre de tickets ouverts — lag important, pas temps réel
• "Le service est up" — binaire, pas de nuance

SLO — Service Level Objective¶

L'objectif interne défini sur un SLI, avec une fenêtre temporelle. Le SLO répond à la question : "quelle fiabilité visons-nous ?"

Un SLO bien formule : "99.9% des requêtes sur /api/checkout répondent en moins de 500ms sur une fenêtre glissante de 30 jours."

Un SLO n'est pas un engagement contractuel. C'est un outil de décision interne qui permet d'arbitrer entre nouvelles fonctionnalités et stabilité.

SLA — Service Level Agreement¶

L'engagement contractuel envers les clients, avec des conséquences (credits, pénalités, résiliation). Le SLA est toujours moins exigeant que le SLO interne — la marge entre les deux est la zone de sécurité.

Error budget¶

Un SLO a 99.9% sur un mois autorise un certain nombre de minutes de dégradation :

L'error budget est la quantite de panne acceptable restante sur la periode. Il transforme "est-ce qu'on peut déployer ?" d'une décision politique en une décision basée sur des données objectives.

Politique d'error budget¶

Le budget sert de signal de décision opérationnelle :

Budget intact (> 75%) — la fiabilité est bonne. Les deployments continuent, les nouvelles fonctionnalités sortent, les refactorings risques sont acceptables. C'est le moment d'innover.

Budget partiellement consomme (25-75%) — augmenter la vigilance. Renforcer les tests pre-production, ralentir la cadence de deployment, éviter les changements d'infrastructure.

Budget faible (< 25%) — mode prudence. Deployments uniquement pour les corrections critiques. Prioriser la stabilité. Toute nouvelle fonctionnalité attend la prochaine fenêtre.

Budget épuisé (0%) — gel des deployments non-critiques. Prioriser la stabilité, investiguer les causes racines, ne pas introduire de nouveau risque. L'équipe se concentre exclusivement sur la fiabilité.

graph LR
    B100["Budget > 75%\nInnovation libre"] -->|consommation| B50["Budget 25-75%\nVigilance accrue"]
    B50 -->|consommation| B25["Budget < 25%\nMode prudence"]
    B25 -->|consommation| B0["Budget epuise\nGel deployments"]
    B0 -->|nouveau mois| B100

    style B100 fill:#2a9d8f,color:#fff
    style B50 fill:#e9c46a,color:#000
    style B25 fill:#e76f51,color:#fff
    style B0 fill:#c44,color:#fff

Toil et error budget¶

Le concept de "toil" (travail opérationnel repetitif et automatisable) est intimement lie à l'error budget. Quand le budget est intact, l'équipe a de la bande passante pour automatiser le toil. Quand le budget est épuisé, le toil augmente (plus d'incidents, plus d'interventions manuelles) exactement au moment où l'équipe devrait se concentrer sur la fiabilité.

Règle pratique : si l'équipe passe plus de 50% de son temps sur du toil, elle n'a pas la capacité d'améliorer la fiabilité. Automatiser le toil libere du temps pour les projets qui reduisent les incidents futurs.

Les 4 Golden Signals¶

Google SRE a identifié quatre SLI universels qui s'appliquent a presque tout système :

Latence¶

Temps de réponse. Mesurer en percentiles : p50 (mediane), p95, p99, p999. Distinguer les succès des erreurs : une erreur retournee rapidement ne doit pas faire baisser artificiellement le p99 et masquer une vraie lenteur.

Taux d'erreur¶

Ratio erreurs / requêtes totales. Inclure les erreurs 5xx, les timeouts côté client, et les erreurs métier selon le contexte. Un paiement refuse par la banque est-il une erreur technique ? Non. Mais un paiement qui timeout est une erreur de fiabilité.

Débit (Traffic)¶

Nombre de requêtes par seconde, volume de données traitees, messages consommes. Signal de charge et de sante globale. Un débit anormalement bas peut indiquer un problème upstream — si personne n'appelle votre service, c'est peut-être que le service qui vous appelle est en panne.

Saturation¶

Utilisation des ressources limitantes : CPU, mémoire, connexions DB, taille de file d'attente. Indicateur predictif : la saturation augmente avant que les erreurs et la latence se degradent. Surveiller pour anticiper.

SLO-based alerting¶

Le problème des alertes traditionnelles¶

Les alertes basées sur des seuils statiques ("alerte si latence > 500ms pendant 5 minutes") génèrent trop de bruit. Elles déclenchent sur des pics brefs sans conséquence sur le SLO, et ratent des dégradations lentes mais continues qui grignottent le budget.

Multi-window, multi-burn-rate¶

L'approche recommandee par Google SRE est le "multi-window, multi-burn-rate alerting". Le principe : alerter quand la vitesse de consommation du budget d'erreur (burn rate) est trop élevée sur plusieurs fenêtres de temps.

Burn rate : le facteur multiplicateur de consommation du budget. Un burn rate de 1 signifie que le budget sera exactement épuisé à la fin de la periode. Un burn rate de 10 signifie que le budget sera épuisé 10 fois plus vite que prévu.

Fenêtres d'alerte¶

La double fenêtre (longue + courte) evite les faux positifs. La fenêtre longue détecté la tendance, la fenêtre courte confirme que le problème est actuel (pas un pic passe qui biaise la fenêtre longue).

Exemple Prometheus¶

# Alerte haute severite : burn rate 14.4x sur 1h, confirme sur 5min
# SLO: 99.9% de requetes reussies sur 30 jours
- alert: HighErrorBudgetBurn
  expr: |
    (
      sum(rate(http_requests_total{code=~"5.."}[1h]))
      / sum(rate(http_requests_total[1h]))
    ) > (14.4 * 0.001)
    and
    (
      sum(rate(http_requests_total{code=~"5.."}[5m]))
      / sum(rate(http_requests_total[5m]))
    ) > (14.4 * 0.001)
  labels:
    severity: page
  annotations:
    summary: "Error budget burn rate critique"

Mettre en place les SLO : méthode pratique¶

Étape 1 — Choisir les SLI¶

Identifier les 3-5 métriques qui reflettent le mieux l'expérience utilisateur. Moins c'est mieux — trop de SLI dilue l'attention.

Étape 2 — Mesurer sans objectif¶

Instrumenter et collecter pendant 4-8 semaines. Observer les distributions réelles, les percentiles, les variations jour/nuit, semaine/weekend.

Étape 3 — Fixer les SLO¶

Choisir des objectifs atteignables avec une marge. Si le p99 réel est a 180ms, ne pas fixer le SLO a 180ms (aucune marge) ni a 1000ms (trop lâche, inutile). 300ms est un bon point de départ.

Étape 4 — Configurer les alertes¶

Mettre en place le multi-window multi-burn-rate alerting. Vérifier que les alertes se déclenchent correctement en injectant des erreurs controlees.

Étape 5 — Iterer¶

Réviser les SLO chaque trimestre. Resserrer si le système est régulièrement dans le vert. Relacher si le budget est systematiquement épuisé (SLO trop ambitieux pour l'état actuel du système).

Chapitre suivant : Observabilité — logs, métriques et traces pour comprendre le système en production.