Imaginé par Netflix quand l’entreprise a basculé de la distribution de DVD à la construction de systèmes clouds distribués pour la diffusion de vidéo en continu, Chaos Monkey a introduit un principe d'ingénierie adopté par les éditeurs de logiciels de tout type et de toute taille : casser intentionnellement les systèmes pour apprendre à les rendre plus résilients. Dans le premier message de blog de Netflix sur le sujet, publié en juillet 2011 par Yury Izrailevsky, alors directeur de l'infrastructure des systèmes et du cloud, et Ariel Tseitlin, directeur des solutions cloud de l’entreprise de streaming, Chaos Monkey a été conçu pour désactiver de manière aléatoire les instances de production sur son infrastructure Amazon Web Services, et mettre en évidence des faiblesses que les ingénieurs de Netflix pourraient supprimer en construisant de meilleurs mécanismes de récupération automatique.

Le nom très imagé de Chaos Monkey, explicité par le message du blog, est censé traduire le scénario suivant : « Un singe sauvage lâché dans un datacenter ou un cloud, qui, avec une arme mettrait aléatoirement hors d’état des instances, l’objectif étant de continuer à servir ses clients sans interruption ». En pratique, le processus impliquerait une simple application « qui choisirait une instance au hasard dans chaque noeud, et à un moment donné, pendant les heures d’activité, la mettrait en panne sans avertissement. Et cela, tous les jours », comme l'ont expliqué Nora Jones et Casey Rosenthal, deux anciens ingénieurs de Netflix, dans leur livre très complet sur le sujet, « Chaos Engineering », publié par O'Reilly Media. L'idée est qu'en découvrant où se trouvent les points faibles, les équipes IT peuvent mettre en place des alertes automatiques pour résoudre un problème, ce qui leur évitera d'être appelés au milieu de la nuit au cas où quelque chose devait mal tourner. Depuis, Chaos Monkey a évolué, donnant lieu à diverses mises en œuvre regroupées sous le terme d'ingénierie du chaos.

Chaos Monkey évolue et s’automatise

Chaos Monkey est né des efforts d'ingénierie menés par Netflix autour de l’année 2010. A l’époque, Greg Orzell - désormais chez GitHub, propriété de Microsoft - avait eu pour mission de renforcer la résilience de la récente architecture cloud de l’entreprise. « Quand je pense à Chaos Monkey, je ne me dis pas que c’est un exploit d'ingénierie », a déclaré Greg Orzell à nos confrères d’InfoWorld. « Ce que l’outil a surtout apporté, c’est un changement de mentalité, indispensable à l’époque, quand Netflix est passé de la distribution de DVD à la diffusion vidéo en continu sur Internet ».

Au tout début, les ingénieurs de Netflix ont provoqué toute une série de pannes et de problèmes dans les systèmes en utilisant la Simian Army composée d'outils open source, chacun prenant en compte certains types de pannes, à commencer par Chaos Monkey. Ce dernier était chargé de provoquer des pannes dans les clusters AWS. Elle comprenait aussi des outils comme Latency Monkey, qui provoquait des retards artificiels dans la couche de communication client-serveur RESTful, et Doctor Monkey, qui exploitait les contrôles de santé effectués sur chaque instance, plus des contrôleurs qui surveillaient d'autres signes extérieurs de santé (la charge du processeur par exemple) pour détecter les instances peu performantes et les retirer du service si nécessaire.

Chaos Kong a fait passer Chaos Monkey à un niveau supérieur en simulant une panne dans toute une zone de disponibilité d’AWS. « Il est très rare qu'une région AWS devienne indisponible, mais cela arrive », faisait remarquer Netflix dans un article de blog datant de 2015. « En réalisant des simulations régulières de panne régionale, nous avons pu identifier rapidement les faiblesses du système et les corriger », poursuivait ce même post. « Le jour où la région US-EAST-1 est devenue indisponible, notre système était déjà assez puissant pour gérer un basculement de trafic ». Comme Nora Jones et Casey Rosenthal le soulignent dans leur livre, l’introduction de Chaos Kong dans l'infrastructure se transformait « en aventure intense, avec une salle de guerre pour surveiller tous les aspects du service de streaming, et cela, pendant des heures ».

Deux ans plus tard, en juillet 2017, Netflix a introduit ChAP (Chaos Automation Platform), une plateforme d'automatisation du chaos qui « interroge le pipeline de déploiement d’un service spécifié par l'utilisateur ». La plateforme lance ensuite des tests et des contrôles sur les clusters, et achemine une petite quantité de trafic vers chacun d'eux », indique encore le blog.

Principes de l'ingénierie du chaos

Les pratiques de base de Chaos Monkey ont rapidement évolué, avec des déploiements de plus en plus importants à travers Chaos Kong, pour devenir ce qui a été plus tard formalisé sous le nom d'ingénierie du chaos. Netflix n'a pas mis en place sa propre équipe d'ingénierie du chaos avant 2015. Cette équipe était dirigée par Bruce Wong, aujourd'hui directeur de l'ingénierie chez Stitch Fix. Les principes de l'ingénierie du chaos ont été formellement décrits par certains des auteurs à l’origine de Chaos Monkey. Selon leur définition, cette discipline « consiste à expérimenter sur un système des conditions de production instables, afin de renforcer la confiance dans la capacité du système à résister ».

