Chaos engineering : casser pour de vrai, mais pas n'importe comment

En 2018, la même année que ma découverte des douze facteurs, je tombe sur le chaos engineering (je serais bien incapable de retrouver les billets de blog exacts qui m’y mènent. C’est d’ailleurs une bonne raison de revenir aux sources plutôt qu’à mon souvenir): la définition et les principes tiennent dans un seul document, qui dit mieux ce que je finis par pratiquer que mes propres reformulations.

Ce n’est pas casser des trucs

Le contresens le plus courant consiste à croire qu’il suffit de redémarrer une machine en production pour faire du chaos engineering, ce qui confond une méthode et un incident: casser au hasard, c’est un incident qu’on n’a pas su éviter, pas une expérience. Le chaos engineering est une discipline d’expérimentation, avec un état stable défini et mesuré, une hypothèse sur sa persistance, une perturbation réaliste injectée et une comparaison rigoureuse (sans état stable mesurable, il n’y a pas d’expérience, il n’y a qu’une panne).

D’où ça vient

La pratique naît chez Netflix, qui publie Chaos Monkey en 2011 dans le cadre de son Simian Army, sous l’impulsion de son architecte cloud de l’époque, Adrian Cockcroft. L’idée est simple et inconfortable: puisque les instances meurent de toute façon, on va tuer les nôtres nous-mêmes, en continu, pour que personne ne s’en aperçoive. La discipline reçoit son nom et ses principes formels au milieu des années 2010, dans le document collectif Principles of Chaos Engineering . L’éditeur Gremlin a fini d’installer le terme dans le vocabulaire.

[edit: 2020] Le livre O’Reilly de Casey Rosenthal et Nora Jones est venu depuis compléter la référence.

Les quatre étapes d’une expérience

Une expérience suit quatre temps: on définit l’état stable par une sortie mesurable, débit, taux d’erreur ou centiles de latence; on formule l’hypothèse que cet état persiste dans le groupe témoin et dans le groupe perturbé; on injecte des variables qui reflètent des événements réels, un serveur qui tombe, un disque qui lâche, une connexion réseau qu’on coupe; puis on cherche à réfuter l’hypothèse, en comparant l’état stable des deux groupes. Plus il est difficile de perturber l’état stable, plus la confiance dans le système est grande.

Les cinq principes avancés

Cinq principes encadrent l’idéal: construire l’hypothèse autour du comportement de l’état stable plutôt que des attributs internes du système; varier des événements réalistes, matériels ou logiciels, pannes comme pics de charge; exécuter les expériences en production, parce que c’est le seul endroit où le trafic réel circule; automatiser et répéter en continu, car une expérience manuelle n’est pas tenable; borner enfin le rayon d’impact, parce qu’expérimenter en production oblige à contenir les dégâts (ce dernier principe est celui qui sépare la méthode de l’irresponsabilité).

Le chaos chez soi

Tout cela part de loin: l’expérimentation en production à grande échelle, comme le Netflix de 2011 la pratiquait, ce n’est pas le quotidien d’une infrastructure modeste. L’adaptation demande un peu d’honnêteté. La première chose à abandonner, c’est l’expérimentation en production quand on n’a pas de marge: sur un Swarm qui porte des services réels, on commence par la recette. On ne monte en production qu’après avoir borné le rayon d’impact. Les expériences utiles sont souvent les plus petites: tuer une réplique pour vérifier qu’un service redémarre et que la sonde de disponibilité le voit, injecter quelques centaines de millisecondes de latence, remplir un disque de Proxmox pour voir ce qui tombe en premier. Une partie du chaos, d’ailleurs, je la pratique déjà sans la nommer: un service qui ne tourne qu’à la demande est en permanence soumis à une expérience de démarrage à froid. Chaque incident documenté dans un post-mortem est une hypothèse réfutée qui aurait pu être testée à froid.

Les outils

Je m’en tiens à ce que je peux lire et comprendre, à des briques séparables. Chaos Monkey reste la référence historique côté AWS, LitmusChaos vise Kubernetes, Gremlin propose la même chose en service, Pumba couvre Docker et Compose, puis toxiproxy simule un proxy défaillant pour tester les timeouts. Mon avis tient en une ligne: tant que le rayon d’impact n’est pas borné, l’outil n’est qu’un bouton de plus.

[edit: 2019] Chaos Mesh est venu depuis occuper la même place dans l’écosystème Kubernetes.

Le lien avec R.A.C.H.E et les post-mortems

Il y a une ironie que j’aime à la RACHE: la méthode satirique affirme qu’un système est en fonctionnement quand il est instable et proche de la panne. Le chaos engineering dit exactement la même chose, mais en refusant le hasard: on choisit le moment, la nature et l’ampleur de la secousse au lieu d’attendre qu’elle vienne toute seule. Un post-mortem et une expérience de chaos sont les deux faces du même geste, l’un reconstruit après coup ce que l’autre provoque exprès. Côté Twelve-Factor , tout commence par la disposabilité.

Verdict

Je ne conseille pas le chaos engineering à qui n’a ni une vraie observabilité, ni des infra plutôt bien automatisées et industrialisées: sans ces deux prérequis, l’expérience dégénère en panne surprise. À qui a les deux, en revanche, je le conseille avant que la production ne se charge de la démonstration. On ne gagne pas en casant, on gagne en sachant à l’avance comment ça casse.