Chaos engineering du quotidien : apprendre à aimer la vague

Arrêter de subir l’imprévu : transformer les incidents ordinaires en apprentissage continu grâce à une pratique légère de chaos engineering, connectée à l’observabilité et au delivery.

Nous rêvons tous d’un système stable, prévisible, “calme”. Et pourtant, la réalité d’une plateforme moderne, c’est une mer vivante : déploiements, dépendances externes, quotas cloud, réseaux capricieux, pics de charge, erreurs humaines, et parfois… juste “un truc” qui n’aurait pas dû arriver.

Le chaos engineering est souvent présenté comme une discipline spectaculaire — “on coupe une zone AWS”, “on tue un cluster”, “on fait tomber Kafka”. Dans la vraie vie (et surtout en petite équipe), ce n’est ni nécessaire, ni souhaitable au départ.

La bonne porte d’entrée, c’est le chaos engineering du quotidien : une pratique légère, régulière, intégrée au delivery, qui transforme les incidents ordinaires en apprentissage continu.

Bienvenue dans la vague.

I. L’objectif n’est pas de casser. C’est de comprendre.  

Le chaos engineering n’est pas un concours de destruction. C’est une méthode pour répondre à une question très simple :

Quand le système vacille, qu’est-ce qui se passe vraiment, et est-ce que notre système se remet comme on l’ imagine ?

La différence, entre une organisation qui subit et une autre qui progresse, est rarement “plus de procédures”. C’est plutôt :

• des hypothèses explicites
• des signaux observables
• des expériences répétables
• et surtout : un apprentissage qui se fixe dans le système (code, config, runbooks, alerting, tests)

II. La vague existe déjà : nous la subissons tous les jours  

Nous faisons déjà du chaos engineering… mais en mode accidentel :

• Un pod meurt en prod
• Une latence qui explose parce qu’un service en aval rame
• Un déploiement qui passe en staging mais pas en prod (données, trafic, config)
• Une limite API qui arrive “sans prévenir”
• Un disque qui se remplit (logs, traces, cache)
• Un certificat qui expire le vendredi soir

Le chaos engineering du quotidien consiste à prendre ces événements et à en faire des expériences intentionnelles.

III. La boucle : Hypothèse → Expérience → Mesure → Amélioration  

Une pratique efficace tient dans une boucle simple.

Étape A — Formuler une hypothèse  

Exemples :

• “Si un pod est tué, le trafic bascule sans erreur utilisateur.”
• “Si la DB répond en 800ms au lieu de 20ms, on dégrade proprement.”
• “Si le cache Redis est indisponible, on continue en mode dégradé.”
• “Si Kafka est en retard, le système reste stable (pas d’emballement).”

Étape B — Choisir une expérience petite  

Le quotidien = des expériences à faible rayon d’impact :

• tuer un pod (pas toute une zone)
• injecter de la latence sur une route (pas partout)
• simuler un HTTP 429 sur un client (pas couper Internet)
• réduire la ressource CPU d’un déploiement (pour tester les limites)
• fermer volontairement un feature flag qui force le fallback

Étape C — Mesurer avec des signaux concrets  

Pas de chaos engineering sans observabilité. Tu veux des métriques qui disent la vérité :

• SLO / taux d’erreur côté utilisateur (4xx/5xx, timeouts)
• latence P95/P99
• saturation (CPU throttling, mémoire, queue length, lag)
• taux de retries / circuit breaker ouvert
• durée de recovery (MTTR sur ce scénario)

Étape D — Fixer l’apprentissage  

C’est là que la valeur se crée :

• un timeout mieux calibré
• un retry avec backoff + jitter
• un circuit breaker
• une limite de concurrence
• une alerte plus pertinente
• un runbook qui tient en 10 lignes
• un test qui empêche la régression

IV. Les 7 expériences “quotidiennes” à faire en premier  

Voici une base que presque toutes les équipes peuvent faire, même avec peu de temps.

1. Tuer un pod “au hasard” Hypothèse : autoscaling + readiness + load balancer assurent.

