Compartir a través de

Recomendaciones para gestionar errores transitorios

  • Artículo

Se aplica a esta recomendación de la lista de verificación de confiabilidad bien diseñada: Power Platform

RE:05 Fortalezca la resistencia de su carga de trabajo implementando la gestión de errores y de errores transitorios. Incorpore capacidades a la solución para manejar errores de componentes y errores transitorios.

Esta guía describe las recomendaciones para gestionar errores transitorios en sus aplicaciones en la nube. Todas las aplicaciones que se comunican con servicios y recursos remotos deben ser sensibles a errores transitorios. Esto es especialmente cierto para las aplicaciones que se ejecutan en la nube, donde, debido a la naturaleza del entorno y la conectividad a través de Internet, es probable que se produzca este tipo de fallo con más frecuencia. Los errores transitorios incluyen la pérdida momentánea de conectividad de red a componentes y servicios, la indisponibilidad temporal de un servicio y los tiempos de espera que ocurren cuando un servicio está ocupado. Estos errores a menudo se corrigen solos, por lo que si la acción se repite después de un retraso adecuado, es probable que tenga éxito.

Estrategias clave de diseño

Los errores transitorios pueden ocurrir en cualquier entorno, en cualquier plataforma o sistema operativo y en cualquier tipo de aplicación.

Desafíos

Los errores transitorios pueden tener un efecto significativo en la disponibilidad percibida de una aplicación, incluso si se ha probado exhaustivamente en todas las circunstancias previsibles. Para garantizar que su carga de trabajo Power Platform pueda funcionar de manera fiable, debe asegurarse de que pueda responder a los siguientes desafíos:

  • La aplicación debe poder detectar errores cuando ocurren y determinar si es probable que sean transitorios, duraderos o terminales. Es probable que diferentes recursos devuelvan respuestas diferentes cuando ocurre un error, y estas respuestas también pueden variar según el contexto de la operación. Por ejemplo, la respuesta a un error cuando la aplicación está recuperando datos de un conector personalizado puede ser diferente de la respuesta cuando la aplicación ejecuta un flujo de nube y espera la respuesta.

  • La aplicación debe poder volver a intentar la operación si determina que es probable que el error sea transitorio.

  • La aplicación debe utilizar una estrategia adecuada para los reintentos. La estrategia especifica la cantidad de veces que la aplicación debe reintentar, el retraso entre cada intento y las acciones a tomar después de un intento fallido. El número adecuado de intentos y el retraso entre cada uno suelen ser difíciles de determinar. La estrategia varía según el tipo de recurso y las condiciones operativas actuales del recurso y la aplicación.

Guías generales

Las siguientes pautas pueden ayudarle a diseñar mecanismos adecuados de gestión de errores transitorios para sus aplicaciones.

Determinar si hay un mecanismo de reintento integrado

Es posible que algunos servicios a los que se esté conectando ya proporcionen un mecanismo de gestión de errores transitorios. La directiva de reintentos que utiliza normalmente se adapta a la naturaleza y los requisitos del servicio de destino. Alternativamente, las interfaces REST para servicios pueden devolver información que puede ayudarle a determinar si un reintento es apropiado y cuánto tiempo esperar antes del siguiente reintento.

Debe utilizar el mecanismo de reintento integrado cuando esté disponible, a menos que tenga requisitos específicos y bien comprendidos que hagan que un comportamiento de reintento diferente sea más apropiado.

Determinar si la operación es adecuada para volver a intentarlo

Realice operaciones de reintento solo cuando los errores sean transitorios (normalmente indicados por la naturaleza del error) y cuando exista al menos cierta probabilidad de que la operación se realice correctamente cuando se reintente. No tiene sentido volver a intentar operaciones que intenten una operación no válida, como actualizar una fila en Microsoft Dataverse que no existe o para la cual el usuario no tiene permiso, o llamar a una API punto de conexión que no existe.

Implemente reintentos solo cuando pueda determinar el efecto total de hacerlo y cuando las condiciones se comprendan bien y puedan validarse. Recuerde que los errores devueltos por recursos y servicios fuera de su control pueden evolucionar con el tiempo y es posible que deba revisar su lógica de detección de fallas transitorias.

Cuando desarrolle componentes o servicios individuales que se llaman desde sus aplicaciones, asegúrese de devolver códigos de error y mensajes que ayuden a los clientes a determinar si deben volver a intentar las operaciones fallidas. Considere indicar si el cliente debe volver a intentar la operación; por ejemplo, devolviendo un valor isTransient. Si crea un servicio web, considere devolver errores personalizados definidos en sus contratos de servicio.