En pratique, le processus comporte quatre étapes :

- Définir « l'état stable » d'un système pour avoir une référence de comportement normal.

- Supposer que cet état d'équilibre sera maintenu par le groupe chargé du contrôle et le groupe chargé de l’expérimentation.

- Introduire des variables qui reflètent les événements du monde réel, par exemple des pannes de serveurs, des dysfonctionnements de disques durs ou des interruptions dans les connexions réseau.

- Essayer d’infirmer l'hypothèse en cherchant une différence entre le groupe chargé du contrôle et le groupe chargé de l’expérimentation.

Si l'état stable est difficile à perturber, c’est que le système est robuste. Par contre, s'il y a une faiblesse, c’est qu’il y a quelque chose à corriger. « Au cours des cinq années qui ont suivi la publication des « Principes », l'ingénierie du chaos a évolué pour relever les nouveaux défis des nouvelles industries », notent Nora Jones et Casey Rosenthal. « Les principes et les fondements de la pratique continueront certainement à évoluer à mesure de l'adoption de l’ingénierie du chaos dans l'industrie du logiciel et dans de nouveaux secteurs verticaux ».

Mise en œuvre de Chaos Monkey

Pour exécuter la version open source de Chaos Monkey, les systèmes doivent répondre à un certain nombre de conditions préalables, comme indiqué sur GitHub. Chaos Monkey ne fonctionne pas comme un service. Il faut donc configurer une tâche Cron, comme indiqué sur la page GitHub, qui appellera ensuite Chaos Monkey une fois par jour de la semaine pour créer un calendrier des arrêts. Pour utiliser cette version de Chaos Monkey, il faut utiliser la propre plate-forme open source, de livraison continue (CD) Spinnaker de Netflix, ce qui peut limiter la capacité de certaines entreprises à adopter la méthode. Chaos Monkey nécessite également une base de données compatible MySQL version 5.6 ou ultérieure. Les propriétaires de services définissent leurs configurations de Chaos Monkey via Spinnaker. Chaos Monkey fonctionne via Spinnaker pour obtenir des informations sur la façon dont les services sont déployés et stoppe les instances - machines virtuelles ou conteneurs - au hasard, selon une fréquence et un calendrier spécifié par chacun.

Bien sûr, la mise en œuvre de Chaos Monkey ne représente que le début de la tâche ardue et complexe de résolution des problèmes de résilience du système. Chaos Monkey ne fait que découvrir les faiblesses du système ; c'est aux équipes devops ou aux équipes d'ingénieurs système d'en identifier les causes et de proposer des solutions. Comme l’a déclaré M. Orzell, « l’outil en lui-même n'est pas coûteux, mais l'investissement qu’il faudra faire pour réagir à l’outil l'est ». S'engager dans l'ingénierie du chaos nécessite également une réaffectation des ressources, pour les consacrer au renforcement de la résilience plutôt qu’’au développement de nouvelles fonctionnalités. « Chaque entreprise se trouve à un niveau de résilience différent et chacune doit décider de la répartition de ses ressources en conséquence », a-t-il ajouté.

Nora Jones et Casey Rosenthal affirment qu'au début, les ingénieurs de Netflix « avaient été très encouragés par les institutions financières ». Même si les banques doivent faire face à des enjeux plus élevés, elles ont quand même subi des pannes, et beaucoup ont changé d'avis sur la mise en œuvre d’une « stratégie proactive comme l'ingénierie du chaos pour comprendre les risques et éviter des défaillances importantes et incontrôlés ». Capital One a été l'un des premiers à l'avoir adopté, comme le précise leur livre.

Ressources pour l'ingénierie du chaos

Le dernier livre en date sur le sujet est « Chaos Engineering », écrit par les anciens ingénieurs de Netflix, Nora Jones et Casey Rosenthal. Publié en avril 2020, l’ouvrage s'appuie en grande partie sur les travaux que ces auteurs, et d'autres, ont compilés dans le livre « Chaos Engineering » sorti en 2017. L'ouvrage « Learning Chaos Engineering » de Russ Miles donne un aperçu plus pratique sur le sujet. Netflix fournit également une multitude de ressources sur le sujet sur GitHub, dont un tutoriel, beaucoup de documentation, un compteur d'erreurs, un vérificateur de pannes et des outils de décryptage. Gremlin - un fournisseur d'outils commerciaux pour réaliser des tests d'ingénierie du chaos - propose un ensemble très complet de ressources, disponibles gratuitement en ligne et au format PDF. L’entreprise soutient également plusieurs efforts communautaires, notamment Chaos Conf et un canal Slack. L’éditeur O'Reilly propose également un grand nombre de ressources, dont une liste très pratique de livres et de vidéos sur le sujet.