Un plan de reprise rangé dans un wiki, validé en réunion, signé par la DSI, et jamais déclenché. Ce n'est pas un plan. C'est un espoir avec une mise en page. Le jour où le disque lâche à 3 h du matin, vous découvrez que le runbook référence une IP qui a changé, que la réplique n'avait pas rattrapé son retard, et que personne ne sait quel ordre de redémarrage respecter. Le chaos engineering existe pour éviter exactement ça : provoquer la panne quand vous êtes prêt, plutôt que de la subir quand vous ne l'êtes pas.
L'idée vient de Netflix, qui a fini par lâcher des pannes en continu sur sa propre production parce que c'était la seule façon de faire confiance à sa résilience. Pas une démarche de cow-boy : une méthode, avec une hypothèse, un périmètre, des métriques. On casse pour apprendre, pas pour le sport.
Un PRA non testé est une fiction
Sur le terrain, voici ce qu'on voit chez les audités. La sauvegarde tourne, le voyant est vert, le rapport quotidien arrive par mail. Personne n'a restauré depuis huit mois. Le jour de l'incident, la restauration échoue parce que la rétention avait silencieusement débordé, ou parce que la clé de chiffrement vivait sur le serveur disparu. Le PRA a toujours un point de défaillance qu'on ne voit pas tant qu'on ne le déclenche pas.
Le raisonnement classique consiste à valider sur le papier. On dessine l'architecture active-passive, on calcule un RTO théorique, on coche la case. Le problème : le RTO théorique suppose que la détection marche, que le basculement DNS se propage, que la base secondaire est cohérente, que l'équipe sait quoi faire. Quatre hypothèses, quatre endroits où ça casse en vrai. Si vous lisez encore comment structurer un plan de reprise d'activité qui tient, retenez surtout sa dernière ligne : la vraie résilience, c'est celle qu'on a testée.
Le chaos engineering transforme ces hypothèses en expériences. Au lieu de croire que le système survit à la perte d'un nœud, on tue le nœud et on regarde. La réponse est binaire, et elle n'est pas négociable.
Les cinq principes, pas le folklore
Le manifeste fondateur (principlesofchaos.org) pose une discipline, pas une autorisation de tout péter. Cinq points structurent chaque expérience.
D'abord, définir l'état stable mesurable. Pas une impression. Une métrique business observable : commandes par seconde, taux de succès des requêtes, latence p99. Si vous ne savez pas mesurer que le système va bien, vous ne saurez pas mesurer qu'il va mal. Côté ops, cette métrique sort de la supervision existante, c'est elle qui dira si l'hypothèse tient.
Ensuite, formuler une hypothèse sur cet état stable. La formule est toujours la même : « quand j'injecte telle panne, l'état stable se maintient ». Exemple concret : « si je tue un pod sur trois de l'API de paiement, le taux de succès reste au-dessus de 99,5 % grâce au load balancing et aux deux pods restants ». L'expérience valide ou casse cette phrase précise.
Troisième principe, varier les événements du monde réel. On injecte ce qui arrive vraiment : crash de machine, latence réseau, disque plein, perte d'une zone de disponibilité, dépendance externe qui répond en erreur 500. Pas des scénarios exotiques. Les pannes ordinaires sont déjà celles qui font tomber la prod.
Quatrième, faire tourner en production. C'est le principe inconfortable, et le plus important. Un environnement de staging ne reproduit jamais la charge réelle, les vrais flux, les vrais voisins bruyants. La résilience qu'on veut prouver, c'est celle de la prod, donc on la teste en prod. Avec un garde-fou : le rayon d'explosion.
Cinquième, minimiser et contenir ce rayon d'explosion. On commence sur 1 % du trafic, un seul nœud, une seule zone. On garde un bouton d'arrêt qui coupe l'expérience en une commande. On augmente seulement quand le palier précédent a tenu. La règle qu'on applique : jamais une expérience dont on ne sait pas comment l'arrêter en dix secondes.
Ce qu'on injecte concrètement
Les types d'injection couvrent les couches où ça casse réellement.
Au niveau orchestrateur, on tue des pods ou des conteneurs, on en supprime aléatoirement pendant que le trafic tourne. C'est le test du « est-ce que mon déploiement encaisse vraiment la perte d'une réplique », et la réponse surprend souvent. Un replicas: 3 ne sert à rien si les trois pods sont schédulés sur le même nœud.
Au niveau réseau, on ajoute de la latence et on provoque de la perte de paquets. Cinq cents millisecondes de délai sur l'appel à la base, 10 % de paquets perdus vers un service tiers. C'est là qu'on découvre les timeouts mal réglés, les retries qui amplifient la panne au lieu de l'absorber, les circuit breakers absents. La latence injectée révèle des cascades qu'aucune revue de code ne voit.
Au niveau ressources, on sature : CPU à fond, I/O disque étranglées, mémoire mangée. On vérifie que la supervision alerte, que l'autoscaling réagit, que les autres processus survivent à un voisin gourmand.
Au niveau infrastructure, on coupe une zone entière. C'est le test grandeur nature du multi-site : on éteint Toulouse et on regarde si Bordeaux prend la charge sans intervention humaine, dans le RTO annoncé. Pour qui opère sur deux sites distants, c'est l'expérience qui valide ou détruit la promesse de résilience géographique. La nôtre passe par une réplication à plus de 200 km et un failover qu'on rejoue, pas qu'on suppose.
Chaos Mesh, LitmusChaos, et le pionnier
L'outillage s'est standardisé autour de Kubernetes, parce que c'est là que vivent la plupart des charges modernes.
Chaos Mesh (chaos-mesh.org), projet CNCF, injecte les pannes via des ressources Kubernetes déclaratives. On décrit un PodChaos, un NetworkChaos, un IOChaos en YAML, on l'applique, l'expérience tourne dans le périmètre défini. Un exemple de définition qui tue la moitié des pods d'un namespace toutes les minutes :
apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
name: kill-half-payment-pods
namespace: chaos-testing
spec:
action: pod-kill
mode: fixed-percent
value: '50'
selector:
namespaces:
- payment
scheduler:
cron: '@every 1m'
LitmusChaos (litmuschaos.io), aussi sous la CNCF, vise la même cible avec un hub d'expériences prêtes à l'emploi et une orchestration de scénarios enchaînés. Le choix entre les deux relève surtout de l'écosystème et du goût, pas d'un écart fonctionnel décisif.
Le pionnier reste Chaos Monkey (github.com/Netflix/chaosmonkey), qui tue des instances en production, intégré au pipeline de déploiement Netflix. Il fonctionne avec tout backend supporté par Spinnaker, Kubernetes compris, mais reste couplé à Spinnaker, ce qui le rend lourd à adopter hors de cet écosystème. C'est pourtant lui qui a posé l'idée fondatrice : si vous ne pouvez pas survivre à la mort aléatoire d'une instance, vous n'êtes pas résilient, vous avez juste eu de la chance.
En dehors de ces outils, le réseau se casse très bien à la main avec tc. Ajouter 200 ms de latence sur une interface tient en une ligne :
tc qdisc add dev eth0 root netem delay 200ms
Pas besoin d'une plateforme pour commencer. Un cron, un pkill, un tc, et déjà vous apprenez des choses.
Le game day, là où l'humain est testé
L'outil casse la machine. Le game day teste l'organisation. On planifie une session, on réunit les équipes ops et dev, on annonce un scénario, et on déclenche une panne réelle en conditions contrôlées. L'objectif n'est pas seulement de voir si le système tient, mais si les humains savent réagir : qui regarde quel dashboard, qui décide du basculement, qui communique, où est le runbook et est-il à jour.
Le game day révèle les défaillances que l'automatisation ne voit pas. Le runbook qui pointe vers une console qui n'existe plus. L'astreinte qui n'a pas les accès. La décision de bascule qui attend une validation d'un manager injoignable. Ces frictions coûtent les minutes qui transforment un incident en sinistre, et seul un exercice grandeur nature les fait remonter. Un game day raté en interne vaut mille fois mieux qu'un vrai incident raté devant le client.
C'est aussi le moment de rejouer un plan de réponse à incident de bout en bout, pendant que tout le monde est calme et prévenu, plutôt que de le découvrir sous adrénaline.
Boucler avec les SLO et les postmortems
Le chaos engineering ne vit pas isolé. Il s'articule avec deux pratiques.
Les SLO d'abord. L'état stable d'une expérience, c'est un SLI mesuré contre son SLO. Si votre objectif est 99,9 % de requêtes réussies, l'expérience vérifie que l'injection ne fait pas franchir ce seuil, et l'écart consommé se compte sur le budget d'erreur. Le chaos engineering devient alors la façon de dépenser volontairement un peu de budget pour acheter de la confiance, plutôt que de le perdre subitement lors d'un vrai incident. Le lien entre SLI, SLO et budget d'erreur donne le cadre chiffré qui rend les expériences décidables.
Les postmortems ensuite. Chaque expérience qui casse l'hypothèse produit un apprentissage, et cet apprentissage se traite comme un incident réel : analyse de cause racine, action corrective, sans chercher un coupable. La doctrine du postmortem sans blâme de Google (sre.google) s'applique mot pour mot. On documente ce qui a cassé, on corrige l'architecture, on rejoue l'expérience jusqu'à ce qu'elle tienne. Une culture du postmortem saine transforme chaque chaos raté en résilience gagnée, au lieu d'un dossier qu'on enterre.
Et tout ça suppose une base saine : si vos charges critiques tournent sur Kubernetes, la résilience commence par un cluster Kubernetes en haute disponibilité correctement configuré, sinon le chaos ne fait que confirmer ce que vous redoutiez.
Verdict ops
Un PRA qui marche, ça n'existe pas. Ce qui existe, c'est un PRA qui a marché, la dernière fois qu'on l'a déclenché pour de vrai. Tout le reste relève de la croyance, et la croyance ne redémarre pas une base de production à 3 h du matin.
Le chaos engineering n'est pas une lubie de géant du web. C'est la seule méthode qui transforme une hypothèse de résilience en fait prouvé. Commencez petit : un pod tué en staging, puis en prod sur 1 % du trafic, un game day par trimestre. Augmentez le rayon d'explosion à mesure que la confiance monte. Le jour de la vraie panne, vous ne découvrirez rien, parce que vous l'aurez déjà vécue.
Quand un audit révèle un PRA jamais déclenché, on ne signe pas un document de plus. On organise le game day, on injecte la panne, on mesure le vrai RTO, on corrige ce qui casse, et on contractualise ce qui tient. C'est notre façon d'exploiter la résilience plutôt que de la postuler. Si votre PRA n'a jamais affronté une vraie panne, on peut le mettre à l'épreuve et le hisser au niveau.
Sources
- Principles of Chaos Engineering : le manifeste fondateur, les cinq principes de l'expérimentation contrôlée en production.
- Chaos Mesh : plateforme CNCF d'injection de pannes déclarative sur Kubernetes (pod, réseau, I/O).
- LitmusChaos : framework CNCF de chaos engineering avec hub d'expériences et orchestration de scénarios.
- Netflix Chaos Monkey : l'outil pionnier qui tue des instances en production, intégré au pipeline Netflix.
- Google SRE Book, Embracing Risk : le cadre error budget qui relie fiabilité, SLO et prise de risque maîtrisée.
- Google SRE Book, Postmortem Culture : la doctrine du postmortem sans blâme, à appliquer à chaque expérience ratée.
