Recomendaciones para realizar el análisis del modo de error

  • Artículo

Se aplica a esta recomendación de lista de comprobación de confiabilidad de Azure Well-Architected Framework:

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 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 del número de capas de resistencia que 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 degraden o se vean afectados gravemente hasta el punto de no estar disponibles.
Solució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 procedimientos y los procesos de alerta.

Estrategias de diseño principales

Requisitos previos

Revise e implemente las recomendaciones para identificar flujos. Se supone que ha identificado y priorizado los 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.

Enfoque de FMA

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 se mueve de la ideación al diseño, debe identificar los tipos de componentes necesarios para admitir la carga de trabajo. La carga de trabajo determina los componentes necesarios para los que debe planear. Normalmente, debe planear el control de entrada, las redes, el proceso, los datos, el almacenamiento, los servicios auxiliares (como la autenticación, la mensajería y la administración de secretos o 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 va a implementar, por lo que el diseño podría tener un aspecto similar al del ejemplo siguiente.

Diagrama que muestra el ejemplo de diseño.

Después de crear el diseño de arquitectura inicial, 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. Tenga en cuenta el efecto de un componente que no funciona correctamente en los flujos.

Identificación de las dependencias

Identifique las dependencias de carga de trabajo para realizar el análisis de un único punto de error. 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 y claves, como Azure Key Vault. Para estas dependencias, capture los datos de confiabilidad, como los acuerdos de nivel de servicio 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 inclúyelas en los artefactos de documentación de flujo.

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 distribuida (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 intenta analizar, por lo que debe asegurarse 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 finalización de la compra.

Tenga en cuenta la probabilidad de cada tipo de modo de error. Algunos son muy improbables, como 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.

Solució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 garantizar que el diseño de la aplicación siga 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 los posibles puntos de error que podrían 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 no están presentes 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 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 lo suficientemente rápido como para satisfacer los 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 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 en la aparición o detección. El diseño de estrategias de mitigación en torno a ellos no vale 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 más información sobre cómo aplicar los principios de FMA a los servicios comunes de Azure, consulte Análisis del 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 Azure App Service con bases de datos de Azure SQL y está delante de Azure Front Door.

Flujo de usuario: interacción de inicio de sesión del usuario, búsqueda de productos y carro de la compra

Componente Riesgo Probabilidad Efecto/Mitigación/Nota Interrupción
Id. de Microsoft Entra Interrupción del servicio Bajo Interrupción completa de la carga de trabajo. Depende de Microsoft para corregirlo. Completo
Id. de Microsoft Entra Error de configuración Media Los usuarios no pueden iniciar sesión. Sin efecto de bajada. El departamento de soporte técnico notifica el problema de configuración al equipo de identidad. None
Azure Front Door Interrupción del servicio Bajo Interrupción completa de los 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 afectadas. None
Azure Front Door Error de configuración Media Las configuraciones incorrectas se deben detectar 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. Posible interrupción parcial
Azure SQL Interrupción del servicio Bajo Interrupción completa de la carga de trabajo. Depende de Microsoft para corregirlo. Completo
Azure SQL 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
Azure SQL Interrupción de la zona de disponibilidad Bajo Sin efecto None
Azure SQL 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 de efecto. Azure Front Door enruta automáticamente el tráfico a regiones no afectadas. None
App Service Interrupción de la zona de disponibilidad Bajo Ningún efecto. Los servicios de aplicaciones se han implementado como redundancia de zona. Sin redundancia de zona, existe una posibilidad 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

Lista de comprobación de confiabilidad

Consulte el conjunto completo de recomendaciones.

Lista de comprobación de confiabilidad