Recommandations pour effectuer une analyse en mode d’échec
S’applique à cette recommandation de liste de vérification de fiabilité Azure Well-Architected Framework :
| RE :03 | Utilisez l’analyse du mode d’échec (FMA) pour identifier et hiérarchiser les défaillances potentielles dans vos composants de solution. Effectuez FMA pour vous aider à évaluer le risque et l’effet de chaque mode d’échec. Déterminez la façon dont la charge de travail répond et récupère. |
|---|
Ce guide décrit les meilleures pratiques pour effectuer l’analyse du mode d’échec (FMA) pour votre charge de travail. FMA consiste à identifier les points de défaillance potentiels au sein de votre charge de travail et les flux associés, et à planifier les actions d’atténuation en conséquence. À chaque étape du flux, vous identifiez le rayon d’explosion de plusieurs types de défaillances, ce qui vous aide à concevoir une nouvelle charge de travail ou à refactoriser une charge de travail existante pour réduire l’effet généralisé des défaillances.
Un principe clé de FMA est que les échecs se produisent, quel que soit le nombre de couches de résilience que vous appliquez. Les environnements plus complexes sont exposés à davantage de types de défaillances. 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 en cas de défaillance.
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
| Terme | Définition |
|---|---|
| Mode d’échec | Type de problème qui peut entraîner une dégradation ou plusieurs composants de charge de travail au point d’être indisponibles. |
| Limitation des risques | Activités que vous avez identifiées pour résoudre les problèmes de manière proactive ou réactive. |
| Détection | Processus et procédures de surveillance et d’alerte de votre infrastructure, des données et des applications. |
Stratégies de conception
Prérequis
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 avez collectées et les artefacts que vous avez créés 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 la rigueur de vos artefacts sont essentielles.
Approche FMA
Une fois que vous avez déterminé les flux critiques, vous pouvez planifier leurs composants requis. Ensuite, suivez chaque flux étape par étape pour identifier les dépendances, notamment les services tiers et les points de défaillance potentiels, et planifier vos stratégies d’atténuation.
Décomposer la charge de travail
Lorsque vous passez de l’idéation à la conception, vous devez identifier les types de composants nécessaires pour prendre 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 secrets ou 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 ressembler à l’exemple suivant.
Après avoir créé votre conception d’architecture initiale, vous pouvez superposer vos flux pour identifier les composants discrets utilisés dans ces flux et créer 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 attribuées aux flux. Tenez compte de l’effet d’un dysfonctionnement d’un composant sur vos flux.
Identifier les dépendances
Identifiez vos dépendances de charge de travail pour effectuer votre analyse de point de défaillance unique. La décomposition de votre charge de travail et la superposition des flux fournissent des informations sur les dépendances internes et externes à la charge de travail.
Les dépendances internes sont des composants dans l’étendue de la charge de travail qui sont requis pour que la charge de travail fonctionne. Les dépendances internes classiques incluent les API ou les solutions de gestion des clés/secrets comme Azure Key Vault. Pour ces dépendances, capturez les données de fiabilité, comme 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 les solutions d’authentification, comme Microsoft Entra ID, et les 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.
Points d’échec
Dans les flux critiques de votre charge de travail, examinez 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. N’importe quel composant peut être affecté par plusieurs modes d’échec à un moment donné. Ces 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 de composants.
L’analyse doit toujours se trouver 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 e-commerce 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 effectuer l’extraction.
Tenez compte de la probabilité de chaque type de mode d’échec. Certaines sont très peu probables, comme les pannes multizones ou multirégions, et l’ajout d’une planification d’atténuation au-delà de la redondance n’est pas une bonne utilisation des ressources et du temps.
Limitation des risques
Les stratégies d’atténuation se répartissent en deux grandes catégories : renforcer la résilience et concevoir pour des performances dégradées.
La création d’une résilience accrue inclut l’ajout de la redondance à vos composants, tels que l’infrastructure, les données et la mise en réseau, et la garantie que la conception de votre application suit les meilleures pratiques en matière de durabilité, par exemple la décomposition d’applications monolithiques en applications et microservices isolés. Pour plus d’informations, consultez Recommandations pour la redondance et Recommandations pour l’auto-conservation.
Pour concevoir des performances dégradées, identifiez les points de défaillance potentiels qui peuvent désactiver un ou plusieurs composants de votre flux, mais qui ne désactivent pas complètement ce flux. Pour conserver 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, la fonction n’est plus disponible dans l’expérience utilisateur. Pour revenir à l’exemple d’application e-commerce, un composant défaillant comme un microservice peut entraîner l’indisponibilité de votre moteur de recommandation, mais les clients peuvent toujours rechercher des produits et terminer leur transaction.
Vous devez également planifier l’atténuation des dépendances. Les dépendances fortes jouent un rôle essentiel dans le fonctionnement et la disponibilité des applications. S’ils sont absents ou rencontrent un dysfonctionnement, il peut y avoir 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 de haute disponibilité entre le service et ses dépendances. Classifiez les dépendances comme 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 la 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.
Détection
La détection des défaillances est essentielle pour vous assurer que vous avez correctement identifié les points de défaillance dans votre analyse et planifié correctement vos stratégies d’atténuation. La détection dans ce contexte signifie la surveillance de votre infrastructure, de vos données et de votre application, et l’alerte en cas de problèmes. Automatisez autant que possible la détection et créez une redondance dans vos processus d’exploitation pour vous assurer que les alertes sont toujours interceptées et traitées assez rapidement pour répondre aux besoins de votre entreprise. Pour plus d’informations, consultez Recommandations pour la supervision.
Résultat
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 concernant les composants de flux et l’atténuation, et l’effet de la défaillance 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 les modes d’échec qui sont assez courants et suffisamment graves pour justifier l’utilisation du temps, des efforts et des ressources pour concevoir des stratégies d’atténuation. Par exemple, certains modes d’échec peuvent être très rares en ce qui concerne l’occurrence ou la détection. La conception de stratégies d’atténuation autour d’eux n’en vaut pas le coût.
Reportez-vous à l’exemple de tableau suivant pour obtenir un point de départ de la documentation.
Au cours de votre exercice FMA initial, les documents que vous produisez seront principalement de la planification théorique. Les documents FMA doivent être examinés et mis à jour régulièrement pour s’assurer qu’ils restent à jour avec votre charge de travail. Les tests de chaos et les expériences réelles vous aideront à affiner vos analyses au fil du temps.
Animation 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, vos applications et vos bases de données, utilisez des outils comme 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 la résilience du service.
Pour plus d’informations sur l’application des principes FMA aux services Azure courants, consultez Analyse du mode d’échec pour les applications Azure.
Exemple
Le tableau suivant montre un exemple de 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 qui est géré par Azure Front Door.
Flux utilisateur : connexion de l’utilisateur, recherche de produits et interaction du panier d’achat
| Composant | Risque | Vraisemblance | Effet/atténuation/remarque | Outage |
|---|---|---|---|---|
| Microsoft Entra ID | Interruption de service | Faible | Panne complète de la charge de travail. Dépend de Microsoft pour corriger. | Complète |
| Microsoft Entra ID | Configuration incorrecte | Moyenne | Les utilisateurs ne peuvent pas se connecter. Aucun effet en aval. Le support technique signale le problème de configuration à l’équipe d’identité. | None |
| Azure Front Door | Interruption de service | Faible | Panne complète pour les utilisateurs externes. Dépend de Microsoft pour corriger. | Externe uniquement |
| Azure Front Door | Panne régionale | Très faible | Effet minimal. Azure Front Door étant un service global, le routage du trafic global dirige le trafic vers des régions Azure non affectées. | None |
| Azure Front Door | Configuration incorrecte | Moyenne | Les erreurs de configuration doivent être interceptées pendant le déploiement. Si cela se produit pendant une mise à jour de configuration, les administrateurs doivent annuler les modifications. La mise à jour de la configuration provoque une brève panne externe. | Externe uniquement |
| Azure Front Door | Attaque DDoS | Moyenne | Risque d’interruption. Microsoft gère la protection DDoS (L3 et L4) et Azure Web Application Firewall bloque la plupart des menaces. Risque potentiel d’effet des attaques L7. | Risque de panne partielle |
| Azure SQL | Interruption de service | Faible | Panne complète de la charge de travail. Dépend de Microsoft pour corriger. | Complète |
| Azure SQL | Panne régionale | Très faible | Le groupe de basculement automatique bascule vers la région secondaire. Panne potentielle pendant le basculement. Objectifs de temps de récupération (RTO) et objectifs de point de récupération (RPO) à déterminer pendant les tests de fiabilité. | Potentiel complet |
| Azure SQL | Panne de zone de disponibilité | Faible | Aucun effet | None |
| Azure SQL | Attaque malveillante (injection) | Moyenne | Risque minimal. Toutes les instances Azure SQL sont liées au réseau virtuel via des points de terminaison privés et des groupes de sécurité réseau (NSG) ajoutent une protection supplémentaire au réseau intra-virtuel. | Risque faible potentiel |
| App Service | Interruption de service | Faible | Panne complète de la charge de travail. Dépend de Microsoft pour corriger. | Complète |
| App Service | Panne régionale | Très faible | Effet minimal. Latence pour les utilisateurs dans les régions concernées. Azure Front Door achemine automatiquement le trafic vers les régions non affectées. | None |
| App Service | Panne de zone de disponibilité | Faible | Aucun effet. Les services d’application ont été déployés en tant que redondant interzone. Sans redondance de zone, il y a un potentiel d’effet. | None |
| App Service | Attaque DDoS | Moyenne | Effet minimal. Le trafic d’entrée est protégé par Azure Front Door et Azure Web Application Firewall. | None |
Liens connexes
Liste de contrôle de fiabilité
Reportez-vous à l’ensemble complet de recommandations.
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour