Estrategias de arquitectura para diseñar una estrategia de pruebas de confiabilidad

Se aplica a la siguiente recomendación de la lista de comprobación de fiabilidad del marco de trabajo Azure Well-Architected:

RE:08 Pruebe los escenarios de resistencia y disponibilidad aplicando los principios de ingeniería de caos. Use pruebas de confiabilidad para comprobar que la carga de trabajo puede soportar errores, escalar bajo demanda y recuperarse dentro de los destinos definidos.

Las pruebas de confiabilidad detectan debilidades arquitectónicas antes de provocar interrupciones. Sin realizar pruebas deliberadas mediante escenarios de fallo, no se puede saber si los patrones de resiliencia realmente funcionan o si la carga de trabajo se recupera dentro de los objetivos definidos.

Puede reforzar la confiabilidad de la carga de trabajo al probar los riesgos de seguridad que afectan a la disponibilidad, los problemas de rendimiento que hacen que el sistema no se pueda usar y las brechas operativas que limiten la respuesta a los incidentes. Use las estrategias de este artículo para establecer una cadencia de pruebas que valide regularmente la carga de trabajo en función de sus modos de error. Evoluciona las pruebas a medida que la arquitectura cambia y los incidentes revelan nuevas debilidades. Genere confianza en que su carga de trabajo puede resistir fallos, escalar para satisfacer la demanda y recuperarse dentro de sus objetivos de RTO y RPO, mediante la creación de un bucle de retroalimentación que refuerce su postura de fiabilidad con el tiempo.

Las estrategias clave de este artículo se basan en las prácticas de prueba fundamentales descritas en Estrategias de arquitectura de OE:09 para pruebas. Revise primero ese artículo. Las recomendaciones de esta guía se limitan a la confiabilidad y se centran en lograr la confianza en la capacidad de la carga de trabajo para resistir errores y recuperarse dentro de los objetivos.

En la tabla siguiente se definen los términos de confiabilidad clave que se usan en este artículo.

Definiciones

Término Definición
Availability Cantidad de tiempo que se ejecuta una carga de trabajo de aplicación en un estado correcto sin tiempo de inactividad significativo.
Ingeniería de caos La práctica que incorpora de forma segura las pruebas de caos en la cultura del equipo, las prácticas de ingeniería y el ciclo de vida de desarrollo para impulsar la mejora continua a la resistencia del sistema.
Pruebas de caos Experimento controlado que valida una hipótesis de resistencia específica sobre cómo debe comportarse una carga de trabajo en condiciones perjudiciales.
Inyección de errores Técnica para introducir deliberadamente errores en un componente, dependencia o ruta de acceso del sistema.
Capacidad de recuperación La capacidad de restaurar las operaciones normales después de una interrupción dentro del tiempo de recuperación acordado (RTO) y los objetivos de punto de recuperación (RPO).
Resiliency La capacidad de una carga de trabajo para soportar errores (como errores transitorios, interrupciones de infraestructura, picos de demanda) y seguir funcionando dentro de una experiencia de usuario aceptable.
Failover Proceso de cambio a un componente secundario tras el error del componente principal.
Failback Proceso mediante el cual se restauran las operaciones en la región primaria después de que esta se haya recuperado.
Presupuesto de errores Nivel máximo aceptable de error para un sistema durante un período definido, derivado de objetivos de nivel de servicio (SLO).

Definición del ámbito de pruebas de confiabilidad en función de los tipos de servicio

Al definir el ámbito de las pruebas de confiabilidad, considere el modelo de responsabilidad compartida de los servicios que usa. Cada tipo de servicio (IaaS, PaaS, SaaS) incluye diferentes garantías de confiabilidad y diferentes niveles de control sobre el control de errores. Centre sus pruebas en los aspectos de confiabilidad que posee.

  • Adapte la profundidad de las pruebas a su nivel de responsabilidad. En el caso de los servicios de infraestructura (IaaS), su equipo posee la mayoría de las decisiones de confiabilidad, por lo que invierte en una validación exhaustiva a través de la ingeniería de caos y la inyección de errores. Para los servicios de plataforma (PaaS) y software (SaaS), el proveedor administra gran parte de la confiabilidad subyacente. Céntrese en cómo interactúa la carga de trabajo con esos servicios, como cómo controla las conmutaciones por error de infraestructura en PaaS, la limitación, la degradación del servicio o los cambios en los patrones de carga.

  • Tenga en cuenta las cargas de trabajo de servicio mixto. Cuando la carga de trabajo abarca varios tipos de servicio, las responsabilidades de prueba varían entre los componentes. Es posible que pruebe la conmutación por error de los componentes de la infraestructura basada en máquinas virtuales durante una interrupción de la zona de disponibilidad, pero confíe en garantías de proveedor para una base de datos PaaS diseñada para alta disponibilidad. Identifique dónde están esos límites y asegúrese de que las pruebas cubren las brechas entre ellos.

Prueba con los objetivos de confiabilidad de un extremo a otro

Los objetivos de confiabilidad, como los SLO, los RTO y los RPO, definen cómo debe comportarse la carga de trabajo en condiciones de error. Úselos como criterios de paso y error en flujos críticos completos, no solo componentes individuales.

  • Valide la recuperación a lo largo de todo el flujo. Un solo componente puede restaurarse dentro de su RTO, pero el tiempo total de recuperación puede superar su objetivo cuando las dependencias posteriores también deben restaurarse. Tenga en cuenta el tiempo total de recuperación en todo el flujo, incluido el tiempo para detectar el problema y responder.

  • Defina el ámbito de prueba con SLO y presupuestos de errores. El presupuesto de errores representa la inversión que puede realizar en la inyección de errores. Limite las pruebas de caos para mantenerse dentro de sus SLO y use sus objetivos de recuperación del flujo para definir los límites de cada prueba.

Crear escenarios de confiabilidad a partir de flujos críticos y modos de error

Comience con los flujos críticos de la carga de trabajo y los modos de error que pueden afectarlos. Use el análisis del modo de error para identificar los escenarios de error más impactantes y crear pruebas que validen la resistencia y las estrategias de recuperación.

Priorice por impacto y probabilidad. No todos los modos de error garantizan la misma inversión de prueba. Céntrese primero en escenarios con el mayor impacto potencial del usuario y la mayor probabilidad de producirse. Deje que el análisis del modo de error impulse esta priorización.

Validación de los mecanismos de tolerancia a errores y recuperación

Céntrese en escenarios que probablemente causen tiempo de inactividad o degradan la experiencia del usuario. Use las estrategias de esta sección para crear pruebas que validen la capacidad de la carga de trabajo para controlar errores y recuperarse de forma eficaz.

Copias de seguridad y restauración

Las pruebas de copia de seguridad y restauración deben validar que el enfoque de protección de datos cumple los objetivos de recuperación.

  • Establecer una cadencia de pruebas. Determine con qué frecuencia necesita probar las restauraciones en función de la frecuencia con la que cambia la configuración de copia de seguridad, el esquema de datos o la infraestructura. Los cambios más frecuentes requieren pruebas de restauración más frecuentes.

  • Establecer objetivos de recuperación. Mida los tiempos reales de restauración en comparación con sus objetivos de RPO y RTO para confirmar que su estrategia de copia de seguridad cumple sus objetivos de recuperación.

  • No dé por sentado que la copia de seguridad esté completa. Las copias de seguridad se pueden configurar de forma incorrecta para capturar solo un subconjunto de los datos. Valide la integridad y la exhaustividad de los datos, no solo si una operación de restauración se completa con éxito.

  • Prueba de forma aislada. Valide las restauraciones en un entorno independiente de producción para poder ejecutar comprobaciones exhaustivas sin interrumpir las cargas de trabajo activas.