• Métriques : erreurs, latence, durée de retour à la normale

2. Injecter 300–800ms de latence sur une dépendance Hypothèse : timeouts/réessais ne créent pas d’emballement.

• Métriques : retries, saturation, p99, erreurs

3. Simuler une dépendance qui renvoie 429 / 503 Hypothèse : backoff + fallback évitent l’effet “DDoS involontaire”.

• Métriques : taux de requêtes, erreurs, circuit breaker

4. Désactiver le cache (ou le rendre “lent”) Hypothèse : le système reste stable sans cache.

• Métriques : DB load, latence, saturation

5. Réduire les ressources CPU/mémoire Hypothèse : le service se dégrade proprement, pas en cascade.

• Métriques : throttling, OOM, restarts, erreurs

6. Rendre la file/queue “en retard” Hypothèse : le lag augmente mais reste sous contrôle.

• Métriques : lag, durée de traitement, backlog

7. Tester un redéploiement “au mauvais moment” Hypothèse : rollout + probes + budgets garantissent une stabilité minimale.

• Métriques : erreurs, disponibilité, durée du rollout, rollback time

V. Aimer la vague : ce que ça change dans la tête  

Le chaos engineering du quotidien nous fait passer de :

• “On va éviter que ça arrive” à
• “Quand ça arrive, on sait ce que ça fait, et on sait comment ça se répare”

Ce shift est énorme.

Parce que les systèmes distribués ne deviennent pas “fiables” par intention. Ils deviennent fiables par exposition répétée à la réalité + réparation structurée.

Nous ne pouvons pas supprimer l’incertitude. Nous pouvons la rendre familière.

VI. Les règles d’or pour ne pas se noyer  

Règle 1 — Jamais sans garde-fous  

Avant de lancer une expérience :

• fenêtre de temps courte
• rollback possible
• blast radius limité
• monitoring visible
• “stop condition” claire (ex : erreur utilisateur > X%)

Règle 2 — Une expérience = une hypothèse  

Si tu testes dix choses à la fois, tu n’apprends rien.

Règle 3 — La victoire, c’est l’amélioration, pas le “test réussi”  

Un chaos test “réussi” mais sans action derrière, ne sert à rien. Même une “bonne” résilience doit être capturée :

• dans les docs
• dans les dashboards
• dans la config
• dans les tests

Règle 4 — La fréquence vaut mieux que la violence  

Un petit exercice chaque semaine est mieux intégré qu’une grande démonstration par trimestre.

VII. Intégration au delivery : le vrai niveau “plateforme”  

L’idéal : que ces expériences deviennent des scénarios de confiance.

Tu peux viser une progression en 3 paliers :

Palier 1 — Manuel, guidé  

Une checklist, un runbook, et une session de 30 minutes.

Palier 2 — Reproductible  

Un script / job / workflow déclenchable :

• en staging
• puis en prod sur un scope contrôlé

Palier 3 — Continu  

Des expériences automatisées périodiques avec alerting :

• “si le test échoue, on crée un ticket”
• “si le SLO se dégrade, on stoppe”

À ce stade, le chaos engineering n’est plus un événement. C’est une propriété de ton système : il apprend.

Conclusion : on ne contrôle pas la mer, on apprend à naviguer  

Aimer la vague, ce n’est pas aimer l’incident. C’est aimer la progression qu’il permet quand tu le rends observable, intentionnel, et actionnable.

Le chaos engineering du quotidien, c’est :

• moins de surprise
• moins de panique
• plus de confiance
• et surtout : une équipe qui devient meilleure parce que le système la force à apprendre

La mer bougera toujours. Autant devenir bon en surf.

Mini-checklist (à copier dans ton repo)  

• Hypothèse formulée en une phrase
• En cas de problème, l’impact doit rester volontairement petit(Blast radius limité)
• Stop condition définie
• Dashboards ouverts
• Expérience lancée
• Résultat noté (attendu vs observé)
• Action décidée (code/config/doc/test)
• Suivi planifié (retest, date)