Stratégies d’architecture pour les tests de fiabilité

S’applique à cette recommandation de liste de contrôle de fiabilité d’Azure Well-Architected Framework :

Les tests de fiabilité interceptent les faiblesses architecturales avant qu’elles ne provoquent des pannes. Sans tester délibérément les scénarios d’échec, vous ne pouvez pas savoir si vos modèles de résilience fonctionnent réellement ou si votre charge de travail récupère dans ses cibles définies.

Vous renforcez la fiabilité de votre charge de travail lorsque vous testez les risques de sécurité qui affectent la disponibilité, les problèmes de performances qui rendent le système inutilisable et les lacunes opérationnelles qui limitent votre réponse aux incidents. Utilisez les stratégies de cet article pour établir une cadence de test qui valide régulièrement votre charge de travail par rapport à ses modes d’échec. Faites évoluer vos tests à mesure que l’architecture change et que les incidents révèlent de nouvelles faiblesses. Assurez-vous que votre charge de travail peut résister aux défaillances, se mettre à l’échelle pour répondre à la demande et se rétablir dans les limites de vos objectifs RTO et RPO, tout en créant une boucle de rétroaction qui renforce votre posture de fiabilité au fil du temps.

Les stratégies clés de cet article reposent sur les pratiques de test fondamentales décrites dans les stratégies d’architecture OE :09 pour les tests. Passez d’abord en revue cet article. Les recommandations de ce guide portent sur la fiabilité et visent à garantir que votre charge de travail puisse résister aux défaillances et se rétablir dans les délais que vous avez définis.

Le tableau suivant définit les termes de fiabilité clés utilisés dans cet article.

Définitions

Définir l’étendue de test de fiabilité en fonction des types de service

Lorsque vous définissez l’étendue de vos tests de fiabilité, tenez compte du modèle de responsabilité partagée des services que vous utilisez. Chaque type de service (IaaS, PaaS, SaaS) est fourni avec des garanties de fiabilité différentes et différents niveaux de contrôle sur la gestion des défaillances. Concentrez vos tests sur les aspects de la fiabilité que vous possédez.

• Adaptez le niveau de test à vos responsabilités. Pour les services d’infrastructure (IaaS), votre équipe possède la plupart des décisions de fiabilité, donc investissez dans une validation approfondie grâce à l’ingénierie du chaos et à l’injection de pannes. Pour les services PaaS (Platform) et Software (SaaS), le fournisseur gère une grande partie de la fiabilité sous-jacente. Concentrez-vous sur la façon dont votre charge de travail interagit avec ces services, telles que la façon dont elle gère les basculements d’infrastructure dans PaaS, la limitation, la dégradation des services ou les changements dans les modèles de charge.

• Prendre en charge les charges de travail à services mixtes. Lorsque votre charge de travail s’étend sur plusieurs types de services, les responsabilités de test varient selon les composants. Vous pouvez tester le basculement de vos composants d’infrastructure basés sur des machines virtuelles lors d’une panne de zone de disponibilité, mais vous devez vous appuyer sur les garanties du fournisseur pour une base de données PaaS conçue pour la haute disponibilité. Identifiez l’emplacement de ces limites et assurez-vous que vos tests couvrent les écarts entre eux.

Tester par rapport à vos cibles de fiabilité de bout en bout

Vos objectifs de fiabilité, tels que les SLO, les RTO et les RPO, définissent la manière dont votre charge de travail doit se comporter en cas de défaillance. Utilisez-les comme des critères de passage et d’échec sur des flux critiques complets, et pas seulement des composants individuels.

• Validez la reprise sur l’ensemble du flux. Un composant unique peut être restauré dans le délai défini par son RTO, mais le temps de récupération global peut dépasser votre objectif lorsque les dépendances en aval doivent également être restaurées. Comptez le temps de récupération total sur l’ensemble du flux, y compris le temps de détection du problème et de réponse.

• Définissez le périmètre des tests avec des SLO et des budgets d’erreur. Votre budget d’erreur représente l’investissement que vous pouvez effectuer dans l’injection de pannes. Limitez les tests de chaos pour rester dans vos SLA et utilisez vos cibles de récupération de flux pour définir les limites de chaque test.

Créer des scénarios de fiabilité à partir de flux critiques et de modes d’échec

Commencez par les flux critiques dans votre charge de travail et les modes d’échec qui peuvent les affecter. Utilisez votre analyse du mode d’échec pour identifier les scénarios d’échec les plus impactants et générer des tests qui valident vos stratégies de résilience et de récupération.

Hiérarchiser par impact et probabilité. Tous les modes d’échec ne justifient pas le même investissement de test. Concentrez-vous d’abord sur les scénarios ayant le plus grand impact potentiel sur l’utilisateur et la probabilité la plus élevée de se produire. Laissez votre analyse du mode d’échec conduire cette hiérarchisation.

Valider vos mécanismes de tolérance de panne et de récupération

Concentrez-vous sur les scénarios susceptibles d’entraîner un temps d’arrêt ou de dégrader l’expérience utilisateur. Utilisez les stratégies de cette section pour générer des tests qui valident la capacité de votre charge de travail à gérer les erreurs et à récupérer efficacement.

Sauvegarde et restauration

Vos tests de sauvegarde et de restauration doivent vérifier que votre approche de protection des données répond à vos objectifs de récupération.

• Établissez une cadence de test. Déterminez la fréquence à laquelle vous devez tester les restaurations en fonction de la fréquence à laquelle votre configuration de sauvegarde, votre schéma de données ou votre infrastructure change. Les modifications plus fréquentes nécessitent des tests de restauration plus fréquents.

• Définissez des cibles de récupération. Mesurez les temps de restauration réels par rapport à vos cibles RPO et RTO pour confirmer que votre stratégie de sauvegarde répond à vos objectifs de récupération.

• Ne supposez pas l’exhaustivité de la sauvegarde. Les sauvegardes peuvent être mal configurées pour capturer uniquement un sous-ensemble de vos données. Validez l’intégrité et l’exhaustivité des données, et non seulement si une opération de restauration réussit.

• Test en isolation. Validez les restaurations dans un environnement distinct de la production afin de pouvoir exécuter des vérifications approfondies sans interrompre les charges de travail actives.

Erreurs temporaires

Les défaillances temporaires, telles que les interruptions de réseau momentanés, l’indisponibilité brève du service et les délais d’expiration de connexion, sont des risques de fiabilité courants. Vérifiez que votre charge de travail gère ces échecs sans impact sur les utilisateurs. Pour plus d’informations, consultez Recommandations pour la gestion des erreurs temporaires.

• Concentrez-vous sur ce que vous possédez. Si vos SDK ou services de plateforme gèrent automatiquement les réessais et les mécanismes de disjoncteur, testez ce qui se passe lorsque ces mécanismes intégrés sont épuisés, par exemple lorsque tous les réessais échouent ou qu’un disjoncteur se déclenche.

• Validez les configurations de gestion des erreurs. Évaluez les configurations de gestion des erreurs de votre charge de travail. Vérifiez que les stratégies de nouvelle tentative, les seuils de disjoncteur et les valeurs de délai d’attente se comportent comme prévu dans des conditions d’échec réalistes.

• Testez la limite entre l’échec temporaire et persistant. Vérifiez que votre charge de travail passe de manière fluide du mécanisme de nouvelle tentative à une solution de repli ou à un mode dégradé lorsqu’une défaillance persiste au-delà des seuils prévus.

• Tenez compte des erreurs transitoires liées aux mécanismes de résilience. La redondance de zone et les conceptions similaires provoquent souvent des défaillances transitoires lors des opérations normales de basculement. Par exemple, une base de données redondante interzone peut entraîner des défaillances de connexion temporaires lorsque le trafic passe à une zone saine lors d’une panne. Testez si votre charge de travail peut gérer ces erreurs temporaires attendues sans impact important sur l’utilisateur.

Réponse de charge et de mise à l’échelle

Vérifiez que votre charge de travail conserve la fiabilité pendant les changements de demande, à la fois des pics soudains et des augmentations progressives. Pour plus d’informations, consultez la stratégie de mise à l’échelle. Pour obtenir des conseils sur les tests de charge et de contrainte, consultez Recommandations pour les tests.

• Testez à la fois le scale-out et le scale-in. Vérifiez que la nouvelle capacité devient disponible suffisamment rapidement et que la réduction de capacité n’entraîne pas de perte de requêtes ni ne laisse de ressources orphelines.

• Tenez compte de la latence de mise à l’échelle. Il existe toujours un délai entre la réunion des conditions pour déclencher la mise à l’échelle et avoir une nouvelle capacité prête. Déterminez si votre charge de travail peut gérer la demande pendant cet écart ou si vous devez préprovisionner une capacité supplémentaire.

Échecs de dépendance