Determinar un recuento y un intervalo de reintentos adecuados

Optimice el recuento de reintentos y el intervalo según el tipo de caso de uso. Si no lo vuelve a intentar suficientes veces, la aplicación no podrá completar la operación y probablemente fallará. Si lo reintenta demasiadas veces o con un intervalo demasiado corto entre intentos, la aplicación podría retener recursos durante períodos prolongados, lo que afecta negativamente el estado de la aplicación.

Adapte los valores del intervalo de tiempo y el número de reintentos al tipo de operación. Por ejemplo, si la operación es parte de una interacción del usuario, el intervalo debe ser corto y solo se deben intentar unos pocos reintentos. Al utilizar este enfoque, puede evitar que los usuarios esperen una respuesta. Si la operación es parte de un flujo de trabajo crítico o de larga duración, donde cancelar y reiniciar el proceso es costoso o requiere mucho tiempo, es apropiado esperar más tiempo entre intentos y volver a intentarlo más veces.

Tenga en cuenta que determinar los intervalos adecuados entre reintentos es la parte más difícil de diseñar una estrategia exitosa. Las estrategias típicas utilizan los siguientes tipos de intervalo de reintento:

  • Intervalo exponencial. La aplicación espera un breve tiempo antes del primer reintento y luego aumenta exponencialmente el tiempo entre cada reintento posterior. Por ejemplo, podría volver a intentar la operación después de 3 segundos, 12 segundos, 30 segundos, etc.

  • Intervalos fijos. La aplicación espera el mismo período de tiempo entre cada intento.

  • Reintento inmediato. A veces, un error transitorio es breve y es apropiado volver a intentar la operación inmediatamente porque podría tener éxito si el error se soluciona en el tiempo que le toma a la aplicación enviar la siguiente solicitud. Sin embargo, nunca debería haber más de un reintento inmediato. Debe cambiar a estrategias alternativas, como intervalo exponencial o acciones alternativas, si falla el reintento inmediato.

Como pauta general, utilice una estrategia de intervalo exponencial para operaciones en segundo plano y utilice estrategias de reintento de intervalo fijo o inmediato para operaciones interactivas. En ambos casos, debe elegir el retraso y el recuento de reintentos de modo que la latencia máxima para todos los reintentos esté dentro del requisito de latencia de extremo a extremo requerido.

Considere la combinación de todos los factores que contribuyen al tiempo de espera máximo general para una operación reintentada. Estos factores incluyen el tiempo que tarda una conexión fallida en producir una respuesta, el retraso entre reintentos y el número máximo de reintentos. El total de todos estos tiempos puede resultar en tiempos de operación generales prolongados, especialmente cuando se utiliza una estrategia de retraso exponencial donde el intervalo entre reintentos crece rápidamente después de cada error. Si un proceso debe cumplir con un acuerdo de nivel de servicio (SLA) específico, el tiempo total de operación, incluidos todos los tiempos de espera y retrasos, debe estar dentro de los límites definidos en el SLA.

No implemente estrategias de reintento demasiado agresivas. Se trata de estrategias que tienen intervalos demasiado cortos o reintentos demasiado frecuentes. Pueden tener un efecto adverso en el recurso o servicio de destino. Estas estrategias pueden impedir que el recurso o servicio se recupere de su estado sobrecargado y continuará bloqueando o rechazando solicitudes. Este escenario da como resultado un círculo vicioso, donde cada vez se envían más solicitudes al recurso o servicio. En consecuencia, su capacidad de recuperación se reduce aún más.

Tenga en cuenta el tiempo de espera de las operaciones cuando elija intervalos de reintento para evitar iniciar un intento posterior inmediatamente (por ejemplo, si el período de tiempo de espera es similar al intervalo de reintento).

Utilice el tipo de error o los códigos de error y mensajes devueltos por el servicio para optimizar el número de reintentos y el intervalo entre ellos. Por ejemplo, algunas excepciones o códigos de error (como el código HTTP 503, Servicio no disponible, con un encabezado Reintentar-Después en la respuesta) pueden indicar cuánto tiempo podría durar el error, o que el servicio falló y no responderá a ningún intento posterior.

Evitar antipatrones

