Recommandations relatives à l’exécution d’une analyse du mode d’échec
S’applique à cette recommandation de liste de contrôle de fiabilité d’Azure Well-Architected Framework :
| RE :03 | Utilisez l’analyse du mode d’échec (FMA) pour identifier et hiérarchiser d’éventuelles défaillances dans les composants de votre 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 une analyse du mode d’échec (FMA) pour votre charge de travail. FMA est la pratique consistant à 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’impact de plusieurs types de défaillances, ce qui vous permet de concevoir une nouvelle charge de travail ou de refactoriser une charge de travail existante afin de réduire l’effet généralisé des défaillances.
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 lorsqu’une défaillance se produit.
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 une dégradation grave d’un 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 | Votre infrastructure, vos données et vos procédures de surveillance et d’alerte des applications. |
Stratégies de conception
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 tous les flux. Pour réussir dans votre travail FMA, la précision et la précision dans vos artefacts est essentielle.
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 la charge de travail
Lorsque vous passez de l'idéation à la conception, vous devez identifier les types de composants nécessaires pour supporter 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, 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 affectées aux flux. Considérez 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 de flux de superposition fournit des insights sur les dépendances internes et externes à la charge de travail.
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 de secrets/clés 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 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é. 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 des composants.
L’analyse doit toujours être 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 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 des performances détériorées.
La création d’une résilience accrue inclut 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 pour la durabilité, par exemple 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 des performances détériorées, identifiez les points d’échec potentiels susceptibles de désactiver un ou plusieurs composants de votre flux, mais ne désactivent pas 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 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 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.
Détection
La détection des défaillances est essentielle pour vous assurer que vous avez correctement identifié les points d’échec dans votre analyse et que vous avez correctement planifié 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ème. 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.
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 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 dans l’occurrence ou la détection. 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 seront principalement une 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.
Facilitation 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 la résilience du service.
Pour plus d’informations sur l’application des principes FMA aux services Azure courants, consultez l’analyse du mode échec pour les applications Azure.
Exemple
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
| Composant | Risque | Vraisemblance | Effet / Atténuation / Remarque | Outage |
|---|---|---|---|---|
| Microsoft Entra ID | Interruption de service | Faible | Panne complète de la charge de travail. Dépendance vis-à-vis de Microsoft pour y remédier. | COMPLET |
| Microsoft Entra ID | Configuration incorrecte | Moyenne | Les utilisateurs ne peuvent pas se connecter. Aucun effet aval. Le service d’assistance signale un problème de configuration à l’équipe d’identité. | Aucune |
| Azure Front Door | Interruption de service | Faible | Panne complète pour les utilisateurs externes. Dépendance vis-à-vis de Microsoft pour y remédier. | Externe uniquement |
| Azure Front Door | Panne régionale | Très faible | Effet minimal. Azure Front Door est un service global. Par conséquent, le routage du trafic global dirige le trafic via des régions Azure non effectives. | Aucune |
| Azure Front Door | Configuration incorrecte | Moyenne | Les mauvaises configurations doivent être détectées lors du déploiement. S’ils se produisent lors d’une mise à jour de configuration, les administrateurs doivent restaurer les modifications. La mise à jour de configuration entraîne une brève panne externe. | Externe uniquement |
| Azure Front Door | Attaque DDoS | Moyenne | Risque de perturbation. Microsoft gère la protection DDoS (L3 et L4) et le Pare-feu d’applications web Azure bloque la plupart des menaces. Risque potentiel d’effets des attaques de niveau 7. | Risque de panne partielle |
| Azure SQL | Interruption de service | Faible | Panne complète de la charge de travail. Dépendance vis-à-vis de Microsoft pour y remédier. | COMPLET |
| 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 lors des tests de fiabilité. | Plein potentiel |
| Azure SQL | Panne de zone de disponibilité | Faible | Aucun effet | Aucune |
| 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 de réseau intra-virtuel supplémentaire. | Risque faible potentiel |
| App Service | Interruption de service | Faible | Panne complète de la charge de travail. Dépendance vis-à-vis de Microsoft pour y remédier. | COMPLET |
| App Service | Panne régionale | Très faible | Effet minimal. Latence pour les utilisateurs dans les régions effectives. Azure Front Door achemine automatiquement le trafic vers des régions non affectées. | Aucune |
| 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 existe un potentiel d’effet. | Aucune |
| App Service | Attaque DDoS | Moyenne | Effet minimal. Le trafic d’entrée est protégé par Azure Front Door et pare-feu d’applications web Azure. | Aucune |
Liens connexes
Liste de contrôle de fiabilité
Reportez-vous à l’ensemble complet de recommandations.