Partager via

Recommandations pour l’exécution de l’analyse du mode d’échec

  • Article

S’applique à cette recommandation de liste de contrôle Fiabilité Power Platform Well-Architected :

RE:03 Utilisez l’analyse du mode d’échec (FMA) pour identifier et hiérarchiser les échecs potentiels dans les composants de votre solution. Effectuez la FMA pour vous aider à évaluer le risque et l’effet de chaque mode d’échec Déterminez comment la charge de travail répond et récupère.

Ce guide décrit les pratiques recommandées pour effectuer une analyse du mode d’échec (FMA) pour votre charge de travail. La FMA consiste à identifier les points de défaillance potentiels au sein de votre charge de travail et des flux associés, et à planifier des actions d’atténuation en conséquence. À chaque étape du flux, vous identifiez le rayon d’explosion de plusieurs types d’échec, ce qui vous aide à concevoir une nouvelle charge de travail ou à refactoriser une charge de travail existante afin de réduire l’effet généralisé des échecs.

L’un des principes fondamentaux de la 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 d’échecs. Compte tenu de cette réalité, la FMA vous permet de concevoir votre charge de travail pour résister à la plupart des types d’échecs et récupérer facilement lorsqu’un échec se produit.

Ignorer complètement la FMA ou effectuer une analyse incomplète expose votre charge de travail à un comportement imprévu et à des pannes potentielles causées par une conception sous-optimale.

Définitions

Terme Définition
Mode d’échec Un type de problème pouvant dégrader ou affecter gravement un ou plusieurs composants de la charge de travail au point de les rendre indisponibles.
Atténuation Les activités que vous avez identifiées pour résoudre les problèmes de manière proactive ou réactive.
Détection Vos processus et procédures de surveillance et d’alerte de vos données et applications.

Stratégies de conception clés

Dans le contexte de la FMA, comprendre les conditions préalables est crucial. Commencez par examiner et mettre en œuvre les recommandations pour identifier les flux, en les hiérarchisant en fonction de leur criticité. Vos artefacts de données jouent un rôle fondamental dans la description des chemins de données au sein de ces flux. Au fur et à mesure que vous approfondissez l’approche FMA, concentrez-vous sur la planification des composants pour les flux critiques, l’identification des dépendances (internes et externes) et la conception de stratégies d’atténuation.

Conditions préalables

Examinez et mettez en œuvre les recommandations pour identifier et évaluer les flux. Nous partons du principe que vous avez identifié et hiérarchisé les flux utilisateur et système en fonction de leur 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 tout au long des flux. Pour réussir votre travail FMA, la précision et la minutie dans vos artefacts sont fondamentales.

Approche FMA

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 de défaillance potentiels, et planifiez vos stratégies d’atténuation.

Décomposer la charge de travail

À mesure que vous passez de l’idéation à la conception, vous devez identifier les types de composants requis pour prendre en charge votre charge de travail. Votre charge de travail détermine les composants nécessaires que vous devez planifier.

Après avoir créé votre conception architecturale 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. Considérez l’effet du dysfonctionnement d’un composant sur vos flux.

Identifier les dépendances

Identifiez les dépendances de votre charge de travail pour effectuer votre analyse du point de défaillance unique. La décomposition de votre charge de travail et la superposition des flux fournissent un aperçu des dépendances internes et externes à la charge de travail.

Les dépendances internes sont des composants dans la portée de la charge de travail qui sont nécessaires au fonctionnement de la charge de travail. Les dépendances internes typiques incluent les API ou les solutions de gestion des secrets/clés comme Azure Key Vault. Pour ces dépendances, capturez les données de fiabilité, telles que les contrats de niveau de service (SLA) de disponibilité et les limites de mise à l’échelle. Les dépendances externes sont des composants requis en dehors de la portée de la charge de travail, comme une autre application ou un service tiers. Les dépendances externes typiques incluent les solutions d’authentification, telles que Microsoft Entra ID et l’infrastructure Power Platform.

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

