Qu’est-ce que l’ingénierie du chaos ?

Les entreprises sont confrontées en permanence au risque de défaillance de leur infrastructure et de leurs applications critiques, avec pour conséquence une incapacité à fournir les services promis aux clients. Les causes possibles sont multiples, des violations de la sécurité et des erreurs de configuration aux interruptions de service. La probabilité d’erreurs ou de perturbations peut augmenter à mesure que de plus en plus d’applications et de données sont hébergées dans le cloud, entraînant une hausse des incidents de sécurité.

L’ingénierie du chaos est l’une des solutions pour prévenir les perturbations. Il ne s’agit pas d’un processus aléatoire au cours duquel les ingénieurs arrêtent des instances ou des services, ou provoquent une défaillance des systèmes sans objectif particulier. Ce processus identifie les problèmes futurs potentiels, permettant aux équipes d’ingénierie de les résoudre de manière proactive afin de les éviter dans l’environnement réel plus tard.

L’ingénierie du chaos est très utile, car une erreur ou une perturbation peut ralentir la dynamique d’une organisation en faisant perdre un temps précieux à rechercher une solution à la volée alors que les temps d’arrêt augmentent. Netflix a appris ce concept de première main en 2008 pendant son passage d’un système sur site au cloud¹ lorsqu’une panne a interrompu la fourniture des services pendant trois jours.

Si cette panne s’était produite après la transition de Netflix vers le streaming vidéo, elle lui aurait coûté des sommes astronomiques. Décidé à faire tout son possible pour minimiser les perturbations, le groupe a commencé à introduire l’ingénierie du chaos dans ses workflows. Ce processus leur permet d’identifier les problèmes avant qu’ils ne se produisent et de minimiser les dommages en cas de défaillance inévitable.

Netflix a créé Chaos Monkey², un outil open source qui provoque des incidents aléatoires dans les services et l’infrastructure informatiques afin d’identifier les faiblesses qui peuvent être corrigées ou résolues par des procédures de récupération automatiques. Chaos Monkey a été mis en œuvre lors de la transition d’un centre de données privé vers Amazon Web Services (AWS) en réponse au manque de fiabilité du cloud. Chaos Monkey est désormais utilisé par de nombreuses entreprises pour mener à bien leurs expériences d’ingénierie du chaos.

L’ingénierie du chaos constitue une défense importante contre les défaillances de l’infrastructure, les pannes ou les composants manquants dans l’environnement de production d’une organisation. Elle aide les ingénieurs en fiabilité des sites (SRE) et les autres membres de l’équipe DevOps à assurer la livraison continue des services en évitant les perturbations importantes. L’ingénierie du chaos leur permet de mieux comprendre les vulnérabilités et les informe sur la manière de minimiser l’impact en cas de perturbation.

Étant donné la diversité des dépendances logicielles, le moindre problème de code peut avoir des conséquences désastreuses sur l’ensemble de l’environnement de production. Par exemple, une erreur dans le système logiciel transactionnel d’une société financière peut entraîner des pertes de plusieurs millions de dollars³.

Si tous les incidents informatiques ne peuvent pas être évités, les organisations peuvent toutefois minimiser les dommages grâce à la gestion du chaos pour comprendre les scénarios probables et les meilleures solutions possibles.

Les organisations dotées d'une grande résilience, d'une maturité numérique et d'une grande observabilité grâce à des tableaux de bord et d'autres outils devraient adopter l'ingénierie du chaos, car elles peuvent prendre des mesures immédiates pour résoudre les problèmes qui surviennent au cours des expériences. Les organisations qui n'ont pas cette observabilité⁴ peuvent mettre trop de temps à résoudre les expériences qu'elles créent grâce à l'ingénierie du chaos.

L’ingénierie du chaos est également indispensable pour les organisations qui utilisent le cloud, en particulier le cloud public et les applications cloud natives. Le risque de panne lié au cloud public exige une coordination avec le fournisseur de cloud, ce qui nécessite une approche différente de la résolution des problèmes sur site.

Selon Constellation Research⁵, les entreprises qui utilisent le cloud abordent encore souvent les incidents informatiques sans tenir compte des différences entre le cloud et un logiciel en tant que service (SaaS) dans la façon dont ils influent sur ces incidents.

De plus, l’essor de l’utilisation des microservices, qui augmente le nombre de conteneurs exécutés dans un système, crée des défis uniques qui peuvent être découverts et résolus grâce à des expériences de chaos. Les complexités ne sont pas éliminées, mais transférées de la conception de code vers les opérations système, ce qui multiplie les possibilités d’automatisation.

L’ingénierie du chaos peut également aider les organisations à améliorer la vitesse de leurs pipelines d’intégration continue et de livraison continue (CI/CD). En intégrant l’ingénierie du chaos à leurs pipelines CI/CD comme l’a fait Netflix⁶, les entreprises peuvent automatiser leurs expériences pour assurer une exécution continue, tout en maîtrisant leur impact.

Enfin, comme les entreprises communiquent de plus en plus avec leurs partenaires via des API, un problème lié à leurs systèmes peut avoir des répercussions sur les autres organisations. L’ingénierie du chaos permet ainsi aux entreprises d’identifier et de corriger les points faibles de leur architecture afin d’anticiper les défaillances futures.

En déployant efficacement leur stratégie d’ingénierie du chaos, les entreprises sont en mesure d’éviter les défaillances techniques susceptibles d’avoir un impact significatif sur leurs clients et de créer des architectures de systèmes complexes, plus solides et plus résilientes. Une fois le choix d’adopter l’ingénierie du chaos fait, la prochaine étape consiste à déterminer si l’exécuter dans l’environnement de production ou de préproduction.

Les équipes DevOps peuvent mener diverses expériences d’ingénierie du chaos afin de tester les différents processus du système.

• Injection de latence : les équipes DevOps créent des scénarios pour simuler une connexion réseau lente ou défaillante. Il s’agit notamment de provoquer des retards dans le réseau ou des temps de réponse plus longs.
• Injection d’erreurs  : il s’agit d’introduire délibérément des erreurs dans le système pour déterminer leur impact sur les systèmes dépendants, ainsi que leur capacité à interrompre les services. Parmi les erreurs injectées, citons les pannes de disque, l’arrêt d’un processus ou d’un hôte, ou encore une augmentation de la puissance ou de la température. L’injection d’erreurs permet aux entreprises d’identifier les points de défaillance uniques susceptibles d’entraîner la défaillance de l’ensemble du système, s’ils venaient à tomber en panne.
• Génération de charge : il s’agit de solliciter excessivement le système en envoyant volontairement des niveaux de trafic bien au-delà des opérations normales. Cette technique aide les ingénieurs en fiabilité des sites (SRE) à comprendre les goulots d’étranglement dans le système, ce qui leur permet de construire des systèmes plus évolutifs.
• Tests canari  : consiste à proposer un nouveau produit ou une nouvelle fonctionnalité à un groupe limité d’utilisateurs. Ainsi, en cas de problème ou de bug, seul un pourcentage de visiteurs sera affecté, le reste du public bénéficiant de l’expérience actuellement offerte par le site Web.

Dans l’idéal, un processus d’ingénierie du chaos doit respecter plusieurs principes afin que l’entreprise puisse disposer d’un système distribué à l’échelle.

• Comprendre le système : connaissance approfondie du système dans son ensemble : fonctions et propriétés émergentes, topologie, architecture, dépendances, comportement en régime permanent, réponse en sortie et caractéristiques telles que la disponibilité, la latence et le débit.
  
• Accepter la défaillance : au départ, il semble paradoxal pour les ingénieurs logiciels de laisser un incident se produire alors qu’ils sont armés pour empêcher que de tels incidents se produisent. Cependant, des interruptions se produiront toujours dans les services informatiques, et il est préférable d’en faire l’expérience dans un environnement contrôlé afin d’identifier la solution de manière préventive plutôt qu’en dehors des heures de bureau lorsque l’équipe est absente ou n’a jamais rencontré ce problème spécifique auparavant.
• Déterminer le comportement en régime permanent : avant toute chose, l’équipe d’ingénierie doit définir le comportement que le système aura lorsqu’il fonctionne correctement, afin de pouvoir comparer l’impact des expériences sur cet état permanent.
• Identifier les incidents réels : au lieu de créer des situations hypothétiques, les expériences d’ingénierie du chaos doivent reproduire au plus près ce qui pourrait arriver lors d’une journée ordinaire : défaillances du réseau et de l’infrastructure, erreurs de code, problèmes d’alimentation, surcharge de trafic, etc.
• Organiser une journée d’expérimentation : l’ingénierie du chaos peut étudier l’environnement un jour particulier. Plusieurs tests sont alors réalisés au cours de la même journée afin de maximiser les ressources qui permettront d’identifier et de résoudre autant de problèmes que possible.
• Automatiser  : les entreprises de toutes tailles ont la possibilité d’automatiser leurs expériences d’ingénierie du chaos, qui demanderaient trop de main-d’œuvre si elles devaient être menées manuellement. Cela permet de réduire la charge des équipes informatiques pendant le processus d’ingénierie du chaos. La conception d’expériences, l’injection d’erreurs et le provisionnement de l’infrastructure sont autant d’aspects de l’expérimentation que les entreprises peuvent automatiser.
• Attention au rayon d’action : un ingénieur du chaos doit s’efforcer de limiter le rayon d’action de l’incident afin de minimiser autant que possible le préjudice réel causé aux clients. Voici quelques manières de procéder :
  • Ciblez un sous-ensemble de services : l’ingénierie du chaos, en particulier dans un environnement de production, ne doit pas perturber radicalement le service d’une organisation. Le ciblage d’un sous-ensemble spécifique de services peut minimiser l’impact d’un incident s’il se produit, en veillant à ce qu’il ne supprime pas l’ensemble du système.
  • Effectuez l’expérience pendant un temps déterminé : l’expérience doit avoir un début et une fin. Le but est de créer un incident et de le résoudre au lieu de le laisser s’exécuter sans contrôle pendant une longue période.
  • Effectuez l’expérience en dehors des heures de pointe : les organisations doivent essayer d’éviter d’exécuter des tests pendant les périodes de pointe, sauf s’il s’agit d’évaluer à quel point la capacité perturbe le système pendant un incident.
  • Réalisez l’expérience dans l’environnement de développement  : le moyen le plus simple de garantir qu’aucun client ne subira d’interruption de service est de la mener dans l’environnement de pré-production. Cependant, comme les conditions sont différentes de celles de l’environnement de production, vous risquez d’obtenir une fausse image de la situation. Pour éviter cet écueil, veillez à mettre en concordance autant que possible vos environnements de préproduction et de production.
  • Testez chaque composant : l’expérimentation du chaos ne s’arrête jamais car le système d’une organisation est en constante évolution. Efforcez-vous également de « tout tester » : examinez tous les composants, couches, services et leurs dépendances tout au long du processus.

