SRE : Arrêtez de monitorer le CPU, passez aux SLOs (Guide Pratique)

INTRODUCTION

Le monitoring classique de l'infrastructure (CPU, RAM, Disque) génère souvent du bruit inutile. Un CPU à 90% est-il un problème ? Pas si vos utilisateurs reçoivent leurs réponses en moins de 200ms.

Pour adopter une culture SRE (Site Reliability Engineering) efficace, il est impératif de changer de paradigme : arrêtez de surveiller la santé des serveurs et commencez à surveiller la satisfaction utilisateur.

Ce guide vous explique comment définir des SLOs (Service Level Objectives) concrets, implémenter des indicateurs fiables et sortir de l'enfer des astreintes inutiles.

Prérequis

Avant de vous lancer, assurez-vous d'avoir :

La stack technique : Une instance Prometheus et un dashboard Grafana opérationnels.
Les accès : Droits de lecture sur les métriques applicatives et d'écriture pour les règles d'alerting.
Le vocabulaire de base :
- SLI (Indicator) : La mesure (ex: latence actuelle).
- SLO (Objective) : La cible interne (ex: 99.5% de succès).
- SLA (Agreement) : Le contrat légal avec le client (ex: pénalités si < 99.0%).

Tutoriel pas à pas

1. Identifier les parcours critiques (CUJ)

Ne monitorez pas tout. Concentrez-vous sur les Critical User Journeys (CUJ). Si votre fonctionnalité "Avatar" plante, ce n'est pas grave. Si le "Paiement" plante, vous perdez de l'argent.

Exemple pour un E-commerce :

Login (Critique)
Ajout au panier (Critique)
Paiement (Critique)
Consultation de l'historique de commandes (Non-Critique)

2. Le Template de définition de SLO (Délivrable)

Avant d'écrire la moindre ligne de code ou de PromQL, remplissez ce modèle avec votre Product Owner. C'est votre contrat moral.

Champ	Exemple
Service	`payment-service`
User Journey	L'utilisateur valide son panier.
SLI (Indicateur)	Ratio des requêtes `POST /checkout` réussies sur le total.
Précision	Les erreurs `5xx` sont des échecs. Les `4xx` (erreurs client) sont des succès du serveur (le serveur a correctement rejeté une mauvaise requête).
SLO (Objectif)	99.5% de succès sur une fenêtre glissante de 28 jours.
Conséquence	Si l'Error Budget est vide : Feature Freeze (gel des déploiements) jusqu'au retour à la normale.

3. Traduire le SLI en PromQL

L'objectif est de traduire la définition ci-dessus en langage machine.

Calcul de la disponibilité instantanée :

# Pourcentage de succès sur les 5 dernières minutes
sum(rate(http_requests_total{status!~"5..", service="payment-service"}[5m]))
/
sum(rate(http_requests_total{service="payment-service"}[5m]))
* 100

Note technique : On utilise rate() pour gérer les redémarrages de compteurs et sum() pour agréger tous les pods/instances du service.

L'Alerting basé sur l'Error Budget : L'Error Budget est votre marge de manœuvre (100% - SLO). Pour un SLO de 99.5%, vous avez droit à 0.5% d'erreurs.

Plutôt que d'alerter dès qu'une erreur survient, on alerte si le budget se vide trop vite.

# Exemple de règle d'alerte Prometheus
- alert: HighErrorRate
  expr: |
    (
      sum(rate(http_requests_total{status=~"5..", service="payment-service"}[5m]))
      /
      sum(rate(http_requests_total{service="payment-service"}[5m]))
    ) > 0.005
  for: 2m
  labels:
    severity: critical
  annotations:
    summary: "Le SLO de disponibilité est en danger (Taux d'erreur > 0.5%)"

4. Visualiser le SLO dans Grafana

Ne surchargez pas vos dashboards. Créez une vue spécifique "SRE Board" avec :

Disponibilité actuelle (Jauge) : Votre requête PromQL.
Error Budget restant (Graphique) : Affichez la tendance. Est-ce qu'on perd du budget ou est-ce stable ?
Burn Rate (Texte) : "À cette vitesse, le budget sera épuisé dans 4 heures".

