SLO, SLI et Error Budgets : piloter la fiabilité de votre infrastructure

Combien de neuf faut-il pour garantir la fiabilité de vos services ? Cinq ? Quatre ? Trois ? Cette question en apparence simple révèle une vérité inconfortable : la plupart des organisations visent des niveaux de disponibilité irréalistes et coûteux.

Le dogme des « five nines » (99.999% = 26 secondes de downtime par an) est séduisant, mais il crée des contraintes technologiques massives, ralentit les déploiements et mobilise des ressources considérables. Quelquefois, trois nines suffisent largement (99.9% = 8.7 heures de downtime par an).

Entrez dans la méthodologie SRE (Site Reliability Engineering) popularisée par Google : plutôt que de poursuivre la perfection, les organisations définissent des SLOs (Service Level Objectives) réalistes, les mesurent via des SLIs (Service Level Indicators), et gèrent un error budget qui autorise les opérations à aller plus vite — tant qu'elles ne brûlent pas leur budget de défaillance.

Cet article vous montre comment implémenter cette approche concrètement.

• SLA, SLO, SLI : les définitions et leurs différences- Choisir les bons SLIs : quelles métriques vraiment représenter
• Définir des SLOs réalistes : basés sur le parcours utilisateur- Error budgets : le concept clé qui change tout
• Implémentation technique : Prometheus, alertes intelligentes- Dashboards Grafana : visualiser la fiabilité en temps réel
• Outils dédiés : Sloth, Pyrra, OpenSLO
• Culture d'équipe : intégrer les SLOs dans les pratiques DevOps
• Calculs pratiques : tables de fiabilité, budgets mensuels- Exemples concrets : une approche SHPV

Ces trois acronymes sont souvent confondus. Soyons clairs :

SLA (Service Level Agreement) : Un contrat, légalement contraignant, entre un prestataire et ses clients. Ex : « Nous garantissons 99.9% de disponibilité, sinon remboursement. »

SLO (Service Level Objective) : Un objectif interne de fiabilité, plus strict que le SLA. Ex : « Nous visons 99.95%, ce qui nous laisse une marge avant le SLA contractuel. »

SLI (Service Level Indicator) : La mesure réelle de ce qui se passe. Ex : « 99.92% de requêtes réussies ce mois-ci. »

L'idée clé : SLA ≤ SLO < réalité mesurée.

Un bon SLA contractuel ne vous engage pas à viser la même cible en interne. Au contraire : si vous promettez 99.9%, visez en interne 99.95%, et mesurez continuellement votre SLI. Vous avez ainsi une marge de sécurité.

Un SLI doit refléter ce que les utilisateurs ressentent réellement. Quelques dimensions classiques :

Availability (disponibilité) : Pourcentage de requêtes réussies / total requêtes.

# Prometheus : requêtes réussies (code 2xx, 3xx, 4xx)
sum(rate(http_requests_total{status=~"[234].."}[5m]))
/
sum(rate(http_requests_total[5m]))

Latency (latence) : Temps de réponse. Ne mesurez pas la moyenne, mesurez les percentiles (p50, p95, p99).

# P95 de latence : 95% des requêtes répondent en < 500ms
histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))

Throughput (débit) : Nombre de requêtes traitées. Utile pour les services batch ou asynchrones.

