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.
# Étape 3 : Évaluer et tester
Au cours de la phase d'*évaluation et de test* du cycle de vie, l'application, ou les modifications apportées à une application existante, ont été conçues mais n'ont pas encore été mises en production. À ce stade, vous mettez en œuvre des activités pour tester les pratiques mises en œuvre lors des étapes précédentes et évaluer les résultats. L'application est peut-être toujours en cours de développement, ou le développement principal est peut-être terminé et l'application est peut-être en cours de test avant sa mise en production. Au cours de cette étape, vous vous concentrez sur le développement et l'exécution de tests qui confirment ou réfutent les attentes selon lesquelles l'application atteindra les objectifs de résilience définis. De plus, vous développez et testez les procédures opérationnelles du système. Les procédures de déploiement que vous avez développées à l'[étape 2 : Conception et mise en œuvre](stage-2.md) sont mises en pratique et les résultats sont évalués. Bien que ces activités de test et d'évaluation commencent au cours de cette partie du cycle de vie, elles ne s'arrêtent pas là. Les tests et les évaluations se poursuivent au fur et à mesure que vous passez à l'[étape 4 : exploitation](stage-4.md).
La phase *d'évaluation et de test* est divisée en deux phases : les activités [préalables au déploiement et les activités](pre-deployment.md) [post-déploiement](post-deployment.md). Les activités de pré-déploiement consistent en des tâches qui doivent être effectuées avant de déployer l'application dans n'importe quel environnement, y compris le déploiement de nouvelles versions du logiciel ainsi que le déploiement initial dans un environnement de test. Les activités de post-déploiement ont lieu après le déploiement du logiciel dans un environnement de test ou de production. Les sections suivantes traitent de ces phases plus en détail.
# Activités préalables au déploiement
## Conception de l'environnement
L'environnement dans lequel vous testez et évaluez votre application influe sur la précision avec laquelle vous pouvez la tester et sur votre degré de confiance dans le fait que ces résultats reflètent fidèlement ce qui se passera en production. Vous pouvez peut-être effectuer des tests d'intégration localement sur les machines des développeurs en utilisant des services tels qu'Amazon DynamoDB (voir [Configuration de DynamoDB en local dans la documentation DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DynamoDBLocal.html)). Cependant, à un moment donné, vous devez effectuer des tests dans un environnement qui reproduit votre environnement de production afin d'obtenir des résultats aussi fiables que possible. Cet environnement étant coûteux, nous vous recommandons d'adopter une approche progressive, ou en pipeline, dans le cadre de laquelle les environnements de type production apparaîtront plus tard dans le pipeline.
## Tests d'intégration
Les tests d'intégration sont le processus qui consiste à vérifier qu'un composant bien défini d'une application exécute correctement ses fonctions lorsqu'il fonctionne avec des dépendances externes. Ces dépendances externes peuvent être d'autres composants développés sur mesure, AWS des services que vous utilisez pour votre application, des dépendances tierces et des dépendances sur site. Ce guide se concentre sur les tests d'intégration qui démontrent la résilience de votre application. Cela suppose qu'il existe déjà des tests unitaires et d'intégration qui démontrent la précision fonctionnelle de votre logiciel.
Nous vous recommandons de concevoir des tests d'intégration qui testent spécifiquement les modèles de résilience que vous avez mis en œuvre, tels que les modèles de disjoncteurs ou le délestage (voir [Étape 2 : Conception et mise en œuvre](stage-2.md)). [Les tests d'intégration axés sur la résilience impliquent souvent d'appliquer une charge spécifique à l'application ou d'introduire intentionnellement des perturbations dans l'environnement en utilisant des fonctionnalités telles que AWS Fault Injection Service ().AWS FIS](https://aws.amazon.com/fis/) Idéalement, vous devez exécuter tous les tests d'intégration dans le cadre de votre CI/CD pipeline et vous assurer d'exécuter des tests chaque fois que le code est validé. Cela vous permet de détecter et de réagir rapidement à toute modification du code ou des configurations qui entraîne des violations de vos objectifs de résilience. Les applications distribuées à grande échelle sont complexes, et même des modifications mineures peuvent avoir un impact significatif sur la résilience de parties apparemment indépendantes de votre application. Essayez d'exécuter vos tests à chaque validation. AWS fournit un excellent ensemble d'outils pour faire fonctionner votre CI/CD pipeline et d'autres DevOps outils. Pour plus d'informations, consultez la section [Introduction à DevOps on AWS](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/introduction-to-devops.html) sur le AWS site Web.
## Pipelines de déploiement automatisés
Le déploiement et les tests dans vos environnements de pré-production sont des tâches répétitives et complexes qu'il est préférable de laisser à l'automatisation. L'automatisation de ce processus libère des ressources humaines et réduit les risques d'erreur. Le mécanisme d'automatisation de ce processus est souvent appelé *pipeline*. Lorsque vous créez votre pipeline, nous vous recommandons de configurer une série d'environnements de test qui se rapprochent de plus en plus de votre configuration de production. Vous utilisez cette série d'environnements pour tester votre application à plusieurs reprises. Le premier environnement fournit un ensemble de fonctionnalités plus limité que l'environnement de production, mais son coût est nettement inférieur. Les environnements suivants devraient ajouter des services et évoluer pour mieux refléter l'environnement de production.
Commencez par tester dans le premier environnement. Une fois que vos déploiements ont réussi tous vos tests dans le premier environnement de test, laissez l'application s'exécuter sous une certaine charge pendant un certain temps pour voir si des problèmes surviennent au fil du temps. Vérifiez que vous avez correctement configuré l'observabilité (voir *Précision des alarmes* plus loin dans ce guide) afin de pouvoir détecter tout problème éventuel. Lorsque cette période d'observation s'est terminée avec succès, déployez votre application dans votre environnement de test suivant et répétez le processus en ajoutant des tests ou une charge supplémentaires selon les besoins de l'environnement. Après avoir suffisamment testé votre application de cette manière, vous pouvez utiliser les méthodes de déploiement que vous avez précédemment configurées pour déployer l'application en production (voir *Définir les stratégies CI/CD* plus haut dans ce guide). L'article [Automating safe and handoff deployments](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/) in the Amazon Builders' Library est une excellente ressource qui décrit comment Amazon automatise le déploiement du code. Le nombre d'environnements qui précèdent votre déploiement en production varie en fonction de la complexité de votre application et des types de dépendances qu'elle comporte.
## Test de charge
À première vue, les tests de charge ressemblent à des tests d'intégration. Vous testez une fonction discrète de votre application et ses dépendances externes pour vérifier qu'elle fonctionne comme prévu. Les tests de charge vont ensuite au-delà des tests d'intégration pour se concentrer sur le fonctionnement de l'application sous des charges bien définies. Les tests de charge nécessitent la vérification des fonctionnalités correctes. Ils doivent donc être effectués après un test d'intégration réussi. Il est important de comprendre dans quelle mesure l'application répond aux charges attendues et comment elle se comporte lorsque la charge dépasse les attentes. Cela vous permet de vérifier que vous avez mis en œuvre les mécanismes nécessaires pour garantir la résilience de votre application en cas de charge extrême. Pour un guide complet sur les tests de charge AWS, voir [Test de charge distribué sur AWS](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/) la bibliothèque de AWS solutions.
# Activités postérieures au déploiement
La résilience est un processus continu et l'évaluation de la résilience de votre application doit se poursuivre après le déploiement de l'application. Les résultats de vos activités post-déploiement, telles que les évaluations continues de la résilience, peuvent nécessiter que vous réévaluiez et mettiez à jour certaines des activités de résilience que vous avez effectuées plus tôt dans le cycle de vie de résilience.
## Réalisation d'évaluations de résilience
L'évaluation de la résilience ne s'arrête pas une fois que vous avez déployé votre application en production. Même si vous disposez de pipelines de déploiement bien définis et automatisés, les modifications peuvent parfois se produire directement dans un environnement de production. En outre, il se peut que vous n'ayez pas encore pris en compte certains facteurs lors de votre vérification de résilience avant le déploiement. [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html)fournit un emplacement central où vous pouvez évaluer si votre architecture déployée répond à vos besoins définis en matière de RPO et de RTO. Vous pouvez utiliser ce service pour effectuer des évaluations à la demande de la résilience de votre application, automatiser les évaluations et même les intégrer dans vos outils CI/CD, comme indiqué dans le billet de AWS blog [Évaluation continue de la résilience des applications avec AWS Resilience Hub](https://aws.amazon.com/blogs/architecture/continually-assessing-application-resilience-with-aws-resilience-hub-and-aws-codepipeline/) et. AWS CodePipeline L'automatisation de ces évaluations est une bonne pratique car elle permet de garantir que vous évaluez en permanence votre posture de résilience en production.
## tests de reprise après sinistre
Au cours de l'[étape 2 : Conception et mise en œuvre](stage-2.md), vous avez développé des stratégies de reprise après sinistre (DR) intégrées à votre système. Au cours de l'étape 4, vous devez tester vos procédures de reprise après sinistre pour vous assurer que votre équipe est parfaitement préparée à un incident et que vos procédures fonctionnent comme prévu. Vous devez tester régulièrement toutes vos procédures de reprise après sinistre, y compris le basculement et le retour en arrière, et examiner les résultats de chaque exercice pour déterminer si et comment les procédures de votre système doivent être mises à jour pour obtenir les meilleurs résultats possibles. Lorsque vous développez initialement votre test DR, planifiez le test bien à l'avance et assurez-vous que toute l'équipe comprend à quoi s'attendre, comment les résultats seront mesurés et quel mécanisme de feedback sera utilisé pour mettre à jour les procédures en fonction des résultats. Une fois que vous aurez acquis les compétences nécessaires pour exécuter des tests de reprise après sinistre planifiés, pensez à exécuter des tests de reprise après sinistre inopinés. Les véritables catastrophes ne se produisent pas selon un calendrier, vous devez donc être prêt à mettre en œuvre votre plan à tout moment. Cependant, inopiné ne signifie pas imprévu. Les principales parties prenantes doivent encore planifier l'événement pour s'assurer qu'une surveillance appropriée est en place et que les clients et les applications critiques ne sont pas affectés négativement.
## Détection des écarts
Des modifications imprévues de configuration dans les applications de production peuvent se produire même lorsque l'automatisation et des procédures bien définies sont en place. Pour détecter les modifications apportées à la configuration de votre application, vous devez disposer de mécanismes permettant de détecter les *dérives*, c'est-à-dire les écarts par rapport à une configuration de référence. Pour savoir comment détecter la dérive dans vos AWS CloudFormation piles, consultez la section [Détection des modifications de configuration non gérées apportées aux piles et aux ressources](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html) dans la documentation. AWS CloudFormation Pour détecter la dérive dans l' AWS environnement de votre application, consultez la section [Détecter et résoudre la dérive AWS Control Tower dans](https://docs.aws.amazon.com/controltower/latest/userguide/drift.html) la AWS Control Tower documentation.
## Tests synthétiques
Les [tests synthétiques](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) sont le processus de création de logiciels configurables qui s'exécutent en production, sur une base planifiée, afin de tester votre application de APIs manière à simuler l'expérience de l'utilisateur final. Ces tests sont parfois appelés *canaris*, en référence à l'utilisation initiale du terme dans les mines de charbon. Les tests synthétiques peuvent souvent fournir des alertes précoces lorsqu'une application subit une interruption, même si celle-ci est partielle ou intermittente, comme c'est souvent le cas pour les [défaillances grises](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html).
## Ingénierie du chaos
L'ingénierie du chaos est un processus systématique qui consiste à soumettre délibérément une application à des événements perturbateurs de manière à atténuer les risques, à surveiller de près sa réponse et à mettre en œuvre les améliorations nécessaires. Son objectif est de valider ou de remettre en question les hypothèses concernant la capacité de l'application à gérer de telles perturbations. Au lieu de laisser ces événements au hasard, l'ingénierie du chaos permet aux ingénieurs d'orchestrer des expériences dans un environnement contrôlé, généralement pendant les périodes de faible trafic, avec un support technique facilement disponible pour une atténuation efficace.
L'ingénierie du chaos commence par la compréhension des conditions de fonctionnement normales, appelées *régime permanent*, de l'application considérée. À partir de là, vous formulez une hypothèse qui détaille le comportement efficace de l'application en cas de perturbation. Vous exécutez l'expérience, qui implique l'injection délibérée de perturbations, y compris, mais sans s'y limiter, la latence du réseau, les pannes de serveur, les erreurs de disque dur et l'altération des dépendances externes. Vous analysez ensuite les résultats de l'expérience et améliorez la résilience de l'application en fonction de vos apprentissages. L'expérience constitue un outil précieux pour améliorer divers aspects de l'application, notamment ses performances, et permet de découvrir des problèmes latents qui auraient pu rester cachés autrement. En outre, l'ingénierie du chaos permet de révéler les lacunes des outils d'observabilité et d'alarme, et vous aide à les affiner. Cela contribue également à réduire le temps de récupération et à améliorer les compétences opérationnelles. L'ingénierie du chaos accélère l'adoption des meilleures pratiques et cultive un état d'esprit d'amélioration continue. En fin de compte, cela permet aux équipes de développer et de perfectionner leurs compétences opérationnelles grâce à des exercices réguliers et à des répétitions.
AWS vous recommande de commencer vos efforts d'ingénierie du chaos dans un environnement hors production. Vous pouvez utiliser [AWS Fault Injection Service (AWS FIS)](https://aws.amazon.com/fis/) pour exécuter des expériences d'ingénierie du chaos avec des défauts à usage général ainsi que des défauts spécifiques à. AWS Ce service entièrement géré inclut des alarmes d'arrêt et des contrôles complets des autorisations afin que vous puissiez facilement adopter l'ingénierie du chaos en toute sécurité et en toute confiance.