Chaos Engineering ou le stress ultime des applications et de l’infrastructure
Mener des tests particulièrement agressifs sur la plateforme de production, c'est le défi auquel sont désormais soumises les équipes DevOps des géants du Web. Car après tout, les tests de non régression, les tests de sécurité et les tests de charge, c'est le seul moyen de s'assurer que la production résistera au pire.
Le mouvement est né chez Netflix avant même que le spécialiste de la VOD ne migre son infrastructure chez Amazon Web Services (AWS) en 2008. Cette infrastructure informatique, entièrement bâtie sur des microservices est sans doute l'une des plus modernes au monde. Elle a certes été imaginée afin de faire face à la charge de millions d'abonnés. Mais cette infrastructure a aussi été conçue pour être résiliente et continuer à fonctionner quel que soit le nombre d'instances Amazon EC2 qui seraient amenées à disparaitre. Elle peut même faire face à l'arrêt de datacenters complets chez le prestataire Cloud, voire de régions géographiques entières (presque) sans broncher.
Atteindre un tel niveau de résilience n'a pas été simple. Et pour cela, l'Américain a inventé le « Chaos Engineering ». Cette approche consiste à générer des pannes volontairement dans l'architecture de production afin d'observer les conséquences de cette défaillance, in-situ. L'objectif de cette démarche est de prendre des mesures qui permettront de contrer l'éventuel effet papillon. Cet effet qui peut se manifester de manière imprévue sur la plateforme de production et qui n'a pu être détecté en pré-production.
C'est ainsi que l'Américain a développé une armée de petit automates qui déclenchent des pannes dans son architecture. Une armée de « singes », avec un premier qui va tuer une instance au hasard, un second qui va introduire des temps de latence anormaux dans les bus de données, dans les pools de connexions, un gorille qui va rayer de la carte un datacenter entier, voire une zone géographique dans son ensemble.
Le Chaos Monkey, une prise de risque réelle, mais nécessaire
Lancer une telle armée simiesque sur un système de production semble totalement fou, notamment pour les équipes d'exploitation qui luttent déjà au quotidien pour garantir la disponibilité et les performances des plateformes.
Pourtant, en dépit de cette prise de risque évidente, de plus en plus de géants du Web ont repris à leur compte cette démarche. Amazon, Microsoft et dernièrement OUI.sncf (nouveau nom de Voyages-SNCF) en sont adeptes. Christophe Rochefolle, Directeur Excellence Opérationnelle chez VSC Technologies (entité IT de Voyage-SNCF.com) explique le pourquoi de cette démarche : « Expérimenter en production : tout le monde pense l'idée folle et pourtant, c'est possible. Il s'agit d'expérimenter afin d'éprouver les systèmes et d’apprendre. » Alors que chaque minute de disponibilité du site Voyages-SNCF représente des milliers d'euros de chiffre d'affaires, l'idée de risquer volontairement le crash semble particulièrement imprudente. Le responsable prévient : « Evidemment, nous ne sommes pas fous. Nous n'expérimentons sur un système de production lorsqu'on considère qu'il est stable, lorsqu'il a atteint un niveau de résilience et de sécurité suffisant pour nous permettre de lancer le test.»
Pour Christophe Rochefolle, mettre en place une telle démarche implique de suivre quelques grands principes. Il faut d'une part commencer par déterminer la question à laquelle on cherche une réponse via le test. Cette question peut être par exemple : que se passe-t-il si je débranche tel ou tel serveur, si telle ou telle brique logicielle ne répond plus. Il convient alors de déterminer le périmètre du test et de mettre en place les dispositifs de mesure qui permettront de collecter toutes les données nécessaires à l'analyse de l'impact réel de la panne.
Dès lors, il faut lancer le singe sur le SI afin de déclencher la panne et analyser son impact pour consolider le système – en clair, agir sur les composants qui sont touchés. « Il est important d'expérimenter en continu. Comme l'a montré récemment l'épisode OVH, ils ont certainement fait tout ce qu'il faut pour assurer la résilience et la redondance des systèmes de leurs datacenters, mais entre-temps le système a changé. Tester en continu et en permanence permet de s'assurer que l'on va rester dans le niveau de résilience que l'on a souhaité atteindre », conclut Christophe Rochefolle.
Une communauté interne créée en 2016
C'est en 2015 que Voyages-SNCF a initié cette démarche de Chaos Engineering. Début 2016, un premier poc est lancé. "Nous l'avons fait avec une équipe restreinte sous la forme d'un mini-hackathon, composée de profils différents afin de voir comme cela se déroule », explique Benjamin Gakic, Expert Sûreté de Fonctionnement & facilitateur - VSC Technologies.
« Très vite, nous avons réussi à faire un kill -9 (cela arrête un processus, NDLR) sur l'infrastructure mais nous avons voulu aller au-delà et améliorer. Nous avons créé une communauté interne baptisée Résilience et Tests Techniques (RTT) afin de faire la promotion de la résilience dans les équipes, de proposer des outils et de l'aide à la mise en place. » C'est ainsi que cette communauté a constitué un bestiaire, non pas de singes comme Netflix et Amazon, mais de « minions » dont la vocation est de semer le chaos sur le site OUI.sncf. Un minion tue des processus tandis qu'un autre introduit des temps de latence, un autre sature les disques, plus sournois encore, un quatrième vient modifier les propriétés des composants. Enfin, un Monkey-Go permet d'automatiser l'activité de ces minons.
Néanmoins, lâcher des bombes logicielles dans l'informatique de Voyages-SNCF n'a pas été simple. Le site est le numéro 3 français en audience avec plus de 1 million de visiteurs uniques par jour. Chaque minute d'indisponibilité est du chiffre d'affaires perdu. « Cela demande un vrai travail de conviction en interne, reconnaît Benjamin Gakic. Nous avons réussi à mener le projet en mai 2017, quasiment un an et demi après avoir mené un premier PoC. La première exécution a été menée sur nos Shared Proxy, nos load balancers. Il n'y a eu que 4 requêtes en erreur, alors que ceux-ci traitent 3 000 requêtes par minute. Depuis, nous avons pris confiance et, d'ici la fin de l'année, nous visons à avoir au moins 5 applications qui tournent avec un Chaos Monkey régulier. »
Néanmoins, Benjamin Gakic souligne que le Chaos Monkey n'est pas un outil de test qui vient valider un nouveau développement dans un environnement bac à sable. « S'il se produit un effet papillon sur le Chaos Monkey, on peut se retrouver avec des effets très lourds, et la perte de paiements en bout de chaîne. On ne casse pas la production pour s'amuser, mais pour éprouver ce que l'on a mis en place et vérifier que cela marche bien. Enfin, il faut inscrire le Chaos Monkey dans une démarche. Ce n'est pas une opération One Shot. C'est une démarche qu'il faut adapter sous peine de passer complètement à côté de la démarche."
Des Gamedays permettent de sceller l'esprit "Chaos Monkey" dans les équipes
Pour promouvoir cette approche au sein de ses équipes de développement et surtout d'exploitation, un Gameday a été organisé. A travers cette compétition interne, 18 équipes en lice devaient trouver l'origine d'une série de pannes provoquées par les minions. Au lancement du projet, les exploitants avaient imaginé 43 pannes, mais seulement 8 ont été proposés lors des 240 minutes de jeu. Cette opération a été un vrai succès pour l'équipe projet, puisque 113 joueurs se sont inscrits au Gameday.
Si 2 pannes n'ont pas fonctionnée comme prévu, le taux de détection des 6 pannes effectivement jouées lors de la journée a été de 87%, le taux de diagnostic de 73% pour une résolution de 45% dans les temps impartis. Cela démontre que les pannes imaginées par les exploitants n'avaient rien de trivial. Un second Gameday a été organisé sur le même modèle le 7 juillet dernier - ce qui a scellé l'esprit Chaos Monkey dans les équipes Dev et Ops du site.
Outre une meilleure compréhension du travail des exploitants par les développeurs, cette démarche a permis à OUI.sncf de renforcer la résilience de son infrastructure de production à plusieurs niveaux. « Nous avons reproduit une panne qui était survenue il y a 5 ans, une panne que nous avons baptisée Irma », souligne Benjamin Gakic. « Il y a 5 ans, nous avions mis 1 heure pour la détecter et la résoudre. Cette année, elle l'a été en moins de 10 minutes. En termes de volume d'affaires que cela représente, c'est très significatif. » Une autre illustration de l'amélioration de la résilience le la production du site concerne sa dépendance vis-à-vis d'un partenaire jugé peu stable. « A chaque incident chez ce prestataire, nous perdions des sessions. La mise en place d'un circuit breaker nous a permis de réduire d'un facteur 40 l'impact de cette instabilité. Là encore, c'est très significatif », résume l'expert en sûreté de fonctionnement.
Désormais, le Chaos Monkey entre peu à peu dans les habitudes du site. Si au premier raid des minions sur le système d'information de Voyages-SNCF tout le monde était prévenu, ce n'est plus le cas aujourd'hui : « Désormais nous exécutons un Chaos Monkey chaque trimestre et on n'a plus de différence entre l'incident de production et le Chaos Monkey », confie Christophe Rochefolle. « Les exploitants ne sont plus informés qu'un Chaos Monkey est en cours. Par contre, il y a une trace que le Chaos Monkey est lancé. Mais nous ne les lançons pas les jours où nous réalisons 20 millions d'euros de chiffre d'affaires ! »
Aujourd'hui, les entreprises qui s'intéressent à cette approche sont encore celles qui sont les plus en avance en termes d'intégration continue et d'architectures avancées. Néanmoins, l'approche se formalise peu à peu. Spécialiste du test d'application, Sylvain Hellegouarch a codéveloppé un framework Open Source dédié au chaos engineering, le Chaos Toolkit. Celui-ci constitue une plateforme développée en Python, imaginée pour commencer à industrialiser la démarche. « Au-delà du concept et de l'approche du Chaos Monkey, techniquement parlant, ce n'est pas simple à aborder, notamment pour ceux qui veulent commercer petit, au niveau applicatif. Il existe peu d'outils pour faire cela et il n'y avait pas d'outil commun. Chacun a construit son propre outil et c'est ainsi qu'est née l'idée de créer ChaosIQ et du Chaos Toolkit." Ce framework ne fournit pas de tests clé en main, mais offre une plateforme où chacun va décrire en Json les actions et les sondes qui correspondent à son système d'information. Le test est ensuite mené à partir de la console.
Si le Chaos Monkey est incontestablement une nouvelle étape dans la maturité des entreprises vis-à-vis des tests d'application et d'infrastructure, il faudra sans doute encore plusieurs années avant que cette approche ne se banalise dans les DSI.
