Qu’est-ce que Chaos Engineering ?

Vos clients, clients, visiteurs – et même employés internes – comptent tous sur vos systèmes pour fonctionner, être disponibles et performants tout le temps. Dans un monde parfait, il n’y aurait jamais de terme pour quand les systèmes, les applications et les services tombent en panne, mais ce n’est pas un monde parfait, et malheureusement, parfois les choses ne se passent pas comme prévu. Les pannes et les temps d’arrêt peuvent coûter des millions de dollars aux entreprises. Parfois, le meilleur plan est un plan pour l’inattendu, ce qui est exactement ce que l’ingénierie du chaos cherche à résoudre. L’ingénierie du chaos, également appelée test du chaos, peut être considérée comme une discipline, ou une approche, pour tester et construire un système capable de résister à des défaillances ou à des conditions inattendues.

Avec l’avènement des pratiques DevOps, les organisations, des startups aux entreprises, ont lentement adopté leurs propres pratiques de test du chaos dans leurs flux de travail de développement. Que l’ingénierie du chaos soit réalisée par des équipes spécifiques ou dans le cadre des responsabilités des ingénieurs en fiabilité de site (SRE),la pratique de l’ingénierie du chaos est conçue pour découvrir les faiblesses cachées des systèmes, des applications et des services, en veillant à ce qu’elle puisse résister aux situations les plus extrêmes pour une résilience complète.

Ingénierie du chaos vs tests de performance

Comme les tests de résistance ou les tests de charge,l’ingénierie du chaos aide les équipes à identifier les points de rupture ou les défaillances en créant des environnements anormaux ou instables. Cependant, l’une des principales différences entre l’ingénierie du chaos et les tests de performance est que l’ingénierie du chaos ne se concentre pas uniquement sur quelques composants clés, mais peut plutôt consister en un nombre apparemment illimité de facteurs, en dehors de la portée des considérations de test normales et évidentes. Dans les grands environnements réseau distribués, les systèmes peuvent échouer pour diverses raisons qui ne sont pas aussi faciles à découvrir que d’autres environnements. La découverte de ces vulnérabilités aide les équipes à comprendre où se trouvent les faiblesses afin d’éviter que ces défaillances potentielles ne se produisent.

 

Chaos (Ingénierie) est né

La pratique de l’ingénierie du chaos a vu le jour avec Netflix vers 2008 après le lancement officiel de son service de streaming. Suite à un problème de corruption de base de données vers 2011, Netflix a prévu de transférer son centre de données vers le cloud via AWS (Amazon Web Services). En fait, il leur a fallu huit ans pour finalement terminer la migration. En 2015, AWS a connu une panne, ce qui a entraîné une panne de Netflix pendant plusieurs heures. C’était les premiers jours du cloud computing, il n’était donc pas aussi robuste, stable et sûr qu’aujourd’hui. Lorsqu’ils ont découvert que le passage au cloud ne créait pas certains des avantages qu’ils attendaient, tels que l’évolutivité, la disponibilité, l’évitement des points de défaillance uniques, la mise à l’échelle automatique, etc., ils ont décidé qu’ils avaient besoin d’un moyen de tester ces problèmes inattendus pour s’assurer que leurs services sont opérationnels et, en fin de compte, éviter l’impact sur les utilisateurs et causer de la frustration. De cette expérience, l’ingénierie du chaos est née.

 

Principes et étapes de l’ingénierie du chaos

L’ingénierie du chaos ne cherche pas à créer le chaos juste pour créer le chaos. Au contraire, basé sur un ensemble de principes et d’étapes précis, il est conçu pour créer de manière réfléchie des plans et des expériences dans le seul but d’apprendre à atténuer les risques au sein de grands systèmes et réseaux distribués. Vous trouverez ci-dessous les étapes à suivre pour créer une ligne directrice générale pour les expériences de chaos.

 

Étape 1 : Créer une hypothèse

Cela consiste à faire des hypothèses générales sur la façon dont un système réagira lorsque des facteurs et des conditions instables sont introduits par rapport à l’environnement normal. C’est également là que vous déterminez quelles mesures, telles que les taux d’erreur, la latence, le débit, etc., doivent être mesurées pendant l’expérience du chaos.

 

