SRE : SLI/SLO et Error Budgets

Introduction — Le SRE, ou comment Google a réinventé les ops

Le Site Reliability Engineering est né chez Google en 2003, quand Ben Treynor Sloss a eu une idée simple mais révolutionnaire : confier les opérations à des ingénieurs software. Sa citation fondatrice : “SRE is what happens when you ask a software engineer to design an operations team.”

Le changement de paradigme est profond. L’ops traditionnelle vise le “zéro downtime” — un objectif impossible qui mène au conservatisme et au blocage des releases. Le SRE accepte que les incidents sont inévitables et introduit les error budgets : un budget d’erreur calculé mathématiquement qui détermine quand on peut déployer et quand il faut stabiliser.

Ce cours couvre les trois piliers pratiques du SRE : les SLI/SLO/SLA (mesurer ce qui compte), les error budgets (décider avec des données), et l’élimination du toil (automatiser le travail répétitif).

🔥 Cas réel : Avant d’adopter le SRE, une scale-up déployait une fois par semaine avec un “change freeze” de 2 jours. Les devs accumulaient les features, les releases étaient massives et risquées. Après implémentation des SLOs et error budgets, ils sont passés à 15 déploiements/jour. Paradoxalement, la fiabilité a augmenté — parce que chaque release était petite et facilement réversible.

🧠 À retenir : Le SRE repose sur 7 principes : embracing risk, SLOs, eliminating toil, monitoring actionnable, release engineering, simplicity, et capacity planning. Mais les trois premiers sont ceux qui changent concrètement le quotidien.

SLI / SLO / SLA : la pyramide de la fiabilité

Ces trois acronymes forment un système cohérent pour mesurer et contractualiser la fiabilité. La confusion entre les trois est fréquente — clarifions.

Le SLI (Service Level Indicator) est la métrique brute. C’est ce que tu mesures : le pourcentage de requêtes réussies, le pourcentage de requêtes sous 300ms, le taux de données correctes. Un bon SLI reflète l’expérience utilisateur, pas les métriques système. “CPU < 80%” n’est pas un SLI — “99% des pages chargent en moins de 2 secondes” en est un.

Le SLO (Service Level Objective) est l’objectif interne. C’est le seuil que tu te fixes : “99.95% de disponibilité sur 30 jours glissants”. Le SLO est plus strict que le SLA pour avoir une marge de sécurité.

Le SLA (Service Level Agreement) est le contrat client. C’est l’engagement légal avec des pénalités : “99.9% de disponibilité ou crédit au prorata”. Le SLA est toujours moins exigeant que le SLO.

Voici comment calculer les SLI en PromQL — la disponibilité (ratio de requêtes non-5xx) et la latence (ratio de requêtes sous le seuil) :

# SLI Disponibilité — % de requêtes réussies
sli:availability:ratio =
  sum(rate(http_requests_total{code!~"5.."}[30d]))
  /
  sum(rate(http_requests_total[30d]))

# SLI Latence — % de requêtes sous 300ms
sli:latency:ratio =
  sum(rate(http_request_duration_seconds_bucket{le="0.3"}[30d]))
  /
  sum(rate(http_request_duration_seconds_count[30d]))

# Exemple concret sur 30 jours :
# 10 000 000 requêtes, 4 500 erreurs 5xx
# Disponibilité = 1 - (4500/10000000) = 99.955% ✅ (SLO: 99.95%)
# 85 000 requêtes > 300ms
# Latence = 1 - (85000/10000000) = 99.15% ✅ (SLO: 99%)

Le standard OpenSLO permet de formaliser les SLOs en YAML, versionnable dans Git et exploitable par des outils comme Sloth ou Pyrra :

apiVersion: openslo/v1
kind: SLO
metadata:
  name: api-availability