💡 Astuce Pro : Pour des calculs de fenêtres glissantes complexes (28 jours), n'écrivez pas le PromQL à la main. Utilisez des outils comme Pyrra ou Sloth qui génèrent automatiquement les recording rules Prometheus optimisées.

Sécurité et Confidentialité 🔐

RBAC : Les dashboards SLO sont stratégiques. Lecture seule pour les devs, écriture pour les SRE/Tech Leads.
Sanitization : Attention à la cardinalité et aux données personnelles (PII).
- ❌ Mauvais label : path="/user/12345/profile" (Explosion de la cardinalité Prometheus).
- ✅ Bon label : path="/user/:id/profile".

Aller plus loin : Burn Rates & Latence 📈

L'objectif n'est pas d'avoir 100% de disponibilité (c'est trop cher et ralentit l'innovation). L'objectif est de dépenser intelligemment votre Error Budget.

Burn Rate Alerting : Une alerte simple sur un seuil fixe est souvent insuffisante. Implémentez le "Multi-Window Burn Rate" (ex: taux d'erreur élevé sur 1h ET sur 5m) pour éviter les faux positifs.
Performance : La disponibilité ne suffit pas. Ajoutez un SLO de latence.
- Exemple : "99% des requêtes doivent être servies en moins de 300ms".

Tests et Validation ✅

Ne faites pas confiance à vos règles aveuglément.

Chaos Engineering : Utilisez k6 ou Gatling pour générer des erreurs artificielles (ex: injecter des 500) et vérifier que l'alerte se déclenche bien.
Linting : Validez la syntaxe avant le déploiement.

# Validation des règles Prometheus avant commit
promtool check rules rules-slo.yml

Politique de Rollback / Plan B ↩️

C'est la partie la plus difficile : la culture. Si l'Error Budget est épuisé, il faut agir :

Stop the line : Arrêt des déploiements de nouvelles features.
Focus Fiabilité : Les développeurs ne travaillent plus que sur la stabilité (fix de bugs, amélioration infra).
Retour à la normale : Le gel est levé quand le budget se reconstitue (souvent au début de la fenêtre glissante suivante ou après x jours de stabilité).

Erreurs fréquentes & diagnostics

Symptôme	Cause probable	Solution
Le SLO clignote (Vert/Rouge)	Fenêtre de temps trop courte (ex: `[1m]`).	Augmentez la fenêtre ou utilisez des alertes basées sur le Burn Rate.
Alerte critique mais tout va bien	Le SLI inclut des erreurs légitimes (ex: 404 bots).	Affinez le filtre PromQL (ex: exclure certains `User-Agent` ou `paths`).
Alerte silencieuse lors d'une panne	Les timeouts ne sont pas comptés comme erreurs.	Vérifiez que votre métrique capture bien les timeouts client ou infra.

Checklist de mise en prod

Le SLO a été validé par le Product Owner (pas juste la Tech).
Les labels Prometheus (service, env) sont standardisés.
Une alerte de type "Burn Rate" est configurée.
Le dashboard Grafana est accessible à toute l'équipe produit.
La politique de "Feature Freeze" est documentée dans le wiki interne.

FAQ

Q1. Pourquoi ne pas monitorer le CPU ? Le CPU est une cause, pas un symptôme. Un CPU à 100% est acceptable lors d'un gros calcul, tant que le service répond. Alertez sur le symptôme (Latence/Erreur), et utilisez le dashboard CPU pour investiguer la cause.

Q2. Quelle est la différence fondamentale entre SLA et SLO ? Le SLO est votre objectif interne (ex: 99.9%). Le SLA est la promesse externe souvent liée à un contrat (ex: 99.5%). Règle d'or : Votre SLO doit toujours être plus strict que votre SLA pour avoir une marge de sécurité.

Conclusion

Définir des SLOs permet de sortir de la réactivité pure. Vous ne subissez plus les alertes d'infrastructure ; vous pilotez la fiabilité de votre service par la donnée.

Votre mission pour demain : Prenez un seul parcours critique (le login par exemple), définissez son SLO, et coupez les alertes CPU sur ce service. Vous dormirez mieux.

SRE : Définir des SLOs pertinents et arrêter de monitorer le CPU inutilement