Étape 2 : Identifier les variables et anticiper les effets

Considérez ce qui pourrait arriver lorsque ces événements hypothétiques devaient se produire dans des situations réelles. Par exemple, si votre serveur tombe en panne de manière inattendue ou s’il y a une augmentation significative du trafic, quel sera l’effet sur l’ensemble de votre système ?

 

Étape 3 : Lancer l’expérience

Idéalement, vous souhaitez exécuter votre expérience de chaos dans un environnement de production en direct. Cependant, des mesures de protection doivent être en place pour éviter qu’un scénario pire ne se produise. Vous voulez vous assurer que vous avez toujours un certain contrôle sur l’environnement si l’expérience va de côté. Ceci est également connu sous le nom de contrôle du rayon de souffle. Ces expériences peuvent être automatisées pour une meilleure analyse, et sont plus durables, que de les exécuter manuellement. Une autre méthode parfois utilisée consiste à utiliser un environnement de test à part entière, mais encore une fois, cela pourrait ne pas refléter ce qui se passe dans le monde réel.

 

Étape 4 : Mesurer l’impact

Comment les résultats sont-ils à la hauteur de l’hypothèse initiale ? Sur la base des mesures qui ont été définies dans l’hypothèse, l’expérience était-elle trop limitée ou doit-elle être mise à l’échelle pour mieux identifier les erreurs et les défauts? Le rayon d’explosion était-il trop limité ? Peut-être qu’il faut l’adapter pour délever les défauts qui se produiraient dans un scénario réel. Cette expérience peut également révéler d’autres problèmes qui doivent être étudiés.

 

Outils d’ingénierie chaos

Revenons à l’introduction de l’ingénierie du chaos avec Netflix. Une fois qu’ils ont pris la décision de passer à l’offensive et de commencer le processus de dédiation des ressources pour une équipe d’ingénierie, ils devaient créer un ensemble formalisé de pratiques et d’outils pour aider les équipes d’ingénierie à effectuer des tests de chaos. L’une des premières applications introduites par Netflix s’appelait Chaos Monkey. Chaque jour, cette application choisissait au hasard un ensemble de clusters et désactivait cette instance à un moment donné de la journée pour observer comment les systèmes restants réagissaient. Évidemment, cela crée une expérience douloureuse pour les équipes d’ingénieurs qui ont suffisamment de maux de tête réseau à gérer quotidiennement, mais en fin de compte, cela met les équipes dans une meilleure position pour comprendre les effets de ces pannes, non seulement en ce qui concerne leur réseau, mais aussi en termes d’impact sur les utilisateurs.

Bien qu’il puisse sembler contre-intuitif de consacrer des ressources et des individus à contourner les choses, la réalisation proactive de ces tests de chaos aide à construire un réseau plus résilient et à créer une expérience utilisateur meilleure et plus fiable. Le monde réel ne fonctionne pas dans un environnement de test contrôlé. Depuis la création de Chaos Monkey, il a subi plusieurs mises à jour et est devenu une application open source populaire. Et à une époque, ce n’était qu’une partie d’une suite d’outils d’ingénierie du chaos appelée l’armée Simienne. La suite Simian Army a été dissoute en 2018, mais comprenait les utilitaires d’ingénierie du chaos spécifiques aux tâches suivants:

 

Chaos Kong

Chaos Kong a été conçu pour simuler la suppression ou la suppression d’une région AWS complète afin de voir comment le système a récupéré et réagi en déplaçant le trafic vers une autre région sans dégradation des performances. Encore une fois, cela arrive rarement, mais dans le cadre de l’ingénierie du chaos, rien n’est hors limites.

 

Conformité Singe

Conformity Monkey est un service qui s’exécute dans AWS dans le but d’identifier les instances qui n’étaient pas conformes à des règles prédéfinies. Toute instance non conforme aux règles, qui étaient suffisamment flexibles pour être personnalisées et configurées pour fonctionner à des fréquences différentes, a été identifiée et une notification par e-mail est envoyée au propriétaire ou au groupe. Conformity Monkey a depuis été transféré aux services Spinnaker.

 