spec:
  service: api-gateway
  description: "99.95% des requêtes doivent réussir"
  budgetingMethod: Occurrences
  objectives:
    - target: 0.9995
      ratioMetrics:
        good:
          metricSource:
            type: prometheus
            spec:
              query: sum(rate(http_requests_total{code!~"5.."}[5m]))
        total:
          metricSource:
            type: prometheus
            spec:
              query: sum(rate(http_requests_total[5m]))
  timeWindow:
    - duration: 30d
      isRolling: true

💡 Tip DevOps : Commence avec 2-3 SLOs maximum par service. Disponibilité + latence couvrent 90% des besoins. Ajoute un SLO de correctness uniquement si ton service transforme ou calcule des données. Trop de SLOs = personne ne les regarde.

⚠️ Attention : Un SLO de 99.99% semble anodin mais ne laisse que 4 minutes de downtime par mois. Vérifie que ton architecture, ton pipeline de déploiement et ton temps de réaction peuvent réellement tenir cet engagement avant de le promettre.

Error Budgets : décider avec des données

L’error budget est le concept le plus puissant du SRE. C’est la quantité d’erreur “autorisée” par ton SLO : Error Budget = 1 - SLO. Avec un SLO de 99.95%, ton error budget est 0.05% — soit 5 000 erreurs autorisées sur 10 millions de requêtes par mois.

Ce budget transforme les discussions subjectives (“on déploie ou pas ?”) en décisions objectives basées sur des données. Budget restant > 50% ? Déployez librement, expérimentez. Budget entre 25-50% ? Review SRE obligatoire, canary deployment. Budget < 10% ? Freeze des features, focus stabilisation.

Le burn rate mesure la vitesse de consommation du budget. Un burn rate de 1 = consommation nominale. Au-dessus de 1, tu consommes trop vite. L’alerting basé sur le burn rate (recommandé par le Google SRE Workbook) détecte les problèmes avant l’épuisement du budget :

# Error budget consommé (ratio, 0 à 1)
1 - (
  sum(rate(http_requests_total{code!~"5.."}[30d]))
  / sum(rate(http_requests_total[30d]))
) / (1 - 0.9995)

# Burn rate sur 1h (1 = nominal, >1 = trop rapide)
(
  1 - sum(rate(http_requests_total{code!~"5.."}[1h]))
      / sum(rate(http_requests_total[1h]))
) / (1 - 0.9995)

L’alerting multi-fenêtre combine une fenêtre courte et une fenêtre longue pour éviter les faux positifs :

# Fast burn — consomme 2% du budget en 1h → page immédiat
- alert: ErrorBudgetFastBurn
  expr: |
    (1 - sum(rate(http_requests_total{code!~"5.."}[5m]))
      / sum(rate(http_requests_total[5m])))
    / (1 - 0.9995) > 14.4
    AND
    (1 - sum(rate(http_requests_total{code!~"5.."}[1h]))
      / sum(rate(http_requests_total[1h])))
    / (1 - 0.9995) > 14.4
  for: 2m
  labels:
    severity: critical
  annotations:
    summary: "Burn rate critique (>14.4x) — error budget en danger"

# Slow burn — consomme 5% du budget en 6h → ticket
- alert: ErrorBudgetSlowBurn
  expr: |
    (1 - sum(rate(http_requests_total{code!~"5.."}[30m]))
      / sum(rate(http_requests_total[30m])))
    / (1 - 0.9995) > 6
    AND
    (1 - sum(rate(http_requests_total{code!~"5.."}[6h]))
      / sum(rate(http_requests_total[6h])))
    / (1 - 0.9995) > 6
  for: 15m
  labels:
    severity: warning

🔥 Cas réel : Une plateforme e-commerce avait un SLO de 99.9% mais déployait “au feeling”. Un vendredi après-midi, un déploiement a causé 2% d’erreurs pendant 4 heures — consommant 80% de l’error budget mensuel. Après adoption des politiques d’error budget, ce genre de déploiement à risque est automatiquement bloqué quand le budget est sous 50%. Le burn rate alerting aurait détecté le problème en 5 minutes au lieu de 4 heures.