Errores transitorios

Los errores transitorios, como las interrupciones de red momentáneas, la falta de disponibilidad del servicio breve y los tiempos de espera de conexión, son riesgos comunes de confiabilidad. Compruebe que la carga de trabajo controla estos errores sin afectar a los usuarios. Para obtener más información, consulte Recomendaciones para controlar errores transitorios.

  • Céntrese en lo que posee. Si los SDK o los servicios de plataforma controlan los reintentos y la interrupción del circuito automáticamente, pruebe lo que sucede cuando se agoten esos mecanismos integrados, como cuando se produzcan errores en todos los reintentos o se abra un disyuntor.

  • Valide las configuraciones de control de errores. Evalúe las configuraciones de control de errores de la carga de trabajo. Compruebe que las directivas de reintento, los umbrales del disyuntor y los valores de tiempo de espera se comportan según lo previsto en condiciones de error realistas.

  • Pruebe el límite entre errores transitorios y persistentes. Compruebe que la carga de trabajo pasa correctamente del comportamiento de reintento a la reserva o degradación cuando un error persiste más allá de los umbrales esperados.

  • Tenga en cuenta los errores transitorios de las características de resistencia. La redundancia de zona y diseños similares suelen producir errores transitorios durante las operaciones de conmutación por error normales. Por ejemplo, una base de datos con redundancia entre zonas podría provocar fallos transitorios de conexión mientras el tráfico se redirige a una zona en buen estado durante una interrupción. Pruebe si la carga de trabajo puede controlar estos errores transitorios esperados sin un impacto significativo en el usuario.

Respuesta ante la carga y la escalabilidad

Compruebe que la carga de trabajo mantiene la confiabilidad durante los cambios de demanda, tanto los picos repentinos como los aumentos graduales. Para obtener más información, consulte Estrategia de escalado. Para obtener instrucciones sobre pruebas de carga y esfuerzo, consulte Recomendaciones para pruebas.

  • Pruebe tanto el escalado horizontal como el escalado vertical. Compruebe que la nueva capacidad entra en línea con la suficiente rapidez y que el escalado de reducción no pierda solicitudes ni deje recursos huérfanos.

  • Tenga en cuenta el retraso de escalado. Siempre hay un retraso entre cumplir las condiciones para desencadenar el escalado y tener lista la nueva capacidad. Determine si la carga de trabajo puede controlar la demanda durante esa brecha o si necesita aprovisionar previamente capacidad adicional.

Fallos de dependencia

Es probable que la carga de trabajo dependa de los servicios fuera del control directo, como api de terceros, servicios de plataforma administrada o servicios internos compartidos. Compruebe que la carga de trabajo controla los errores en esas dependencias sin interrupciones significativas para los usuarios.

  • Clasificar las dependencias por importancia. No todas las dependencias garantizan la misma inversión de prueba. Priorice las pruebas de las dependencias que están en sus flujos críticos y que carecen de redundancia integrada o vías alternativas.

  • Pruebe el comportamiento de recuperación para cada dependencia. Cuando una dependencia deja de estar disponible, la carga de trabajo debe revertir a una ruta de acceso o comportamiento alternativo en lugar de generar errores por completo. Compruebe que cada mecanismo de respaldo se activa correctamente y que la funcionalidad no relacionada sigue funcionando.

  • Tenga en cuenta los errores parciales y en cascada. Las dependencias rara vez fallan de forma binaria. No solo pruebe las interrupciones completas. Cubra los aumentos de latencia, los errores intermitentes y la disponibilidad parcial de los datos.

  • Valide el aislamiento y la contención del radio de impacto. Compruebe que un fallo de una única dependencia no se propague en cascada a funcionalidades no relacionadas.

Autoconservación y recuperación

