View a markdown version of this page

REL08-BP03 Intégrer les tests de résilience dans le cadre de votre déploiement - AWS Well-Architected Framework

REL08-BP03 Intégrer les tests de résilience dans le cadre de votre déploiement

Intégrez des tests de résilience en introduisant consciemment des défaillances dans le système afin de mesurer sa fonctionnalité en cas de scénarios perturbateurs. Les tests de résilience sont différents des tests unitaires et fonctionnels qui sont généralement intégrés dans les cycles de déploiement, car ils se concentrent sur l’identification des défaillances imprévues de votre système. Bien qu’il soit prudent de commencer par l’intégration des tests de résilience en pré-production, fixez-vous comme objectif d’implémenter ces tests en production dans le cadre de vos journées de simulation.

Résultat souhaité : les tests de résilience contribuent à renforcer la confiance dans la capacité du système à résister à la dégradation en cours de production. Les expériences identifient les points faibles susceptibles d’entraîner une défaillance, ce qui vous permet d’améliorer le système afin d’atténuer automatiquement et efficacement les défaillances et la dégradation.

Anti-modèles courants :

  • Manque d’observabilité et de surveillance dans les processus de déploiement

  • Dépendance à l’humain pour résoudre les défaillances du système

  • Mécanismes d’analyse de mauvaise qualité

  • Accent mis sur les problèmes connus d’un système et manque d’expérimentation pour identifier les problèmes inconnus

  • Identification des défaillances, mais pas de solution

  • Aucune documentation sur les résultats ni aucun runbook

Avantages de la mise en place de cette bonne pratique : les tests de résilience intégrés à vos déploiements permettent d’identifier les problèmes système inconnus qui, autrement, passeraient inaperçus, ce qui pourrait entraîner des interruptions en production. L’identification de ces problèmes système inconnus vous permet de documenter les résultats, d’intégrer les tests dans votre processus CI/CD et de créer des runbooks, ce qui simplifie leur atténuation grâce à des mécanismes efficaces et reproductibles.

Niveau de risque exposé si cette bonne pratique n’est pas respectée : moyen

Directives d’implémentation

Les formes de test de résilience les plus courantes pouvant être intégrées dans les déploiements de votre système sont la reprise après sinistre et l’ingénierie du chaos.

  • Incluez des mises à jour de vos plans de reprise après sinistre et de vos procédures opérationnelles standard (SOP) lors de tout déploiement important.

  • Intégrez des tests de fiabilité à vos pipelines de déploiement automatisés. Des services comme AWS Resilience Hub peuvent être intégrés à votre pipeline CI/CD pour établir des évaluations de résilience continues qui sont automatiquement évaluées dans le cadre de chaque déploiement.

  • Définissez vos applications dans AWS Resilience Hub. Les évaluations de résilience génèrent des extraits de code qui vous aident à créer des procédures de restauration sous forme de documents AWS Systems Manager pour vos applications et fournissent une liste de moniteurs et d’alarmes Amazon CloudWatch recommandés.

  • Une fois vos plans de reprise après sinistre et vos SOP mis à jour, effectuez des tests de reprise après sinistre pour vérifier leur efficacité. Les tests de reprise après sinistre contribuent à déterminer si vous pouvez restaurer votre système après un événement et revenir à un fonctionnement normal. Vous pouvez simuler différentes stratégies de reprise après sinistre et déterminer si votre planification est suffisante pour répondre à vos exigences de disponibilité. Les stratégies courantes de reprise après sinistre incluent la sauvegarde et la restauration, l’environnement en veille, la veille à froid, la veille à chaud, la veille permanente et la veille active/active. Elles diffèrent toutes en termes de coût et de complexité. Avant les tests de reprise après sinistre, nous vous recommandons de définir votre objectif de temps de restauration (RTO) et votre objectif de point de reprise (RPO) afin de simplifier le choix de la stratégie à simuler. AWS propose des outils de reprise après sinistre comme Reprise après sinistre AWS Elastic pour vous aider à démarrer votre planification et vos tests.

  • Les expériences d’ingénierie du chaos introduisent des perturbations dans le système, telles que des pannes de réseau et des pannes de service. En simulant le système avec des pannes contrôlées, vous pouvez en découvrir les vulnérabilités tout en limitant les impacts des pannes injectées. Tout comme les autres stratégies, exécutez des simulations de pannes contrôlées dans des environnements hors production à l’aide de services comme AWS Fault Injection Service pour gagner en confiance avant le déploiement en production.

Ressources

Documents connexes :

Vidéos connexes :