Ingénierie du Chaos — Comment Commencer? — Partie 1 : Introduire le sujet dans l’entreprise
Il existe beaucoup d’articles sur le Chaos Engineerging, mais à l’heure de l’écriture de cet article, très peu d’entreprises en font réellement. Étant donné les apports potentiels de cette discipline c’est assez surprenant. Cependant il faut reconnaitre que passer de la théorie à la pratique nécessite un ensemble de facteurs assez conséquents et complexes à gérer.
Aussi, pour avoir entreprit cette démarche depuis maintenant deux ans, je souhaite vous proposer quelques pistes pour lancer la machine.
La résilience est souvent perçue comme un sujet plutôt “exploitants/ops” que dev. Pourtant la résilience applicative permet de solutionner certains problèmes que la résilience infra ne peut résoudre toute seule. Au final c’est l’ensemble des interlocuteurs depuis le développement jusqu'à la gestion des infrastructures en passant par l’exploitation de la production et toute la chaine d’intégration qui sont impliqués dans l’optimisation de la résilience des systèmes d’informations.
Le Chaos engineering vise à accroitre la résilience des systèmes d’informations, des applications et des infrastructures qui la composent.
C’est donc avec ce premier point qu’il faut commencer : savoir où son entreprise/organisation en est techniquement et “culturellement” sur le sujet de la résilience.
Posez la question directement à vos équipes!
Pensent-elles que leurs applications réagiront correctement à une panne donnée?
Une réponse négative permettra de se poser une question essentielle : pourquoi l’application visée ne résistera pas?
A charge des équipes de voir quelles sont les contre-mesures, au niveau développement / architecture / infrastructure, qu’il est possible de mettre en place pour pouvoir survivre à l’expérimentation.
Les outils du Chaos Engineering peuvent alors être utilisés en mode bridés sur les environnements hors production et en particulier sur les environnements de tests (non régression, tir de charge, etc…). Ces exécutions hors production seront les compléments idéaux des tests techniques existants (exploitabilité, monitoring, performance, charge, résilience de base, etc…).
Il faut d’ailleurs tester régulièrement les outils de chaos engineering en environnement hors production, ne serait-ce que pour s’assurer un minimum du bon fonctionnement des outils et du comportement des applications.
Faire un Chaos Monkey dans une plage restreinte lors d’un tir de charge sur un environnement de pré-production est un bon prémisse à l’expérimentation en production.
La résilience des applications sortira renforcée de cette démarche et avec le temps c’est la résilience globale du système qui sera accrue. Pourra alors se poser la question du test en production.
Reste à déterminer les expérimentations les plus pertinentes pour chacune de vos applications et pour votre infrastructure. Nous verrons ça dans la prochaine partie.
