Este principio del pilar de confiabilidad del Google Cloud framework de Well-Architected proporciona recomendaciones para ayudarte a diseñar y ejecutar pruebas de recuperación en caso de fallas.
Este principio es pertinente para el área de enfoque del aprendizaje de la confiabilidad.
Descripción general del principio
Para asegurarte de que tu sistema pueda recuperarse de las fallas, debes ejecutar periódicamente pruebas que incluyan conmutaciones por error regionales, reversiones de versiones y restablecimiento de datos desde copias de seguridad.
Estas pruebas te ayudan a practicar las respuestas a eventos que representan riesgos importantes para la confiabilidad, como la interrupción de una región completa. Estas pruebas también te ayudan a verificar que tu sistema se comporte según lo previsto durante una interrupción.
En el caso improbable de que se produzca una interrupción en toda una región, debes conmutar por error todo el tráfico a otra región. Durante el funcionamiento normal de tu carga de trabajo, cuando se modifican los datos, estos deben sincronizarse desde la región principal a la región de conmutación por error. Debes verificar que los datos replicados sean siempre muy recientes para que los usuarios no experimenten pérdida de datos ni interrupciones de sesión. El sistema de balanceo de cargas también debe poder cambiar el tráfico a la región de conmutación por error en cualquier momento sin interrupciones del servicio. Para minimizar el tiempo de inactividad después de una interrupción regional, los ingenieros de operaciones también deben poder desviar el tráfico de usuarios de una región de forma manual y eficiente, en el menor tiempo posible. Esta operación a veces se denomina vaciar una región, lo que significa que detienes el tráfico entrante a la región y lo trasladas a otro lugar.
Recomendaciones
Cuando diseñes y ejecutes pruebas para la recuperación ante fallas, ten en cuenta las recomendaciones de las siguientes subsecciones.
Define los objetivos y el alcance de las pruebas
Define claramente lo que quieres lograr con las pruebas. Por ejemplo, tus objetivos pueden incluir lo siguiente:
- Valida el objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO). Para obtener más información, consulta Conceptos básicos de la planificación de DR.
- Evaluar la capacidad de recuperación y la tolerancia a errores del sistema en diversas situaciones de falla
- Probar la eficacia de los mecanismos de conmutación por error automáticos
Decide qué componentes, servicios o regiones se incluirán en el alcance de la prueba. El alcance puede incluir niveles de aplicación específicos, como el frontend, el backend y la base de datos, o puede incluir recursos Google Cloud específicos, como instancias de Cloud SQL o clústeres de GKE. El alcance también debe especificar las dependencias externas, como las API de terceros o las interconexiones en la nube.
Prepara el entorno para las pruebas
Elige un entorno adecuado, de preferencia un entorno de zona de pruebas o de etapa de pruebas que replique tu configuración de producción. Si realizas la prueba en producción, asegúrate de tener listas las medidas de seguridad, como la supervisión automatizada y los procedimientos de reversión manual.
Crea un plan de copias de seguridad. Toma instantáneas o copias de seguridad de las bases de datos y los servicios críticos para evitar la pérdida de datos durante la prueba. Asegúrate de que tu equipo esté preparado para realizar intervenciones manuales si fallan los mecanismos de conmutación por error automatizados.
Para evitar interrupciones en las pruebas, asegúrate de que tus roles y políticas de IAM, y las configuraciones de conmutación por error estén configurados correctamente. Verifica que los permisos necesarios estén establecidos para las herramientas y los secuencias de comandos de prueba.
Informa a los interesados, incluidos los propietarios de operaciones, DevOps y aplicaciones, sobre el programa, el alcance y el posible impacto de las pruebas. Proporciona a las partes interesadas un cronograma estimado y los comportamientos esperados durante la prueba.
Simula situaciones de falla
Planifica y ejecuta fallas con herramientas como Chaos Monkey. Puedes usar secuencias de comandos personalizadas para simular fallas de servicios críticos, como el apagado de un nodo principal en un clúster de GKE multizona o una instancia de Cloud SQL inhabilitada. También puedes usar secuencias de comandos para simular una interrupción de la red en toda la región con reglas de firewall o restricciones de la API según el alcance de la prueba. Aumenta gradualmente las situaciones de falla para observar el comportamiento del sistema en diversas condiciones.
Introduce pruebas de carga junto con situaciones de falla para replicar el uso en el mundo real durante las interrupciones. Prueba los impactos de las fallas en cascada, por ejemplo, cómo se comportan los sistemas de frontend cuando los servicios de backend no están disponibles.
Para validar los cambios de configuración y evaluar la resistencia del sistema ante errores humanos, prueba situaciones que involucren errores de configuración. Por ejemplo, ejecuta pruebas con una configuración incorrecta de conmutación por error del DNS o permisos de IAM incorrectos.
Supervisa el comportamiento del sistema
Supervisa cómo los balanceadores de cargas, las verificaciones de estado y otros mecanismos redireccionan el tráfico. Usa Google Cloud herramientas como Cloud Monitoring y Cloud Logging para capturar métricas y eventos durante la prueba.
Observa los cambios en la latencia, las tasas de error y el rendimiento durante y después de la simulación de fallas, y supervisa el impacto general en el rendimiento. Identificar cualquier degradación o incoherencia en la experiencia del usuario
Asegúrate de que se generen registros y se activen alertas para eventos clave, como interrupciones del servicio o conmutaciones por error. Utiliza estos datos para verificar la eficacia de tus sistemas de alertas y respuesta ante incidentes.
Verifica la recuperación en función de tus objetivos de RTO y RPO
Mide cuánto tiempo tarda el sistema en reanudar las operaciones normales después de una falla y, luego, compara estos datos con el RTO definido y documenta cualquier brecha.
Asegúrate de que la integridad y la disponibilidad de los datos se alineen con el RPO. Para probar la coherencia de la base de datos, compara las instantáneas o las copias de seguridad de la base de datos antes y después de una falla.
Evalúa el restablecimiento del servicio y confirma que todos los servicios se restablecieron a un estado funcional con una interrupción mínima para el usuario.
Documenta y analiza los resultados
Documenta cada paso de la prueba, situación de falla y comportamiento del sistema correspondiente. Incluye marcas de tiempo, registros y métricas para realizar análisis detallados.
Destaca los cuellos de botella, los puntos únicos de fallo o los comportamientos inesperados que se observaron durante la prueba. Para ayudar a priorizar las correcciones, clasifica los problemas según su gravedad y su impacto.
Sugerir mejoras en la arquitectura del sistema, los mecanismos de conmutación por error o la configuración de supervisión Según los resultados de las pruebas, actualiza las políticas de conmutación por error y las guías pertinentes. Presentar un informe post mortem a las partes interesadas El informe debe resumir los resultados, las lecciones aprendidas y los próximos pasos. Para obtener más información, consulta Cómo realizar análisis post mortem exhaustivos.
Itera y mejora
Para validar la confiabilidad y la resistencia continuas, planifica pruebas periódicas (por ejemplo, trimestrales).
Ejecuta pruebas en diferentes situaciones, incluidos los cambios en la infraestructura, las actualizaciones de software y el aumento de las cargas de tráfico.
Automatiza las pruebas de conmutación por error con canalizaciones de CI/CD para integrar las pruebas de confiabilidad en tu ciclo de vida de desarrollo.
Durante la revisión posterior, usa los comentarios de las partes interesadas y los usuarios finales para mejorar el proceso de prueba y la capacidad de recuperación del sistema.