En la mayoría de los casos, evite implementaciones que incluyan capas duplicadas de código de reintento. Evite diseños que incluyan mecanismos de reintento en cascada o que implementen reintentos en cada etapa de una operación que involucre una jerarquía de solicitudes, a menos que tenga requisitos específicos para hacerlo. En estas circunstancias excepcionales, utilice directivas que eviten un número excesivo de reintentos y períodos de retraso, y asegúrese de comprender las consecuencias. Por ejemplo, digamos que un componente realiza una solicitud a otro, que luego accede al servicio de destino. Si implementa el reintento contando hasta tres en ambas llamadas, hay nueve reintentos en total contra el servicio. Muchos servicios y recursos implementan un mecanismo de reintento integrado. Debe investigar cómo puede deshabilitar o modificar estos mecanismos si necesita implementar reintentos en un nivel superior.

Nunca implemente un mecanismo de reintento sin fin. Al hacerlo, es probable que impida que el recurso o servicio se recupere de situaciones de sobrecarga y provoque que las limitaciones y las conexiones rechazadas continúen durante más tiempo.

Nunca realice un reintento inmediato más de una vez.

Evite usar un intervalo de reintento fijo cuando acceda a servicios y recursos en Azure, especialmente cuando tenga una gran cantidad de reintentos. El mejor enfoque en este escenario es una estrategia de intervalo exponencial.

Pruebe su estrategia e implementación de reintentos

Pruebe completamente su estrategia de reintento en el mayor conjunto de circunstancias posible, especialmente cuando tanto la aplicación como los recursos o servicios de destino que utiliza se encuentran bajo una carga extrema. Para comprobar el comportamiento durante las pruebas, puede:

  • Inyectar errores transitorios y no transitorios en el servicio. Por ejemplo, envíe solicitudes no válidas o agregue código que detecte solicitudes de prueba y responda con diferentes tipos de errores.

  • Cree una versión del recurso o servicio que devuelva una variedad de errores que el servicio real podría devolver. Cubra todos los tipos de errores que su estrategia de reintento está diseñada para detectar.

  • Para los servicios personalizados que crea e implementa, fuerce la aparición de errores transitorios deshabilitando o sobrecargando temporalmente el servicio. (No intente sobrecargar ningún recurso o servicio compartido en Azure).

  • Al probar la resistencia de una aplicación web cliente a errores transitorios, utilice las herramientas de desarrollo del navegador o la capacidad de su marco de prueba para simular o bloquear solicitudes de red.

  • Realice pruebas simultáneas y de alto factor de carga para garantizar que el mecanismo y la estrategia de reintento funcionen correctamente en estas condiciones. Estas pruebas también ayudan a garantizar que el reintento no tenga un efecto adverso en el funcionamiento del cliente ni provoque contaminación cruzada entre solicitudes.

Administrar configuraciones de directivas de reintentos

Una directiva de reintentos es una combinación de todos los elementos de su estrategia de reintento. Define el mecanismo de detección que determina si es probable que una error sea transitorio, el tipo de intervalo a usar (como fijo o exponencial), los valores reales del intervalo y la cantidad de veces que se debe reintentar.

Aproveche las estrategias de reintento integradas o predeterminadas, pero solo cuando sean apropiadas para su situación. Estas estrategias suelen ser genéricas. En algunos escenarios, pueden ser todo lo que necesita, pero en otros no ofrecen la gama completa de opciones para satisfacer sus requisitos específicos. Para determinar los valores más apropiados, debe realizar pruebas para comprender cómo la configuración afecta su aplicación.

Registre y rastree fallas transitorias y no transitorias

Como parte de su estrategia de reintento, incluya la gestión de excepciones y otra instrumentación que registre los reintentos. Se espera que se produzcan errores transitorios ocasionales y reintentos, pero no indican ningún problema. Sin embargo, un número creciente y regular de reintentos suele ser un indicador de un problema que podría provocar un error o que degrada el rendimiento y la disponibilidad de la aplicación.

Registre los errores transitorios como entradas de advertencia en lugar de entradas de error para que los sistemas de supervisión no las detecten como errores de aplicaciones que podrían desencadenar alertas falsas.

Considere almacenar un valor en sus entradas de registro que indique si los reintentos son causados ​​por la limitación del servicio o por otros tipos de fallas, como fallas de conexión, para que pueda diferenciarlos durante el análisis de los datos. Un aumento en la cantidad de errores de limitación suele ser un indicador de un defecto de diseño en la aplicación o de la necesidad de agregar capacidad superior al entorno.

Considere implementar un sistema de telemetría y supervisión que pueda generar alertas cuando aumente la cantidad y la tasa de errores, la cantidad promedio de reintentos o el tiempo total transcurrido antes de que las operaciones tengan éxito.

Gestionar operaciones que fallan continuamente

Considere cómo manejar operaciones que siguen fallando en cada intento. Situaciones como esta son inevitables.