Votre charge de travail dépend probablement des services en dehors de votre contrôle direct, tels que les API tierces, les services de plateforme managée ou les services internes partagés. Vérifiez que votre charge de travail gère les défaillances de ces dépendances sans interruption significative pour les utilisateurs.

• Catégoriser les dépendances par criticité. Toutes les dépendances ne justifient pas le même investissement de test. Hiérarchiser les tests pour les dépendances qui se trouvent dans vos flux critiques et qui manquent de redondance intégrée ou de chemins de secours.

• Testez le comportement de repli pour chaque dépendance. Lorsqu’une dépendance devient indisponible, votre charge de travail doit basculer vers une autre voie ou un autre comportement plutôt que d’échouer complètement. Vérifiez que chaque mécanisme de repli se déclenche correctement et que les fonctionnalités non liées continuent de fonctionner.

• Prenez en compte les défaillances partielles et en cascade. Les dépendances échouent rarement de manière binaire. Ne testez pas seulement les pannes totales. Couvrir les augmentations de latence, les erreurs intermittentes et la disponibilité partielle des données.

• Validez l’isolation et le confinement du périmètre d’impact. Vérifiez qu’une défaillance d’une seule dépendance ne se propage pas à des fonctionnalités sans rapport.

Auto-conservation et récupération

Validez la façon dont votre conception d’auto-guérison et de conservation automatique répond aux dysfonctionnements, notamment si votre charge de travail peut continuer à fonctionner dans une capacité réduite lorsque la récupération complète n’est pas immédiate.

• Testez la récupération automatisée de bout en bout. Évaluez vos modèles d’état de santé pour vous assurer qu’ils incluent les vérifications appropriées. Vérifiez que ces vérifications détectent les défaillances avec précision, déclenchent une correction automatisée comme prévu et retournent le système à un état sain dans les délais acceptables.

• Validez les runbooks de récupération manuelle. La récupération automatisée ne couvre pas tous les scénarios. Testez les procédures manuelles dans des conditions réalistes afin de vous assurer que les opérateurs peuvent les exécuter sous pression et dans les délais de reprise visés.

• Vérifiez le comportement de dégradation progressive. En cas d’échec d’un composant, votre charge de travail doit se dégrader correctement au lieu d’échouer complètement. Vérifiez qu’il peut fonctionner en mode dégradé, par exemple en mettant les demandes en file d’attente pour un examen manuel, et que l’expérience dégradée est acceptable pour les utilisateurs. Vérifiez que votre équipe sait comment utiliser la charge de travail dans cet état et comment restaurer toutes les fonctionnalités.

Incidents et récupération d’urgence

Lorsqu’un incident ou une catastrophe se produit, votre capacité à le détecter rapidement et à y répondre efficacement est cruciale. Testez vos plans et processus pour vous assurer qu’ils traitent les défaillances catastrophiques et les incidents majeurs. Utilisez un environnement dédié pour les tests de reprise après sinistre afin d’éviter d’impacter les charges de travail de production. Pour plus d’informations, consultez le plan de récupération d’urgence.

• Valider les mécanismes de détection des incidents. Simuler des incidents pour vérifier que les journaux d’activité de surveillance capturent les informations nécessaires et que les alertes se déclenchent correctement. Par exemple, testez la rapidité avec laquelle les taux d’échec de requête sont détectés et la fréquence à laquelle les données de surveillance sont échantillonées.

• Tester les processus de gestion des incidents. Vérifiez que votre équipe peut suivre efficacement les procédures de réponse aux incidents. Pour plus d’informations, consultez la réponse aux incidents.

• Testez le basculement complet et la restauration automatique. Le test d’éléments individuels isolés peut manquer des défaillances de coordination qui n’apparaissent qu’au cours d’un basculement réel. Vérifiez l’ensemble de la séquence de basculement, y compris la bascule DNS, la restauration des sauvegardes, la cohérence de la réplication des données et la reconnexion des clients. Testez également le retour vers le déploiement principal, qui est souvent plus complexe que le basculement initial.

• Valider la capacité dans l’environnement de basculement. Assurez-vous que votre environnement de basculement dispose d’une capacité préprovisionnée suffisante pour absorber le trafic dès le basculement, sans s’effondrer sous la charge. Testez que l’environnement peut maintenir les opérations pendant que les mécanismes de mise à l’échelle activent et valident votre approche de mise à l’échelle. Pour plus d’informations, consultez La réponse de charge et de mise à l’échelle.

• Mesurez-les par rapport à vos cibles. Si un test de reprise après sinistre ne respecte pas vos objectifs de RTO ou de RPO, analysez les écarts et mettez à jour votre plan de reprise après sinistre en conséquence.

