Sre

“Pourquoi la prod est lente ?” Sans observability, impossible de répondre. Voici comment implémenter les 3 piliers pour debug efficace en production. Monitoring vs Observability Monitoring (approche classique) Savoir QUAND ça casse → Alertes sur métriques connues → "CPU > 80%" → Alerte Limite : Ne répond pas au “Pourquoi ?” Observability (approche moderne) Comprendre POURQUOI ça casse → Investiguer comportements émergents → Corréler métriques + logs + traces Exemple : Alerte: API latency increased (+200ms) Monitoring classique: - "La latency est haute" - Restart service ? Observability: - Trace montre : DB query lente - Logs montrent : Lock contention - Metrics montrent : Connexions DB saturées → Root cause: Missing index sur table users Les 3 piliers 1. Métriques (Metrics) Qu’est-ce que c’est ? ...

“Notre système est résilient.” Vraiment ? L’avez-vous testé ? Le Chaos Engineering consiste à casser volontairement la prod pour vérifier qu’elle survit. Retour d’expérience après 1 an de pratique. Le problème : Fausse résilience Ce qu’on croit ✅ Redondance serveurs ✅ Auto-scaling configuré ✅ Health checks en place ✅ Backups automatiques → "Le système est résilient !" La réalité Premier incident critique : - Auto-scaling ne scale pas (config obsolète) - Health checks passent mais app bugue - Backup restore : jamais testé, ne marche pas - Cascading failure : tout tombe → Downtime 4 heures Problème : On ne teste la résilience que pendant les incidents. ...