“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.
Chaos Engineering : Le principe
Injecter des failures volontaires en prod pour prouver la résilience.
Les 4 piliers
- Hypothèse : “Le système survit si le service X crash”
- Expérience : Tuer le service X en prod
- Mesure : Observer métriques métier (not just tech)
- Learn : Si ça casse, fixer avant le vrai incident
Netflix Simian Army
Netflix a popularisé le concept :
- Chaos Monkey : Tue instances EC2 random
- Latency Monkey : Ajoute latence réseau
- Chaos Kong : Tue une région AWS entière
Résultat : Netflix peut perdre une région entière sans impact utilisateur.
Commencer simple : GameDays
Qu’est-ce qu’un GameDay ?
Exercice planifié où on simule des incidents.
Format (2-3 heures) :
Planning (30min)
- Équipe complète réunie
- Scénario annoncé : “On va tuer la DB principale”
- Métriques à observer définies
Execution (1h)
- Injecter la failure
- Observer comportement système
- Noter surprises/bugs
Debrief (1h)
- Qu’est-ce qui a cassé ?
- Qu’est-ce qui a bien marché ?
- Actions correctives
Exemple GameDay réel
Scénario : Service “Recommendations” crash
# 10h00 : Baseline metrics
curl /metrics | grep recommendation_calls
# → 1200 req/min, 0.2% errors
# 10h15 : Kill service
kubectl delete pod recommendations-xxx
# 10h16 : Observer
# ❌ Erreur 500 sur homepage
# ❌ Checkout bloqué (depend on reco)
# ❌ Pas de fallback
# 10h20 : Fix temporaire
# Activer feature flag: recommendations-disabled
# 10h25 : System recovered
# Homepage : OK (sans reco)
# Checkout : OK (reco non-bloquante)
Découvertes :
- Checkout dépend de Reco (pas documenté)
- Pas de fallback si Reco down
- Circuit breaker mal configuré
Actions :
- Ajouter fallback vide []
- Fix circuit breaker (timeout 2s → 500ms)
- Découpler checkout de reco
Outils Chaos Engineering
1. Chaos Mesh (Kubernetes)
# Tuer 50% des pods random
apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
name: kill-pods
spec:
action: pod-kill
mode: percentage
value: "50"
selector:
namespaces:
- production
labelSelectors:
app: web-api
scheduler:
cron: "@every 1h"
Installation :
helm install chaos-mesh chaos-mesh/chaos-mesh
2. Gremlin (SaaS)
# Ajouter latency réseau
gremlin attack-network create \
--target-type host \
--target-tags "env:prod,service:api" \
--delay 300ms \
--duration 300s
Pros : Interface GUI, facile Cons : Payant ($$$)
3. Litmus (Open Source)
# Chaos workflow
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
name: api-chaos
spec:
experiments:
- name: pod-delete
spec:
components:
env:
- name: TOTAL_CHAOS_DURATION
value: "60"
Scénarios de Chaos courants
1. Pod/Instance Failure
# Tuer un pod au hasard
kubectl delete pod -l app=api --random
# Observer :
# - Auto-scaling fonctionne ?
# - Load balancer retire pod ?
# - Users impactés ?
2. Network Latency
# Ajouter 500ms latency
tc qdisc add dev eth0 root netem delay 500ms
# Observer :
# - Timeouts configurés ?
# - Circuit breakers activés ?
# - UX dégradée gracefully ?
3. Database Failure
# Killer DB primary
kubectl delete pod postgres-primary
# Observer :
# - Failover automatique ?
# - Readonly mode activé ?
# - Queues temporaires ?
4. Dependency Failure
# Service externe down (Stripe, SendGrid)
# → Mock 500 errors
# Observer :
# - Circuit breaker ?
# - Retry logic ?
# - Fallback ?
5. Resource Exhaustion
# CPU stress
apiVersion: chaos-mesh.org/v1alpha1
kind: StressChaos
metadata:
name: cpu-stress
spec:
mode: one
selector:
namespaces:
- production
stressors:
cpu:
workers: 4
load: 100
Progression : Du simple au complexe
Niveau 1 : GameDays planifiés (Mois 1-2)
- 1 GameDay/mois
- Scénarios simples (kill 1 pod)
- Environnement staging
- Équipe complète présente
Niveau 2 : Chaos automatisé non-prod (Mois 3-4)
# Cron job chaos staging
schedule: "0 10 * * MON" # Tous les lundis 10h
scenarios:
- pod-kill
- network-latency
Niveau 3 : Chaos automatisé prod (Mois 5-6)
# Chaos en prod avec safeguards
schedule: "0 14 * * TUE,THU" # Mardi/jeudi 14h
safeguards:
- error_rate < 0.5%
- on_call_available: true
- no_ongoing_incident: true
Niveau 4 : Continuous Chaos (Mois 7+)
Chaos 24/7 en prod
- Scenarios aléatoires
- Abort si SLI violated
- Auto-remediation
Résultat : Prod vraiment antifragile.
Cas réel : Notre migration
Situation initiale
- 0 Chaos Engineering
- 4-5 incidents/mois
- MTTR : 2-3 heures
- “On hope it works”
Après 6 mois de Chaos
Mois 1-2 : GameDays staging
- Découvert : 12 single points of failure
- Fixé : 8/12
Mois 3-4 : Chaos auto staging
- Découvert : Circuit breakers mal configurés
- Découvert : Timeouts trop longs (30s!)
Mois 5-6 : Chaos auto prod
- Premier GameDay prod : 😱 checkout cassé
- Fixé avant incident réel
Résultats (6 mois) :
- Incidents : 4/mois → 0.5/mois (-87%)
- MTTR : 2h → 15min (-87%)
- Confidence : 3/10 → 9/10
Conclusion
Chaos Engineering n’est pas de la destruction pour le fun.
C’est de l’assurance :
- Tester résilience avant incidents réels
- Découvrir faiblesses en conditions contrôlées
- Build confidence équipe et système
Commencer petit :
- GameDay staging (1 scénario simple)
- Fixer ce qui casse
- Répéter jusqu’à confiance
- Progresser vers prod
En 6 mois : Système vraiment résilient.
Et vous, prêts à casser votre prod ?