Valide cómo responde su diseño de recuperación automática y autoconservación a errores de funcionamiento, incluido si la carga de trabajo puede seguir funcionando en una capacidad reducida cuando la recuperación completa no es inmediata.

  • Pruebe la recuperación automatizada de un extremo a otro. Evalúe sus modelos de estado para asegurarse de que incluyen las comprobaciones adecuadas. Compruebe que esas comprobaciones detecten errores con precisión, desencadenen la corrección automatizada según lo previsto y devuelvan el sistema a un estado correcto en períodos de tiempo aceptables.

  • Validar procedimientos manuales de recuperación. La recuperación automatizada no abarca todos los escenarios. Pruebe los procedimientos operativos manuales en condiciones realistas para asegurarse de que los operadores pueden ejecutarlos bajo presión y dentro de sus objetivos de tiempo de recuperación.

  • Valide el comportamiento de la degradación controlada. Cuando un componente falla, la carga de trabajo debería degradarse de forma gradual en lugar de fallar por completo. Compruebe que puede funcionar en un modo reducido, como poner en cola las solicitudes para su revisión manual, y que la experiencia degradada es aceptable para los usuarios. Confirme que el equipo sabe cómo operar la carga de trabajo en este estado y cómo restaurar la funcionalidad completa.

Incidentes y recuperación ante desastres (DR)

Cuando se produce un incidente o desastre, la capacidad de detectarlo rápidamente y responder de forma eficaz es crítico. Pruebe los planes y los procesos para asegurarse de que abordan errores catastróficos y incidentes importantes. Use un entorno dedicado para las pruebas de recuperación ante desastres para evitar afectar a las cargas de trabajo de producción. Para más información, consulte plan de recuperación ante desastres.

  • Valide los mecanismos de detección de incidentes. Simulación de incidentes para comprobar que los registros de supervisión capturan la información necesaria y que las alertas se desencadenan correctamente. Por ejemplo, compruebe con qué rapidez se detectan los aumentos en las tasas de error de las solicitudes y con qué frecuencia se muestrean los datos de supervisión.

  • Pruebe los procesos de administración de incidentes. Confirme que el equipo puede seguir los procedimientos de respuesta a incidentes de forma eficaz. Para obtener más información, consulte respuesta a incidentes.

  • Pruebe la conmutación por error completa y la restauración tras la conmutación por error. Probar componentes individuales por separado puede pasar por alto fallos de coordinación que solo aparecen durante una conmutación real. Valide la secuencia de conmutación por error completa, incluida la conmutación de DNS, la restauración de copias de seguridad y la coherencia de la replicación de datos y la reconexión del cliente. Pruebe también la reversión por error al despliegue principal, que a menudo es más compleja que la conmutación inicial.

  • Valide la capacidad en el entorno de conmutación por error. Asegúrese de que su entorno de conmutación por error tenga suficiente capacidad preaprovisionada para absorber el tráfico inmediatamente después de la conmutación por error sin colapsarse por la carga. Compruebe que el entorno puede sostener las operaciones mientras se activan los mecanismos de escalado y valide su estrategia de escalado. Para obtener más información, consulte Respuesta de carga y escalado.

  • Mida sus resultados con respecto a sus objetivos. Si una prueba de recuperación ante desastres no cumple con el RTO o el RPO, analice las brechas y actualice el plan de recuperación ante desastres en consecuencia.

  • Validar personas y procesos. Las pruebas de recuperación ante desastres deben verificar los canales de comunicación, confirmar que los operadores disponen del acceso y de los permisos necesarios para ejecutar los procedimientos de recuperación y garantizar que pueden encontrar rápidamente los procedimientos específicos de recuperación ante desastres en situaciones de presión.

Pon a prueba y evalúa tu plan con ejercicios de simulación

