Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Présentation
## Comparaison entre les tests de résilience et l'ingénierie du chaos
Les tests de résilience sont déterministes. En d'autres termes, il valide les caractéristiques connues des mécanismes de résilience, tels que les disjoncteurs, les nouvelles tentatives, les basculements ou les solutions de repli, qui ont été implémentés dans votre application. Cela confirme la manière dont ces composants de l'application absorbent les perturbations contrôlées avec un impact minimal, voire nul, sur les utilisateurs. Par conséquent, les tests de résilience se concentrent sur la validation des modes de défaillance connus qui sont injectés dans les composants de l'application dans le but de produire des pass/fail résultats. Vous devez effectuer des tests de résilience en continu dans le cadre de votre pipeline afin de vous assurer de ne pas introduire de régressions dans votre posture de résilience. Dans les tests de résilience, il est fréquent que vous n'exécutiez pas de tests sur des composants réels, mais APIs que vous simuliez un composant en particulier. Cette approche permet de tester des scénarios de défaillance de manière cohérente et reproductible dans un environnement contrôlé, ce qui la rend adaptée à l'intégration automatisée des pipelines et aux tests de régression.
En revanche, l'ingénierie du chaos n'est pas déterministe. En d'autres termes, il repose sur des hypothèses et vérifie votre modèle mental sur la manière dont l'application et ses dépendances (personnes, processus et technologie) absorbent, s'adaptent et finissent par se rétablir après des défaillances imprévues. Par conséquent, l'ingénierie du chaos se concentre sur la end-to-end vérification de modes de défaillance inconnus, dans le but de détecter rapidement les défauts et de les corriger avant qu'ils ne se transforment en événements de grande envergure. L'ingénierie du chaos favorise l'apprentissage continu et doit être mise en pratique par le biais d'un pipeline de chaos distinct ou d'expériences ad hoc qui vous permettent d'exécuter plusieurs expériences à tout moment sans bloquer la productivité de votre développeur lors du déploiement du code.
Le processus d'ingénierie du chaos commence souvent par une journée de jeu chaotique, un événement dédié au cours duquel les équipes injectent intentionnellement des défauts ou des défaillances contrôlés dans leur application. La journée de jeu est progressive : elle commence dans des environnements de niveau inférieur (tels que le développement ou les tests) et passe progressivement à des environnements de niveau supérieur (tels que la mise en scène et la préproduction) au fur et à mesure que la confiance augmente. En parcourant systématiquement ces environnements, les équipes peuvent vérifier que leurs systèmes tolèrent correctement les défauts injectés avant leur mise en production. Cette progression méthodique garantit qu'au moment où les expériences de chaos sont menées dans les environnements de production, les équipes ont acquis une confiance substantielle dans les capacités de résilience de leur système. Le processus du jour du match est une approche proactive visant à identifier les faiblesses et les vulnérabilités de l'architecture et des pratiques opérationnelles d'une application, tout en éliminant le stress lié à l'apprentissage lors d'une interruption de production imprévue.
## La valeur de l'ingénierie du chaos
Les systèmes complexes sont omniprésents dans le monde d'aujourd'hui. Ils jouent un rôle essentiel dans de nombreux aspects de notre vie, des marchés financiers aux soins de santé. Nous nous attendons à ce que ces systèmes soient toujours opérationnels. Cependant, les systèmes complexes sont souvent vulnérables à des événements et à des comportements inattendus qui peuvent avoir des conséquences importantes. Organisations doivent planifier les perturbations au lieu de se demander si elles vont se produire. Ils peuvent le faire en appliquant des tests de scénarios à l'ensemble de leurs services commerciaux critiques ou stratégiques. C'est là que l'ingénierie du chaos entre en jeu.
L'ingénierie du chaos propose une approche pour gérer des systèmes complexes qui peut aider à atténuer les risques et à améliorer la résilience. Le processus de préparation des expériences sur le chaos oblige les équipes à élaborer des hypothèses sur le comportement de leur système, ce qui leur permet de mieux comprendre comment les systèmes sont construits et comment ils fonctionnent. Cette préparation révèle souvent des lacunes mentales, des connaissances architecturales et des connaissances opérationnelles qui pourraient autrement rester inconnues. En approfondissant la compréhension de la façon dont les systèmes complexes réagissent aux défaillances, l'ingénierie du chaos favorise une plus grande transparence et une plus grande responsabilité dans la conception et la gestion des systèmes. Plus votre organisation pratique fréquemment l'ingénierie du chaos, mieux elle est préparée sur le plan opérationnel. L'ingénierie du chaos vous aide à établir les meilleures pratiques pour concevoir des applications résilientes capables de résister aux défaillances des composants avec un impact minimal, voire nul, sur les utilisateurs. Cela garantit que les applications critiques fonctionnent dans les limites des niveaux de service et de tolérance aux impacts attendus, tout en améliorant continuellement les connaissances de l'équipe sur ses propres systèmes.
## Préparation aux conditions défavorables
Lorsque vous vous basez sur AWS, vous utilisez différents types de services, notamment des services zonaux tels qu'Amazon Elastic Compute Cloud (Amazon EC2), des services régionaux tels qu'Amazon Simple Storage Service (Amazon S3), des services mondiaux Gestion des identités et des accès AWS tels que (IAM), des services tiers sous forme de service (SaaS) et des services sur site. Chaque type de service expose différents domaines de défaillance dont vous devez tenir compte. Comment vous préparez-vous à faire face à des événements auto-infligés ou à des événements provoqués par des tiers sur lesquels votre organisation n'a aucun contrôle ?
Pour mieux comprendre comment votre application peut réagir à des conditions défavorables, vous pouvez utiliser [AWS Fault Injection Service (AWS FIS)](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html). AWS FIS est un service entièrement géré permettant d'exécuter des expériences d'injection de défauts de manière contrôlée. Vous pouvez utiliser ce service pour injecter des scénarios AWS fournis, tels que des interruptions de courant dans la zone de disponibilité et des problèmes de connectivité entre régions, ou pour créer vos propres expériences en regroupant une grande variété d'actions de défaillance fournies par le service. AWS FIS permet à vos équipes de s'entraîner en permanence et d'apprendre comment leur application réagirait aux défaillances courantes et corrigerait les défauts au fur et à mesure qu'elles les détectent.
## Pratiquer l'ingénierie du chaos contrôlée
Les principes clés des expériences de chaos contrôlé sont les suivants :
+ Commencez par un environnement similaire à votre environnement de production.
+ Établissez une hypothèse et arrêtez les conditions de votre expérience.
+ Commencez à petite échelle.
+ Prenez le contrôle de vos expériences sur le chaos.
+ Définissez l'étendue de l'impact.
+ Connaissez votre base de service.
+ Planifiez des expériences.
+ Corrigez d'abord, puis expérimentez.
+ Surveillez l'expérience de près.
+ Tirez des leçons de vos résultats.
+ Hiérarchisez les résultats, corrigez et vérifiez.
+ Diffusez les connaissances acquises au sein de votre organisation.
Pour réussir à étendre l'ingénierie du chaos, vous devez mettre en œuvre des expériences sur le chaos de manière contrôlée. Lorsque vous l'utilisez AWS FIS, vous pouvez créer des conditions d'arrêt à l'aide des [ CloudWatchalarmes Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html). Vous pouvez intégrer ces conditions dans un modèle d'expérience pour vous assurer que les expériences sont arrêtées en cas de dépassement des limites et ramenées à leur dernier état connu. AWS FIS fournit également des leviers de sécurité. Lorsque vous actionnez ces leviers, toutes les expériences en cours dans le compte sont arrêtées et AWS FIS annulées Région AWS, y compris les expériences multi-comptes, et empêche le démarrage de nouvelles expériences. Cela empêche l'injection de défauts pendant certaines périodes, telles que les heures de négociation, les événements commerciaux ou les lancements de produits, ou en réponse à des alarmes relatives à l'état d'une application. Le levier de sécurité reste enclenché jusqu'à ce qu'il soit débrayé manuellement.
Lorsque vous menez une expérience chaotique, vous devez définir des mesures de protection pour éviter les effets secondaires indésirables dans l'environnement, en particulier s'il est possible que l'expérience affecte les applications en production. Lorsque vous planifiez l'expérience, anticipez les effets indésirables qu'elle pourrait avoir sur les autres applications de l'environnement. Par exemple, d'autres applications peuvent recevoir des messages erronés de la part de l'application participant à l'expérience, recevoir des volumes de demandes élevés ou rencontrer des problèmes de ressources si elles partagent une infrastructure. Documentez ces risques et corrigez tout problème connu ou inacceptable avant de lancer l'expérience.