Gestion des erreurs temporaires
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.
Cet article fournit des conseils généraux sur la gestion des erreurs temporaires.
Pourquoi les erreurs temporaires se produisent-ils dans le cloud ?
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. Pour les solutions qui s’exécutent sur une infrastructure locale locale, les performances et la disponibilité de l’application et de ses composants sont généralement conservées via une redondance matérielle coûteuse et souvent sous-utilisée, et les composants et les ressources se trouvent à proximité les uns des autres. Cette approche rend l'échec moins probable, mais des défaillances temporaires peuvent toujours se produire, tout comme des pannes causées par des événements imprévus tels qu'une coupure d'alimentation externe ou des problèmes de réseau, ou d'autres scénarios de catastrophe.
L’hébergement cloud, y compris les systèmes de cloud privé, peut offrir une disponibilité globale plus élevée à l’aide de ressources partagées, de redondance, de basculement automatique et d’allocation de ressources dynamiques sur de nombreux nœuds de calcul de base. Toutefois, en raison de la nature des environnements cloud, les erreurs temporaires sont plus susceptibles de se produire. Il existe plusieurs raisons pour cela :
De nombreuses ressources dans un environnement cloud sont partagées et l’accès à ces ressources est soumis à une limitation afin de protéger les ressources. Certains services refusent les connexions lorsque la charge augmente à un niveau spécifique, ou lorsqu’un débit de débit maximal est atteint, pour permettre le traitement des requêtes existantes et maintenir les performances du service pour tous les utilisateurs. La limitation permet de maintenir la qualité du service pour les voisins et les autres locataires qui utilisent la ressource partagée.
Les environnements cloud utilisent un grand nombre d’unités matérielles de base. Ils offrent des performances en distribuant dynamiquement la charge entre plusieurs unités de calcul et composants d’infrastructure. Ils fournissent une fiabilité en recyclant ou en remplaçant automatiquement les unités défaillantes. En raison de cette nature dynamique, des erreurs temporaires et des défaillances de connexion temporaires peuvent parfois se produire.
Il existe souvent davantage de composants matériels, notamment l’infrastructure réseau, comme les routeurs et les équilibreurs de charge, entre l’application et les ressources et les services qu’elle utilise. Cette infrastructure supplémentaire peut parfois introduire une latence de connexion supplémentaire et des erreurs de connexion temporaires.
Les conditions réseau entre le client et le serveur peuvent être variables, en particulier lorsque la communication traverse Internet. Même dans les emplacements locaux, de lourdes charges de trafic peuvent ralentir la communication et provoquer des défaillances de connexion intermittentes.
Défis
Les erreurs temporaires peuvent avoir un effet important sur la disponibilité perçue d’une application, même si elle a été soigneusement testée dans toutes les circonstances prévisibles. Pour vous assurer que les applications hébergées dans le cloud fonctionnent de manière fiable, vous devez vous assurer qu’elles peuvent 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 lit dans le stockage peut différer de la réponse à une erreur lorsqu'elle écrit sur le stockage. De nombreuses ressources et services ont des contrats de pannes temporaires bien documentés. Toutefois, si ces informations ne sont pas disponibles, il peut être difficile de découvrir la nature de l’erreur et de déterminer s’il est susceptible d’être temporaire.
L’application doit être en mesure de réessayer l’opération si elle détermine que la défaillance est probablement transitoire. Il doit également suivre le nombre de nouvelles tentatives d’opération.
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.
Instructions 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é
De nombreux services fournissent un sdk ou une bibliothèque cliente qui contient un mécanisme de gestion des erreurs temporaire. 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 réessayer des opérations qui tentent une opération non valide, comme une mise à jour de base de données d'un élément qui n’existe pas ou une requête vers un service ou une ressource ayant subi une erreur irrécupérable.
En règle générale, implémentez des nouvelles tentatives uniquement lorsque vous pouvez déterminer l’effet complet de cette opération et lorsque les conditions sont bien comprises et peuvent être validées. Sinon, laissez le code appelant implémenter les nouvelles tentatives. 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 créez des services ou des composants, envisagez d’implémenter des codes d’erreur et des messages qui aident les clients à déterminer s’ils doivent réessayer les opérations ayant échoué. En particulier, indiquez si le client doit réessayer l’opération (peut-être en retournant une valeur isTransient) et suggérer un délai approprié avant la nouvelle tentative suivante. Si vous créez un service web, envisagez de renvoyer les erreurs personnalisées définies dans vos contrats de service. Même si les clients génériques peuvent ne pas être en mesure de lire ces erreurs, ils sont utiles dans la création de clients personnalisés.
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 contenir des ressources telles que des threads, des connexions et de la mémoire pendant 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 de faire attendre les utilisateurs pour une réponse, ce qui maintient des connexions ouvertes et peut réduire la disponibilité pour les autres utilisateurs. Si l’opération fait partie d’un flux de travail long ou critique, où l’annulation et le redémarrage du processus sont coûteux ou longs, il est préférable d’attendre plus longtemps entre les tentatives et réessayer plus de 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 :
Temporisation exponentielle. 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 incrémentiels. L’application attend un court instant avant la première nouvelle tentative, puis augmente de façon incrémentielle le temps entre chaque nouvelle tentative suivante. Par exemple, il peut réessayer l’opération après 3 secondes, 7 secondes, 13 secondes, et ainsi de suite.
Intervalles réguliers. L’application attend le même intervalle de temps entre chaque tentative. Par exemple, il peut réessayer l’opération toutes les 3 secondes.
Nouvelle tentative immédiate. Parfois, une erreur temporaire est brève, peut-être causée par un événement tel qu’une collision de paquets réseau ou un pic dans un composant matériel. Dans ce cas, une nouvelle tentative de l’opération est appropriée, car elle peut réussir si l’erreur est effacée dans le temps nécessaire à l’assemblage de l’application et à l’envoi de la requête suivante. Cependant, il ne devrait jamais y avoir plus d’une nouvelle tentative immédiate. Si le réessai immédiat échoue, vous devez basculer vers d'autres stratégies, telles que le retrait exponentiel ou les actions de secours.
Répartition aléatoire. L’une des stratégies de nouvelle tentative répertoriées précédemment peut inclure une randomisation pour empêcher plusieurs instances du client d’envoyer des tentatives de nouvelle tentative ultérieures en même temps. Par exemple, une instance peut réessayer l’opération après 3 secondes, 11 secondes, 28 secondes, et ainsi de suite, tandis qu’une autre instance peut réessayer l’opération après 4 secondes, 12 secondes, 26 secondes, et ainsi de suite. La randomisation est une technique utile qui peut être combinée à d’autres stratégies.
En règle générale, utilisez une stratégie d’interruption exponentielle pour les opérations en arrière-plan et utilisez des stratégies de nouvelle tentative immédiate ou régulière 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.
Prenez en compte la combinaison de tous les facteurs qui contribuent au délai d’expiration maximal global d’une opération retentée. Ces facteurs incluent le temps nécessaire à une connexion ayant échoué pour produire une réponse (généralement définie par une valeur de délai d’attente dans le client), 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.
Prenez en compte le délai d’expiration des opérations lorsque vous choisissez des intervalles de nouvelle tentative afin d’éviter de lancer immédiatement une tentative ultérieure (par exemple, si la période d’expiration est similaire à l’intervalle de nouvelle tentative). Déterminez également si vous devez conserver le délai total possible (délai d’expiration plus les intervalles de nouvelle tentative) en dessous d’une durée totale spécifique. Si une opération a un délai d’expiration inhabituellement court ou long, le délai d’attente peut influencer la durée d’attente et la fréquence de nouvelle tentative de l’opération.
Utilisez le type de l’exception et toutes les données qu’il contient, ou les codes d’erreur et les messages retournés par le service, pour optimiser le nombre de nouvelles tentatives et l’intervalle entre eux. 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 antimodè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 requêtes, sauf si vous avez des exigences spécifiques qui le nécessitent. 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 trois nouvelles tentatives sur chaque appel, vous obtenez 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 instaurer des réessaies à 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. Utilisez un nombre fini de nouvelles tentatives ou implémentez un modèle tel que disjoncteur pour permettre au service de récupérer.
N’effectuez jamais de nouvelle tentative immédiate plus d’une fois.
Évitez d’utiliser un intervalle de nouvelle tentative régulier lorsque vous accédez aux services et aux ressources sur Azure, en particulier lorsque vous avez un nombre élevé de nouvelles tentatives. La meilleure approche dans ce scénario est d’utiliser une stratégie de temporisation exponentielle avec une capacité de disjoncteur.
Empêcher plusieurs instances du même client, ou plusieurs instances de différents clients, d’envoyer simultanément des nouvelles tentatives. Si ce scénario est susceptible de se produire, introduisez une randomisation dans les intervalles de nouvelle tentative.
Tester votre stratégie de réessai et sa mise en œuvre
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 erreurs temporaires et non temporaires 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. Pour des exemples d’utilisation de TestApi, consultez Test d’injection d’erreurs avec TestApi et Présentation de TestApi - Partie 5 : API d’injection d’erreurs dans du code managé.
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.)
Pour les API HTTP, envisagez d’utiliser une bibliothèque dans vos tests automatisés pour modifier le résultat des requêtes HTTP, soit en ajoutant des heures d’aller-retour supplémentaires, soit en modifiant la réponse (comme le code d’état HTTP, les en-têtes, le corps ou d’autres facteurs). Cela permet de tester déterministement un sous-ensemble des conditions d’échec, pour les erreurs temporaires et d’autres types d’échecs.
Effectuez un facteur de charge élevé et des tests simultanés pour vous assurer que le mécanisme et la stratégie de nouvelle tentative fonctionnent correctement dans ces conditions. Ces tests aideront également à s’assurer que la nouvelle tentative n’a pas d’effet négatif sur l’opération du client ou provoque une contamination croisée entre les demandes.
Gérer les configurations de 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. Il définit le mécanisme de détection qui détermine si une erreur est susceptible d’être temporaire, le type d’intervalle à utiliser (comme l’interruption régulière, exponentielle et la randomisation), les valeurs d’intervalle réelles et le nombre de tentatives de nouvelle tentative.
Implémentez des nouvelles tentatives dans de nombreux endroits, même dans l’application la plus simple et dans chaque couche d’applications plus complexes. Au lieu de coder en dur les éléments de chaque stratégie à plusieurs emplacements, envisagez d’utiliser un point central pour stocker toutes les stratégies. Par exemple, stockez des valeurs telles que l’intervalle et le nombre de nouvelles tentatives dans les fichiers de configuration d’application, lisez-les au moment de l’exécution et générez par programme les stratégies de nouvelle tentative. Cela facilite la gestion des paramètres et la modification et l’optimisation des valeurs afin de répondre aux exigences et scénarios changeants. Toutefois, concevez le système pour stocker les valeurs plutôt que de relire un fichier de configuration à chaque fois et utilisez les valeurs par défaut appropriées si les valeurs ne peuvent pas être obtenues à partir de la configuration.
Dans une application Azure Cloud Services, envisagez de stocker les valeurs utilisées pour générer les stratégies de nouvelle tentative au moment de l’exécution dans le fichier de configuration du service afin de pouvoir les modifier sans avoir à redémarrer l’application.
Tirez parti des stratégies de nouvelle tentative intégrées ou par défaut disponibles dans les API clientes que vous utilisez, mais uniquement quand elles sont appropriées pour 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 de débit est souvent un indicateur d’un défaut de conception dans l’application ou la nécessité de basculer vers un service premium offrant du matériel dédié.
Envisagez de mesurer et de journaliser les temps écoulés globaux pour les opérations qui incluent un mécanisme de nouvelle tentative. Cette métrique est un bon indicateur de l’effet global des erreurs temporaires sur les temps de réponse utilisateur, la latence du processus et l’efficacité des cas d’utilisation de l’application. Consignez également le nombre de nouvelles tentatives qui se produisent afin de comprendre les facteurs qui contribuent au temps de réponse.
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 façon dont vous allez gérer les opérations qui continuent d’échouer à chaque tentative. Les situations de ce genre sont inévitables.
Bien qu’une stratégie de nouvelle tentative définit le nombre maximal de tentatives qu’une opération doit être retentée, elle n’empêche pas l’application de répéter à nouveau l’opération avec le même nombre de nouvelles tentatives. Par exemple, si un service de traitement des commandes échoue avec une erreur irrécupérable qui le met hors action définitivement, la stratégie de nouvelle tentative peut détecter un délai d’expiration de connexion et considérer qu’il s’agit d’une erreur temporaire. Le code retente l’opération un nombre spécifié de fois, puis abandonne. Toutefois, lorsqu’un autre client passe une commande, l’opération est tentée à nouveau, même si elle échoue à chaque fois.
Pour empêcher les nouvelles tentatives des opérations qui échouent continuellement, implémentez le modèle Disjoncteur. Lorsque vous utilisez ce modèle, si le nombre d’échecs dans une fenêtre de temps spécifiée dépasse un seuil, les demandes retournent immédiatement à l’appelant en tant qu’erreurs et il n’y a aucune tentative d’accès à la ressource ou au service ayant échoué.
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 revenir à une autre instance du service (peut-être dans un autre centre de données ou application), utiliser un service similaire qui offre des fonctionnalités compatibles (peut-être plus simples) ou effectuer des opérations alternatives en fonction de l’espoir 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. Vous pouvez également rediriger l’utilisateur vers une autre instance de l’application, dégrader les performances de l’application, mais toujours offrir des fonctionnalités acceptables, ou simplement renvoyer un message à l’utilisateur pour indiquer que l’application n’est pas actuellement 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 en cas d’échec. Dans ce cas, un intervalle très long et un grand nombre de nouvelles tentatives peuvent être acceptables tant que cette stratégie ne bloque pas d’autres opérations en maintenant ou en verrouillant 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 incrémente une valeur est répétée, elle produit un résultat non valide. La répétition d’une opération qui envoie un message à une file d’attente peut entraîner une incohérence dans le consommateur de messages si le consommateur ne peut pas détecter les messages en double. Pour éviter ces scénarios, concevez chaque étape en tant qu’opération idempotente. Pour plus d’informations, consultez Modèles d’idempotence.
Considérez la portée des opérations en cours de répétition. 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. Toutefois, cela peut donner lieu à des problèmes d’idempotence ou à des opérations de restauration inutiles.
Si vous choisissez une étendue de nouvelle tentative qui englobe plusieurs opérations, prenez en compte la latence totale de tous ceux-ci 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 pour les défaillances.
Réfléchissez à la façon dont votre stratégie de nouvelle tentative peut affecter les voisins et d’autres locataires dans une application partagée et quand vous utilisez des ressources et des services partagés. Les stratégies de nouvelle tentative agressive peuvent entraîner un nombre croissant d’erreurs temporaires pour ces autres utilisateurs et pour les applications qui partagent les ressources et les services. De même, votre application peut être affectée par les stratégies de nouvelle tentative implémentées par d’autres utilisateurs des ressources et services. Pour les applications critiques pour l’entreprise, vous pouvez utiliser des services Premium qui ne sont pas partagés. Cela vous permet de mieux contrôler la charge et la limitation conséquente de ces ressources et services, ce qui peut vous aider à justifier le coût supplémentaire.