Ce sont les travaux du météorologue Edward Lorenz dans les années 60 qui ont permis l’émergence de la théorie du chaos : Lorenz a mis en avant le caractère chaotique de la météo, à travers la notion de sensibilité aux conditions initiales. Cette théorie s’illustre notamment à travers l’image du papillon, dont “le battement d’ailes au Brésil pourrait provoquer une tornade au Texas”. De cette image, il faut retenir que le battement d’ailes du papillon n’est pas la cause de la tornade, mais qu’il modifie les conditions initiales et induit une différence d’effet. Autrement dit, un petit changement dans un système complexe peut amener des conséquences inattendues à plus grande échelle. Il en va de même pour les architectures IT actuelles, qui sont par définition des systèmes complexes, et le Chaos Engineering vise à améliorer leur fiabilité à travers l’expérimentation.

Pour comprendre comment fonctionne le chaos engineering, imaginez un vaccin : il s’agit d’injecter dans le système un élément potentiellement nocif et de voir comment le système réagit. Le chaos engineering vise à stresser des environnements de production et à y créer des dysfonctionnements, dans le but de rendre ces environnements plus résilients à terme. Mais contrairement ce qu’on pourrait penser, le chaos engineering est tout sauf chaotique : c’est une expérimentation planifiée, contrôlée et mesurée. Il ne s’agit pas de détruire le système, mais au contraire il faut le connaître suffisamment bien pour pouvoir isoler les pannes et impacter un nombre limité d’utilisateurs. Il faut également être capable d’arrêter immédiatement l’expérimentation en cas de besoin. Le Chaos Engineering demande un niveau poussé d’automatisation du système.

La notion de Chaos Engineering a été développée par Netflix, qui avait déjà créé la Simian Army afin de tester l’intégration de la résilience dans les couches applicatives, à travers des pannes planifiées de VM. Le Chaos Engineering va beaucoup plus loin que cette première approche, qui créait des pannes que l’on savait résoudre, et dont le résultat était connu. Le Chaos Engineering représente un saut dans l’inconnu, et il suppose d’avoir déjà largement testé et éprouvé la résilience de son système : tous ses points possibles de faiblesses connus ont été traités. Le Chaos Engineering va justement permettre de modéliser la complexité de son système, de faire émerger des points d’amélioration.

Pourquoi une telle approche ? Dans la vie quotidienne comme dans celle des systèmes informatiques, les événements non anticipés pouvant amener des conséquences inattendues sont nombreux. A terme, les répercussions de ces événements peuvent influencer le comportement du système, puis entraîner des répercussions risquant de dégrader la performance ou le service fourni. Comme ces événements sont difficiles à prévoir à l’avance, il est nécessaire d’apprendre de son système pour voir comment il réagit à certains événements. Le Chaos Engineering est une forme d’apprentissage, grâce auquel on gagnera en maîtrise de la complexité du système.

Cet apprentissage demande également de réfléchir à ce qu’est le comportement normal du système : quel comportement attend-on lors d’un pic d’utilisation, quelles sont les métriques en heures creuses, etc. Le comportement “normal” du système doit être documenté de façon statistique, d’où le besoin d’outils de monitoring et d’analyse pour obtenir les bonnes métriques.

Les systèmes informatiques ont gagné en complexité, et le Chaos Engineering permet de répondre à cette évolution. Par le passé, on a eu tendance à essayer de simplifier les systèmes pour mieux les piloter et les industrialiser, ce qui les a rendus plus stables, mais moins aptes au changement. Le Chaos Engineering permet justement de nous aider à maîtriser la notion d’incertitude, et de développer un modèle d’organisation capable de gérer la complexité. Il faut accepter que la complexité soit un avantage concurrentiel, mais cela demande d’apprendre à la maîtriser et de développer une capacité de résilience intégrant cette complexité.

Rejoignez-nous au prochain Meetup Chaos Engineering et participez au GameDay « Days of Chaos »