Partager via

Recommandations pour la gestion des défaillances transitoires

  • Article

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

RE:05 Renforcez la résilience de votre charge de travail en mettant en œuvre la gestion des erreurs et la gestion des défaillances transitoires. Intégrez des fonctionnalités dans la solution pour gérer les défaillances de composants et les erreurs transitoires.

Ce guide décrit les recommandations pour gérer les défaillances transitoires dans vos applications cloud. Toutes les applications qui communiquent avec des ressources et des services distants doivent être sensibles aux défaillances transitoires. Cela est particulièrement vrai pour les applications qui s’exécutent dans le cloud où, en raison de la nature de l’environnement et de la connectivité sur Internet, ce type de défaillance risque de se produire plus souvent. Les défaillances transitoires incluent la perte momentanée de la connectivité réseau aux composants et services, l’indisponibilité temporaire d’un service et les délais d’attente qui se produisent lorsqu’un service est occupé. Ces défaillances se corrigent souvent d’elles-mêmes, donc si l’action est répétée après un délai approprié, elle a de fortes chances de réussir.

Stratégies de conception clés

Des défaillances transitoires peuvent se produire dans n’importe quel environnement, sur n’importe quelle plateforme ou système d’exploitation et dans n’importe quel type d’application.

Défis

Les défaillances transitoires peuvent avoir un effet significatif sur la disponibilité perçue d’une application, même si elle a été minutieusement testée dans toutes les circonstances prévisibles. Pour garantir que votre charge de travail Power Platform peut fonctionner de manière fiable, vous devez vous assurer qu’elle peut répondre aux défis suivants :

  • L’application doit être en mesure de détecter les défaillances lorsqu’elles se produisent et de déterminer si elles sont probablement transitoires, durables ou terminales. Différentes ressources sont susceptibles de renvoyer des réponses différentes lorsqu’une défaillance se produit, et ces réponses peuvent également varier en fonction du contexte de l’opération. Par exemple, la réponse à une erreur lorsque l’application récupère des données à partir d’un connecteur personnalisé peut être différente de la réponse lorsque l’application exécute un flux de cloud et attend la réponse.

  • L’application doit être en mesure de réessayer l’opération si elle détermine que la défaillance est probablement transitoire.

  • L’application doit utiliser une stratégie appropriée pour les nouvelles tentatives. La stratégie spécifie le nombre de nouvelles tentatives de l’application, le délai entre chaque tentative et les actions à entreprendre après une tentative infructueuse. Le nombre approprié de tentatives et le délai entre chacune d’elles sont souvent difficiles à déterminer. La stratégie varie en fonction du type de ressource et des conditions d’exploitation actuelles de la ressource et de l’application.

Directives générales

Les directives suivantes peuvent vous aider à concevoir des mécanismes de gestion des défaillances transitoires adaptés pour vos applications.

Déterminer s’il existe un mécanisme de nouvelle tentative intégré

Certains services auxquels vous vous connectez peuvent déjà fournir un mécanisme de gestion des défaillances transitoires. La stratégie de nouvelle tentative utilisée est généralement adaptée à la nature et aux exigences du service cible. Sinon, les interfaces REST pour les services peuvent renvoyer des informations qui peuvent vous aider à déterminer si une nouvelle tentative est appropriée et le délai d’attente avant la prochaine nouvelle tentative.

Vous devez utiliser le mécanisme de nouvelle tentative intégré lorsqu’il est disponible, sauf si des exigences spécifiques et bien comprises rendent un comportement de nouvelle tentative différent plus approprié.

Déterminer si l’opération est appropriée pour une nouvelle tentative

Effectuez des opérations de nouvelle tentative uniquement lorsque les défaillances sont transitoires (généralement indiquées par la nature de l’erreur) et lorsqu’il existe au moins une certaine probabilité que l’opération réussisse lors d’une nouvelle tentative. Il est inutile de retenter des opérations qui tentent une opération non valide, comme mettre à jour une ligne dans Microsoft Dataverse qui n’existe pas ou pour laquelle l’utilisateur ne dispose pas de l’autorisation, ou appeler un point de terminaison d’API qui n’existe pas.

Mettez en œuvre les nouvelles tentatives uniquement lorsque vous pouvez en déterminer le plein effet et lorsque les conditions sont bien comprises et peuvent être validées. N’oubliez pas que les erreurs renvoyées à partir de ressources et de services en dehors de votre contrôle peuvent évoluer avec le temps et que vous devrez peut-être revoir votre logique de détection des défaillances transitoires.

Lorsque vous développez des composants ou des services individuels appelés à partir de vos applications, veillez à renvoyer les codes d’erreur et les messages qui aident les clients à déterminer s’ils doivent retenter les opérations infructueuses. Pensez à indiquer si le client doit réessayer l’opération ; par exemple, en renvoyant une valeur isTransient. Si vous créez un service web, envisagez de renvoyer les erreurs personnalisées définies dans vos contrats de service.

Déterminer un nombre et un intervalle de nouvelles tentatives appropriés

Optimisez le nombre et l’intervalle de nouvelles tentatives en fonction du type de cas d’utilisation. Si vous ne réessayez pas suffisamment de fois, l’application ne pourra pas terminer l’opération et échouera probablement. Si vous réessayez trop de fois ou avec un intervalle trop court entre les tentatives, l’application peut conserver des ressources sur de longues périodes, ce qui affecte négativement l’intégrité de l’application.

Adaptez les valeurs de l’intervalle de temps et du nombre de nouvelles tentatives au type d’opération. Par exemple, si l’opération fait partie d’une interaction utilisateur, l’intervalle doit être court et seules quelques nouvelles tentatives doivent être effectuées. En utilisant cette approche, vous pouvez éviter aux utilisateurs d’attendre une réponse. Si l’opération fait partie d’un flux de travail de longue durée ou critique, où l’annulation et le redémarrage du processus sont coûteux ou prennent du temps, il est approprié d’attendre plus longtemps entre les tentatives et de réessayer plusieurs fois.

Gardez à l’esprit que déterminer les intervalles appropriés entre les tentatives est la partie la plus difficile de la conception d’une stratégie réussie. Les stratégies classiques utilisent les types d’intervalles de nouvelle tentative suivants :

  • Intervalle exponentiel. L’application attend un court instant avant la première tentative, puis augmente de façon exponentielle le temps entre chaque nouvelle tentative ultérieure. Par exemple, elle peut réessayer l’opération après 3 secondes, 12 secondes, 30 secondes, etc.

  • Intervalles fixes. L’application attend le même intervalle de temps entre chaque tentative.

  • Nouvelle tentative immédiate. Parfois, une défaillance transitoire est brève et il est approprié de réessayer immédiatement l’opération, car elle peut réussir si la défaillance est effacée dans le temps nécessaire à l’application pour envoyer la requête suivante. Cependant, il ne devrait jamais y avoir plus d’une nouvelle tentative immédiate. Vous devez passer à des stratégies alternatives, comme un intervalle exponentiel ou des actions de secours, si la nouvelle tentative immédiate échoue.

En règle générale, utilisez une stratégie d’intervalle exponentiel pour les opérations en arrière-plan et utilisez des stratégies de nouvelle tentative à intervalle immédiat ou fixe pour les opérations interactives. Dans les deux cas, vous devez choisir le délai et le nombre de nouvelles tentatives afin que la latence maximale pour toutes les nouvelles tentatives soit comprise dans les exigences de latence de bout en bout requises.

Tenez compte de la combinaison de tous les facteurs qui contribuent au délai d’attente maximal global pour une nouvelle tentative de l’opération. Ces facteurs incluent le temps nécessaire à une connexion infructueuse pour produire une réponse, le délai entre les nouvelles tentatives et le nombre maximal de nouvelles tentatives. Le total de tous ces temps peut entraîner des temps de fonctionnement globaux longs, en particulier lorsque vous utilisez une stratégie de retard exponentiel où l’intervalle entre les nouvelles tentatives augmente rapidement après chaque échec. Si un processus doit respecter un contrat de niveau de service (SLA) spécifique, le temps de fonctionnement global, y compris tous les délais d’attente et les retards, doit être dans les limites définies dans le SLA.