Points de défaillance

Dans les flux critiques de votre charge de travail, considérez chaque composant et déterminez la façon dont ce composant et ses dépendances peuvent être affectés par un mode d’échec. N’oubliez pas que de nombreux modes d’échec doivent être pris 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. Ces modes d’échec incluent :

  • Panne régionale : une région Power Platform ou Azure entière n’est pas disponible
  • Panne de service : un ou plusieurs services Power Platform ou Azure ne sont pas disponibles
  • Déni de service distribué (DDoS) ou autre attaque malveillante
  • Configuration incorrecte de l’application ou du composant
  • Erreur de l’opérateur
  • Panne de la maintenance planifiée
  • Surcharge de composant

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

Atténuation

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

Renforcer la résilience signifie s’assurer que la conception de votre application suit les pratiques recommandées en matière de durabilité ; par exemple, diviser les applications monolithiques en applications et microservices isolés et utiliser les configurations de résilience fournies par la plateforme, comme les stratégies de nouvelle tentative. Pour plus d’informations, voir Recommandations pour la redondance et Recommandations pour l’auto-préservation.

Pour concevoir pour des performances dégradées, identifiez les points de défaillance potentiels qui peuvent désactiver un ou plusieurs composants de votre flux, mais ne désactivez pas complètement ce flux. Pour maintenir la fonctionnalité du flux de bout en bout, vous devrez peut-être rediriger une ou plusieurs étapes vers d’autres composants ou accepter qu’un composant défaillant exécute une fonction, de sorte que la fonction ne soit plus disponible dans l’expérience utilisateur. Pour revenir à l’exemple de l’application de commerce électronique, un composant défaillant tel qu’un microservice peut entraîner l’indisponibilité de votre moteur de recommandations, 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 fondamental dans le fonctionnement et la disponibilité des applications. Si elles sont absentes ou connaissent un dysfonctionnement, cela peut 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 nécessaire pour maintenir la relation de haute disponibilité entre le service et ses dépendances. Classez les dépendances comme fortes ou faibles pour vous aider à identifier les composants essentiels à l’application.

Si l’application a de fortes dépendances sans lesquelles elle ne peut pas fonctionner, les objectifs de disponibilité et de récupération de ces dépendances doivent s’aligner sur les objectifs de l’application elle-même. Si le cycle de vie de l’application est étroitement lié 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 échecs est essentielle pour garantir que vous avez correctement identifié les points de défaillance dans votre analyse et que vous avez correctement planifié vos stratégies d’atténuation. La détection dans ce contexte signifie surveiller votre infrastructure, vos données et vos applications et alerter lorsque des problèmes surviennent. Automatisez la détection autant que possible et créez une redondance dans vos processus opérationnels pour garantir que les alertes sont toujours détectées et traitées assez rapidement pour répondre aux besoins de votre entreprise. Pour plus d’informations, voir Recommandations pour la surveillane.

Résultat

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

Dans votre analyse, hiérarchisez les modes d’échec et les stratégies d’atténuation que vous avez identifiés en fonction de leur gravité et de leur probabilité. Utilisez cette hiérarchisation pour concentrer votre documentation sur les modes d’échec qui sont suffisamment courants et graves pour justifier de consacrer du temps, des efforts et des ressources à la conception de stratégies d’atténuation. Par exemple, certains modes d’échec peuvent être très rares en termes d’occurrence ou de détection. Concevoir des stratégies d’atténuation autour de ces problèmes n’en vaut pas la peine.

Reportez-vous à l’exemple du tableau comme point de départ pour la documentation.

Lors de votre exercice initial de FMA, les documents que vous produisez seront pour la plupart de la planification théorique. Les documents FMA doivent être révisés et mis à jour régulièrement pour garantir qu’ils restent à jour avec votre charge de travail. Les tests de chaos et les expériences du monde réel vous aideront à affiner vos analyses au fil du temps.

