Les entreprises ayant atteint un niveau élevé de résilience, de maturité numérique et d’observabilité, au moyen de tableaux de bord et d’autres outils, ont tout intérêt à adopter l’ingénierie du chaos car elles sont en mesure de réagir promptement face aux problèmes qui surviennent au cours des expériences. En l’absence d’un tel niveau d’observabilité⁴ (lien externe à ibm.com), le délai pour mener à bien les expériences créées grâce à l’ingénierie du chaos serait trop long.

L’ingénierie du chaos s’avère également incontournable pour les entreprises qui utilisent le cloud, notamment des solutions cloud public et des applications cloud natives. Le risque de panne associé au cloud public exige une coordination avec le fournisseur cloud, incompatible avec la démarche de gestion des problèmes sur site. 

Selon Constellation Research, les entreprises ayant adopté le cloud ont tendance, encore aujourd’hui, à aborder les incidents informatiques sans prendre en compte l’impact différent que le cloud et les logiciels à la demande (SaaS) ont sur ces incidents⁵.(lien externe à ibm.com) 

En outre, l’utilisation croissante des microservices, qui entraîne une multiplication des hôtes ou des conteneurs exécutés dans un système, pose de nouveaux défis (lien externe à ibm.com) que l’ingénierie du chaos permet d’identifier et de résoudre. 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 opportunités d’automatisation.

L’ingénierie du chaos permet également aux entreprises d’accélérer 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⁶ (lien externe à ibm.com), les entreprises peuvent automatiser leurs expériences pour assurer une exécution continue, tout en maîtrisant leur impact. 

Pour finir, il convient de noter que les entreprises se tournent de plus en plus vers les  API pour communiquer avec leurs partenaires, ce qui veut dire que tout problème survenu dans leurs systèmes est susceptible d’affecter également d’autres infrastructures.

L’ingénierie du chaos permet aux entreprises d’identifier et de corriger les points faibles de leur architecture afin de prévenir les défaillances. 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 nettement supérieurs à la normale. Cette technique permet aux ingénieurs de fiabilité du site (SRE) de mieux appréhender les goulots d’étranglement afin de renforcer l’évolutivité du système. 
• Test du canari : il s’agit de proposer un nouveau produit ou une nouvelle fonctionnalité à un groupe restreint d’utilisateurs. Ainsi, en cas de problème ou de bogue, seul un pourcentage des visiteurs sera affecté, pendant que les autres pourront bénéficier de l’expérience actuellement offerte par le site Web.

Plusieurs principes sont appliqués pour élaborer un processus d’ingénierie du chaos efficace et garantir à l’entreprise un système distribué à grande é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 du monde réel : au lieu d’imaginer des situations improbables, les expériences d’ingénierie du chaos doivent se rapprocher le plus possible de ce qui est susceptible de se produire lors d’une journée normale : défaillances du réseau et de l’infrastructure, erreurs de code, problèmes d’alimentation, trafic surchargé.
• 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, trop gourmandes en 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. Conception d’expériences, injection d’erreur, provisionnement de l’infrastructure... Autant d’aspects 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 du trafic 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. 
  • Mener l’expérience dans l’environnement de développement : pour garantir qu’aucun client ne subira une interruption de service, le plus simple est de mener l’expérience dans l’environnement de préproduction. Étant donné que les conditions diffèrent de celles de l’environnement de production, vous risquez toutefois d’obtenir de faux résultats. Pour les éviter, il est important de veiller à que vos environnements de préproduction et de production se reflètent autant que possible. 
  • Tester chaque composant : l’ingénierie du chaos est un processus continu, car le système de l’entreprise ne cesse d’évoluer. Il est donc essentiel de « tout » tester, d’examiner l’ensemble des composants, des couches et des services, ainsi que leurs dépendances, tout au long du processus.

Les entreprises qui adoptent l’ingénierie du chaos doivent décider si mener leurs tests dans l’environnement de production ou de préproduction. L’environnement de production est préférable pour plusieurs raisons. En effet, ce dernier s’avère plus exact et vous permettra de mieux comprendre l’impact que tel ou tel incident aurait sur l’expérience client. Autre raison : l’environnement de préproduction peut présenter des paramètres différents et entraîner une certaine variabilité lors des tests.

Par exemple, un incident en préproduction risque de ne pas créer une réponse réaliste, car les niveaux de trafic ne sont pas les mêmes que dans l’environnement réel. Les configurations de sécurité des deux environnement peuvent également différer. 

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 ainsi l’environnement à utiliser en fonction de leur tolérance au risque. Pour conclure sur ce point, comme l’ingénierie du chaos vise à tester des problèmes réels à grande échelle, les environnements de production donnent l’image la plus précise de ce qui se passe et de ce qui doit être corrigé.