Ne mettez pas en œuvre des stratégies de nouvelle tentative trop agressives. Ce sont des stratégies avec des intervalles trop courts ou des nouvelles tentatives trop fréquentes. Elles peuvent avoir un effet négatif sur la ressource ou le service cible. Ces stratégies peuvent empêcher la ressource ou le service de récupérer de son état surchargé, et il continuera à bloquer ou à refuser les demandes. Ce scénario crée un cercle vicieux, où de plus en plus de demandes sont envoyées à la ressource ou au service. Par conséquent, sa capacité à récupérer est davantage réduite.

Tenez compte du délai d’attente des opérations lorsque vous choisissez des intervalles de nouvelle tentative pour éviter de lancer une tentative ultérieure immédiatement (par exemple, si la période d’attente est similaire à l’intervalle de nouvelle tentative).

Utilisez le type d’erreur ou les codes d’erreur et les messages renvoyés par le service pour optimiser le nombre de nouvelles tentatives et l’intervalle entre elles. Par exemple, certaines exceptions ou certains codes d’erreur (comme le code HTTP 503, Service indisponible, avec un en-tête Réessayer après dans la réponse) peuvent indiquer la durée de l’erreur, ou que le service a échoué et ne répondra à aucune tentative ultérieure.

Éviter les anti-modèles

Dans la plupart des cas, évitez les implémentations qui incluent des couches de code de nouvelle tentative dupliquées. Évitez les conceptions qui incluent des mécanismes de nouvelle tentative en cascade ou qui implémentent une nouvelle tentative à chaque étape d’une opération impliquant une hiérarchie de demandes, à moins que vous ayez des exigences spécifiques pour le faire. Dans ces circonstances exceptionnelles, utilisez des stratégies qui empêchent un nombre excessif de nouvelles tentatives et de délais, et assurez-vous d’en comprendre les conséquences. Par exemple, imaginons qu’un composant envoie une demande à un autre, qui accède ensuite au service cible. Si vous implémentez une nouvelle tentative avec un nombre de trois sur les deux appels, il y a neuf nouvelles tentatives au total sur le service. De nombreux services et ressources implémentent un mécanisme de nouvelle tentative intégré. Vous devez rechercher comment désactiver ou modifier ces mécanismes si vous devez implémenter des nouvelles tentatives à un niveau supérieur.

N’implémentez jamais un mécanisme de nouvelle tentative sans fin. Cela risquerait d’empêcher la ressource ou le service de récupérer de situations de surcharge et de causer des limitations et des connexions refusées sur une période plus longue.

N’effectuez jamais de nouvelle tentative immédiate plus d’une fois.

Évitez d’utiliser un intervalle de nouvelle tentative fixe lorsque vous accédez aux services et ressources sur Azure, en particulier lorsque vous avez un nombre élevé de nouvelles tentatives. La meilleure approche dans ce scénario est une stratégie d’intervalle exponentiel.

Tester votre stratégie et mise en œuvre de nouvelle tentative

Testez entièrement votre stratégie de nouvelle tentative dans un ensemble de circonstances aussi large que possible, en particulier lorsque l’application et les ressources ou services cibles qu’elle utilise sont soumis à une charge extrême. Pour vérifier le comportement pendant les tests, vous pouvez :

  • Injecter des défaillances transitoires et non transitoires dans le service. Par exemple, envoyez des demandes non valides ou ajoutez du code qui détecte les demandes de test et répond avec différents types d’erreurs.

  • Créer une maquette de la ressource ou du service qui renvoie une plage d’erreurs que le service réel pourrait renvoyer. Couvrez tous les types d’erreurs que votre stratégie de nouvelle tentative est conçue pour détecter.

  • Pour les services personnalisés que vous créez et déployez, forcer les erreurs transitoires à se produire en désactivant ou en surchargeant temporairement le service. (N’essayez pas de surcharger les ressources partagées ou les services partagés dans Azure.)

  • Lorsque vous testez la résilience d’une application web cliente aux défaillances transitoires, utiliser les outils de développement du navigateur ou la capacité de votre infrastructure de test à simuler ou bloquer les demandes du réseau.

  • Effectuer des tests simultanés et à facteur de charge élevé pour garantir que le mécanisme et la stratégie de nouvelle tentative fonctionnent correctement dans ces conditions. Ces tests vous aident également de garantir que la nouvelle tentative n’a pas d’effet négatif sur le fonctionnement du client ni ne provoque de contamination croisée entre les demandes.

