Estrategias de arquitectura para realizar el análisis del modo de error

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

El análisis del modo de error (FMA) le ayuda a identificar posibles puntos de error dentro de la carga de trabajo y los flujos asociados. En esta guía se describen los procedimientos recomendados para realizar FMA para que pueda planear acciones de mitigación, diseñar nuevas cargas de trabajo o refactorizar cargas de trabajo existentes para minimizar el efecto generalizado de los errores. Al analizar cada paso del flujo e identificar el radio de explosión de varios tipos de error, puede mejorar la resistencia de la arquitectura.

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 dentro de los objetivos de recuperación definidos.

Si omite FMA por completo o realiza un análisis incompleto, la carga de trabajo corre el riesgo de un comportamiento impredecible y apagones potenciales causados por un diseño subóptimo.

Definiciones

Revise e implemente las recomendaciones para identificar flujos. Se supone que identificó y priorizó los flujos de usuario y sistema en función de la importancia crítica.

Los datos que recopila y los artefactos que crea en el trabajo proporcionan una descripción concreta de las rutas de acceso de datos implicadas en los flujos. Para tener éxito en tu trabajo de FMA, es fundamental que tus documentos sean precisos y exhaustivos.

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 avanza de la ideación al diseño, identifique los tipos de componentes que dan soporte a su 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, 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, superponga los flujos para identificar los componentes discretos que se usan en esos flujos. Cree 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 crítica que asignó a los flujos. Considere el efecto de un mal funcionamiento de un componente en los flujos.

Identificación de las dependencias de carga de trabajo

Identifique las dependencias de su carga de trabajo para realizar su análisis de punto único de fallo. 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 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.

Identifica y documenta las dependencias de tu carga de trabajo, e inclúyelas en los documentos de tu flujo de trabajo.

Evaluación de puntos de error en los flujos

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. Considere errores de lectura y de escritura por separado ya que el impacto y los posibles pasos de mitigación varían. Entre los modos de error se 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.

Analice siempre el efecto 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 ningún cliente pueda completar el proceso de pago.

Tenga en cuenta la probabilidad de cada tipo de modo de error. Algunos modos de error son muy poco probables, como interrupciones de varias zonas o de varias regiones. Agregar planeamiento de mitigación más allá de la redundancia no es un buen uso de recursos y tiempo.

Planear estrategias de 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 garantizar que el diseño de la aplicación siga los procedimientos recomendados para la durabilidad, como dividir 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.

Debe también planificar la mitigación en relación con las dependencias. Las dependencias fuertes desempeñan un papel fundamental en la función y la disponibilidad de la aplicación. Si están ausentes o no funcionan correctamente, podrían causar 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.

Implementación de la detección de errores

La detección de errores es esencial para asegurarse de identificar correctamente los puntos de error en el análisis y planear correctamente las estrategias de mitigación. En este contexto, la detección significa supervisar la infraestructura, los datos y la aplicación, y alertar cuando surjan 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.

Documente los hallazgos del FMA

Para el resultado del análisis, cree un conjunto de documentos que comuniquen eficazmente los resultados, las decisiones que tomó 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 identificó 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 su ejercicio inicial de FMA, los documentos que produzca son en su mayoría documentos de planificación teórica. Revise y actualice periódicamente los documentos de FMA para garantizar que se mantengan actualizados con su carga de trabajo. Las pruebas de caos y las experiencias reales le ayudan a refinar los análisis a lo largo del tiempo.

Supervisión de Azure

Use Azure Monitor y Log Analytics para detectar problemas en la carga de trabajo. Para obtener información más detallada 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 la aplicación y el servicio en la nube.

Utilice Monitor de conexiones y Solución de problemas de conexión en Azure Network Watcher para modelar y validar escenarios de conectividad de red antes de la implementación. Al simular pruebas sintéticas y solucionar posibles rutas de enrutamiento, estas herramientas le ayudan a anticipar y documentar posibles modos de error en la arquitectura de red. Además, mediante el análisis de registros históricos de flujo de red virtual con análisis de tráfico, puede identificar patrones de tráfico bloqueados o anómalos que podrían informar a la documentación de FMA en toda la infraestructura de Azure.

Example

En la tabla siguiente se muestra un ejemplo de FMA para un sitio web de comercio electrónico alojado en instancias de Azure App Service con bases de datos de Azure SQL, y que tiene como frente a Azure Front Door.

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

Vínculo relacionado

• Resistencia y dependencias

Lista de comprobación de confiabilidad

Consulte el conjunto completo de recomendaciones.