🧠 À retenir : L’error budget n’est pas punitif — c’est un outil de négociation entre fiabilité et vélocité. Quand le budget est plein, les devs déploient vite. Quand il est bas, tout le monde se concentre sur la stabilité. C’est un langage commun entre dev et ops.

Éliminer le Toil

Le toil est le travail opérationnel qui est manuel, répétitif, automatisable, sans valeur durable, et qui scale linéairement avec le service. Google recommande que le toil ne dépasse pas 50% du temps d’un SRE — le reste devrait être de l’engineering (automatisation, outils, architecture).

Exemples concrets : redémarrer des pods à la main (toil) vs écrire un controller de self-healing (engineering). Vérifier les logs chaque matin (toil) vs créer des alertes automatiques (engineering). Renouveler les certificats manuellement (toil) vs déployer cert-manager (engineering).

Pour réduire le toil, il faut d’abord le mesurer :

# Toil tracker — inventaire trimestriel
team: platform-sre
quarter: Q1-2026
members: 4

toil_items:
  - name: "Certificate renewal"
    frequency: weekly
    time_per_occurrence: 30m
    monthly_hours: 2
    status: automated  # cert-manager

  - name: "Scale for traffic peaks"
    frequency: daily
    time_per_occurrence: 15m
    monthly_hours: 7.5
    status: in_progress  # KEDA en cours

  - name: "Investigate false-positive alerts"
    frequency: daily
    time_per_occurrence: 20m
    monthly_hours: 10
    status: todo  # Affiner les alerting rules

# Total: 19.5h/mois/personne
# Ratio: 19.5/160 = 12.2% ✅ (objectif < 50%)

💡 Tip DevOps : Le ROI de l’automatisation se calcule simplement : temps_économisé_par_an = fréquence × durée × 12. Si une tâche prend 20 min/jour, c’est ~120h/an. Si l’automatisation prend 3 jours (24h), le ROI est atteint en 2.4 mois. Priorise les tâches quotidiennes à fort impact.

Bonnes pratiques et pièges à éviter

Bonnes pratiques :

• SLOs basés sur l’expérience utilisateur, pas sur les métriques système
• Commencer avec des SLOs modestes (99.9%) et les durcir progressivement
• Afficher l’error budget sur un dashboard visible de toute l’équipe
• Burn rate alerting multi-fenêtre > alertes sur seuils fixes
• Postmortems blameless après chaque incident significatif
• Revoir les SLOs chaque trimestre — ils ne sont pas gravés dans le marbre

Pièges courants :

• SLO trop ambitieux dès le début → error budget épuisé en permanence → perte de crédibilité
• Confondre SLO et SLA → le SLO interne doit être plus strict que le SLA contractuel
• Mesurer le CPU au lieu de l’expérience utilisateur → faux sentiment de sécurité
• Ignorer le toil → les SRE passent 80% de leur temps en travail manuel → pas de progrès
• Error budget sans politique claire → personne ne sait quoi faire quand le budget est bas

⚠️ Attention : Le piège le plus subtil du SRE est de définir des SLOs que personne ne regarde. Un SLO sans dashboard visible, sans alerting de burn rate, et sans politique d’error budget n’est qu’un document mort. L’adoption culturelle est plus dure que l’implémentation technique.

Résumé

Le SRE transforme l’approche des opérations en remplaçant l’intuition par des données. Les SLI mesurent l’expérience utilisateur réelle, les SLO fixent des objectifs internes, et les SLA contractualisent avec les clients. L’error budget — la quantité d’erreur autorisée — devient l’outil de décision qui régule le rythme des déploiements. Le burn rate alerting multi-fenêtre détecte la consommation anormale du budget avant qu’il ne soit épuisé. L’élimination du toil libère du temps pour l’engineering qui améliore la fiabilité à long terme.

🧠 À retenir : Le SRE n’est pas un rôle — c’est une culture. La disponibilité n’est pas un objectif technique mais un choix business : chaque “9” supplémentaire dans le SLO coûte exponentiellement plus cher. Le bon SLO est celui qui satisfait les utilisateurs sans paralyser l’équipe.