Los ejercicios de tableta le ayudan a encontrar brechas en las pruebas de confiabilidad antes de que un incidente real los exponga. Al simular escenarios de error con el equipo, puede identificar condiciones no probadas y validar que los procedimientos de respuesta funcionan según lo previsto.

  • Simular incidentes realistas. Recorra un escenario de error, como una interrupción regional o una implementación dañada, y haga que el equipo describa los pasos que se deben seguir para detectar, responder y recuperarse de ella. Estas discusiones suelen revelar suposiciones sobre el comportamiento del sistema que no se han validado a través de las pruebas.

  • Convierta los resultados en casos de prueba. Use los huecos y desconocidos que aparecen durante el ejercicio para crear nuevas pruebas de confiabilidad. Si el equipo detecta que nadie sabe cómo se comporta la carga de trabajo cuando se produce un error en una dependencia específica, es un escenario para agregar a la estrategia de pruebas.

Aprovechar las interrupciones planeadas y no planeadas

Cuando la carga de trabajo no está disponible debido a un mantenimiento planificado o a una interrupción imprevista, tiene una oportunidad única para realizar pruebas y entender mejor su carga de trabajo.

Mantenimiento planeado

Durante las ventanas de mantenimiento para actualizaciones o revisiones, pruebe componentes y flujos que no intervienen en el trabajo de mantenimiento. Puede ejecutar pruebas sin riesgo de degradar inesperadamente la carga de trabajo o desconectarla. Si tiene suficiente tiempo, pruebe también los componentes implicados en el mantenimiento una vez completado el trabajo.

Interrupción no planeada

Cada interrupción no planeada es una oportunidad para reforzar la estrategia de pruebas de confiabilidad. Después de restaurar el servicio y completar la revisión posterior al incidente, use los resultados para mejorar las pruebas.

  • Pruebe las medidas de mitigación. Si ha aplicado una solución alternativa o una corrección temporal, valide que puede controlar la carga esperada antes de que se aplique la corrección permanente.

  • Busque puntos débiles similares. Revise otros componentes para conocer los mismos patrones de configuración o diseño que han contribuido a la interrupción. Agregue pruebas para esos componentes antes de que produzcan un error de la misma manera.

Combinar diferentes tipos de pruebas

Al ejecutar diferentes tipos de pruebas juntas, puede revelar problemas de confiabilidad que no son visibles cuando cada prueba se ejecuta de forma aislada. Una carga de trabajo puede soportar una carga específica en condiciones normales, pero esa misma carga provoca fallos cuando se introduce un fallo.

  • Reutilizar la infraestructura de prueba existente. Si ya tiene infraestructura y un arnés de pruebas para pruebas de carga, úselo para ejecutar pruebas de caos simultáneamente. Combinar pruebas de carga e inyección de fallos en una misma ejecución de prueba muestra cómo se comporta su carga de trabajo en condiciones realistas, donde la demanda y los fallos se producen al mismo tiempo.

  • Comience en entornos que no son de producción. Comience las pruebas de confiabilidad en entornos de menor riesgo, donde puede explorar de forma segura los modos de error. Pase a realizar pruebas en producción solo después de haber aprovechado al máximo la información obtenida en entornos no productivos y de contar con mecanismos de protección para limitar el alcance del impacto y revertir los cambios rápidamente.

Use la inyección de fallos y la ingeniería del caos

