Du chaos à la maîtrise

Le contexte

Plateforme e-commerce, 100M€ de CA annuel, croissance rapide. Mais l’équipe Ops ? Au bord du burnout.

Chaque jour : 300+ alertes Pagerduty. 90% étaient du bruit (faux positifs, alertes cascading, seuils mal calibrés). L’équipe passait 70% de son temps à “chasser” les alertes au lieu d’améliorer.

Pire : lors de Black Friday, les vraies problèmes se noyaient dans le bruit. Une API dégradée ? Invisible au milieu de 1000 alertes insignifiantes.

Et les développeurs ? Ils ne comprenaient pas pourquoi leurs features étaient bloquées. C’était “pour la stabilité” disait-on. Mais quelle stabilité ? Juste du froid généralisé.

L’action Leanovia

Pas de silver bullet. Une transformation progressive.

Phase 1: Définition des SLO

• Qu’est-ce que c’est vraiment une “latence acceptable” pour un utilisateur e-commerce ?
  • Listing produit : p95 < 500ms (utilisateurs cliquent ailleurs si ça traîne)
  • Checkout : p99 < 2s (on est pessimistes, utilisateur stressé)
  • Admin : p95 < 5s (pas critique, ça peut être plus lent)

Ces SLO viennent du business, pas d’un dashboardiste qui regarde des nines.

Phase 2: Tracing distribué

• Déploiement OpenTelemetry + Jaeger
• Chaque requête est tracée à travers tous les services
• Enfin on peut relier une latence lente à “service X a mis 3s en base de données”

Phase 3: Élagage des alertes

• Au lieu d’alerter sur “p95 latence”, on alerte sur “Vous avez dépensé 50% de votre SLO budget ce mois-ci”
• Au lieu d’alerter sur “Un log d’erreur”, on alerte sur “Votre error rate a dévié de 3x sa baseline”
• Les vraies alertes : celles qui impactent le SLO utilisateur

Phase 4: Runbooks + Automation

• Quand vous alertez, vous devez avoir un runbook : “Comment fix ça ?”
• Ou mieux : automatiser la réponse (redeploy, scale up, clear cache)

L’impact

• -60% d’alertes : De 300+ à ~120 par jour (et ces 120, c’est du signal)
• MTTR divisé par 3 : Avant, 45min pour identifier le problème. Maintenant, 15min (grâce au tracing)
• Budget d’erreur actif : Les devs savent qu’ils ont 0,1% de marge. Une feature audacieuse ? Ils la lancent, monitoring c’est de la responsabilité partagée
• Confiance restaurée : Ops et Dev ne sont plus ennemis. Ils pilotent ensemble sur les SLO

Leçon

C’est pas que les outils (Prometheus, Jaeger, etc). C’est que vous avez changé le langage.

Avant : “Aïe, votre app est lente !”
Après : “Aïe, votre SLO est impacté, dépensez votre budget d’erreur intelligemment”

C’est subjectivement plus dépressif peut-être, mais c’est aussi beaucoup plus actionable.