Recomendaciones para realizar el análisis del modo de error
Se aplica a esta recomendación de lista de comprobación de confiabilidad del marco de trabajo bien diseñado de Azure:
| RE:03 | Use el análisis del modo de error (FMA) para identificar y priorizar posibles errores en los componentes de la solución. Realice FMA para ayudarle a evaluar el riesgo y el efecto de cada modo de error. Determine cómo responde y recupera la carga de trabajo. |
|---|
En esta guía se describen los procedimientos recomendados para realizar el análisis del modo de error (FMA) para la carga de trabajo. FMA es la práctica de identificar posibles puntos de error dentro de la carga de trabajo y los flujos asociados y planear las acciones de mitigación en consecuencia. En cada paso del flujo, se identifica el radio de explosión de varios tipos de error, lo que le ayuda a diseñar una nueva carga de trabajo o a refactorizar una carga de trabajo existente para minimizar el efecto generalizado de los errores.
Un tenet clave de FMA es que los errores se producen independientemente de cuántas capas de resistencia aplique. Los entornos más complejos se exponen a más tipos de errores. Dada esta realidad, FMA permite diseñar la carga de trabajo para resistir la mayoría de los tipos de errores y recuperarse correctamente cuando se produce un error.
Si omite FMA por completo o realiza un análisis incompleto, la carga de trabajo corre el riesgo de que el comportamiento no esté precedido y las posibles interrupciones causadas por un diseño poco óptimo.
Definiciones
| Término | Definición |
|---|---|
| Modo de error | Un tipo de problema que puede hacer que uno o varios componentes de carga de trabajo se degradan o se vean gravemente afectados hasta el punto de no estar disponibles. |
| Mitigación | Las actividades que ha identificado para solucionar problemas de forma proactiva o reactiva. |
| Detección | La infraestructura, los datos y la supervisión de aplicaciones y los procesos y procedimientos de alertas. |
Estrategias de diseño principales
Revise e implemente las recomendaciones para identificar flujos. Se supone que ha identificado y priorizado flujos de usuario y sistema en función de la importancia crítica.
Los datos que ha recopilado y los artefactos que ha creado en el trabajo proporcionan una descripción concreta de las rutas de acceso de datos implicadas en los flujos. Para tener éxito en el trabajo de FMA, la precisión y la profundidad de los artefactos es fundamental.
Después de determinar los flujos críticos, puede planear sus componentes necesarios. A continuación, siga cada flujo paso a paso para identificar las dependencias, incluidos los servicios de terceros y los posibles puntos de error, y planee las estrategias de mitigación.
Descompone la carga de trabajo
A medida que pasa de la idea al diseño, debe identificar los tipos de componentes necesarios para la carga de trabajo. La carga de trabajo determina los componentes necesarios que debe incluir en la planeamiento. Normalmente, debe planear el control de entrada, las redes, los procesos, los datos, el almacenamiento, los servicios auxiliares (como la autenticación, la mensajería y la administración de claves) y el control de salida. En esta fase del trabajo de diseño, es posible que no conozca las tecnologías específicas que implementará, por lo que el diseño podría ser similar al ejemplo siguiente.
Después de crear el diseño inicial de la arquitectura, puede superponer los flujos para identificar los componentes discretos que se usan en esos flujos y crear listas o diagramas de flujo de trabajo que describen los flujos y sus componentes. Para comprender la importancia de los componentes, use las definiciones de importancia que ha asignado a los flujos. Considere el efecto de un mal funcionamiento de un componente en los flujos.
Identificación de las dependencias
Identifique las dependencias de carga de trabajo para realizar el análisis de punto de error único. La descomposición de la carga de trabajo y los flujos de superposición proporciona información sobre las dependencias que son internas y externas a la carga de trabajo.
Las dependencias internas son componentes del ámbito de carga de trabajo que son necesarios para que funcione la carga de trabajo. Las dependencias internas típicas incluyen API o soluciones de administración de secretos o claves, como Azure Key Vault. Para estas dependencias, capture los datos de confiabilidad, como los SLA de disponibilidad y los límites de escalado. Las dependencias externas son componentes necesarios fuera del ámbito 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 y soluciones de conectividad en la nube, como Azure ExpressRoute.
Identifique y documente las dependencias de la carga de trabajo e incluyalas en los artefactos de documentación de flujo.
Evaluación de puntos de error
En los flujos críticos de la carga de trabajo, tenga en cuenta 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 que se deben tener en cuenta al planear 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 no está disponible.
Interrupción de la zona de disponibilidad. Una zona de disponibilidad de Azure no está disponible.
Interrupción del servicio. Uno o varios servicios de Azure no están disponibles.
Denegación de servicio distribuido (DDoS) u otro ataque malintencionado.
Configuración incorrecta de la aplicación o componente.
Error del operador.
Interrupción del mantenimiento planeado.
Sobrecarga de componentes.
El análisis siempre debe estar en el contexto del flujo que está intentando analizar, por lo que asegúrese de documentar el efecto en el usuario y el resultado esperado de ese flujo. Por ejemplo, si tiene una aplicación de comercio electrónico y está analizando el flujo de clientes, el efecto de un modo de error determinado en uno o varios componentes podría ser que todos los clientes no puedan completar la desprotección.
Tenga en cuenta la probabilidad de cada tipo de modo de error. Algunos son muy poco probables, como las interrupciones de varias zonas o varias regiones, y agregar un planeamiento 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 generales: crear más resistencia y diseñar para un rendimiento degradado.
La creación de más resistencia incluye agregar redundancia a los componentes, como la infraestructura, los datos y las redes, y asegurarse de que el diseño de la aplicación sigue los procedimientos recomendados para la durabilidad, por ejemplo, la separación de aplicaciones monolíticas en aplicaciones aisladas y microservicios. Para obtener más información, consulte Recomendaciones para redundancia y recomendaciones para la autoconservación.
Para diseñar un rendimiento degradado, identifique posibles puntos de error que puedan deshabilitar uno o varios componentes del flujo, pero no deshabilite completamente ese flujo. Para mantener la funcionalidad del flujo de un extremo a otro, es posible que tenga que volver a enrutar uno o varios pasos a otros componentes o aceptar que un componente con errores ejecuta una función, por lo 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 con errores como un microservicio podría hacer que el motor de recomendaciones no esté disponible, pero los clientes todavía pueden buscar productos y completar su transacción.
También debe planear la mitigación en torno a las dependencias. Las dependencias fuertes desempeñan un papel fundamental en la disponibilidad y la función de la aplicación. Si están ausentes o experimentan un mal funcionamiento, puede haber un efecto significativo. La ausencia de dependencias débiles solo puede afectar a características específicas y no afectar 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 sólidas sin las que no puede funcionar, los destinos de disponibilidad y recuperación de estas dependencias deben alinearse con los destinos de la propia aplicación. Minimice las dependencias para lograr el control sobre la confiabilidad de las aplicaciones. Para obtener más información, consulte Minimizar la coordinación entre los servicios de aplicaciones para lograr la escalabilidad.
Si el ciclo de vida de la aplicación está estrechamente unido al ciclo de vida de sus dependencias, la agilidad operativa de la aplicación podría estar limitada, especialmente para las nuevas versiones.
Detección
La detección de errores es esencial para asegurarse de que ha identificado correctamente los puntos de error en el análisis y ha planeado correctamente las estrategias de mitigación. La detección en este contexto significa la supervisión de la infraestructura, los datos y la aplicación y las alertas cuando surgen problemas. Automatice la detección tanto como sea posible y cree redundancia en los procesos de operaciones para asegurarse de que las alertas siempre se detectan y se responden a lo suficientemente rápido como para satisfacer sus requisitos empresariales. Para obtener más información, consulte Recomendaciones para la supervisión.
Resultado
Para el resultado del análisis, cree un conjunto de documentos que comuniquen eficazmente los resultados, las decisiones que ha tomado en relación con los componentes de flujo y la mitigación, y el efecto del error en la carga de trabajo.
En el análisis, priorice los modos de error y las estrategias de mitigación que ha identificado en función de la gravedad y la probabilidad. Use esta priorización para centrar su documentación en los modos de error que son lo suficientemente comunes y graves como para garantizar el gasto del tiempo, el esfuerzo y los recursos en el diseño de estrategias de mitigación. Por ejemplo, puede haber algunos modos de error que son muy raros en caso de aparición o detección. Diseñar estrategias de mitigación en torno a ellas no merece la pena el costo.
Consulte la tabla de ejemplo siguiente para obtener un punto de partida de documentación.
Durante el ejercicio de FMA inicial, los documentos que genere serán principalmente la planificación teórica. Los documentos de FMA deben revisarse y actualizarse periódicamente para asegurarse de que se mantengan actualizados con la carga de trabajo. Las pruebas de caos y las experiencias reales le ayudarán a refinar los análisis a lo largo del tiempo.
Facilitación de Azure
Use Azure Monitor y Log Analytics para detectar problemas en la carga de trabajo. Para obtener más información sobre los problemas relacionados con la infraestructura, las aplicaciones y las bases de datos, use herramientas como Application Insights, Container Insights, Network Insights, VM Insights y SQL Insights.
Azure Chaos Studio es un servicio administrado que usa ingeniería de caos para ayudarle a medir, comprender y mejorar la resistencia de las aplicaciones y servicios en la nube.
Para obtener información sobre cómo aplicar principios de FMA a servicios comunes de Azure, consulte Análisis de modo de error para aplicaciones de Azure.
Ejemplo
En la tabla siguiente se muestra un ejemplo de FMA para un sitio web de comercio electrónico hospedado en instancias de servicio de App de Azure con bases de datos de Azure SQL y que azure Front Door realiza frente a él.
Flujo de usuario: interacción de inicio de sesión de usuario, búsqueda de productos y carro de la compra
| Componente | Riesgo | Probabilidad | Efecto/Mitigación/Nota | Interrupción |
|---|---|---|---|---|
| Microsoft Entra ID | Interrupción del servicio | Bajo | Interrupción completa de la carga de trabajo. Depende de Microsoft para corregirlo. | Completo |
| Microsoft Entra ID | Error de configuración | Media | Los usuarios no pueden iniciar sesión. Sin efecto de bajada. El departamento de soporte técnico informa del problema de configuración al equipo de identidades. | None |
| Azure Front Door | Interrupción del servicio | Bajo | Interrupción completa de usuarios externos. Depende de Microsoft para corregirlo. | Solo externo |
| Azure Front Door | Interrupción regional | Muy baja | Efecto mínimo. Azure Front Door es un servicio global, por lo que el enrutamiento del tráfico global dirige el tráfico a través de regiones de Azure no efectivas. | None |
| Azure Front Door | Error de configuración | Media | Se deben detectar errores de configuración durante la implementación. Si se producen durante una actualización de configuración, los administradores deben revertir los cambios. La actualización de configuración provoca una breve interrupción externa. | Solo externo |
| Azure Front Door | Ataques de denegación de servicio distribuido | Media | Potencial de interrupción. Microsoft administra la protección contra DDoS (L3 y L4) y Azure Web Application Firewall bloquea la mayoría de las amenazas. Riesgo potencial de efecto de ataques L7. | Potencial de interrupción parcial |
| SQL de Azure | Interrupción del servicio | Bajo | Interrupción completa de la carga de trabajo. Depende de Microsoft para corregirlo. | Completo |
| SQL de Azure | Interrupción regional | Muy baja | El grupo de conmutación por error automática conmuta por error a la región secundaria. Posible interrupción durante la conmutación por error. Objetivos de tiempo de recuperación (RTO) y objetivos de punto de recuperación (RPO) que se determinarán durante las pruebas de confiabilidad. | Posible lleno |
| SQL de Azure | Interrupción de la zona de disponibilidad | Bajo | Sin efecto | None |
| SQL de Azure | Ataque malintencionado (inyección) | Media | Riesgo mínimo. Todas las instancias de Azure SQL están enlazadas a la red virtual a través de puntos de conexión privados y grupos de seguridad de red (NSG) agregan más protección dentro de la red virtual. | Riesgo bajo potencial |
| App Service | Interrupción del servicio | Bajo | Interrupción completa de la carga de trabajo. Depende de Microsoft para corregirlo. | Completo |
| App Service | Interrupción regional | Muy baja | Efecto mínimo. Latencia para los usuarios en regiones en vigor. Azure Front Door enruta automáticamente el tráfico a regiones no efectivas. | None |
| App Service | Interrupción de la zona de disponibilidad | Bajo | Ningún efecto. Los servicios de aplicaciones se han implementado como redundantes de zona. Sin redundancia de zona, hay un potencial de efecto. | None |
| App Service | Ataques de denegación de servicio distribuido | Media | Efecto mínimo. El tráfico de entrada está protegido por Azure Front Door y Azure Web Application Firewall. | None |
Vínculos relacionados
Lista de comprobación de confiabilidad
Consulte el conjunto completo de recomendaciones.