Les entreprises qui adoptent l’ingénierie du chaos doivent décider où effectuer leurs tests, dans l’environnement de production ou de préproduction. L’environnement de production est préférable pour plusieurs raisons.

En effet, les environnements réels offrent une vue plus précise pour comprendre l’impact d’un incident sur l’expérience client. De plus, la configuration de l’environnement de préproduction peut présenter des différences avec l’environnement réel, ce qui introduit une certaine variabilité dans les expériences.

Par exemple, un incident dans un environnement de préproduction peut générer une réponse inadaptée, les niveaux de trafic n’étant pas les mêmes que dans l’environnement live. Les configurations de sécurité peuvent aussi être différentes.

Certaines organisations préfèrent exécuter leurs tests dans un environnement de préproduction ou de développement afin d’éviter de perturber un site déjà en service. Les problèmes éventuels n’ont ainsi aucun impact sur l’expérience client. Pour limiter les risques, elles commencent donc par des environnements de préproduction afin de maîtriser le processus avant de passer à l’environnement de production.

Les organisations choisissent l’environnement à utiliser en fonction de leur tolérance au risque. En fin de compte, l’ingénierie du chaos vise à tester les problèmes à grande échelle. C’est pourquoi les environnements de production offrent la vue la plus précise de ce qui se passe et de ce qui doit être corrigé.

L’ingénierie du chaos apporte aux entreprises plusieurs avantages majeurs.

Les clients ont des attentes élevées quant à la disponibilité des services qu’ils achètent auprès des entreprises. Les temps d’arrêt ou l’impossibilité d’accéder aux services qu’ils ont payé peut avoir un effet désastreux sur la satisfaction client, avec pour conséquences une perte de chiffre d’affaires et une atteinte à la réputation. Le test des systèmes et la recherche de solutions permettent d’atténuer le risque qu’un système soit hors service pendant une trop longue durée.

Les perturbations peuvent être dues à un code erroné, à des problèmes de serveur ou à des menaces externes. Celles-ci peuvent se manifester même avec d’excellentes pratiques de sécurité. L’ingénierie du chaos aide à identifier les problèmes que les organisations peuvent exploiter pour introduire des correctifs et des corrections de bugs de façon à assurer la sécurité de leurs services.

L’ingénierie du chaos permet aux organisations de créer un schéma directeur bien documenté sur la stratégie à adopter pour résoudre les problèmes futurs. En adoptant l’ingénierie du chaos, elles disposeront de plans d’attaque spécifiques pour répondre à de nombreux incidents, de manière à accélérer la réparation et à limiter les temps d’arrêt. L’ingénierie du chaos peut  réduire les temps d’arrêt⁷ jusqu’à 20 %.

Les expériences d’ingénierie du chaos permettent d’identifier la manière dont le système alloue les ressources et gère les charges, ainsi que les endroits où les goulots d’étranglement se situent ou sont susceptibles de se produire.

L’ingénierie du chaos permet aux équipes de renforcer la résilience et la flexibilité de leurs logiciels. Les entreprises sont donc en mesure d’aborder plus intelligemment le codage de leurs logiciels et solutions, puisqu’elles savent comment le système actuel gère les problèmes.