Exemple

Le tableau suivant présente un exemple de FMA pour une application de dépenses hébergée en tant que application canevas Power Apps avec un back-end Microsoft Dataverse et des API hébergées dans APIM pour interagir avec un système tiers.

Flux utilisateur : connexion de l’utilisateur, envoi de la note de frais et interaction avec la note de frais

Composant Risque Probabilité Effet/Atténuation/Remarque Panne
Microsoft Entra ID Panne de service Faible Panne totale de la charge de travail. Dépend de Microsoft pour la corriger. Totale
Microsoft Entra ID Configuration incorrecte Moyen Connexion impossible des utilisateurs. Aucun effet en aval. Le service d’assistance signale le problème de configuration à l’équipe d’identité. Aucune
Power Apps Panne de service Faible Panne totale pour les utilisateurs externes. Dépend de Microsoft pour la corriger. Totale
Power Apps Panne régionale Très faible Panne totale pour les utilisateurs externes. Dépend de Microsoft pour la corriger. Totale
Power Apps Attaque DDoS Moyen Risque de perturbation. Microsoft gère la protection DDoS (L3 et L4). Risque de panne partielle
Dataverse Panne de service Faible Panne totale de la charge de travail. Dépend de Microsoft pour la corriger. Totale
Dataverse Panne régionale Très faible Le groupe de basculement automatique bascule vers la région secondaire. Panne potentielle lors du basculement. Objectifs du temps de récupération (RTO) et objectifs du point de récupération (RPO) à déterminer lors des tests de fiabilité. Totale potentielle
Dataverse Attaque malveillante (injection) Moyen Risque minimal. Risque faible potentiel
APIM Panne de service Faible Panne totale pour les utilisateurs externes. Dépend de Microsoft pour la corriger. Totale
APIM Panne régionale Très faible Panne totale pour les utilisateurs externes. Dépend de Microsoft pour la corriger. Totale
APIM Attaque DDoS Moyen Risque de perturbation. Microsoft gère la protection DDoS (L3 et L4). Risque de panne partielle
Votre solution Power Platform Configuration incorrecte Moyen Les configurations incorrectes doivent être détectées lors du déploiement. Si celles-ci se produisent lors d’une mise à jour de la configuration, les administrateurs doivent annuler les modifications. La mise à jour de la configuration provoque une brève panne externe. Risque de panne totale

Facilitation de Power Platform

Power Platform s’intègre à Application Insights, qui fait partie de l’écosystème Azure Monitor. Vous pouvez utiliser cette intégration pour :

  • Vous inscrire pour recevoir la télémétrie capturée par la plateforme Dataverse dans Application Insights sur les diagnostics, les performances et les opérations exécutées par les applications sur votre base de données Dataverse et dans les applications pilotées par modèle. Cette télémétrie fournit des informations que vous pouvez utiliser pour diagnostiquer et résoudre les problèmes liés aux erreurs et aux performances.

  • Connecter vos applications canevas à Application Insights pour utiliser ces analyses pour diagnostiquer les problèmes, comprendre ce que les utilisateurs font réellement avec vos applications, prendre de meilleures décisions commerciales et améliorer la qualité de vos applications.

  • Configurer la télémétrie Power Automate pour les flux dans Application Insights. Vous pouvez utiliser cette télémétrie pour surveiller les exécutions de flux de cloud et créer des alertes en cas d’échecs de l’exécution de flux de cloud.

Les ressources Power Platform consignent les activités dans le portail de conformité Microsoft Purview. La plupart des événements sont disponibles dans les 24 heures suivant l’activité. N’utilisez pas ces informations pour la surveillance en temps réel. Pour plus d’informations sur la consignation des activités dans Power Platform, voir :

Liste de contrôle de fiabilité

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

Liste de contrôle de fiabilité