Stratégies d’architecture pour effectuer une analyse du mode d’échec

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

L’analyse du mode d’échec (FMA) vous permet d’identifier les points potentiels d’échec dans votre charge de travail et les flux associés. Ce guide décrit les meilleures pratiques d’exécution de FMA afin de planifier des actions d’atténuation, concevoir de nouvelles charges de travail ou refactoriser les charges de travail existantes afin de réduire l’effet généralisé des défaillances. En analysant chaque étape de votre flux et en identifiant le rayon d’explosion de plusieurs types d’échecs, vous pouvez améliorer la résilience de votre architecture.

L’un des principaux éléments de LMA est que les défaillances se produisent quel que soit le nombre de couches de résilience que vous appliquez. Des environnements plus complexes sont exposés à davantage de types d’échecs. Compte tenu de cette réalité, FMA vous permet de concevoir votre charge de travail pour résister à la plupart des types de défaillances et de récupérer correctement dans les objectifs de récupération définis.

Si vous ignorez complètement FMA ou effectuez une analyse incomplète, votre charge de travail risque d’avoir un comportement non prédicté et des pannes potentielles causées par une conception non optimale.

Définitions

Passez en revue et implémentez les recommandations pour identifier les flux. Il est supposé que vous avez identifié et hiérarchisé les flux utilisateur et système en fonction de la criticité.

Les données que vous collectez et les artefacts que vous créez dans votre travail vous fournissent une description concrète de vos chemins de données impliqués dans les flux. Pour réussir dans votre travail FMA, la précision et l'exhaustivité dans vos artefacts sont essentielles.

Après avoir déterminé les flux critiques, vous pouvez planifier leurs composants requis. Ensuite, suivez chaque flux étape par étape pour identifier les dépendances, y compris les services tiers et les points potentiels d’échec, et planifiez vos stratégies d’atténuation.

Décomposer votre charge de travail

À mesure que vous passez de l’idée à la conception, identifiez les types de composants qui prennent en charge votre charge de travail. Votre charge de travail détermine les composants nécessaires que vous devez planifier. En règle générale, vous devez planifier le contrôle d’entrée, la mise en réseau, le calcul, les données, le stockage, les services de prise en charge (comme l’authentification, la messagerie et la gestion des clés) et le contrôle de sortie. À ce stade de votre travail de conception, vous ne connaissez peut-être pas les technologies spécifiques que vous allez déployer. Votre conception peut donc ressembler à l’exemple suivant.

Après avoir créé votre conception d’architecture initiale, superposez vos flux pour identifier les composants discrets utilisés dans ces flux. Créez des listes ou des diagrammes de flux de travail qui décrivent les flux et leurs composants. Pour comprendre la criticité des composants, utilisez les définitions de criticité que vous avez affectées aux flux. Considérez l’effet d’un dysfonctionnement d’un composant sur vos flux.

Identifier les dépendances de charge de travail

Identifiez les dépendances de vos charges de travail afin d’effectuer votre analyse des points de défaillance uniques. La décomposition de votre charge de travail et la superposition des flux fournissent des aperçus sur les dépendances qui sont internes et externes à celle-ci.

Les dépendances internes sont des composants de l’étendue de la charge de travail requises pour que la charge de travail fonctionne. Les dépendances internes classiques incluent des API ou des solutions de gestion des clés et des secrets, comme Azure Key Vault. Pour ces dépendances, capturez les données de fiabilité, telles que les contrats SLA de disponibilité et les limites de mise à l’échelle. Les dépendances externes sont des composants requis en dehors de l’étendue de la charge de travail, comme une autre application ou un service tiers. Les dépendances externes classiques incluent des solutions d’authentification, telles que Microsoft Entra ID et des solutions de connectivité cloud, comme Azure ExpressRoute.

Identifiez et documentez les dépendances dans votre charge de travail et incluez-les dans vos artefacts de documentation de flux.

Évaluer les points d’échec dans vos flux

Dans les flux critiques de votre charge de travail, tenez compte de chaque composant et déterminez comment ce composant et ses dépendances peuvent être affectés par un mode d’échec. N’oubliez pas qu’il existe de nombreux modes d’échec à prendre en compte lors de la planification de la résilience et de la récupération. Tout composant peut être affecté par plusieurs modes d’échec à tout moment donné. Envisagez les échecs de lecture et les échecs d’écriture séparément, car l’impact et les étapes d’atténuation possibles varient. Les modes d’échec sont les suivants :

• Panne régionale. Une région Azure entière n’est pas disponible.

• Panne de zone de disponibilité. Une zone de disponibilité Azure n’est pas disponible.

• Panne de service. Un ou plusieurs services Azure ne sont pas disponibles.

• Déni de service distribué (DDoS) ou d’autres attaques malveillantes.

• Configuration incorrecte de l’application ou du composant.

• Erreur de l’opérateur.

• Panne de maintenance planifiée.

• Surcharge des composants.

Analysez toujours l’effet dans le contexte du flux que vous tentez d’analyser. Veillez donc à documenter l’effet sur l’utilisateur et le résultat attendu de ce flux. Par exemple, si vous disposez d’une application de commerce électronique et que vous analysez votre flux client, l’effet d’un mode d’échec particulier sur un ou plusieurs composants peut être que tous les clients ne peuvent pas terminer l’extraction.

Considérez la probabilité de chaque type de mode d’échec. Certains modes d’échec sont très peu probables, comme les pannes multizones ou multirégions. L’ajout d’une planification d’atténuation au-delà de la redondance n’est pas une bonne utilisation des ressources et du temps.

Planifier des stratégies d’atténuation