Gorille du Chaos

Chaos Gorilla est comme Chaos Monkey, mais à une plus grande échelle. Au lieu de simuler des défaillances sur des instances AWS uniques, Chaos Gorilla a simulé une défaillance d’une zone AWS entière. Cet utilitaire a été conçu pour montrer comment une catastrophe à grande échelle a affecté les utilisateurs ou les clients d’une région différente, ce qui était parfait pour la façon dont l’infrastructure et le modèle commercial de Netflix ont été mis en place. Si la plate-forme cloud peut résister à ce test en s’assurant correctement que les équilibreurs de charge réagissent correctement et que les services restent interrompus, elle peut alors résister à tout ce qui lui est lancé.

 

Singe de latence

Latency Monkey, comme son nom l’indique, est utilisé pour tester les services par rapport aux retards du réseau, ou aux défaillances complètes, afin d’aider à identifier comment les services et leurs dépendances ont réagi à ces retards simulés. Cependant, comme les services Web en général, il peut y avoir des conséquences inconnues dans d’autres applications qui peuvent ne pas être facilement identifiées au premier coup d’œil, c’est pourquoi un utilitaire comme Latency Monkey est si important pour évaluer la tolérance aux pannes entre les services.

 

Docteur Singe

L’utilitaire Doctor Monkey a été utilisé pour effectuer des vérifications de l’état de santé dans des instances individuelles et surveiller l’état (charge du processeur, mémoire, ressources, etc.) de l’ensemble du système. En outre, Doctor Monkey peut signaler l’état de l’instance et supprimer toutes les instances du service qu’il juge inadaptée à l’ensemble du système.

 

10-18 Singe

Le nom de 10-18 Monkey vient des abréviations pour la localisation et l’internationalisation et la localisation, L10n et i18n. Les chiffres représentent le nombre de lettres entre la première et la dernière lettre. Étant donné que les clients de Netflix résident partout dans le monde, il était de la plus haute importance d’avoir une méthode pour surveiller la fiabilité de leurs services de streaming, dans différentes régions. L’avantage de l’utilitaire 10-18 Monkey est qu’il peut vérifier les problèmes de configuration et de performances dans plusieurs régions géographiques qui desservent et utilisent différentes langues et jeux de caractères.

 

Singe concierge

Qu’en est-il de toutes ces ressources AWS inutilisées ? Entrez Janitor Monkey. Le but de l’utilitaire Janitor Monkey est de trouver et de supprimer les ressources inutilisées. Comme Chaos Monkey, il est également personnalisable et suffisamment extensible pour être utilisé avec d’autres fournisseurs de cloud. Les utilisateurs fournissent un ensemble de règles et Janitor Monkey se met au travail, identifiant les ressources, groupes et volumes inutilisés qui sont candidats au nettoyage et à la suppression et envoie une notification. Au fil du temps, la fonctionnalité a été remplacée par un nouveau service appelé Swabbie.

 

Conclusion : Ingénierie du chaos – Principes, exemples et outils

Au fil du temps, l’ingénierie du chaos est devenue sa propre industrie à part entière. Il existe maintenant une myriade d’outils open source et commerciaux, tels que Litmus Chaos, Gremlin, Chaos Mesh et bien d’autres, que les organisations peuvent utiliser. La construction de systèmes résilients n’est pas réservée aux entreprises technologiques. Les systèmes distribués sont devenus plus complexes, ce qui signifie que les défaillances sont plus difficiles à prévoir. En outre, en raison de divers problèmes de réglementation et de conformité, les banques, les entités gouvernementales, les sociétés pharmaceutiques, les établissements d’enseignement, etc., doivent tester régulièrement leurs systèmes et services pour s’assurer qu’ils répondent aux exigences commerciales et critiques de la mission. Les tests de performance et les tests de chaos sont des approches proactives pour apprendre à construire des systèmes résilients en observant les échecs.