Un nouveau tour d’horizon du Chaos Engineering
La résilience se travaille
Depuis peu, le Chaos Engineering a pris de l’ampleur. Nous sommes encore assez loin d’une discipline mise en pratique de manière structurelle, comme le sont l’agilité, le testing ou l’intégration continue. A l’heure actuelle, la curiosité grandit pour la démarche et nous sommes dans une phase d’éducation sur le sujet.
Rappelons que le Chaos Engineering vous offre une approche, parmi d’autres, pour donner du sens à des systèmes de plus en plus complexes en découvrant leurs faiblesses avant que les utilisateurs ne les subissent.
Réduire le stress de l’incertitude
Pour les équipes, le gain est important. Plus vous vous familiarisez avec les faiblesses potentielles, plus vous êtes équipés pour les gérer quand elles frappent (ou des variations). En effet, qui n’a pas été sous le coup d’un stress énorme lorsque le système a commencé à montrer des signes de difficultés, pour finir par “appuyer sur tous les boutons, au cas où…”. On ne peut pas raisonner sereinement devant l’inconnu sous le stress.
Le Chaos Engineering vous permet donc d’explorer vos systèmes afin d’expérimenter des scénarios plus ou moins graves. L’idée n’est pas de donner des coups de pieds au hasard, mais plutôt de poser des hypothèses et de regarder comment le système réagit sous des conditions dégradées.
En ce sens, il n’est pas obligatoire de “casser” un système pour en apprendre quelque chose. Parfois, il est utile de provoquer des erreurs, mais parfois il faut juste changer les règles. En gros, le chaos engineering est l’idée de challenger les attentes que les équipes, et les services logiciels, ont sur l’ensemble du système.
Par exemple, “je sais que je peux parler au service X par HTTP et qu’il me répondra”. Cette attente se doit d’être remise en question afin d’éprouver la résilience de ce service quand son attente ne peut pas être vérifiée. Pour expérimenter, vous pouvez évidemment faire tomber le service X, mais vous pouvez aussi changer vos règles réseaux, ou mettre un proxy qui altère le trafic. Bref, il existe maintes approches d’apprentissage.
Démarrer simplement
Une nouvelle discipline, ou pratique, fait toujours un peu peur. Tout d’abord, on s’imagine que ça n’est pas nous. Puis on se dit qu’on n’a pas le temps ou que le coût sera trop élevé. Par la suite, il y a la question de la maturité de l’organisation à absorber et impliquer les équipes de manière positive et effective. Et évidemment, il faut une confiance du management envers ses propres équipes.
Je renvoie aux articles et présentations de Benjamin Gakic et Christophe Rochefolle sur la mise en place du Chaos Engineering dans les équipes de OUI.sncf.
Un outillage encore rustique
C’est — malheureusement — par là où on veut démarrer. Disons le tout de suite, l’outillage du Chaos Engineering est encore rustique. Certes, le Chaos Monkey de Netflix est éprouvé, mais il correspond à un certain type de perturbations qui ne s’appliquent pas à tout le monde et qui ne permettent pas un apprentissage de tous types de faiblesses (sécurité par exemple). Néanmoins, de plus en plus d’outils sortent régulièrement et la plupart sont open-source. Parfois, ils viennent d’une entreprise qui avait un besoin adhoc (par exemple PowerfulSeal de BloomBerg) ou parfois ils viennent d’une commaunauté de passionnés, comme Pumba ou le Chaos Toolkit (de votre serviteur). On commence à voir sortir des offres SaaS comme celles de Gremlin ou du tout nouveau Fuzzbox. Finalement, certaines plateformes proposent directement des points d’entrées d’injection de perturbations, comme Microsoft Azure Service Fabric ou Istio.
D’une manière générale, il faut accepter de mettre les mains dans le camboui encore pour le moment et si vous cherchez une solution “clés en main”, vous devrez patienter un peu. De mon point de vue, l’idée est de créer une culture plus ouverte à l’expérimentation et l’outillage actuel n’est pas un frein à cela si la confiance est présente en interne.
Un effort qui se structure
Le Chaos Engineering a conquis le zeitgeist. La communauté se fédère et des efforts pour consolider le message se mettent en place. Notamment, récemment, la Cloud Native Computing Foundation (CNCF) a démarré le processus de création d’un groupe de travail sur le sujet, afin de fédérer les acteurs. N’hésitez donc pas à vous y joindre ! Des livres sont aussi en préparation.
Où en apprendre plus ?
Il existe plusieurs forums qui peuvent vous aider à poursuivre votre exploration du sujet. Le canal #chaosengineering du Slack du CNCF ou son groupe de travail. Il existe aussi un annuaire de ressources très riche. Des conférences commencent à s’organiser sur le sujet, j’ai pu ainsi donner deux présentations à la dernière KubeCon Europe, sans oublier ChaosConf en septembre et des tracks spécifiques comme à l’Open Security Summit.
On trouve aussi plusieurs articles d’équipes (OUI.sncf, Twilio, VictorOps…) qui ont commencé à utiliser cette approche et en font un retour public.
La communauté francophone n’est pas en reste, Christophe et Benjamin sont actifs et proposent des meetups réguliers sur le sujet. La communauté Cloud Native a aussi montré un intérêt pour le sujet et on peut espérer un meetup à la rentrée.
Il existe une curiosité grandissante pour cette approche. N’hésitez pas à rejoindre le Slack du Days of Chaos pour une discussion, en français, sur le sujet.
Bonne exploration !