Error rate (taux d'erreur) : Peut être combiné à availability, mais parfois distinct (ex : erreurs métier vs erreurs techniques).

Conseil : Choisissez 2-3 SLIs par service, pas plus. Chaque SLI doit être mesurable, actionnable et représenter un vrai problème utilisateur.

Un SLO doit répondre à trois critères :

1. Basé sur le parcours utilisateur : Pas une moyenne synthétique, mais une expérience réelle.

Pour un e-commerce : « 99.5% des sessions de checkout complètent avec succès (de la page panier à la confirmation). »

2. Percentile, pas moyenne : Oubliez « latence moyenne 100ms ». Dites « p95 < 500ms ».

Pourquoi ? Parce qu'une average de 100ms peut cacher des pics à 5s qui ruinent l'expérience de quelques utilisateurs.

3. Composite quand nécessaire : Si votre service dépend de trois composants, définissez un SLI composite.

SLI global = (SLI_api × SLI_db × SLI_cache)

Exemples réalistes :

• API publique critique : 99.9% (8.7h downtime/an)
• API interne non critique : 95% (36.5 jours downtime/an)
• Batch de reporting : 90% (36.5 jours downtime/an)

Un error budget répond à la question : « Combien de défaillance puis-je me permettre ce mois-ci ? »

Calcul :

Error Budget = (1 - SLO) × nombre de minutes dans la période

Exemple, SLO = 99.9%, période = 1 mois (43 200 minutes) :

Error Budget = (1 - 0.999) × 43 200 = 43.2 minutes d'indisponibilité tolérée

Burn rate : Vitesse à laquelle vous consommez votre budget.

Burn rate = indisponibilité réelle / error budget tolérée

Si vous avez 43.2 minutes de downtime en 1 jour, votre burn rate est :

(43.2 min / 30 jours) / 43.2 min = 1.0 (budget épuisé en 30 jours au rythme actuel)

Politique d'error budget :

• Burn rate < 1 : Continuez, déployez plus vite, réduisez les tests.
• Burn rate 1-5 : Ralentissez légèrement, soyez prudent.
• Burn rate > 5 : Feature freeze. Concentrez-vous sur la stabilité jusqu'au mois prochain.

C'est radical, mais efficace. Plus besoin de débat : la métrique décide.

Vous avez Prometheus ? Voici comment mettre en place des SLIs et burn rate alerts.

1. Recording rules pour les SLIs

# prometheus/rules/slo.yaml
groups:
  - name: slo
    rules:
      - record: sli:http_availability:5m
        expr: |
          sum(rate(http_requests_total{status=~"[234].."}[5m]))
          /
          sum(rate(http_requests_total[5m]))

      - record: sli:http_availability:30m
        expr: |
          sum(rate(http_requests_total{status=~"[234].."}[30m]))
          /
          sum(rate(http_requests_total[30m]))

      - record: sli:http_p95_latency:5m
        expr: |
          histogram_quantile(0.95,
            sum(rate(http_request_duration_seconds_bucket[5m])) by (le)
          )

2. Alertes sur le burn rate

# Alerte "slow burn" : budget épuisé en 30 jours
- alert: SLO_BurnRate_30d
  expr: |
    sum(rate(http_requests_total{status!~"[234].."}[30m]))
    /
    sum(rate(http_requests_total[30m]))
    > (1 - 0.999)
  for: 15m
  labels:
    severity: warning
  annotations:
    summary: 'SLO brûlé en 30 jours'

# Alerte "fast burn" : budget épuisé en 5 minutes
- alert: SLO_BurnRate_5m
  expr: |
    sum(rate(http_requests_total{status!~"[234].."}[5m]))
    /
    sum(rate(http_requests_total[5m]))
    > (1 - 0.999) * 30
  for: 1m
  labels:
    severity: critical

Ces deux alertes capturent les dégradations lentes et rapides. Pas besoin de réveiller les gens pour chaque spike, mais oui pour les vraies tendances.

Un bon dashboard SLO affiche :

1. Vue d'ensemble du mois : Diagramme en jauge montrant la disponibilité réalisée vs SLO.
2. Error budget restant : Nombre d'heures de downtime encore tolérées ce mois.
3. Burn rate : Graphique du burn rate sur 30 jours (pour détecter les tendances).
4. Composants critiques : SLI par service (API, DB, Cache).

Voici une requête Grafana typique :

# SLO du mois (availability)
(
  sum(increase(http_requests_total{status=~"[234].."}[30d]))
  /
  sum(increase(http_requests_total[30d]))
) * 100

Et pour l'error budget restant (en heures) :

# Minutes consommées ce mois
(
  1 - (
    sum(increase(http_requests_total{status=~"[234].."}[30d]))
    /
    sum(increase(http_requests_total[30d]))
  )
) * 43200 / 60

L'équipe SRE consulte ce dashboard tous les jours. C'est votre décisiongram pour la vitesse de déploiement.

Prometheus est puissant mais verbeux. Quelques outils simplifient la génération de SLOs.

Sloth (https://sloth.dev) : Outil CNCF qui génère Prometheus rules et alerts à partir d'un fichier YAML simple.

# slothrc.yaml
version: v1
services:
  - name: api
    objectives:
      - name: availability
        indicatorType: latency
        target: 99.9
        window: 30d
        sli:
          prometheus:
            error_rate: 'rate(http_requests_total{status=~"5.."}[5m])'

Sloth génère les recording rules et alertes pour vous.

Pyrra (https://github.com/pyrra-dev/pyrra) : Interface web pour gérer les SLOs, intègre Prometheus directement.

OpenSLO (https://openslo.com) : Spécification open source pour standardiser les SLOs entre outils.

Ces outils réduisent la friction. Commencez avec Prometheus si vous êtes petit. À l'échelle, Sloth ou Pyrra devient indispensable.

Un SLO sur papier ne vaut rien. Intégrez-le dans les rituels :

1. Feature freeze par burn rate : Si burn rate > 5, pas de nouveau code en prod. Point final.

2. Postmortem blameless : Après une panne, analysez non pas « qui a merdé » mais « le SLO devrait-il être ajusté ? »

Si vous avez une panne majeure tous les 6 mois, peut-être que 99.99% n'est pas réaliste pour ce service.

3. Budget planning : Au début du sprint, l'équipe demande : « Avons-nous du budget pour déployer ? »

Si oui, vous pouvez réduire les tests et aller plus vite. Si non, concentrez-vous sur la fiabilité.

4. Incidents post-mortem : Documentez les incidents avec impact SLO. Tracez les patterns.

Voici une table de référence rapide :

Pour les budgets hebdomadaires et mensuels :

Downtime mensuel = (1 - SLO) × 43 200 minutes
Downtime hebdomadaire = (1 - SLO) × 10 080 minutes

99.9% → 43.2 min/mois, soit ~10 minutes par semaine. 99.95% → 21.6 min/mois, soit ~5 minutes par semaine.

Pour aller plus loin, découvrez nos articles :

• Monitorer Kubernetes en production : appliquez les SLOs sur des clusters K8s.
• Stack de monitoring Prometheus + Grafana + AlertManager : architecture complète.
• Déployer et monitorer vos services : intégration SLOs + déploiement.

SHPV, entreprise d'infrastructure IT depuis 2012, opère un backbone AS41652 avec 150 Gbps de capacité et 500+ peerings directs. Son SLA cible est 99.9%+ de disponibilité pour les services d'hébergement et d'infogérance.

Comment SHPV appliquerait-elle cette méthodologie ?

1. SLO par service : hébergement web (99.9%), cloud (99.95%), infogérance (99.99% car critique).
2. SLI mesurée : disponibilité globale du backbone, latence p95 sur les connexions client, taux d'erreur BGP/routage.
3. Error budget : SHPV tolère ~8.7h de downtime par an pour l'hébergement, mais vise 99.95% en interne (marge de 4.3h).
4. GTI de 2h : l'objectif de temps de guérison (incident resolution) s'aligne avec le burn rate — un incident majeur ne doit pas durer plus de 2h.
5. Culture : chaque déploiement ou modification réseau est validé contre le burn rate du mois. Pas de changement risqué en fin de mois.

Cette approche transforme la fiabilité d'un coût (« payer pour des redondances ») en un atout commercial (« nous maîtrisons le risque »).

• Google SRE Book, chapitre « Monitoring and Alerting » et « Service Level Objectives » (https://sre.google/sre-book/)
• Sloth Documentation (https://sloth.dev)
• OpenSLO Specification (https://openslo.com)
• Prometheus Best Practices (https://prometheus.io/docs/practices/)
• Grafana Alerting Guide (https://grafana.com/docs/grafana/latest/alerting/)

La méthodologie SRE et ses SLOs ne sont pas une tour d'ivoire académique. C'est un outil opérationnel qui :

✓ Donne un langage commun entre Dev et Ops. ✓ Autorise les équipes à aller plus vite en quantifiant le risque. ✓ Réduit les incidents majeurs en mesurant continuellement la fiabilité. ✓ Transforme la fiabilité en avantage concurrentiel.

Commencez modeste : définissez un SLO simple (99.9% d'availability), mesurez-le avec Prometheus, et ajustez chaque mois. Deux trimestres plus tard, vous aurez une culture de fiabilité robuste.

Et qui sait ? Peut-être découvrirez-vous que trois nines suffiront à 80% de vos services, et que ce que vous économisierez en stabilité, vous le réinvestirez en innovation.