Gérer les configurations de la stratégie de nouvelle tentative

Une stratégie de nouvelle tentative est une combinaison de tous les éléments de votre stratégie de nouvelle tentative. Elle définit le mécanisme de détection qui détermine si une défaillance est probablement transitoire, le type d’intervalle à utiliser (par exemple, fixe ou exponentiel), les valeurs réelles de l’intervalle et le nombre de nouvelles tentatives.

Tirez parti des stratégies de nouvelle tentative intégrées ou par défaut, mais uniquement lorsqu’elles sont appropriées à votre scénario. Ces stratégies sont généralement génériques. Dans certains scénarios, elles peuvent être tout ce dont vous avez besoin, mais dans d’autres scénarios, elles n’offrent pas la gamme complète d’options pour répondre à vos besoins spécifiques. Pour déterminer les valeurs les plus appropriées, vous devez effectuer des tests pour comprendre comment les paramètres affectent votre application.

Enregistrer et suivre les défaillances transitoires et non transitoires

Dans le cadre de votre stratégie de nouvelle tentative, incluez la gestion des exceptions et d’autres instruments qui enregistrent les nouvelles tentatives. Une défaillance transitoire occasionnelle et une nouvelle tentative devraient se produire et n’indiquent pas un problème. Cependant, un nombre régulier et croissant de tentatives est souvent le signe d’un problème pouvant provoquer une défaillance ou dégrader les performances et la disponibilité de l’appplication.

Enregistrez les défaillances transitoires sous forme d’entrées d’avertissement au lieu d’entrées d’erreur afin que les systèmes de surveillance ne les détectent pas comme des erreurs d’application pouvant déclencher de fausses alertes.

Pensez à stocker une valeur dans vos entrées de journal qui indique si les tentatives sont causées par la limitation du service ou par d’autres types de défaillances, comme des échecs de connexion, afin que vous puissiez les différencier lors de l’analyse des données. Une augmentation du nombre d’erreurs de limitation est souvent un indicateur d’un défaut de conception dans l’application ou de la nécessité d’ajouter une capacité premium à l’environnement.

Envisagez de mettre en œuvre un système de télémétrie et de surveillance pouvant déclencher des alertes lorsque le nombre et le taux d’échecs, le nombre moyen de nouvelles tentatives ou le temps total écoulé avant la réussite des opérations augmente.

Gérer les opérations qui échouent continuellement

Réfléchissez à la manière de gérer les opérations qui échouent à chaque tentative. Les situations de ce genre sont inévitables.

Bien qu’une stratégie de nouvelle tentative définisse le nombre maximal de nouvelles tentatives d’une opération, elle n’empêche pas l’application de répéter l’opération avec le même nombre de nouvelles tentatives. Par exemple, l’envoi d’un formulaire dans votre application peut déclencher un flux. La stratégie de nouvelle tentative peut détecter un délai d’attente de connexion et le considérer comme une défaillance transitoire. Le flux retentera l’opération un nombre de fois spécifié, puis abandonnera. Cependant, lorsque le même utilisateur ou un nouvel utilisateur tente d’envoyer à nouveau le formulaire, l’opération est tentée à nouveau, même si elle peut continuer à échouer.

L’application peut tester régulièrement le service, de manière intermittente et avec de longs intervalles entre les demandes, pour détecter quand il devient disponible. Un intervalle approprié dépend de facteurs tels que la criticité de l’opération et la nature du service. Cela peut varier entre quelques minutes et plusieurs heures. Lorsque le test réussit, l’application peut reprendre ses opérations normales et transmettre des demandes au service nouvellement récupéré.

