# FIA 12. Comment tester la fiabilité ?
Une fois que vous avez conçu votre charge de travail pour qu’elle soit résiliente aux sollicitations de la production, les tests sont le seul moyen de s’assurer qu’elle fonctionne comme prévu et d’obtenir la résilience voulue.
**Topics**
+ [
# REL12-BP01 Utiliser des playbooks pour enquêter sur les causes des défaillances
](rel_testing_resiliency_playbook_resiliency.md)
+ [
# REL12-BP02 Effectuer une analyse post-incident
](rel_testing_resiliency_rca_resiliency.md)
+ [
# REL12-BP03 Tester les exigences de capacité de mise à l’échelle et de performances
](rel_testing_resiliency_test_non_functional.md)
+ [
# REL12-BP04 Tester la résilience à l’aide de l’ingénierie du chaos
](rel_testing_resiliency_failure_injection_resiliency.md)
+ [
# REL12-BP05 Organiser régulièrement des tests de simulation de panne
](rel_testing_resiliency_game_days_resiliency.md)
# REL12-BP01 Utiliser des playbooks pour enquêter sur les causes des défaillances
Consignez le processus d’enquête dans des playbooks afin de faciliter l’application de réponses cohérentes et rapides face aux scénarios de défaillance qui ne sont pas bien compris. Les playbooks sont les étapes prédéfinies suivies pour identifier les facteurs adjuvants à un scénario de défaillance. Les résultats des étapes du processus sont utilisés pour déterminer les prochaines mesures à prendre jusqu’à ce que la question soit identifiée ou remontée.
Le playbook est une planification proactive que vous devez appliquer afin de pouvoir prendre efficacement des mesures réactives. Lorsque des scénarios de défaillance ne figurant pas dans le playbook sont rencontrés en production, commencez par résoudre le problème (éteindre l’incendie). Procédez ensuite à une rétrospective en examinant les étapes suivies pour résoudre le problème et utilisez-les pour ajouter une nouvelle entrée dans le playbook.
Notez que les playbooks sont utilisés en réponse à des incidents spécifiques, tandis que les runbooks le sont pour obtenir des résultats spécifiques. En règle générale, les runbooks sont employés pour les activités de routine et les playbooks pour répondre à des événements non réguliers.
**Anti-modèles courants :**
+ Planification du déploiement d’une charge de travail sans connaître les processus permettant de diagnostiquer les problèmes ou de réagir aux incidents.
+ Décisions imprévues sur les systèmes à partir desquels peut se faire la collecte des journaux et métriques lors de l’examen d’un événement.
+ Non-conservation des métriques et événements pendant suffisamment longtemps pour pouvoir récupérer les données.
**Avantages du respect de cette bonne pratique :** la capture de playbooks garantit le respect constant des processus. La codification de vos playbooks limite l’introduction d’erreurs à partir de l’activité manuelle. L’automatisation des playbooks accélère le temps de réponse à un événement en évitant aux membres de l’équipe d’intervenir ou en leur fournissant des informations supplémentaires lorsque leur intervention commence.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé
## Directives d’implémentation
+ Utilisez des playbooks pour identifier les problèmes. Les playbooks sont des processus documentés pour enquêter sur les problèmes. Mettez en œuvre des réponses cohérentes et rapides aux échecs en documentant les processus dans des playbooks. Les playbooks doivent contenir les informations et les instructions nécessaires pour permettre à une personne compétente de recueillir les informations pertinentes, identifier les causes potentielles de défaillance, isoler les pannes et déterminer les facteurs adjuvants (c’est-à-dire effectuer une analyse post-incident).
+ Mettez en œuvre les playbooks en tant que code. Effectuez vos opérations en tant que code en scriptant vos playbooks afin d’en assurer la cohérence et de limiter les erreurs causées par les processus manuels. Les playbooks peuvent être composés de plusieurs scripts représentant les différentes étapes qui pourraient être nécessaires pour identifier les facteurs contribuant à un problème. Les activités de runbook peuvent être invoquées ou effectuées dans le cadre d’activités de playbook, ou peuvent demander l’exécution d’un playbook en réponse à des événements identifiés.
+ [Automatisez vos playbooks opérationnels avec AWS Systems Manager](https://aws.amazon.com/about-aws/whats-new/2019/11/automate-your-operational-playbooks-with-aws-systems-manager/)
+ [Run Command d’AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Présentation de AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ [Qu’est-ce qu’Amazon EventBridge ?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Utilisation d’alarmes Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
## Ressources
**Documents connexes :**
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Run Command d’AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html)
+ [Automatisez vos playbooks opérationnels avec AWS Systems Manager](https://aws.amazon.com/about-aws/whats-new/2019/11/automate-your-operational-playbooks-with-aws-systems-manager/)
+ [Utilisation d’alarmes Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Utilisation de scripts Canary (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Qu’est-ce qu’Amazon EventBridge ?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Présentation de AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
**Exemples connexes :**
+ [Automatisation des opérations avec les playbooks et les runbooks](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
# REL12-BP02 Effectuer une analyse post-incident
Passez en revue les événements ayant un impact sur le client et identifiez les facteurs adjuvants et les mesures préventives. Utilisez ces informations pour développer des mesures d’atténuation afin de limiter ou d’empêcher la récurrence. Développez des procédures pour fournir des réponses rapides et efficaces. Publiez, le cas échéant, les facteurs adjuvants et les mesures correctives adaptées au public ciblé. Vous devez disposer d’une méthode pour communiquer ces causes à d’autres si nécessaire.
Évaluez pourquoi les tests existants n’ont pas permis de résoudre le problème. Ajoutez des tests pour ce cas si aucun test correspondant n’existe.
**Résultat escompté :** vos équipes ont adopté une approche cohérente et convenue pour gérer l’analyse post-incident. L’un des mécanismes est le [processus de correction d’erreur (COE)](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/). Celui-ci aide vos équipes à identifier, comprendre et traiter les causes profondes des incidents, tout en mettant en place des mécanismes et des barrières de protection pour limiter la probabilité qu’un incident se reproduise.
**Anti-modèles courants :**
+ Trouver des facteurs adjuvants sans pour autant continuer à chercher plus en profondeur d’autres problèmes et approches potentiels pour atténuer les risques.
+ Identification limitée aux causes d’erreur humaine et sans formation ou automatisation pouvant empêcher les erreurs humaines.
+ Se concentrer sur les reproches plutôt que sur la compréhension des causes profondes, ce qui crée une culture de la peur et empêche de communiquer ouvertement
+ Absence de partage d’informations, qui entrave la circulation des résultats de l’analyse de l’incident et empêche les autres de bénéficier des enseignements tirés
+ Absence de mécanisme permettant de capturer les connaissances institutionnelles, ce qui engendre une perte d’informations précieuses en ne conservant pas les enseignements tirés sous la forme de bonnes pratiques actualisées, et entraîne la répétition d’incidents ayant des causes profondes identiques ou similaires
**Avantages du respect de cette bonne pratique :** une analyse post-incident et le partage des résultats permettent à d’autres charges de travail d’atténuer les risques si elles ont mis en œuvre les mêmes facteurs adjuvants. Elle permet aussi de mettre en œuvre l’atténuation des risques ou la récupération automatisée avant qu’un incident ne se produise.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé
## Directives d’implémentation
Une bonne analyse post-incident permet de proposer des solutions courantes pour les problèmes avec des modèles d’architecture utilisés dans d’autres compartiments de vos systèmes.
La documentation et la résolution des problèmes sont l’une des pierres angulaires du processus COE. Il est recommandé de définir une méthode normalisée pour documenter les causes profondes et de veiller à ce qu’elles soient examinées et traitées. Attribuez clairement la responsabilité du processus d’analyse post-incident. Désignez une équipe ou une personne chargée de superviser les enquêtes et le suivi de l’incident.
Encouragez une culture axée sur l’apprentissage et l’amélioration plutôt que sur les reproches. Insistez sur le fait que l’objectif est de prévenir de futurs incidents, et non de pénaliser des individus.
Élaborez des procédures bien définies pour mener les analyses post-incident. Ces procédures doivent décrire les étapes à suivre, les informations à collecter et les principales questions à aborder lors de l’analyse. Enquêtez en profondeur sur les incidents, en allant au-delà des causes immédiates afin d’identifier les causes profondes et les facteurs contributifs. Utilisez des techniques telles que les *[« cinq pourquoi »](https://en.wikipedia.org/wiki/Five_whys)* pour approfondir les problèmes sous-jacents.
Tenez un répertoire des enseignements tirés des analyses des incidents. Ces connaissances institutionnelles peuvent servir de référence pour les incidents futurs et les efforts de prévention. Partagez les résultats et les réflexions tirées des analyses post-incident, et envisagez d’organiser des réunions de synthèse post-incident ouvertes à tous pour discuter des enseignements tirés.
### Étapes d’implémentation
+ Veillez à ce que l’analyse post-incident soit exempte de tout reproche. Cela permet aux personnes impliquées dans l’incident de faire preuve d’objectivité quant aux actions correctives proposées, et de promouvoir une auto-évaluation et une collaboration honnêtes entre les équipes.
+ Définissez une méthode standardisée pour documenter les problèmes critiques. Voici un exemple de structure :
+ Que s’est-il passé ?
+ Quel a été l’impact sur vos clients et votre activité ?
+ Quelle était la cause profonde ?
+ Quelles sont les données à votre disposition pour étayer votre raisonnement ?
+ Par exemple, des métriques et des graphiques.
+ Quelles ont été les principales répercussions, notamment en termes de sécurité ?
+ Lors de la conception des charges de travail, vous faites un compromis entre les piliers en fonction de votre activité. Ces décisions professionnelles peuvent orienter vos priorités en matière d’ingénierie. Vous pouvez opter pour l’optimisation afin de réduire les coûts au détriment de la fiabilité dans les environnements de développement ou, pour les solutions stratégiques, vous pouvez optimiser la fiabilité pour des coûts plus importants. La sécurité est toujours une priorité, car vous devez protéger vos clients.
+ Quelles leçons avez-vous apprises ?
+ Quelles mesures correctives allez-vous prendre ?
+ Éléments d’action
+ Éléments connexes
+ Élaborez des procédures opérationnelles standard bien définies pour mener les analyses post-incident.
+ Mettez en place un processus standardisé de signalement des incidents. Documentez tous les incidents de manière exhaustive, y compris le rapport d’incident initial, les journaux, les communications et les mesures prises pendant l’incident.
+ N’oubliez pas qu’un incident n’est pas forcément une panne. Il peut s’agir d’un accident évité de justesse ou d’un système qui fonctionne de manière inattendue tout en remplissant sa fonction.
+ Améliorez sans cesse votre processus d’analyse post-incident en fonction des retours et des enseignements tirés.
+ Capturez les principales conclusions dans un système de gestion des connaissances et examinez les modèles qui devraient être ajoutés aux guides du développeur ou aux listes de contrôle de prédéploiement.
## Ressources
**Documents connexes :**
+ [Pourquoi mettre en place la correction des erreurs (COE)](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/)
**Vidéos connexes :**
+ [ Amazon’s approach to failing successfully ](https://aws.amazon.com/builders-library/amazon-approach-to-failing-successfully/)
+ [AWS re:Invent 2021 - Amazon Builders’ Library: Operational Excellence at Amazon ](https://www.youtube.com/watch?v=7MrD4VSLC_w)
# REL12-BP03 Tester les exigences de capacité de mise à l’échelle et de performances
Utilisez des techniques telles que les tests de charge pour valider que la charge de travail répond aux exigences de mise à l’échelle et de performances.
Dans le cloud, vous pouvez créer un environnement de test à l’échelle de la production pour votre charge de travail à la demande. Au lieu de vous fier à un environnement de test réduit, qui pourrait entraîner des prévisions inexactes des comportements de production, vous pouvez utiliser le cloud pour provisionner un environnement de test qui reflète étroitement votre environnement de production attendu. Cet environnement vous permet de réaliser des tests dans le cadre d’une simulation plus précise des conditions réelles auxquelles votre application est confrontée.
Parallèlement aux tests de performance, il est essentiel de vérifier que vos ressources de base, vos paramètres de mise à l’échelle, vos quotas de service et votre conception de la résilience fonctionnent comme prévu sous charge. Cette approche globale garantit que votre application peut être mise à l’échelle de manière fiable et fonctionner selon les besoins, même dans les conditions les plus exigeantes.
**Résultat escompté :** votre charge de travail conserve son comportement attendu même lorsqu’elle est soumise à des pics de charge. Vous abordez de manière proactive tous les problèmes liés aux performances susceptibles de survenir au fur et à mesure que l’application grandit et évolue.
**Anti-modèles courants :**
+ Vous utilisez des environnements de test qui ne correspondent pas étroitement à l’environnement de production.
+ Vous considérez les tests de charge comme une activité ponctuelle distincte plutôt que comme une partie intégrante du pipeline d’intégration continue (CI) du déploiement.
+ Vous ne définissez pas d’exigences de performances claires et mesurables, telles que des cibles de temps de réponse, de débit et de capacité de mise à l’échelle.
+ Vous effectuez des tests avec des scénarios de charge non réalistes ou insuffisants, et vous ne parvenez pas à tester les pics de charge, les pics soudains ou une charge élevée prolongée.
+ Vous n’effectuez pas de test de stress de la charge de travail en dépassant les limites de charge attendues.
+ Vous utilisez des outils de test de charge ou de profilage des performances inadaptés ou inappropriés.
+ Vous ne disposez pas de systèmes complets de surveillance et d’alerte pour effectuer le suivi des métriques de performances et détecter les anomalies.
**Avantages liés au respect de cette bonne pratique :**
+ Les tests de charge vous aident à identifier les goulots d’étranglement potentiels de performances de votre système avant sa mise en production. Lorsque vous simulez le trafic et les charges de travail au niveau de la production, vous pouvez identifier les domaines dans lesquels votre système peut avoir du mal à gérer la charge, tels que de longs délais de réponse, des contraintes de ressources ou des défaillances du système.
+ En testant votre système dans différentes conditions de charge, vous pouvez mieux comprendre les exigences en matière de ressources pour prendre en charge votre charge de travail. Ces informations peuvent vous aider à prendre des décisions éclairées concernant l’allocation des ressources et à éviter un surprovisionnement ou un sous-provisionnement des ressources.
+ Pour identifier les points de défaillance potentiels, vous pouvez observer les performances de votre charge de travail dans des conditions de charge élevée. Ces informations vous aident à améliorer la fiabilité et la résilience de votre charge de travail en mettant en œuvre des mécanismes de tolérance aux pannes, des stratégies de basculement ou des mesures de redondance, selon le cas.
+ Vous identifiez et traitez les problèmes de performances à un stade précoce, ce qui vous permet d’éviter les conséquences coûteuses de pannes du système, de longs délais de réponse et d’utilisateurs mécontents.
+ Les données de performances et les informations de profilage détaillées collectées lors des tests peuvent vous aider à résoudre les problèmes liés aux performances susceptibles de survenir en production. Cela peut conduire à une réponse et une résolution plus rapides des incidents, ce qui réduit l’impact sur les utilisateurs et les opérations de votre organisation.
+ Dans certains secteurs, les tests de performances proactifs peuvent aider votre charge de travail à respecter les normes de conformité, réduisant ainsi le risque de pénalités ou de problèmes juridiques.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé
## Directives d’implémentation
La première étape consiste à définir une stratégie de tests complète qui couvre tous les aspects des exigences de mise à l’échelle et de performances. Pour commencer, définissez clairement les objectifs de niveau de service (SLO) de votre charge de travail en fonction des besoins de votre entreprise, tels que le débit, l’histogramme de latence et le taux d’erreur. Concevez ensuite une suite de tests capables de simuler différents scénarios de charge allant d’une utilisation moyenne à des pics soudains et des pics de charge prolongés, et vérifiez que le comportement de la charge de travail respecte vos objectifs de niveau de service. Ces tests doivent être automatisés et intégrés dans votre pipeline d’intégration et de déploiement continus afin de détecter les régressions de performances de façon précoce dans le processus de développement.
Pour tester efficacement la mise à l’échelle et les performances, investissez dans les outils et l’infrastructure appropriés. Cela inclut des outils de test de charge capables de générer un trafic utilisateur réaliste, des outils de profilage des performances pour identifier les goulots d’étranglement et des solutions de surveillance pour suivre les métriques clés. Il est important de vérifier que vos environnements de test correspondent étroitement à l’environnement de production en termes d’infrastructure et de conditions d’environnement afin que les résultats de vos tests soient aussi précis que possible. Pour faciliter la réplication et la mise à l’échelle fiables de configurations de type production, utilisez une infrastructure en tant que code et des applications basées sur des conteneurs.
Les tests de mise à l’échelle et de performances sont un processus continu et non une activité ponctuelle. Mettez en œuvre une surveillance et des alertes complètes pour suivre les performances de l’application en production, et utilisez ces données pour affiner en permanence vos stratégies de test et vos efforts d’optimisation. Analysez régulièrement les données de performances pour identifier les problèmes émergents, tester les nouvelles stratégies de mise à l’échelle et mettre en œuvre des optimisations afin d’améliorer l’efficacité et la fiabilité de l’application. Lorsque vous adoptez une approche itérative et que vous tirez constamment des enseignements des données de production, vous pouvez vérifier que votre application peut s’adapter aux demandes variables des utilisateurs et maintenir une résilience et des performances optimales au fil du temps.
### Étapes d’implémentation
1. Établissez des exigences de performances claires et mesurables, telles que des cibles de temps de réponse, de débit et de capacité de mise à l’échelle. Ces exigences doivent être basées sur les modèles d’utilisation de votre charge de travail, les attentes des utilisateurs et les besoins de votre entreprise.
1. Sélectionnez et configurez un outil de test de charge capable d’imiter avec précision les modèles de charge et le comportement des utilisateurs dans votre environnement de production.
1. Configurez un environnement de test correspondant étroitement à l’environnement de production, y compris aux conditions d’infrastructure et d’environnement, afin d’améliorer la précision des résultats de vos tests.
1. Créez une suite de tests couvrant un large éventail de scénarios, allant de modèles d’utilisation moyenne à des pics de charge, à des pics rapides et à des charges élevées prolongées. Intégrez ces tests dans vos processus d’intégration et de déploiement continus afin de détecter les régressions de performances de façon précoce dans le processus de développement.
1. Effectuez des tests de charge pour simuler le trafic utilisateur réel et comprendre le comportement de votre application dans différentes conditions de charge. Pour effectuer un test de stress de votre application, dépassez la charge attendue et observez son comportement, tel qu’une dégradation du temps de réponse, l’épuisement des ressources ou des défaillances du système, afin d’identifier le point de rupture de votre application et d’élaborer des stratégies de mise à l’échelle. Évaluez la capacité de mise à l’échelle de votre charge de travail en augmentant progressivement la charge, et mesurez l’impact sur les performances pour identifier les limites de mise à l’échelle et planifier les besoins futurs de capacité.
1. Mettez en œuvre une surveillance et des alertes complètes pour suivre les métriques de performances, détecter les anomalies et lancer des actions de mise à l’échelle ou des notifications lorsque les seuils sont dépassés.
1. Surveillez et analysez en permanence les données de performances pour identifier les domaines à améliorer. Itérez sur vos stratégies de test et vos efforts d’optimisation.
## Ressources
**Bonnes pratiques associées :**
+ [REL01-BP04 Surveiller et gérer les quotas](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_manage_service_limits_monitor_manage_limits.html)
+ [REL06-BP01 Surveiller tous les composants de la charge de travail (génération)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_monitor_resources.html)
+ [REL06-BP03 Envoyer des notifications (traitement et alarmes en temps réel)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_notification_monitor.html)
**Documents connexes :**
+ [Tests de charge des applications](https://docs.aws.amazon.com/prescriptive-guidance/latest/load-testing/welcome.html)
+ [Test de charge distribuée sur AWS](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/)
+ [Surveillance des performances d’application](https://aws.amazon.com/what-is/application-performance-monitoring/)
+ [Politique de test d’Amazon EC2](https://aws.amazon.com/ec2/testing/)
**Exemples connexes :**
+ [Test de charge distribuée sur AWS (GitHub)](https://github.com/aws-solutions/distributed-load-testing-on-aws)
**Outils associés :**
+ [Amazon CodeGuru Profiler](https://docs.aws.amazon.com/codeguru/latest/profiler-ug/what-is-codeguru-profiler.html)
+ [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html)
+ [Apache JMeter](https://jmeter.apache.org/)
+ [K6](https://k6.io/)
+ [Vegeta](https://github.com/tsenart/vegeta)
+ [Hey](https://github.com/rakyll/hey)
+ [ab](https://httpd.apache.org/docs/2.4/programs/ab.html)
+ [wrk](https://github.com/wg/wrk)
+ [Test de charge distribuée sur AWS](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/)
# REL12-BP04 Tester la résilience à l’aide de l’ingénierie du chaos
Exécutez régulièrement des expériences de chaos dans des environnements dont les conditions se rapprochent autant que possible de la production pour comprendre comment nos systèmes réagissent à des conditions défavorables.
** Résultat escompté : **
la résilience de la charge de travail est régulièrement vérifiée en appliquant l’ingénierie du chaos sous la forme d’expériences d’injection de pannes ou de charge inattendue, en plus des tests de résilience qui confirment le comportement attendu connu de votre charge de travail lors d’un événement. Associez l’ingénierie du chaos aux tests de résilience pour avoir l’assurance que votre charge de travail peut résister en cas de défaillance des composants et récupérer suite à des perturbations inattendues avec peu ou pas d’impact.
** Anti-modèles courants : **
+ Conception à des fins de résilience, mais pas de vérification du fonctionnement de la charge de travail dans son ensemble en cas de défaillances.
+ Pas d’expériences dans des conditions concrètes et pour la charge prévue.
+ Pas de traitement de vos expériences en tant que code ou de maintenance de vos expériences tout au long du cycle de développement.
+ Pas d’exécution d’expériences de chaos dans le cadre de votre pipeline CI/CD, ainsi qu’en dehors des déploiements.
+ Pas d’utilisation des analyses passées post-incident pour déterminer les défaillances à tester.
** Avantages du respect de cette bonne pratique :** l’injection de défaillances pour vérifier la résilience de votre charge de travail vous permet d’avoir l’assurance que les procédures de récupération de votre conception résiliente fonctionneront en cas de défaillances réelles.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen
## Directives d’implémentation
L’ingénierie du chaos offre la possibilité à vos équipes d’injecter en continu des perturbations concrètes (simulations) de manière contrôlée au niveau du fournisseur de services, de l’infrastructure, de la charge de travail et des composants, avec peu ou pas d’impact pour vos clients. Ainsi, vos équipes tirent les leçons de ces défaillances et observent, mesurent et améliorent la résilience de vos charges de travail, tout en confirmant que les alertes se déclenchent et que les équipes sont informées en cas d’événement.
Une pratique de l’ingénierie du chaos en continu peut mettre en évidence des défaillances dans vos charges de travail qui, si elles ne sont pas résolues, peuvent impacter de manière négative la disponibilité et le fonctionnement.
**Note**
L’ingénierie du chaos est la discipline d’expérimentation d’un système. Elle permet de s’assurer de la capacité du système à résister à des conditions de production difficiles. – [Principes de l’ingénierie du chaos](https://principlesofchaos.org/)
Si un système est capable de résister à ces perturbations, l’expérience de chaos doit être maintenue en tant que test de régression automatisé. De cette façon, les expériences de chaos doivent être réalisées dans le cadre de votre cycle de développement des systèmes et de votre pipeline CI/CD.
Pour veiller à ce que votre charge de travail résiste en cas de défaillance des composants, injectez des événements concrets dans le cadre de vos expériences. Par exemple, expérimentez une perte des instances Amazon EC2 ou un basculement de l’instance de base de données Amazon RDS principale, puis vérifiez que votre charge de travail n’est pas impactée (ou très peu). Utilisez plusieurs défaillances des composants pour simuler des événements capables de causer une perturbation dans une zone de disponibilité.
Pour les défaillances de niveau application (telles que les plantages), commencez par des tests de stress comme l’épuisement de la mémoire et du processeur.
Afin de valider des [mécanismes de remplacement ou de basculement](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/) pour les dépendances externes dues aux pannes réseau intermittentes, vos composants doivent simuler un tel événement en bloquant l’accès aux fournisseurs tiers pendant une durée spécifiée pouvant aller de quelques secondes à plusieurs heures.
D’autres modes de dégradation peuvent entraîner des fonctionnalités limitées et ralentir les réponses, ce qui se traduit par une perturbation de vos services. Généralement, cette dégradation résulte d’une latence accrue sur les services critiques et d’une communication réseau peu fiable (perte de paquets). Les expériences avec ces défaillances, dont les effets de mise en réseau tels que la latence, les messages supprimés et les défaillances DNS, peuvent inclure l’incapacité de résoudre un nom, d’atteindre un service DNS ou de se connecter aux services dépendants.
**Outils de l’ingénierie du chaos :**
AWS Fault Injection Service (AWS FIS) est un service entièrement géré permettant l’exécution d’expériences d’injection de pannes qui peuvent être utilisées dans le cadre de votre pipeline CD, ou en dehors du pipeline. AWS FIS s’impose donc comme un choix judicieux lors des tests de simulation de pannes. Il prend en charge l’introduction simultanée de défaillances sur différents types de ressources, notamment Amazon EC2, Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS) et Amazon RDS. Ces défaillances incluent l’arrêt des ressources, les basculements forcés, le stress du processeur ou de la mémoire, la limitation, la latence et la perte de paquets. Comme il est intégré aux alarmes Amazon CloudWatch, vous pouvez définir des conditions d’arrêt comme barrières de protection pour annuler une expérience si elle provoque un impact inattendu.
![\[Schéma montrant que AWS Fault Injection Service s’intègre aux ressources AWS pour vous permettre d’exécuter des expériences d’injection de pannes pour vos charges de travail.\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/latest/framework/images/fault-injection-simulator.png)
Il existe également plusieurs options tierces pour les expériences d’injection de pannes. Il s’agit notamment d’outils open source tels que [Chaos Toolkit](https://chaostoolkit.org/), [Chaos Mesh](https://chaos-mesh.org/) et [Litmus Chaos](https://litmuschaos.io/), ainsi que d’options commerciales telles que Gremlin. Pour élargir le champ des pannes pouvant être injectées sur AWS, AWS FIS [s’intègre à Chaos Mesh et Litmus Chaos](https://aws.amazon.com/about-aws/whats-new/2022/07/aws-fault-injection-simulator-supports-chaosmesh-litmus-experiments/), ce qui vous permet de coordonner les flux de travail d’injection de pannes entre plusieurs outils. Par exemple, vous pouvez exécuter un test de stress sur un processeur de pod à l’aide des défaillances Chaos Mesh ou Litmus, tout en arrêtant un pourcentage de nœuds de cluster sélectionné de façon aléatoire grâce aux actions des défaillances AWS FIS.
## Étapes d’implémentation
1. Déterminez les défaillances à utiliser pour les expériences.
Évaluez la conception de votre charge de travail à des fins de résilience. Ces conceptions (créées selon les bonnes pratiques du [cadre Well-Architected](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html)) tiennent compte des risques basés sur les dépendances critiques, les événements passés, les problèmes connus et les exigences de conformité. Répertoriez chaque élément de la conception destiné à maintenir la résilience et les défaillances qu’il entend réduire. Pour plus d’informations sur la création de telles listes, consultez le [livre blanc consacré à l’examen de la préparation opérationnelle](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html), qui explique comment créer un processus visant à empêcher que de tels incidents ne se reproduisent. Le processus de Failure Modes and Effects Analysis (FMEA) ou d’analyse des modes de défaillance et de leurs effets vous propose un framework pour réaliser une analyse de niveau composant des défaillances et de leur impact sur votre charge de travail. Le FMEA est décrit plus en détail par Adrian Cockcroft dans [Failure Modes and Continuous Resilience](https://adrianco.medium.com/failure-modes-and-continuous-resilience-6553078caad5).
1. Attribuer une priorité à chaque défaillance.
Commencez par définir une classification grossière telle que élevée, moyenne et basse. Pour évaluer les priorités, tenez compte de la fréquence de la défaillance et de son impact sur la charge de travail dans son ensemble.
Lors de la prise en compte de la fréquence d’une défaillance donnée, analysez les données passées de cette charge de travail, le cas échéant. Si aucune donnée passée n’est disponible, utilisez les données des autres charges de travail s’exécutant dans un environnement semblable.
Lors de la prise en compte de l’impact d’une défaillance donnée, souvenez-vous qu’en général plus le champ de la défaillance est large, plus grand est l’impact. Tenez compte également de la conception de la charge de travail et de son objectif. Par exemple, la capacité à accéder aux magasins de données sources est essentielle pour une charge de travail effectuant des transformations et de l’analyse de données. Dans ce cas, vous donnerez la priorité aux expériences liées aux défaillances d’accès ainsi qu’aux accès limités et à l’insertion de la latence.
Les analyses post-incident constituent une excellente source de données pour comprendre à la fois la fréquence et l’impact des modes de défaillance.
Utilisez la priorité attribuée pour déterminer les défaillances à expérimenter en premier lieu, puis l’ordre dans lequel développer de nouvelles expériences d’injection de pannes.
1. Suivre le volant d’inertie de l’ingénierie du chaos et de la résilience continue figurant sur la figure suivante pour chaque expérience réalisée.
![\[Schéma du volant d’inertie de l’ingénierie du chaos et de la résilience continue montrant les phases Améliorer, État stable, Hypothèse, Exécuter l’expérience et Vérifier.\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/latest/framework/images/chaos-engineering-flywheel.png)
1. Définir l’état stable comme le résultat mesurable d’une charge de travail qui indique un comportement normal.
Votre charge de travail présente un état stable si elle fonctionne de manière fiable et comme prévu. Par conséquent, confirmez que votre charge de travail est saine avant de définir un état stable. L’état stable ne signifie pas forcément sans impact pour la charge de travail en cas de défaillance, car un certain pourcentage des défaillances n’excède pas des limites supportables. L’état stable constitue le repère que vous observerez pendant l’expérience, qui mettra en évidence des anomalies si votre hypothèse formulée dans l’étape suivante ne donne pas les résultats escomptés.
Par exemple, un état stable d’un système de paiements peut être défini comme le traitement de 300 TPS avec un taux de réussite de 99 % et un temps de transmission aller-retour de 500 ms.
1. Formuler une hypothèse sur la façon dont la charge de travail réagira à la défaillance.
Une bonne hypothèse repose sur la façon dont la charge de travail est destinée à réduire la défaillance pour maintenir l’état stable. L’hypothèse indique que vu qu’il s’agit d’une défaillance d’un type particulier, le système ou la charge de travail maintiendra un état stable, car la charge de travail a été conçue avec une atténuation des risques spécifique. Le type particulier de défaillance et d’atténuation des risques doit être spécifié dans l’hypothèse.
Le modèle suivant peut être utilisé pour l’hypothèse (mais une autre formulation est aussi acceptable) :
**Note**
En cas de *panne spécifique*, le *nom de la charge de travail* *décrira les contrôles d’atténuation* visant à maintenir l’*impact des métriques commerciales ou techniques*.
Par exemple :
+ Si 20 % des nœuds du node-group Amazon EKS sont supprimés, l’API Transaction Create continue de répondre au 99e centile des demandes en moins de 100 ms (état stable). Les nœuds Amazon EKS seront opérationnels dans les cinq minutes, et les pods seront planifiés et traiteront le trafic huit minutes après le début de l’expérience. Les alertes se déclencheront sous trois minutes.
+ En cas de défaillance d’une seule instance Amazon EC2, la surveillance de l’état Elastic Load Balancing du système de commandes permet à Elastic Load Balancing d’envoyer uniquement des demandes aux instances saines restantes, tandis qu’Amazon EC2 Auto Scaling remplace l’instance en échec, tout en maintenant une augmentation des erreurs (5xx) côté serveur (état stable) inférieure à 0,01 %.
+ Si l’instance de base de données Amazon RDS principale échoue, la charge de travail de collecte des données Chaîne d’approvisionnement basculera et se connectera à l’instance de base de données Amazon RDS de secours pour maintenir les erreurs de lecture ou d’écriture de base de données (état stable) inférieures à 1 minute.
1. Exécuter l’expérience en injectant la défaillance.
Une expérience doit par défaut être sécurisée et tolérée par la charge de travail. Si vous savez que la charge de travail va échouer, n’exécutez pas l’expérience. L’ingénierie du chaos doit être utilisée pour rechercher les risques connus ou inconnus. Les risques *connus* sont des choses dont vous êtes conscient mais que vous ne comprenez pas complètement, et les risques *inconnus* sont des choses dont vous n’êtes pas conscient et que vous ne comprenez pas complètement. Exécuter une expérience sur une charge de travail que vous savez défaillante ne vous apportera rien de plus. Votre expérience doit être soigneusement préparée, disposer d’un champ d’impact défini et fournir un mécanisme de protection pouvant être appliqué en cas de perturbations inattendues. Si votre vérification préalable indique que votre charge de travail doit résister à l’expérience, exécutez cette dernière. Il existe plusieurs moyens d’injecter les défaillances. Pour les charges de travail sur AWS, [AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html) fournit de nombreuses simulations de pannes prédéfinies appelées [actions](https://docs.aws.amazon.com/fis/latest/userguide/actions.html). Vous pouvez également définir des actions personnalisées qui s’exécutent dans AWS FIS à l’aide des [documents AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-ssm-docs.html).
Nous déconseillons l’utilisation de scripts personnalisés pour les expériences de chaos, sauf si ces derniers sont capables de comprendre l’état actuel de la charge de travail, d’émettre des journaux, de fournir des mécanismes de protection pour annuler une expérience et des conditions d’arrêt dans la mesure du possible.
Un framework ou des outils efficaces capables de prendre en charge l’ingénierie du chaos doivent suivre l’état actuel d’une expérience, émettre des journaux et fournir des mécanismes de protection pour prendre en charge l’exécution contrôlée d’une expérience. Commencez par un service établi comme AWS FIS qui vous permet d’exécuter des expériences avec un champ clairement défini et des mécanismes de sécurité capables de protéger l’expérience en cas de perturbations inattendues. Pour en savoir plus sur une plus grande variété d’expériences utilisant AWS FIS, consultez également l’[atelier Applications résilientes et Well-Architected avec l’ingénierie du chaos](https://catalog.us-east-1.prod.workshops.aws/workshops/44e29d0c-6c38-4ef3-8ff3-6d95a51ce5ac/en-US). [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) analysera votre charge de travail et créera des expériences que vous pourrez choisir d’implémenter et d’exécuter dans AWS FIS.
**Note**
Pour chaque expérience, vous devez bien comprendre le champ et son impact. Nous recommandons que les défaillances soient d’abord simulées sur un environnement hors production avant d’être exécutées en production.
Les expériences doivent être menées en production sous une charge réelle à l’aide de [déploiements Canary](https://medium.com/the-cloud-architect/chaos-engineering-q-a-how-to-safely-inject-failure-ced26e11b3db) qui permettent de déployer à la fois un système de contrôle et un déploiement de système expérimental, dans la mesure du possible. L’exécution d’expériences pendant les heures creuses est une bonne pratique pour réduire l’impact potentiel de la première expérience en production. De plus, si l’utilisation du trafic client réel s’avère trop risquée, vous pouvez exécuter des expériences à l’aide du trafic synthétique sur l’infrastructure de production pour des déploiements de système de contrôles et d’expériences. Lorsqu’une exécution en production n’est pas possible, exécutez les expériences dans des environnements de pré-production aussi proches que possible de la production.
Vous devez définir des barrières de protection pour veiller à ce que l’expérience n’impacte pas le trafic de la production ou d’autres systèmes au-delà des limites acceptables. Définissez des conditions d’arrêt pour stopper une expérience si elle atteint le seuil d’une métrique de barrière de protection défini par vos soins. Ces conditions doivent inclure les métriques de l’état stable de la charge de travail, ainsi que celles sur les composants dans lesquels vous injectez la défaillance. Un [moniteur synthétique](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) (également appelée un utilisateur canary) est une métrique que vous devez généralement inclure en tant que proxy utilisateur. [Les conditions d’arrêt de AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/stop-conditions.html) sont prises en charge dans le cadre d’un modèle de test, autorisant jusqu’à cinq conditions d’arrêt par modèle.
L’un des principes de l’ingénierie du chaos est de minimiser le champ de l’expérience et son impact :
Bien qu’un impact négatif à court terme soit autorisé, l’ingénieur du chaos a la responsabilité et l’obligation de minimiser et de maîtriser les conséquences des expériences.
Pour vérifier le champ et l’impact potentiel, vous pouvez dans un premier temps exécuter l’expérience dans un environnement hors production, en vérifiant que les seuils des conditions d’arrêt s’activent comme prévu pendant l’expérience et que l’observabilité est en place pour détecter une exception, plutôt que d’exécuter l’expérience directement en production.
Lorsque vous exécutez des expériences d’injection de pannes, vérifiez que toutes les parties responsables sont bien informées. Communiquez avec les équipes appropriées, telles que les équipes en charge des opérations, les équipes chargées de la fiabilité du service et le service client pour leur indiquer quand les expériences seront exécutées et à quoi ils doivent s’attendre. Donnez à ces équipes les outils de communication nécessaires pour informer les personnes en charge de l’exécution de l’expérience si elles constatent des effets négatifs.
Vous devez restaurer la charge de travail et ses systèmes sous-jacents dans leur état fonctionnel et connu d’origine. En général, la conception résiliente de la charge de travail lui permet de s’auto-réparer. Cependant, certaines conceptions défaillantes ou échecs d’expériences peuvent laisser votre charge de travail dans un état d’échec inattendu. À la fin de l’expérience, vous devez en être conscient et restaurer la charge de travail et les systèmes. Avec AWS FIS, vous pouvez définir une configuration de barrière de protection (également appelée post action) dans les paramètres d’action. Une post action restaure la cible dans l’état dans lequel elle se trouvait avant l’exécution de l’action. Qu’elles soient automatisées (comme lorsque vous utilisez AWS FIS) ou manuelles, ces post actions doivent faire partie d’un playbook décrivant la façon de détecter et de gérer les échecs.
1. Vérifier l’hypothèse.
[Principes de l’ingénierie du chaos](https://principlesofchaos.org/) donne des conseils sur la façon de vérifier l’état stable de votre charge de travail :
Concentrez-vous sur le résultat mesurable d’un système, plutôt que sur les attributs internes du système. Les mesures de ce résultat sur une courte période de temps constituent un proxy pour l’état stable du système. Le débit général du système, les taux d’erreur et les centiles de latence peuvent tous être des métriques d’intérêt représentant un comportement d’état stable. En se focalisant sur les modèles de comportement systémique pendant les expériences, l’ingénierie du chaos vérifie que le système fonctionne, au lieu d’essayer de confirmer qu’il fonctionne.
Dans nos deux exemples précédents, nous incluons la métrique de l’état stable inférieure à 0,01 % d’augmentation des erreurs (5xx) côté serveur et la métrique inférieure à 1 minute d’erreurs de lecture ou d’écriture de base de données.
Les erreurs 5xx constituent une bonne métrique, car elles sont une conséquence du mode de défaillance dont le client de la charge de travail fera l’expérience directement. La mesure des erreurs de base de données est correcte en tant que conséquence directe de la défaillance, mais doit être également complétée par une mesure d’impact, telle que les échecs de demandes client ou les erreurs remontées. Par ailleurs, incluez une surveillance synthétique (également appelée utilisateur canary) sur n’importe quelle API ou URI directement accessible par le client de votre charge de travail.
1. Améliorer la conception de la charge de travail à des fins de résilience.
Si l’état stable n’a pas été maintenu, enquêtez sur les moyens d’améliorer la conception de la charge de travail afin de réduire la défaillance, tout en appliquant les bonnes pratiques du [pilier AWS Well-Architected Reliability](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html). Vous trouverez des conseils et des ressources supplémentaires dans la [AWS Builder’s Library](https://aws.amazon.com/builders-library/), qui contient des articles sur la manière d’[améliorer vos surveillances de l’état](https://aws.amazon.com/builders-library/implementing-health-checks/) ou d’[utiliser des nouvelles tentatives avec retard dans le code de votre application](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/), entre autres.
Une fois ces changements implémentés, exécutez de nouveau l’expérience (illustrée par la ligne pointillée dans le volant d’inertie de l’ingénierie du chaos) pour déterminer son efficacité. Si l’étape de vérification indique que l’hypothèse est vraie, alors la charge de travail sera en état stable et le cycle continuera.
1. Exécuter régulièrement des expériences.
Une expérience de chaos est un cycle, et les expériences doivent être exécutées régulièrement dans le cadre de l’ingénierie du chaos. Lorsqu’une charge de travail correspond à l’hypothèse d’une expérience, cette dernière doit être automatisée pour s’exécuter en continu en tant que test de régression de votre pipeline CI/CD. Pour savoir comment procéder, consultez ce blog sur [la façon de mener des expériences AWS FIS à l’aide d’AWS CodePipeline](https://aws.amazon.com/blogs/architecture/chaos-testing-with-aws-fault-injection-simulator-and-aws-codepipeline/). Ce laboratoire sur les [expériences AWS FIS récurrentes dans un pipeline CI/CD](https://chaos-engineering.workshop.aws/en/030_basic_content/080_cicd.html) vous permet de travailler sur le terrain.
Les expériences d’injection de pannes font également partie des tests de simulation de pannes (consultez [REL12-BP05 Organiser régulièrement des tests de simulation de panne](rel_testing_resiliency_game_days_resiliency.md)). Les tests de simulation de pannes simulent une défaillance ou un événement pour vérifier les systèmes, les processus et la réponse de l’équipe. L’objectif est d’effectuer les actions que l’équipe effectuerait si un événement exceptionnel se produisait.
1. Enregistrer et stocker les résultats des expériences.
Les résultats des expériences d’injection de pannes doivent être enregistrés et conservés. Incluez toutes les données nécessaires (telles que l’heure, la charge de travail et les conditions) afin de pouvoir analyser ultérieurement les résultats de l’expérience et les tendances. Les exemples de résultats peuvent inclure des captures d’écran des tableaux de bord, des fichiers CSV de la base de données de votre/vos métriques ou un registre manuscrit des événements et observations pendant l’expérience. [La journalisation des expériences avec AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/monitoring-logging.html) peut faire partie de cette capture de données.
## Ressources
**Bonnes pratiques associées:**
+ [REL08-BP03 Intégrer les tests de résilience dans le cadre de votre déploiement](rel_tracking_change_management_resiliency_testing.md)
+ [REL13-BP03 Effectuer un test de validation de la mise en œuvre de la reprise après sinistre](rel_planning_for_recovery_dr_tested.md)
**Documents connexes:**
+ [Qu’est-ce qu AWS Fault Injection Service?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
+ [Qu'est-ce que AWS Resilience Hub?](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html)
+ [Principes de l’ingénierie du chaos](https://principlesofchaos.org/)
+ [Ingénierie du chaos : préparation de votre première expérience](https://medium.com/the-cloud-architect/chaos-engineering-part-2-b9c78a9f3dde)
+ [Ingénierie de résilience : apprendre à intégrer les pannes](https://queue.acm.org/detail.cfm?id=2371297)
+ [Témoignages d’utilisation de l’ingénierie du chaos](https://github.com/ldomb/ChaosEngineeringPublicStories)
+ [Éviter les solutions de secours dans les systèmes distribués](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/)
+ [Déploiement canary pour des expériences de chaos](https://medium.com/the-cloud-architect/chaos-engineering-q-a-how-to-safely-inject-failure-ced26e11b3db)
**Vidéos connexes :**
+ [AWS re:Invent 2020: Testing resiliency using chaos engineering (ARC316)](https://www.youtube.com/watch?v=OlobVYPkxgg)
+ [AWS re:Invent 2019: Improving resiliency with chaos engineering (DOP309-R1)](https://youtu.be/ztiPjey2rfY)
+ [AWS re:Invent 2019: Performing chaos engineering in a serverless world (CMY301)](https://www.youtube.com/watch?v=vbyjpMeYitA)
** Outils associés: **
+ [AWS Fault Injection Service](https://aws.amazon.com/fis/)
+ AWS Marketplace: [Gremlin Chaos Engineering Platform](https://aws.amazon.com/marketplace/pp/prodview-tosyg6v5cyney)
+ [Chaos Toolkit](https://chaostoolkit.org/)
+ [Chaos Mesh](https://chaos-mesh.org/)
+ [Litmus](https://litmuschaos.io/)
# REL12-BP05 Organiser régulièrement des tests de simulation de panne
Organisez des tests de simulation de panne pour tester régulièrement vos procédures de réponse aux événements et aux déficiences ayant un impact sur la charge de travail. Impliquez les mêmes équipes qui seraient chargées de traiter les scénarios de production. Ces exercices permettent de mettre en œuvre des mesures visant à prévenir l’impact des événements de production sur les utilisateurs. Lorsque vous mettez en pratique vos procédures de réponse dans des conditions réalistes, vous pouvez identifier et corriger toute lacune ou faiblesse avant l’avènement d’un événement réel.
Les tests de simulation de panne simulent des événements dans des environnements de type production pour tester les systèmes, les processus et la réponse de votre équipe. L’objectif est d’effectuer les mêmes actions que l’équipe effectuerait si l’événement se produisait réellement. Ces exercices vous aident à comprendre où apporter des améliorations et comment développer une expérience de gestion des événements et des déficiences au sein de votre organisation. Ces exercices doivent être effectués régulièrement afin que votre équipe développe des automatismes pour mieux réagir.
Les tests de simulation de panne préparent les équipes à gérer les événements de production en toute confiance. Les équipes expérimentées sont plus à même de détecter différents scénarios et d’y réagir rapidement. Cela se traduit par une amélioration significative de l’état de préparation et de la posture de résilience.
**Résultat escompté :** vous planifiez et effectuez régulièrement des tests de simulation sur la résilience. Ces tests de simulation de panne sont considérés comme un élément normal et attendu de l’activité de l’entreprise. Votre organisation a développé une culture de préparation et lorsque des problèmes de production surviennent, vos équipes sont bien préparées pour réagir promptement, résoudre efficacement les problèmes et atténuer leur impact sur les clients.
**Anti-modèles courants :**
+ Vous documentez vos procédures sans jamais vous exercer à les appliquer.
+ Vous excluez les décideurs d’entreprise des exercices de test.
+ Vous organisez des tests de simulation de panne, mais vous n’informez pas toutes les parties prenantes concernées.
+ Vous vous concentrez uniquement sur les défaillances techniques, mais vous n’impliquez pas les parties prenantes de l’entreprise.
+ Vous n’incorporez pas les leçons apprises lors des tests de simulation de panne dans vos processus de reprise.
+ Vous blâmez les équipes pour les échecs et les bogues.
**Avantages liés au respect de cette bonne pratique :**
+ Amélioration des compétences en matière de réponse : lors des tests de simulation de panne, les équipes s’exercent à réaliser leurs tâches et testent leurs mécanismes de communication, ce qui leur permet de réagir de façon plus coordonnée et efficace dans le cadre de situations de production.
+ Identification et traitement des dépendances : les environnements complexes impliquent souvent des dépendances complexes entre différents systèmes, services et composants. Les tests de simulation de panne peuvent vous aider à identifier et à traiter ces dépendances, ainsi qu’à vérifier que vos systèmes et services critiques sont correctement couverts par vos procédures de dossier d¦exploitation et peuvent être augmentés verticalement ou récupérés en temps opportun.
+ Promotion d’une culture de résilience : les tests de simulation de panne peuvent aider à développer un état d’esprit de résilience au sein d’une organisation. Lorsqu’ils impliquent des parties prenantes et des équipes interfonctionnelles, ces exercices favorisent la prise de conscience, la collaboration et une compréhension commune de l’importance de la résilience dans l’ensemble de l’organisation.
+ Amélioration et adaptation continues : des tests de simulation de panne réguliers vous aident à évaluer en permanence vos stratégies de résilience et à les adapter, afin de les maintenir pertinentes et efficaces face à des circonstances changeantes.
+ Renforcement de la confiance dans le système : des tests de simulation de panne réussis peuvent vous aider à renforcer la confiance dans la capacité du système à résister aux perturbations et à s’en remettre.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen
## Directives d’implémentation
Une fois que vous avez conçu et mis en œuvre les mesures de résilience nécessaires, organisez des tests de simulation de panne pour confirmer que tout fonctionne comme prévu en production. Les tests de simulation de panne, en particulier la première fois, doivent impliquer tous les membres de l’équipe, et l’ensemble des parties prenantes et des participants doivent être informés à l’avance de la date, de l’heure et des scénarios simulés.
Pendant les tests de simulation de panne, les équipes impliquées simulent divers événements et scénarios potentiels conformément aux procédures prescrites. Les participants surveillent de près et évaluent l’impact de ces événements simulés. Si le système fonctionne comme prévu, les mécanismes automatisés de détection, de mise à l’échelle et de réparation automatique devraient s’activer et n’entraîner que peu ou pas d’impact sur les utilisateurs. Si l’équipe constate un impact négatif, elle doit annuler le test et résoudre les problèmes identifiés, soit par des moyens automatisés, soit par une intervention manuelle documentée dans les dossiers d¦exploitation applicables.
Pour améliorer continuellement la résilience, il est essentiel de documenter et d’incorporer les leçons apprises. Ce processus constitue une *boucle de rétroaction* qui capture systématiquement les informations exploitables recueillies pendant les tests de simulation de panne et les utilise pour améliorer les systèmes, les processus et les compétences des équipes.
Pour vous aider à reproduire des scénarios réels dans lesquels des services ou des composants du système peuvent tomber en panne de façon inattendue, injectez des défauts simulés dans un exercice de test de simulation. Les équipes peuvent tester la résilience et la tolérance aux pannes de leurs systèmes et simuler leurs processus de réponse aux incidents et de reprise dans un environnement contrôlé.
Dans AWS, vos tests de simulation de panne peuvent être réalisés avec des réplicas de votre environnement de production en utilisant une infrastructure en tant que code. Ce processus vous permert d’effectuer des tests dans un environnement sûr qui ressemble étroitement à votre environnement de production. Envisagez d’utiliser [AWS Fault Injection Service](https://aws.amazon.com/fis/) pour créer différents scénarios de panne. Utilisez des services tels qu’[Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) et [AWS X-Ray](https://aws.amazon.com/xray/) pour surveiller le comportement du système pendant les tests de simulation de panne. Utilisez [AWS Systems Manager](https://aws.amazon.com/systems-manager/) pour gérer et exécuter les playbooks, et [AWS Step Functions](https://aws.amazon.com/step-functions/) pour orchestrer les flux de travail récurrents des tests de simulation de panne.
### Étapes d’implémentation
+ **Établissez un programme de tests de simulation de panne :** élaborez un programme structuré qui définit la fréquence, la portée et les objectifs des tests de simulation de panne. Impliquez les principales parties prenantes et les experts du domaine concerné dans la planification et l’exécution de ces exercices.
+ **Préparez les tests de simulation de panne :**
1. Identifiez les principaux services essentiels à l’entreprise qui seront au centre des tests de simulation de panne. Cataloguez et cartographiez les personnes, les processus et les technologies qui prennent en charge ces services.
1. Définissez l’ordre du jour des tests de simulation de panne et préparez les équipes impliquées à participer à l’événement. Préparez vos services d’automatisation pour simuler les scénarios planifiés et exécuter les processus de récupération appropriés. Les services AWS tels que [AWS Fault Injection Service](https://aws.amazon.com/fis/), [AWS Step Functions](https://aws.amazon.com/step-functions/) et [AWS Systems Manager](https://aws.amazon.com/systems-manager/) peuvent vous aider à automatiser divers aspects des tests de simulation de panne, tels que l’injection des défauts et le lancement des actions de récupération.
+ **Exécutez votre simulation :** dans le cadre des tests de simulation de panne, exécutez le scénario planifié. Observez et documentez la façon dont les personnes, les processus et les technologies réagissent à l’événement simulé.
+ **Réalisez le bilan de l’exercice :** après les tests de simulation de panne, organisez une séance rétrospective pour passer en revue les enseignements tirés. Identifiez les domaines d’amélioration et les actions nécessaires pour améliorer la résilience opérationnelle. Consignez vos résultats et effectuez le suivi des modifications nécessaires pour améliorer vos stratégies de résilience et votre préparation aux travaux à entreprendre.
## Ressources
**Bonnes pratiques associées :**
+ [REL12-BP01 Utiliser des playbooks pour enquêter sur les causes des défaillances](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_playbook_resiliency.html)
+ [REL12-BP04 Tester la résilience à l’aide de l’ingénierie du chaos](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_failure_injection_resiliency.html)
+ [OPS04-BP01 Identification des indicateurs de rendement clés](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_observability_identify_kpis.html)
+ [OPS07-BP03 Utilisation de runbooks pour effectuer des procédures](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_runbooks.html)
+ [OPS10-BP01 Utilisation d’un processus pour la gestion des événements, des incidents et des problèmes](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_event_incident_problem_process.html)
**Documents connexes :**
+ [Qu’est-ce qu’AWS GameDay ?](https://aws.amazon.com/gameday/)
**Vidéos connexes:**
+ [AWS re:Invent 2023 - Practice like you play: How Amazon scales resilience to new heights](https://www.youtube.com/watch?v=r3J0fEgNCLQ&t=1734s)
**Exemples connexes :**
+ [AWS Atelier – Surmonter la tempête : déclenchement d’un chaos contrôlé pour systèmes résilients](https://catalog.us-east-1.prod.workshops.aws/workshops/eb89c4d5-7c9a-40e0-b0bc-1cde2df1cb97)
+ [Élaboration de tests de simulation de panne en vue de soutenir la résilience opérationnelle](https://aws.amazon.com/blogs/architecture/build-your-own-game-day-to-support-operational-resilience/)