Compartir a través de


Recomendaciones para realizar análisis de modo de error

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

RE:03 Use el análisis modal de fallos ( FMA) para identificar y priorizar los errores potenciales en los componentes de su solución. Lleve a cabo el FMA como ayuda para evaluar el riesgo y el efecto de cada modo de error. Determine cómo responde y se recupera la carga de trabajo.

Esta guía describe los procedimientos recomendados para realizar análisis de modo de error (FMA) para su carga de trabajo. FMA es la práctica de identificar posibles puntos de error dentro de su carga de trabajo y los flujos asociados, y planifique acciones de mitigación en consecuencia. En cada paso del flujo, usted identifica el radio de explosión de múltiples tipos de errores, lo que le ayuda a diseñar una nueva carga de trabajo o refactorizar una carga de trabajo existente para minimizar el efecto generalizado de los errores.

Un principio clave de FMA es que los errores ocurren sin importar cuántas capas de resiliencia se apliquen. Los entornos más complejos están expuestos a más tipos de errores. Dada esta realidad, FMA le permite diseñar su carga de trabajo para resistir la mayoría de los tipos de errores y recuperarse sin problemas cuando ocurre un error.

Si omite FMA por completo o realiza un análisis incompleto, su carga de trabajo corre el riesgo de sufrir un comportamiento imprevisto y posibles interrupciones causadas por un diseño subóptimo.

Definiciones

Término Definición
Modo de error Un tipo de problema que puede provocar que uno o más componentes de la carga de trabajo se degraden o afecten gravemente hasta el punto de no estar disponibles.
Mitigación Las actividades que ha identificado para abordar los problemas de forma proactiva o reactiva.
duplicados Sus procesos y procedimientos de seguimiento y alerta de datos y aplicaciones.

Estrategias clave de diseño

En el contexto de FMA, comprender los requisitos previos es crucial. Comience revisando e implementando recomendaciones para identificar flujos, priorizándolos según su criticidad. Sus artefactos de datos desempeñan un papel fundamental a la hora de describir las rutas de datos dentro de estos flujos. A medida que profundiza en el enfoque FMA, concéntrese en planificar componentes para flujos críticos, identificar dependencias (tanto internas como externas) y diseñar estrategias de mitigación.

Requisitos previos

Revisar e implementar las recomendaciones para identificar y calificar flujos. Se supone que ha identificado y priorizado los flujos de usuarios y sistemas según su criticidad.

Los datos que ha recopilado y los artefactos que ha creado en su trabajo le proporcionan una descripción concreta de las rutas de datos involucradas a lo largo de los flujos. Para tener éxito en su trabajo de FMA, la precisión y minuciosidad en sus artefactos son fundamentales.

Enfoque de FMA

Después de determinar los flujos críticos, puede planificar los componentes necesarios. A continuación, siga cada flujo paso a paso para identificar dependencias, incluidos servicios de terceros y posibles puntos de error, y planifique sus estrategias de mitigación.

Descomponer la carga de trabajo

A medida que pasa de la idea al diseño, debe identificar los tipos de componentes necesarios para dar soporte a su carga de trabajo. Su carga de trabajo determina los componentes necesarios que debe planificar.

Tras crear su diseño de arquitectura inicial, puede superponer sus flujos para identificar los componentes discretos que se utilizan en esos flujos y crear listas o diagramas de flujo de trabajo que describan los flujos y sus componentes. Para comprender la criticidad de los componentes, utilice las definiciones de criticidad que haya asignado a los flujos. Considere el efecto del mal funcionamiento de un componente en sus flujos.

Identificar dependencias

Identifique las dependencias de su carga de trabajo para realizar su análisis de punto único de error. Descomponer su carga de trabajo y superponer flujos proporciona información sobre las dependencias internas y externas a la carga de trabajo.

Las dependencias internas son componentes en el alcance de la carga de trabajo que son necesarios para que la carga de trabajo funcione. Las dependencias internas típicas incluyen API o soluciones de administración de claves/secretos como Azure Key Vault. Para estas dependencias, capture los datos de fiabilidad, como los acuerdos de nivel de servicio (SLA) de disponibilidad y los límites de escalamiento. Las dependencias externas son componentes necesarios fuera del alcance de la carga de trabajo, como otra aplicación o servicio de terceros. Las dependencias externas típicas incluyen soluciones de autenticación, como Microsoft Entra ID e infraestructura de Power Platform.

Identifique y documente las dependencias en su carga de trabajo e inclúyalas en sus artefactos de documentación de flujo.