Les stratégies d’atténuation se répartissent en deux grandes catégories : renforcer la résilience et concevoir des performances détériorées.

La création d’une résilience accrue comprend l’ajout de redondance à vos composants, comme l’infrastructure, les données et la mise en réseau, et la garantie que la conception de votre application suit les meilleures pratiques de durabilité, telles que la séparation d’applications monolithiques en applications isolées et en microservices isolés. Pour plus d’informations, consultez Recommandations pour la redondance et recommandations pour la préservation de soi.

Pour concevoir pour une performance dégradée, identifiez les points d'échec potentiels susceptibles de désactiver un ou plusieurs composants de votre flux sans toutefois désactiver complètement ce flux. Pour maintenir les fonctionnalités du flux de bout en bout, vous devrez peut-être rediriger une ou plusieurs étapes vers d’autres composants ou accepter qu’un composant ayant échoué exécute une fonction, de sorte que la fonction n’est plus disponible dans l’expérience utilisateur. Pour revenir à l’exemple d’application de commerce électronique, un composant ayant échoué comme un microservice peut entraîner l’indisponibilité de votre moteur de recommandation, mais les clients peuvent toujours rechercher des produits et effectuer leur transaction.

Vous devez également planifier l’atténuation autour des dépendances. Les dépendances fortes jouent un rôle essentiel dans la fonction d’application et la disponibilité. S’ils sont absents ou défectueux, ils peuvent entraîner un effet significatif. L’absence de dépendances faibles peut affecter uniquement des fonctionnalités spécifiques et ne pas affecter la disponibilité globale. Cette distinction reflète le coût de maintien de la relation haute disponibilité entre le service et ses dépendances. Classifiez les dépendances comme étant fortes ou faibles pour vous aider à identifier les composants essentiels à l’application.

Si l’application a des dépendances fortes sans lesquelles elle ne peut pas fonctionner, les cibles de disponibilité et de récupération de ces dépendances doivent s’aligner sur les cibles de l’application elle-même. Réduisez les dépendances pour contrôler la fiabilité de l’application. Pour plus d’informations, consultez Réduire la coordination entre les services d’application pour obtenir une scalabilité.

Si le cycle de vie de l’application est étroitement associé au cycle de vie de ses dépendances, l’agilité opérationnelle de l’application peut être limitée, en particulier pour les nouvelles versions.

Implémenter la détection des défaillances

La détection des défaillances est essentielle pour vous assurer que vous identifiez correctement les points d’échec dans votre analyse et planifiez correctement vos stratégies d’atténuation. Dans ce contexte, la détection signifie surveiller votre infrastructure, vos données et votre application et alerter lorsque des problèmes se produisent. Automatisez la détection autant que possible et générez une redondance dans vos processus d’exploitation pour vous assurer que les alertes sont toujours interceptées et sont traitées assez rapidement pour répondre à vos besoins métier. Pour plus d’informations, consultez les recommandations pour la surveillance.

Documentez vos constatations FMA

Pour obtenir le résultat de votre analyse, créez un ensemble de documents qui communiquent efficacement vos résultats, les décisions que vous avez prises par rapport aux composants de flux et à l’atténuation, ainsi que l’effet de l’échec sur votre charge de travail.

Dans votre analyse, hiérarchiser les modes d’échec et les stratégies d’atténuation que vous avez identifiés en fonction de la gravité et de la probabilité. Utilisez cette hiérarchisation pour concentrer votre documentation sur ces modes d’échec qui sont courants et suffisamment graves pour justifier le temps, l’effort et les ressources nécessaires pour concevoir des stratégies d’atténuation autour de. Par exemple, il peut y avoir certains modes d’échec qui sont très rares quant à leur occurrence ou à être détectés. La conception de stratégies d’atténuation autour d’elles ne vaut pas le coût.

Reportez-vous au tableau d’exemple suivant pour obtenir un point de départ de documentation.

Au cours de votre exercice FMA initial, les documents que vous produisez sont principalement une planification théorique. Passez en revue et mettez à jour régulièrement les documents FMA pour vous assurer qu’ils restent up-to-date avec votre charge de travail. Les tests de chaos et les expériences réelles vous aident à affiner vos analyses au fil du temps.

supervision d’Azure

Utilisez Azure Monitor et Log Analytics pour détecter les problèmes dans votre charge de travail. Pour plus d’informations sur les problèmes liés à votre infrastructure, applications et bases de données, utilisez des outils tels que Application Insights, Container Insights, Network Insights, VM Insights et SQL Insights.

Azure Chaos Studio est un service managé qui utilise l’ingénierie du chaos pour vous aider à mesurer, comprendre et améliorer votre application cloud et votre résilience de service.

Utilisez le moniteur de connexion et la résolution des problèmes de connexion dans Azure Network Watcher pour modéliser et valider les scénarios de connectivité réseau avant le déploiement. En simulant des tests synthétiques et en analysant des chemins de routage potentiels, ces outils vous aident à anticiper et à documenter les modes d’échec possibles dans votre architecture réseau. En outre, en analysant les journaux de flux de réseau virtuel historiques avec l’analytique du trafic, vous pouvez identifier des modèles de trafic bloqués ou anormaux susceptibles d’informer votre documentation FMA sur l’infrastructure Azure.

Example

Le tableau suivant présente un exemple FMA pour un site web de commerce électronique hébergé sur des instances Azure App Service avec des bases de données Azure SQL et est géré par Azure Front Door.

Flux utilisateur : connexion utilisateur, recherche de produits et interaction du panier d’achat

Lien connexe

• Résilience et dépendances

Liste de contrôle de fiabilité

Reportez-vous à l’ensemble complet de recommandations.