• Validez les personnes et le processus. Les tests de récupération d’urgence doivent vérifier les canaux de communication, vérifier que les opérateurs disposent des autorisations nécessaires pour exécuter des procédures de récupération d’urgence et s’assurer qu’ils peuvent rapidement trouver des runbooks spécifiques à la récupération d’urgence sous pression.

Tester et évaluer votre plan avec des exercices de table

Les exercices tabletop vous aident à trouver des lacunes dans vos tests de fiabilité avant qu’un incident réel ne les expose. En simulant des scénarios d’échec avec votre équipe, vous pouvez identifier les conditions non testées et vérifier que vos procédures de réponse fonctionnent comme prévu.

• Simuler des incidents réalistes. Parcourez un scénario d’échec, tel qu’une panne régionale ou un déploiement endommagé, et faites en sorte que votre équipe décrive les étapes à suivre pour détecter, répondre et récupérer à partir de celui-ci. Ces discussions révèlent souvent des hypothèses sur le comportement du système qui n’ont pas été validés par le biais de tests.

• Transformez les résultats en cas de test. Utilisez les lacunes et les inconnus qui s’affichent pendant l’exercice pour créer de nouveaux tests de fiabilité. Si l’équipe découvre que personne ne sait comment la charge de travail se comporte lorsqu’une dépendance spécifique échoue, c’est un scénario à ajouter à votre stratégie de test.

Tirer parti des pannes planifiées et non planifiées

Lorsque votre charge de travail est hors connexion en raison d’une maintenance planifiée ou d’une panne non planifiée, vous avez l’occasion unique d’effectuer des tests et d’améliorer votre compréhension de votre charge de travail.

Maintenance planifiée

Pendant les fenêtres de maintenance pour les mises à jour ou les correctifs, testez les composants et les flux qui ne sont pas impliqués dans le travail de maintenance. Vous pouvez exécuter des tests sans risque de dégrader de manière inattendue la charge de travail ou de la mettre hors connexion. Si vous avez suffisamment de temps, testez également les composants impliqués dans la maintenance une fois le travail terminé.

Panne non planifiée

Chaque panne non planifiée est l’occasion de renforcer votre stratégie de test de fiabilité. Après avoir restauré le service et terminé votre révision post-incident, utilisez vos résultats pour améliorer vos tests.

• Testez vos mesures d’atténuation. Si vous avez appliqué une solution de contournement ou un correctif temporaire, vérifiez qu’il peut gérer la charge attendue avant que le correctif permanent soit en place.

• Recherchez des faiblesses similaires. Passez en revue d’autres composants pour les mêmes modèles de configuration ou de conception qui ont contribué à la panne. Ajoutez des tests pour ces composants avant qu’ils ne présentent la même défaillance.

Combiner différents types de tests

Lorsque vous exécutez différents types de tests ensemble, vous pouvez révéler des problèmes de fiabilité qui ne sont pas visibles lorsque chaque test s’exécute en isolation. Une charge de travail peut gérer une charge spécifique dans des conditions normales, mais la même charge provoque des défaillances lorsque vous introduisez une erreur.

• Réutiliser l’infrastructure de test existante. Si vous disposez déjà d’une infrastructure et d’un harnais de test pour les tests de charge, utilisez-le pour exécuter simultanément des tests de chaos. Le fait de combiner l’injection de charge et l’injection de défaillances au cours de la même exécution de test montre comment votre charge de travail se comporte dans des conditions réalistes, où la demande et les défaillances surviennent en même temps.

• Démarrez dans des environnements hors production. Commencez les tests de fiabilité dans des environnements à faible risque dans lesquels vous pouvez explorer en toute sécurité les modes de défaillance. Passez aux tests en production uniquement après avoir tiré tous les enseignements des environnements hors production et mis en place des garde-fous pour limiter l’impact et revenir rapidement en arrière.

Utiliser l’injection de pannes et l’ingénierie du chaos

L’injection de pannes et l’ingénierie du chaos vous permettent d’avoir davantage confiance dans la résilience de votre charge de travail en introduisant délibérément des défaillances et en observant la réaction. Veillez à mettre en place des stratégies d’atténuation avant d’exécuter des expériences.

• Exécutez régulièrement des expériences de chaos. Évaluez votre étendue de test. Injectez des défaillances dans les composants et les flux que vous supposez fiables. À mesure que votre architecture change, les nouveaux modes d’échec émergent et les hypothèses précédentes peuvent ne plus contenir. Exécutez des expériences à une cadence régulière pour intercepter les régressions, valider de nouvelles dépendances et confirmer que les modifications récentes n’ont pas introduit de faiblesses.

