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.
Débuter avec l'ingénierie du chaos
Avant de réaliser une expérience, nous vous recommandons de mettre en place quelques éléments essentiels pour tirer le meilleur parti de vos pratiques d'ingénierie du chaos. Ces éléments essentiels incluent :
-
Observabilité (métriques, journalisation, suivi des demandes)
-
Une liste d'événements ou de failles du monde réel que vous aimeriez explorer
-
Parrainage de la résilience organisationnelle grâce à l'adhésion des dirigeants
-
Priorisation des résultats critiques, en fonction de l'impact commercial potentiel, par rapport aux nouvelles fonctionnalités découvertes lors d'expériences chaotiques
Observabilité pour les expériences sur le chaos
L'observabilité, qui comprend les métriques, la journalisation et le suivi des demandes, joue un rôle clé dans l'ingénierie du chaos. Lorsque vous réalisez un test, vous devez comprendre les indicateurs commerciaux, les indicateurs côté serveur, les indicateurs d'expérience client et les indicateurs opérationnels. Sans observabilité, vous ne serez pas en mesure de définir un comportement en régime permanent ou de créer une expérience significative pour vérifier si votre hypothèse concernant votre application est vraie.
Métriques
Le schéma suivant montre les types de métriques que vous pouvez suivre pour des expériences de chaos pour différents types d'applications.
-
Indicateurs commerciaux — L'état d'équilibre indique le fonctionnement normal de votre système et est défini par vos indicateurs commerciaux. Il peut être représenté par des transactions par seconde (TPS), des flux de clics par seconde, des commandes par seconde ou une mesure similaire. Votre application présente un état d'équilibre lorsqu'elle fonctionne comme prévu. Vérifiez donc que votre application est saine avant de lancer des tests. L'état d'équilibre ne signifie pas nécessairement qu'il n'y aura aucun impact sur l'application en cas de panne, car un pourcentage de défauts peut se situer dans les limites acceptables. L'état d'équilibre est votre point de référence. Par exemple, l'état d'équilibre d'un système de paiement peut être défini comme le traitement de 300 TPS avec un taux de réussite de 99 % et un temps aller-retour de 500 ms. Visuellement, imaginez l'état d'équilibre comme un électrocardiogramme (ECG). Si l'état d'équilibre de votre système fluctue soudainement, vous savez qu'il y a un problème avec votre service.
-
Mesures côté serveur : pour comprendre les performances de vos ressources pendant le test, vous avez besoin d'informations sur leurs performances avant, pendant et après le test. Pour mesurer l'impact de vos ressources sur AWS, vous pouvez utiliser Amazon CloudWatch. CloudWatch est un service qui surveille les applications, répond aux changements de performances, optimise l'utilisation des ressources et fournit des informations sur l'état des opérations. Au cours de vos expériences, vous souhaiterez capturer des métriques côté serveur telles que la saturation, les volumes de demandes, les taux d'erreur et la latence.
-
Indicateurs d'expérience client — Activé AWS, vous pouvez capturer des indicateurs réels des utilisateurs en utilisant CloudWatchRUM pour simuler les demandes des utilisateurs à l'aide d'outils tels que Locust, Grafana k6, Selenium ou Puppeteer. Les indicateurs réels des utilisateurs sont essentiels pour les organisations qui mènent des expériences d'ingénierie du chaos. En surveillant l'impact des utilisateurs réels au cours d'une expérience, les équipes peuvent avoir une idée précise de la manière dont les pannes et les perturbations affecteront les clients en production. Les indicateurs clés de l'expérience client sont le délai jusqu'au premier octet (TTFB), le Largest Contentful Paint (LCP), l'interaction avec le prochain dessin (INP) et le temps de blocage total (TBT).
-
Mesures opérationnelles : les interventions mesurent la capacité à atténuer les défaillances de manière automatisée, par exemple, la latence réussie des demandes des clients lors du redémarrage de pods, de tâches ou d'instances EC2 à l'aide de mécanismes tels que le contrôleur de réplication ou le dimensionnement automatique. La possibilité d'intervenir automatiquement en cas de panne est directement liée à une bonne expérience utilisateur. Il est essentiel de comprendre si ces mécanismes d'atténuation évoluent au fil du temps. En définissant des indicateurs pour les mesures d'atténuation automatisées réussies et échouées, vous créez des repères qui aident à identifier les régressions potentielles dans l'ensemble de votre système.
Logging
La journalisation centralisée est essentielle pour comprendre l'état des composants de votre application avant, pendant et après une expérience chaotique. Nous vous recommandons de collecter les journaux de tous les composants de votre application afin de créer une vue consolidée de ce que faisait chaque composant au moment de l'injection de l'expérience. Cela donne une image claire du déroulement de l' end-to-endexpérience.
Suivi des demandes
Le suivi des demandes vous permet d'observer le flux de chaque demande entre les composants de votre application afin de mieux comprendre l'impact de la panne injectée sur le système et ses dépendances. En suivant les demandes, vous pouvez voir comment la panne se propage entre les différents services et composants, afin de mieux évaluer l'ampleur de la perturbation. Pour suivre vos demandes AWS, vous pouvez utiliser AWS X-Ray.
Scénarios d'échec à intégrer dans les expériences de chaos
L'objectif de l'injection de défauts courants dans votre application est de comprendre comment l'application réagit à ces événements inattendus, afin de créer des mécanismes d'atténuation et de rendre votre système résilient face à de telles défaillances. En outre, vous devez utiliser l'ingénierie du chaos pour rejouer les scénarios de défaillance historiques afin de vérifier que vos mécanismes d'atténuation fonctionnent toujours comme prévu et n'ont pas évolué au fil du temps.
Tenez compte des événements suivants lorsque vous planifiez vos expériences d'ingénierie du chaos.
| Mode de défaillance | Description |
|---|---|
Défaillance du serveur |
Redémarrez les instances EC2, supprimez les pods Kubernetes ou les tâches Amazon Elastic Container Service (Amazon ECS) pour comprendre comment votre application réagit à de tels incidents. |
erreurs d’API |
Injectez AWS des erreurs dans votre propre service APIs afin de comprendre le comportement des applications. |
Problèmes liés au réseau |
Introduisez de la latence ou de la congestion, ou bloquez les connexions pour imiter les problèmes de réseau réels. |
AWS Atteinte à la zone de disponibilité |
Reproduisez l'altération d'une zone de disponibilité complète pour vérifier la reprise dans toutes les zones. |
Région AWS troubles de la connectivité |
Reproduisez une défaillance du réseau Régions AWS pour vérifier comment les ressources de la région secondaire réagissent à un tel événement. |
Défaillances de base |
Basculez sur des répliques de bases de données ou des données corrompues, ou rendez les instances de base de données inaccessibles, afin de comprendre l'impact sur votre application et vos stratégies de restauration. |
Pause de la réplication de la base de données et Amazon S3 |
Interrompez la réplication de la base de données ou d'Amazon Simple Storage Service (Amazon S3) entre les zones de disponibilité Régions AWS ou pour comprendre l'impact des applications en aval. |
Dégradation du stockage |
Interrompez les E/S, supprimez les volumes Amazon Elastic Block Store (Amazon EBS) ou supprimez des fichiers pour vérifier la durabilité et la restauration des données. |
Déficience de dépendance |
Diminuez ou dégradez les performances des services en aval ou en amont dont vous dépendez, y compris les services tiers, afin de comprendre le end-to-end flux et l'impact sur vos clients. |
Hausses de trafic |
Générez des pics de trafic utilisateur pour tester les fonctionnalités de dimensionnement automatique et découvrez comment le temps de démarrage à froid peut avoir un impact sur l'état général de votre application. |
Épuisement des ressources |
Maximisez le processeur, la mémoire et l'espace disque pour vérifier la dégradation progressive de votre application. |
Défaillances en cascade |
Initiez les défaillances principales qui se répercutent sur les applications et les composants en aval. |
Déploiements incorrects |
Déployez les modifications ou les configurations problématiques pour vérifier les mécanismes de restauration. |
Parrainage de la résilience organisationnelle
L'ingénierie du chaos apporte le plus de valeur lorsqu'elle est appliquée à l'ensemble de votre organisation. Nous vous recommandons de travailler avec un sponsor exécutif qui pourra vous aider à définir des objectifs de résilience au sein de votre organisation, à éliminer les craintes, les incertitudes et les doutes concernant le domaine, et à démarrer le processus de transformation afin que la résilience soit la responsabilité de tous.
Pour étayer l'analyse de rentabilisation de la création d'un cabinet d'ingénierie du chaos, associez des efforts d'ingénierie du chaos à vos projets commerciaux critiques. Faire de la résilience un atout et un moteur d'accélération vous aidera à suivre le succès au fil du temps. Commencez par le décompte des incidents critiques par mois ou par trimestre, le délai moyen de reprise et l'impact que ces incidents ont eu sur vos clients et votre entreprise. Fixez l'objectif avec vos équipes de réduire le nombre d'incidents sur une période de 6 à 12 mois à mesure que des améliorations seront apportées à vos piles d'applications en réponse aux expériences d'ingénierie chaotiques.
Mesurez si les incidents sont très répétitifs. Supposons, par exemple, qu'un certificat TLS expiré entraîne une interruption de service car les clients ne peuvent pas établir de connexion fiable. Si plusieurs incidents se produisent au cours d'une année en raison de l'expiration de plusieurs certificats TLS, vous pouvez tester l'expiration d'un certificat TLS et vérifier que vos équipes reçoivent des alertes ou sont en mesure d'atténuer automatiquement ces problèmes. Cela vous aidera à devenir résilient face à de tels défauts.
Pour suivre les progrès de l'ingénierie du chaos au fil du temps, capturez les indicateurs suivants afin de mettre en évidence la valeur de l'ingénierie du chaos tout au long du cycle de vie d'une application :
-
Taux d'incidents réduit : suivez le nombre d'incidents de production au fil du temps et associez ce chiffre à l'adoption de l'ingénierie du chaos. On s'attend à ce que le taux d'incidents graves diminue.
-
Temps moyen de résolution (MTTR) amélioré : calculez le temps moyen nécessaire pour résoudre les incidents et suivez ces données pour voir si l'ingénierie du chaos s'améliore au fil du temps.
-
Disponibilité accrue des applications : utilisez des indicateurs de niveau de service pour montrer les améliorations de disponibilité à mesure que la résilience des applications augmente grâce à des expériences chaotiques.
-
Réduction des délais de mise sur le marché — L'ingénierie du chaos peut apporter la confiance nécessaire pour lancer des offres innovantes plus rapidement, car vous savez que vos applications sont résilientes. Suivez l'augmentation de la vitesse de lancement des produits.
-
Réduction des coûts d'exploitation : quantifiez si les indicateurs tels que le bruit d'alerte, la charge opérationnelle et les efforts manuels nécessaires à la gestion des applications diminuent en raison de la mise en place de pratiques chaotiques.
-
Renforcer la confiance : interrogez les développeurs, les ingénieurs de fiabilité des sites (SREs) et les autres membres du personnel technique afin de déterminer si l'ingénierie du chaos a renforcé leur confiance dans la résilience des applications. Les perceptions sont importantes.
-
Expériences client améliorées ‒ Connectez l'ingénierie du chaos à des résultats positifs pour les clients, tels que la réduction des interruptions de service, des annulations et des pannes.
Prioriser les mesures correctives
Lorsque vous réalisez des expériences chaotiques, vous êtes susceptible d'identifier les domaines à améliorer dans lesquels l'application ne fonctionne pas comme prévu. La correction de ces éléments deviendra une tâche de votre carnet de travail qui devra être priorisée au même titre que d'autres tâches telles que le développement de fonctionnalités. Nous vous recommandons de prendre le temps de procéder à ces améliorations afin d'éviter de futures défaillances. Envisagez de hiérarchiser ces tâches d'apprentissage et de correction en fonction du niveau d'impact qu'elles peuvent avoir. Les résultats qui ont un impact direct sur la résilience ou la sécurité de votre application doivent avoir la priorité sur les nouvelles fonctionnalités, afin d'éviter tout impact sur les clients. Si l'équipe a du mal à prioriser les travaux de remédiation par rapport au développement de fonctionnalités, pensez à contacter votre sponsor exécutif pour vous assurer que les priorités sont définies en fonction de la tolérance au risque de l'entreprise.
