SLAs, SLOs & SLIs : Construire des Objectifs de Fiabilité Qui Fonctionnent Vraiment

Les Accords de Niveau de Service (SLA), les Objectifs de Niveau de Service (SLO) et les Indicateurs de Niveau de Service (SLI) constituent le socle de l'ingénierie de fiabilité moderne. Bien les définir fait la différence entre une équipe SRE noyée sous les alertes et une équipe qui déploie en confiance.

Vue d'Ensemble

Pourquoi C'est Important

Sans objectifs de fiabilité explicites, les équipes se rabattent sur « tout doit être disponible à 100 % » — ce qui est à la fois impossible et extrêmement coûteux. Les SLOs donnent un moyen rationnel d'arbitrer entre fiabilité et vélocité : s'il resté du budget d'erreur, déployez plus vite ; s'il est consommé, ralentissez et stabilisez.

« L'espoir n'est pas une stratégie. » — Google SRE Book

Étape 1 — Choisir les Bons SLIs

Les SLIs doivent refléter ce que les utilisateurs vivent réellement. Catégories classiques :

Disponibilité

La proportion de requêtes validés qui réussissent.

SLI = (requêtes réussies) / (total des requêtes valides)

« Réussie » signifie généralement une réponse HTTP 2xx/3xx, en excluant les 4xx (erreurs client). Soyez explicite sur ce qui compte.

Latence

La proportion de requêtes plus rapides qu'un seuil.

SLI = (requêtes < 300ms) / (total des requêtes)

Utilisez des seuils en percentiles (p50, p95, p99) plutôt que des moyennes. Une latence moyenne de 200 ms peut masquer un p99 à 5 secondes.

Exactitude / Qualité

La proportion de réponses qui retournent les bonnes données.

SLI = (réponses correctes) / (total des réponses)

Pertinent pour les pipelines de données, l'inférence ML, les moteurs de recherche et les systèmes financiers.

Fraîcheur

La proportion de données mises à jour dans un délai acceptable.

SLI = (enregistrements mis à jour dans le seuil) / (total des enregistrements)

Critique pour les tableaux de bord, les caches et les systèmes événementiels.

Débit

La proportion de temps où le système traité au-dessus d'un taux minimum.

SLI = (minutes au-dessus de X req/s) / (total des minutes)

Utile pour le traitement par lots, les pipelines de streaming et les jobs ETL.

Conseils pour choisir les SLIs

• Mesurez à la périphérie, pas en interne. Un serveur sain derrière un load balancer cassé échoue quand même pour les utilisateurs.
• Moins c'est mieux. 2 à 4 SLIs par service. Si vous ne pouvez pas les expliquer en une phrase chacun, simplifiez.
• Utilisez des ratios. « Événements bons / événements totaux » est le format universel de SLI. Cela normalisé quel que soit le volume de trafic.

Étape 2 — Définir les Cibles SLO

Un SLO est une valeur cible pour un SLI sur une fenêtre temporelle.

SLO : 99,5 % des requêtes réussissent sur une fenêtre glissante de 30 jours

Choisir le bon chiffré

Règles pratiqués

1. Commencez plus bas que vous ne le pensez. Il est facile de resserrer un SLO, douloureux de le relâcher — surtout s'il est dans un SLA.
2. Alignez-vous sur vos dépendances. Votre SLO ne peut pas dépasser celui de votre dépendance la moins fiable.
3. Séparez par parcours utilisateur. Le login peut nécessiter 99,9 % ; un tableau de bord de reporting seulement 99 %.
4. Utilisez des fenêtres glissantes (ex. 30 jours) plutôt que des mois calendaires. Les fenêtres calendaires créent des paniques de fin de mois et des incitations à la remise à zéro.

Étape 3 — Calculer les Budgets d'Erreur

Budget d'erreur = 1 − cible SLO

Pour un SLO de 99,5 % sur 30 jours :

• Budget = 0,5 % des requêtes totales
• Si vous servez 10 M requêtes/mois → 50 000 échecs autorisés

Politiques de budget d'erreur

Définissez à l'avance ce qui se passé quand le budget est consommé :

Formalisez cela comme un accord d'équipe, signé par les responsables ingénierie et produit. Sans politique, les budgets d'erreur ne sont que des dashboards que personne ne consulte.

Étape 4 — Instrumenter et Mesurer