• Utilisez votre analyse du mode d’échec pour concentrer les expériences. Chaque expérience doit cibler une erreur spécifique ou un ensemble d’erreurs et avoir une hypothèse claire, comme tester la capacité d’un flux donné à résister à la perte d’un composant particulier. À mesure que les expériences révèlent de nouveaux modes d’échec ou des dépendances non découvertes, mettez à jour votre analyse du mode d’échec pour la maintenir à jour.

• Limitez le périmètre d’impact lors des expérimentations. Ciblez les composants que vous pouvez rétablir rapidement et définissez clairement les effets attendus de chaque injection d’erreurs. Si une expérience dépasse la portée ou produit des résultats inattendus, arrêtez-la. Équilibrez la collecte de données significatives et réduisez l’effet sur les utilisateurs.

• Mesure par rapport aux lignes de base. Établissez des métriques de fiabilité et de performances cohérentes pour les flux et les composants de chaque expérience. Comparez les métriques d’état détériorées par rapport à ces bases de référence pour comprendre l’effet complet de l’erreur et déterminer si votre conception de résilience répond à ses cibles.

• Réintégrez les résultats à votre stratégie de tests. Utilisez les résultats de l’expérience pour effectuer de nouveaux tests, mettre à jour des plans de récupération et informer les éléments du backlog de correction. À mesure que des comportements inattendus surviennent, créez des tests ciblés pour ces comportements et concevez des stratégies de correction.

Inconvénient: les tests d’injection de pannes en production peuvent être perturbateurs et potentiellement provoquer des interruptions de service. Soyez transparent avec les parties prenantes à propos de cette possibilité. Placez les dispositifs de protection en place pour que vous puissiez arrêter les expériences et restaurer rapidement, et rester flexible sur le moment où exécuter des tests ou les éviter pendant des périodes sensibles. Pour vous protéger contre les pannes involontaires, planifiez une redondance suffisante et assurez-vous que vos parties prenantes comprennent le compromis des coûts.

Risque: Les tests de fiabilité peuvent élargir la couverture à de nombreux modes de défaillance, mais vous devez les arrêter une fois qu’ils n’apportent plus de valeur ajoutée réelle. Si vous avez déjà un backlog de problèmes de fiabilité connus, hiérarchiser la résolution de ces problèmes au lieu d’ajouter d’autres tests.

Facilitation par Azure

Azure Test Plans est une solution de gestion des tests basée sur un navigateur qui fournit toutes les fonctionnalités requises pour les tests manuels planifiés, les tests d’acceptation des utilisateurs, les tests exploratoires et la collecte de commentaires des parties prenantes.

Azure Chaos Studio est un service géré qui utilise des tests de chaos pour vous aider à mesurer, comprendre et améliorer la résilience de votre application cloud et de votre service.

Test d’applications Azure est un service qui vous permet d’exécuter des tests fonctionnels avec des Espaces de travail pour les dramaturges et des tests de performances à l’aide de Test de charge Azure pour identifier les problèmes dans leurs applications.

Azure Service Health dispose d’un volet de maintenance planifiée, qui est une section dédiée du portail Azure qui vous informe des activités de maintenance à venir. Il met en évidence les événements qui peuvent affecter vos ressources Azure, ce qui vous aide à vous préparer à l’avance.

Le moniteur de connexion est une fonctionnalité d’Azure Network Watcher que vous pouvez utiliser pour la supervision synthétique et les tests en temps réel de la connectivité réseau dans les environnements Azure et hybrides. Dans les scénarios d’ingénierie de chaos, le moniteur de connexion peut être utilisé pour injecter des erreurs dans des composants réseau ciblés et mesurer en permanence les métriques clés telles que la latence et la perte de paquets. Cette fonctionnalité permet aux équipes d’observer comment les interruptions affectent la fiabilité du réseau, tant pour les composants de flux individuels que pour les chemins réseau de bout en bout. Pour évaluer l’impact des erreurs et identifier les domaines d’amélioration, comparez les données de télémétrie du moniteur de connexion aux métriques de référence.

Liens connexes

• Sauvegarde et récupération d’urgence pour les applications Azure
• Liste de contrôle pour les tests de fiabilité
• Tester les applications pour la disponibilité et la résilience

Liste de contrôle de fiabilité

Référez-vous à l’ensemble complet des recommandations.