La inserción de errores y la ingeniería de caos le ayudan a crear confianza en la resistencia de la carga de trabajo mediante la introducción deliberada de errores y la observación de la respuesta. Asegúrese de que tiene estrategias de mitigación en vigor antes de ejecutar experimentos.

  • Ejecute experimentos de caos con regularidad. Evalúe el ámbito de prueba. Inserte errores en componentes y flujos que se supone que son confiables. A medida que cambia la arquitectura, los nuevos modos de error emergen y es posible que las suposiciones anteriores ya no se mantengan. Ejecute experimentos con una cadencia regular para detectar regresiones, validar nuevas dependencias y confirmar que los cambios recientes no han introducido puntos débiles.

  • Utilice su análisis de modos de fallo para enfocar los experimentos. Cada experimento debe tener como destino un error específico o un conjunto de errores y tener una hipótesis clara, como probar la capacidad de un flujo determinado para resistir la pérdida de un componente determinado. A medida que los experimentos revelan nuevos modos de error o dependencias no detectadas, actualice el análisis del modo de error para mantenerlo actualizado.

  • Limita el impacto durante los experimentos. Identifique los componentes objetivo que pueda recuperar rápidamente y establezca expectativas fundamentadas sobre el efecto de cada inyección de fallos. Si un experimento va más allá del ámbito o genera resultados inesperados, deténgalo. Equilibre la recopilación de datos significativos con la minimización del efecto en los usuarios.

  • Medición respecto a líneas de base. Establezca métricas de confiabilidad y rendimiento coherentes para los flujos y componentes de cada experimento. Compare las métricas de estado degradadas con estas líneas base para comprender el efecto completo del error y determinar si el diseño de resistencia cumple sus objetivos.

  • Vuelva a incorporar los resultados a la estrategia de pruebas. Use los resultados del experimento para impulsar nuevas pruebas, actualizar planes de recuperación e informar a los elementos de trabajo pendiente de corrección. A medida que surgen comportamientos inesperados, cree pruebas dirigidas para esos comportamientos y estrategias de corrección de diseño.

Compensación: las pruebas de inyección de errores en producción pueden ser perjudiciales y pueden provocar tiempo de inactividad. Ser transparente con las partes interesadas sobre esta posibilidad. Coloque las medidas de seguridad en su lugar para que pueda detener los experimentos y revertirlos rápidamente y mantenerse flexible sobre cuándo ejecutar pruebas o evitarlos durante períodos confidenciales. Para protegerse frente a interrupciones no deseadas, planee una redundancia suficiente y asegúrese de que las partes interesadas comprendan el equilibrio de costos.

Riesgo: Las pruebas de confiabilidad pueden expandir la cobertura en muchos modos de error, pero debe detenerse una vez que ya no proporciona un valor significativo. Si ya tiene un trabajo pendiente de problemas de confiabilidad conocidos, priorice la corrección de esos problemas en lugar de agregar más pruebas.

Facilitación con Azure

Azure Test Plans es una solución de administración de pruebas basada en explorador que proporciona todas las funcionalidades necesarias para las pruebas manuales planeadas, las pruebas de aceptación de usuarios, las pruebas exploratorias y la recopilación de comentarios de las partes interesadas.

Azure Chaos Studio es un servicio administrado que usa pruebas de caos para ayudarle a medir, comprender y mejorar la resistencia de la aplicación y el servicio en la nube.

Pruebas de aplicaciones de Azure es un servicio que permite ejecutar pruebas funcionales con Espacios de trabajo de dramaturgo y pruebas de rendimiento mediante Azure Load Testing para identificar problemas en sus aplicaciones.

Azure Service Health tiene un panel de mantenimiento planeado que es una sección dedicada del portal de Azure que le mantiene informado sobre las próximas actividades de mantenimiento. Resalta los eventos que pueden afectar a los recursos de Azure, lo que le ayuda a prepararse de antemano.

El monitor de conexión es una característica de Azure Network Watcher que puede usar para la supervisión sintética y las pruebas en tiempo real de la conectividad de red en entornos híbridos y de Azure. En escenarios de ingeniería de caos, el monitor de conexión se puede usar para insertar errores en componentes de red de destino y medir continuamente métricas clave, como la latencia y la pérdida de paquetes. Esta funcionalidad permite a los equipos observar cómo afectan las interrupciones a la confiabilidad de la red, tanto para los componentes de flujo individuales como para las rutas de acceso de red de un extremo a otro. Para evaluar el impacto de los errores e identificar las áreas de mejora, compare la telemetría del monitor de conexión con las métricas de línea de base.

Lista de comprobación de confiabilidad

Consulte el conjunto completo de recomendaciones.

Lista de comprobación de confiabilidad

  • Last updated on