En attendant, vous pourrez peut-être effectuer des opérations alternatives en espérant que le service sera bientôt disponible. Par exemple, il peut être approprié de stocker les demandes du service dans une file d’attente ou un magasin de données et de les réessayer plus tard. Ou bien, vous devrez peut-être renvoyer un message à l’utilisateur pour indiquer que l’application n’est pas disponible.

Autres considérations

Lorsque vous décidez des valeurs pour le nombre de tentatives et les intervalles entre les tentatives pour une stratégie, déterminez si l’opération sur le service ou la ressource fait partie d’une opération de longue durée ou en plusieurs étapes. Il peut être difficile ou coûteux de compenser toutes les autres étapes opérationnelles qui ont déjà réussi lorsque l’une d’entre elles échoue. Dans ce cas, un intervalle long et un grand nombre de nouvelles tentatives peuvent être acceptables, à condition que cette stratégie ne bloque pas d’autres opérations en retenant ou en bloquant des ressources rares.

Déterminez si une nouvelle tentative de la même opération pourrait entraîner des incohérences dans les données. Si certaines parties d’un processus en plusieurs étapes sont répétées et que les opérations ne sont pas idempotentes, des incohérences peuvent survenir. Par exemple, si une opération qui insère un enregistrement dans Microsoft Dataverse est répétée, cela peut entraîner des valeurs incorrectes dans la table. Ou bien, si vous répétez une opération qui envoie une notification à l’utilisateur, celui-ci peut recevoir des messages en double.

Considérez la portée des opérations retentées. Par exemple, il peut être plus facile d’implémenter un code de nouvelle tentative à un niveau qui englobe plusieurs opérations et de toutes les retenter en cas d’échec de l’une d’entre elles. Cependant, cela pourrait entraîner des problèmes d’idempotence ou des opérations de restauration inutiles.

Si vous choisissez une portée de nouvelle tentative qui englobe plusieurs opérations, tenez compte de la latence totale de chacune d’elles lorsque vous déterminez les intervalles de nouvelle tentative, lorsque vous surveillez les temps écoulés de l’opération et avant de déclencher des alertes en cas d’échec.

Facilitation de Power Platform

Les sections suivantes décrivent les mécanismes que vous pouvez utiliser pour gérer les défaillances transitoires.

Power Automate

Power Automate inclut une fonctionnalité pour retenter une action en cas d’échec. Configurez-la au niveau de chaque action. En savoir plus sur la réduction des risques et la planification de la gestion des erreurs dans un projet Power Automate. Power Automate offre également des actions pour renvoyer des erreurs et des données personnalisées à l’application ou au flux appelant.

Certains flux transitoires peuvent être causés par des limites de débit et de requête. En savoir plus sur les limites des flux automatisés, planifiés et instantanés et sur les limites et allocations de requêtes.

Configurez la gestion des erreurs et des exceptions dans les flux de cloud en utilisant des portées et des paramètres d’exécution postérieure.

Power Apps

Les applications canevas Power Apps offrent la possibilité de vérifier le statut de la connexion, ce qui leur permet de se comporter différemment si l’application est hors ligne. Découvrez comment développer des applications canevas pouvant fonctionner hors connexion.

Vous pouvez également utiliser les fonctions Error, IfError, IsError et IsBlankOrError dans les applications canevas pour décider des prochaines étapes si une erreur se produit.

En savoir plus sur la gestion des défaillances transitoires dans Power Apps :

Connecteurs Azure et personnalisés

Si votre charge de travail se connecte aux services Azure, découvrez comment gérer les défaillances transitoires à l’aide d’Azure Well-Architected Framework.

Pour gérer les réponses du connecteur personnalisé aux erreurs, suivez les normes de codage.

Application Insights

Utilisez les intégrations Application Insights pour enregistrer les erreurs dans Power Automate et Power Apps :

Voir aussi

Continuité des activités et reprise après sinistre pour les applications Dynamics 365 SaaS

Liste de contrôle de fiabilité

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

Liste de contrôle de fiabilité