Aunque una estrategia de reintentos define la cantidad máxima de veces que se debe reintentar una operación, no impide que la aplicación repita la operación con la misma cantidad de reintentos. Por ejemplo, enviar un formulario en su aplicación podría desencadenar un flujo. La estrategia de reintentos podría detectar un tiempo de espera de conexión y considerarlo como un error transitorio. El flujo reintentará la operación un número específico de veces y luego se dará por vencido. Sin embargo, cuando el mismo usuario o uno nuevo intenta enviar el formulario nuevamente, la operación se intenta nuevamente, aunque pueda seguir fallando.

La aplicación puede probar periódicamente el servicio, de forma intermitente y con largos intervalos entre solicitudes, para detectar cuando esté disponible. Un intervalo apropiado depende de factores como la criticidad de la operación y la naturaleza del servicio. Puede ser desde unos pocos minutos hasta varias horas. Cuando la prueba tiene éxito, la aplicación puede reanudar las operaciones normales y pasar solicitudes al servicio recién recuperado.

Mientras tanto, es posible que puedas realizar algunas operaciones alternativas con la esperanza de que el servicio esté disponible pronto. Por ejemplo, podría ser apropiado almacenar las solicitudes del servicio en una cola o almacén de datos y volver a intentarlas más tarde. O es posible que deba devolver un mensaje al usuario para indicarle que la aplicación no está disponible.

Otras consideraciones

Cuando decida los valores para el número de reintentos y los intervalos de reintento para una directiva, considere si la operación en el servicio o recurso es parte de una operación de larga duración o de varios pasos. Puede resultar difícil o costoso compensar todos los demás pasos operativos que ya han tenido éxito cuando uno falla. En este caso, un intervalo largo y una gran cantidad de reintentos podrían ser aceptables, siempre y cuando esa estrategia no bloquee otras operaciones reteniendo o bloqueando recursos escasos.

Considere si volver a intentar la misma operación podría causar inconsistencias en los datos. Si algunas partes de un proceso de varios pasos se repiten y las operaciones no son idempotentes, pueden ocurrir inconsistencias. Por ejemplo, si se repite una operación que inserta un registro en Microsoft Dataverse, podría provocar valores incorrectos en la tabla. O, si repite una operación que envía una notificación al usuario, es posible que reciba mensajes duplicados.

Considere el ámbito de las operaciones que se reintentan. Por ejemplo, podría ser más fácil implementar un código de reintento en un nivel que abarque varias operaciones y reintentarlas todas si una falla. Sin embargo, hacerlo podría provocar problemas de idempotencia u operaciones de reversión innecesarias.

Si elige un ámbito de reintento que abarca varias operaciones, considere la latencia total de todas ellas cuando determine los intervalos de reintento, cuando supervise los tiempos transcurridos de la operación y antes de generar alertas de fallas.

Facilitación de Power Platform

Las siguientes secciones describen los mecanismos que puede utilizar para gestionar fallas transitorias.

Power Automate

Power Automate incluye una función para volver a intentar una acción si falla. Configure esto a nivel de acción. Aprenda a reducir riesgos y planificar el manejo de errores en un Power Automate proyecto. Power Automate también ofrece acciones para devolver errores y datos personalizados a la aplicación o flujo de llamadas.

Algunos flujos transitorios pueden deberse a límites de solicitud y rendimiento. Aprenda sobre los límites de flujos automatizados, programados e instantáneos y solicitar límites y asignaciones.

Configure el manejo de errores y excepciones en flujos de nube mediante el uso de ámbitos y configuraciones de ejecución posterior.

Power Apps

Las aplicaciones de lienzo de Power Apps ofrecen la capacidad de comprobar el estado de la conexión, lo que les permite comportarse de manera diferente si la aplicación está fuera de línea. Aprenda a desarrollar aplicaciones de Canvas que puedan ejecutarse sin conexión.

También puede utilizar las funciones Error, IfError, IsError e IsBlankOrError en aplicaciones de lienzo para decidir qué hacer a continuación si se produce un error.

Obtenga más información sobre el manejo de errores transitorios en Power Apps:

Conectores Azure y personalizados

Si su carga de trabajo se conecta a los servicios de Azure, aprenda a gestionar errores transitorios mediante Azure Well-Architected Framework.

Para administrar las respuestas del conector personalizado a los errores, siga estándares de codificación.

Application Insights

Utilizar las integraciones de Application Insights para registrar errores en Power Automate y Power Apps:

Continuidad empresarial y recuperación ante desastres para aplicaciones SaaS de Dynamics 365

Lista de comprobación de fiabilidad

Consulte el conjunto completo de recomendaciones.

Lista de verificación de confiabilidad