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. # Stratégies d'atténuation communes Pour commencer, pensez à utiliser des mesures d'atténuation *préventives* pour éviter que le mode de défaillance n'ait un impact sur l'histoire de l'utilisateur. Vous devriez alors réfléchir à des *mesures correctives* d'atténuation. Les mesures d'atténuation correctives aident le système à s'auto-guérir ou à s'adapter aux conditions changeantes. Voici une liste des mesures d'atténuation courantes pour chaque catégorie de défaillance qui correspondent aux propriétés de résilience. | | | **Catégorie de défaillance** | **Propriétés de résilience souhaitées** | **Atténuations** | | --- |--- |--- | | Points de défaillance uniques (SPOFs) | Redondance et tolérance aux pannes | Mettez en œuvre [la redondance](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html), par exemple en utilisant plusieurs EC2 instances derrière Elastic Load Balancing (ELB). Supprimez les dépendances sur le [plan de contrôle de service AWS global](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/aws-service-types.html#global-services) et prenez uniquement les dépendances sur les plans de données de service globaux. Utilisez [la dégradation progressive](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_mitigate_interaction_failure_graceful_degradation.html) lorsqu'une ressource n'est pas disponible, afin que votre système soit statiquement stable jusqu'à un point de défaillance unique. | | Charge excessive | Capacité suffisante | [https://aws.amazon.com/builders-library/caching-challenges-and-strategies](https://aws.amazon.com/builders-library/caching-challenges-and-strategies) Vous devez également tenir compte de votre plan de capacité et réfléchir aux futures limites de capacité et de dimensionnement, liées à la fois aux ressources AWS et aux limites de votre système, que vous pourriez atteindre. | | Latence excessive | Sortie en temps opportun | Mettez en œuvre [des délais d'attente](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) configurés de manière appropriée ou des délais d'expiration adaptatifs (en modifiant les valeurs de délai d'attente en fonction des conditions de latence actuelles et prévues afin de permettre à une dépendance lente de progresser au lieu de renoncer à des demandes lentes). [https://aws.amazon.com/builders-library/caching-challenges-and-strategies](https://aws.amazon.com/builders-library/caching-challenges-and-strategies) | | Mauvaise configuration et bogues | Sortie correcte | Le principal moyen de détecter les erreurs fonctionnelles répétables dans les logiciels consiste à effectuer des tests rigoureux au moyen de mécanismes tels que l'[analyse statique](https://en.wikipedia.org/wiki/Static_program_analysis), les [tests unitaires, les tests](https://en.wikipedia.org/wiki/Unit_testing) [d'intégration, les tests](https://en.wikipedia.org/wiki/Integration_testing) de [régression](https://en.wikipedia.org/wiki/Regression_testing), les [tests de charge](https://docs.aws.amazon.com/prescriptive-guidance/latest/load-testing/welcome.html) et les [tests de résilience](https://aws.amazon.com/blogs/architecture/chaos-engineering-in-the-cloud/). Mettez en œuvre des stratégies telles que [l'infrastructure sous forme de code (IaC)](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/infrastructure-as-code.html) et l'[automatisation de l'intégration continue et de la livraison continue (CI/CD)](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments) pour atténuer les menaces liées aux erreurs de configuration. Utilisez des techniques de déploiement telles que les déploiements à [boîtier unique](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/), [les déploiements Canary, les](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/canary-deployments.html) déploiements fractionnés alignés sur les limites d'isolation des pannes ou les [déploiements bleu/vert](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/blue-green-deployments.html) pour réduire les erreurs de configuration et les bogues. | | Un destin partagé | Isolation des défauts | Mettez en œuvre [la tolérance aux pannes](https://aws.amazon.com/builders-library/minimizing-correlated-failures-in-distributed-systems) dans votre système et utilisez des limites logiques et physiques d'isolation des pannes, telles que plusieurs clusters de calcul ou de conteneurs, plusieurs comptes AWS, plusieurs principaux Gestion des identités et des accès AWS (IAM), plusieurs zones de disponibilité, voire plusieurs. Régions AWS Des techniques telles que les [architectures basées sur les cellules](https://youtu.be/swQbA4zub20) et le [shuffle sharding](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding) peuvent également améliorer l'isolation des pannes. Envisagez des modèles tels que le [couplage lâche](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_prevent_interaction_failure_loosely_coupled_system.html) et [la dégradation progressive](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_mitigate_interaction_failure_graceful_degradation.html) pour éviter les défaillances en cascade. Lorsque vous hiérarchisez les user stories, vous pouvez également utiliser cette hiérarchisation pour faire la distinction entre les user stories qui sont essentielles à la fonction commerciale principale et les user stories qui peuvent être dégradées avec élégance. Par exemple, dans un site de commerce électronique, vous ne voudriez pas qu'une altération du widget de promotions du site Web ait un impact sur la capacité de traiter les nouvelles commandes. | Bien que certaines de ces mesures d'atténuation nécessitent un minimum d'efforts pour être mises en œuvre, d'autres (telles que l'adoption d'une architecture basée sur les cellules pour une isolation prévisible des pannes et un minimum de défaillances à destin partagé) peuvent nécessiter une refonte de l'ensemble de la charge de travail et pas seulement des composants d'une histoire utilisateur en particulier. Comme indiqué précédemment, il est important d'évaluer la probabilité et l'impact du mode de défaillance par rapport aux compromis que vous devez faire pour l'atténuer. Outre les techniques d'atténuation applicables à chaque catégorie de mode de défaillance, vous devez réfléchir aux mesures d'atténuation nécessaires à la restauration de l'histoire utilisateur ou de l'ensemble du système. Par exemple, une panne peut interrompre un flux de travail et empêcher l'écriture des données vers les destinations prévues. Dans ce cas, vous aurez peut-être besoin d'outils opérationnels pour relancer le flux de travail ou corriger manuellement les données. Vous devrez peut-être également intégrer un mécanisme de point de contrôle à votre charge de travail pour éviter les pertes de données en cas de défaillance. Il se peut également que vous deviez créer un cordon andon pour interrompre le flux de travail et arrêter d'accepter de nouvelles tâches afin d'éviter de nouveaux dommages. Dans ces cas, vous devez réfléchir aux outils opérationnels et aux glissières de sécurité dont vous avez besoin. Enfin, vous devez toujours partir du principe que les humains commettront des erreurs lors de l'élaboration de votre stratégie d'atténuation. Bien que DevOps les pratiques modernes visent à automatiser les opérations, les humains doivent toujours interagir avec vos charges de travail pour diverses raisons. Une action humaine incorrecte peut entraîner une défaillance dans l'une des catégories SEEMS, par exemple en supprimant un trop grand nombre de nœuds pendant la maintenance et en provoquant une surcharge, ou en définissant un indicateur de fonctionnalité de manière incorrecte. Ces scénarios constituent un véritable échec en matière de garde-corps préventifs. Une analyse des causes profondes ne doit jamais aboutir à la conclusion qu' « un humain a commis une erreur ». Il devrait plutôt aborder les raisons pour lesquelles des erreurs étaient possibles au départ. Par conséquent, votre stratégie d'atténuation doit tenir compte de la manière dont les opérateurs humains peuvent interagir avec les composants de la charge de travail et de la manière de prévenir ou de minimiser l'impact des erreurs des opérateurs grâce à des glissières de sécurité.