Puntos de error

En los flujos críticos de su carga de trabajo, considere cada componente y determine cómo ese componente y sus dependencias podrían verse afectados por un modo de error. Recuerde que hay muchos modos de error a considerar al planificar la resistencia y la recuperación. Cualquier componente puede verse afectado por más de un modo de error en un momento dado. Estos modos de error incluyen:

  • Interrupción regional: toda una región de Azure de Power Platform no está disponible
  • Interrupción del servicio: uno o más servicios de Azure o Power Platform no están disponibles
  • Denegación de servicio distribuido (DDoS) u otro ataque malicioso
  • Configuración errónea de aplicación o componente
  • Error del operador
  • Interrupción del mantenimiento planeado
  • Sobrecarga de componente

Considere la probabilidad de cada tipo de modo de error. Algunos son muy poco probables, como las interrupciones en varias zonas o regiones, y agregar una planificación de mitigación más allá de la redundancia no es un buen uso de los recursos y el tiempo.

Mitigación

Las estrategias de mitigación se dividen en dos categorías amplias: generar más resistencia y diseñar para un rendimiento degradado.

Desarrollar más resistencia significa garantizar que el diseño de su aplicación siga los procedimientos recomendados para mayor durabilidad; por ejemplo, dividir aplicaciones monolíticas en aplicaciones y microservicios aislados y utilizar configuraciones de resistencia proporcionadas por la plataforma, como directivas de reintento. Para obtener más información, consulte Recomendaciones de redundancia y Recomendaciones de autoconservación.

Para diseñar para un rendimiento degradado, identifique posibles puntos de error que podrían deshabilitar uno o más componentes de su flujo, pero no deshabilite ese flujo por completo. Para mantener la funcionalidad del flujo de un extremo a otro, es posible que necesite redirigir uno o más pasos a otros componentes o aceptar que un componente fallido ejecute una función, de modo que la función ya no esté disponible en la experiencia del usuario. Para volver al ejemplo de la aplicación de comercio electrónico, un componente fallido, como un microservicio, puede hacer que su motor de recomendaciones no esté disponible, pero los clientes aún pueden buscar productos y completar su transacción.

También es necesario planificar la mitigación en torno a las dependencias. Las dependencias fuertes desempeñan un papel fundamental en el funcionamiento y la disponibilidad de las aplicaciones. Si están ausentes o experimentan un mal funcionamiento, puede haber un efecto significativo. La ausencia de dependencias débiles podría afectar solo a características específicas y no a la disponibilidad general. Esta distinción refleja el costo de mantener la relación de alta disponibilidad entre el servicio y sus dependencias. Clasifique las dependencias como fuertes o débiles para ayudarle a identificar qué componentes son esenciales para la aplicación.

Si la aplicación tiene dependencias fuertes sin las cuales no puede funcionar, los objetivos de disponibilidad y recuperación de estas dependencias deben alinearse con los objetivos de la aplicación misma. Si el ciclo de vida de la aplicación está estrechamente relacionado con el ciclo de vida de sus dependencias, la agilidad operativa de la aplicación podría ser limitada, especialmente para las nuevas versiones.

duplicados

La detección de errores es esencial para garantizar que haya identificado correctamente los puntos de error en su análisis y planificado adecuadamente sus estrategias de mitigación. La detección en este contexto significa supervisar su infraestructura, datos y aplicaciones, y alertar cuando surjan problemas. Automatice la detección tanto como sea posible y cree redundancia en sus procesos operativos para garantizar que las alertas siempre se detecten y se respondan con la suficiente rapidez para cumplir con los requisitos de su negocio. Para más información, consulte Recomendaciones de supervisión.

Resultado

Para el resultado de su análisis, cree un conjunto de documentos que comuniquen de manera efectiva sus hallazgos, las decisiones que tomó en relación con los componentes del flujo y la mitigación, y el efecto de la falla en su carga de trabajo.

En su análisis, priorice los modos de error y las estrategias de mitigación que haya identificado en función de la gravedad y la probabilidad. Utilice esta priorización para centrar su documentación en aquellos modos de error que son lo suficientemente comunes y graves como para justificar la inversión de tiempo, esfuerzo y recursos en el diseño de estrategias de mitigación. Por ejemplo, puede haber algunos modos de error que son muy raros de ocurrir o detectar. No vale la pena diseñar estrategias de mitigación en torno a ellos.

Consulte la tabla de ejemplo como punto de partida para la documentación.