OpenTelemetry (recommandé)

Utilisez OTel pour émettre des métriques au niveau applicatif :

from opentelemetry import metrics

meter = metrics.get_meter("my-service")
request_counter = meter.create_counter(
    "http.server.request.count",
    description="Total des requêtes HTTP",
)
error_counter = meter.create_counter(
    "http.server.error.count",
    description="Requêtes HTTP en erreur",
)

# Dans votre handler de requête :
request_counter.add(1, {"method": "GET", "route": "/api/orders"})
if response.status >= 500:
    error_counter.add(1, {"method": "GET", "route": "/api/orders"})

Prometheus

Si vous êtes déjà sur Prometheus, utilisez des histogrammes pour les SLIs de latence :

# règles d'enregistrement prometheus
groups:
  - name: slo_rules
    rules:
      - record: sli:availability:ratio_30d
        expr: |
          1 - (
            sum(rate(http_requests_total{status=~"5.."}[30d]))
            /
            sum(rate(http_requests_total[30d]))
          )
      - record: sli:latency:ratio_30d
        expr: |
          sum(rate(http_request_duration_seconds_bucket{le="0.3"}[30d]))
          /
          sum(rate(http_request_duration_seconds_count[30d]))

Options cloud-native

Étape 5 — Alerter sur le Taux de Consommation, Pas sur les Seuils

Les alertes classiques par seuil (« taux d'erreur > 1 % ») sont bruyantes. Préférez les alertes sur le burn rate — la vitesse à laquelle vous consommez votre budget d'erreur.

Alertes multi-fenêtres, multi-taux

C'est l'approche du Google SRE Workbook :

# Exemple d'alerte Prometheus — burn rapide
- alert: HighErrorBudgetBurn
  expr: |
    (
      sli:error_ratio:rate1h > (14.4 * 0.005)
      and
      sli:error_ratio:rate5m > (14.4 * 0.005)
    )
  labels:
    severity: page
  annotations:
    summary: "Consommation du budget d'erreur 14,4x plus vite que prévu"

La fenêtre de confirmation courte (5 min) évite les alertes sur des pics isolés.

Étape 6 — Du SLO au SLA

Un SLA est un contrat commercial. Règles :

1. Cible SLA < cible SLO. Gardez toujours une marge. Si votre SLO est 99,9 %, votre SLA devrait être 99,5 % ou moins.
2. Définissez la mesure précisément. Quel endpoint, quelles méthodes HTTP, mesuré où, hors maintenance planifiée.
3. Définissez les conséquences. Crédits de service (ex. 10 % de crédit par 0,1 % sous le SLA), extensions d'abonnement, ou droits de résiliation.
4. Excluez la force majeure et les fenêtres de maintenance planifiée (avec délai de prévenance requis).

Exemple de clause SLA

« Le Prestataire garantit une disponibilité mensuelle de 99,5 % pour l'API de Production, mesurée comme le ratio de réponses API réussies (HTTP 2xx/3xx) sur le total des requêtes API, hors fenêtres de maintenance planifiée annoncées 72 heures à l'avance. Pour chaque tranche de 0,1 % en dessous du niveau garanti, le Client reçoit un crédit de service de 10 % sur la facture du mois concerné, dans la limite de 30 %. »

Étape 7 — Réviser et Itérer

Les SLOs sont des documents vivants. Revue trimestrielle :

• Respectons-nous nos SLOs ? Si toujours à 100 %, le SLO est trop lâche — resserrez-le ou déployez plus vite.
• Consommons-nous le budget trop vite ? Identifiéz les principales sources d'erreur et corrigez-les.
• Nos SLIs reflètent-ils toujours l'expérience utilisateur ? Des plaintes qui n'apparaissent pas dans les SLIs signifient que vous mesurez la mauvaise chose.
• Le contexte métier a-t-il changé ? Nouvelles exigences de conformité, nouveaux tiers clients, nouvelles dépendances.

Anti-Patterns Courants

Ressources

• Google SRE Book — Service Level Objectives
• Google SRE Workbook — Implementing SLOs
• Spécification OpenSLO — Format SLO-as-code indépendant des fournisseurs
• Sloth — Générer des règles Prometheus SLO depuis un simple fichier YAML
• Art of SLOs (cours Google) — Cours Coursera gratuit

:::