Durante su ejercicio inicial de FMA, los documentos que produzca serán en su mayoría de planificación teórica. Los documentos de la FMA deben revisarse y actualizarse periódicamente para garantizar que se mantengan actualizados con su carga de trabajo. Las pruebas de caos y las experiencias del mundo real le ayudarán a perfeccionar sus análisis con el tiempo.

Ejemplo

La siguiente tabla muestra un ejemplo de FMA para una aplicación de gastos alojada como aplicación de lienzo de Power Apps con un backend de Microsoft Dataverse y API alojadas en APIM para interactuar con un sistema de terceros.

Flujo de usuario: Inicio de sesión del usuario, envío del reclamo de gastos e interacción con el informe de gastos

Componente Riesgo Probabilidad Efecto/Mitigación/Nota Interrupción
Id. de Microsoft Entra Interrupción de servicio Bajo Interrupción total de la carga de trabajo. Depende de Microsoft remediar. Completo
Id. de Microsoft Entra Error de configuración Medio Los usuarios no pueden iniciar sesión. Sin efecto descendente. La mesa de ayuda informa el problema de configuración al equipo de identidad. None
Power Apps Interrupción de servicio Bajo Interrupción total para usuarios externos. Depende de Microsoft remediar. Completo
Power Apps Interrupción regional Muy bajo Interrupción total para usuarios externos. Depende de Microsoft remediar. Completo
Power Apps Ataque DDoS Medio Potencial de interrupción. Microsoft Gestiona la protección DDoS (L3 y L4). Posible interrupción parcial
Dataverse Interrupción de servicio Bajo Interrupción total de la carga de trabajo. Depende de Microsoft remediar. Completo
Dataverse Interrupción regional Muy bajo El grupo de conmutación por error automático conmuta por error a la región secundaria. Posible interrupción durante la conmutación por error. Los objetivos de tiempo de recuperación (RTO) y los objetivos de punto de recuperación (RPO) se determinarán durante las pruebas de fiabilidad. Potencial completo
Dataverse Ataque malicioso (inyección) Medio Riesgo mínimo. Riesgo potencial bajo
API Management Interrupción de servicio Bajo Interrupción total para usuarios externos. Depende de Microsoft remediar. Completo
API Management Interrupción regional Muy bajo Interrupción total para usuarios externos. Depende de Microsoft remediar. Completo
API Management Ataque DDoS Medio Potencial de interrupción. Microsoft Gestiona la protección DDoS (L3 y L4). Posible interrupción parcial
Su solución de Power Platform Error de configuración Medio Las configuraciones incorrectas deben detectarse durante la implementación. Si esto sucede durante una actualización de configuración, los administradores deben revertir los cambios. La actualización de la configuración provoca una breve interrupción externa. Posible interrupción completa

Facilitación de Power Platform

Power Platform se integra con Application Insights, que es parte del ecosistema de Azure Monitor. Puede usar esta integración para lo siguiente:

  • Suscribirse para recibir telemetría capturada por la plataforma Dataverse en Application Insights sobre diagnósticos, rendimiento y las operaciones que realizan las aplicaciones en su base de datos de Dataverse y dentro de las aplicaciones basadas en modelo. Esta telemetría proporciona información que puede utilizar para diagnosticar y solucionar problemas relacionados con errores y rendimiento.

  • Conectar sus aplicaciones de lienzo a Application Insights para utilizar estos análisis para diagnosticar problemas, comprender qué hacen realmente los usuarios con sus aplicaciones, impulsar mejores decisiones comerciales y mejorar la calidad de sus aplicaciones.

  • Configurar la telemetría de Power Automate para flujos en Application Insights. Puede usar esta telemetría para supervisar las ejecuciones de flujos en la nube y crear alertas para errores en la ejecución de flujos en la nube.

  • Captura datos de telemetría de tu Microsoft Copilot Studio copiloto para usar en Azure Application Insights. Puede utilizar esta telemetría para monitorear los mensajes y eventos registrados enviados hacia y desde su copiloto, los temas que se activarán durante las conversaciones de los usuarios y los eventos de telemetría personalizados que se pueden enviar desde sus temas.

Power Platform actividades del registro de recursos en el Microsoft portal de cumplimiento de Purview. La mayoría de los eventos están disponibles dentro de las 24 horas posteriores a la actividad. No utilice esta información para supervisión en tiempo real. Para obtener más información sobre actividades de registro en Power Platform, consulte:

Lista de comprobación de fiabilidad

Consulte el conjunto completo de recomendaciones.