Este principio del pilar de confiabilidad del Google Cloud Well-Architected Framework proporciona recomendaciones para ayudarte a diseñar y ejecutar pruebas de recuperación en caso de fallas.
Este principio es relevante para el área de enfoque de aprendizaje de la confiabilidad.
Descripción general del principio
Para asegurarte de que tu sistema pueda recuperarse de fallas, debes ejecutar pruebas de forma periódica 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 como se espera durante una interrupción.
En el caso improbable de que una región completa deje de funcionar, 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 hasta la región de conmutación por error. Debes verificar que los datos replicados siempre sean muy recientes para que los usuarios no experimenten pérdida de datos ni interrupción de la 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 de forma manual y eficiente el tráfico de los usuarios fuera de una región, en el menor tiempo posible. A veces, esta operación se denomina vaciado de una región, lo que significa que detienes el tráfico entrante a la región y mueves todo el tráfico 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 con claridad 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 resiliencia y la tolerancia a errores del sistema en varias situaciones de falla
- Prueba la eficacia de los mecanismos de conmutación por error automatizados.
Decide qué componentes, servicios o regiones están dentro del alcance de las pruebas. El alcance puede incluir niveles de aplicación específicos, como el frontend, el backend y la base de datos, o puede incluir recursos de Google Cloud específicos, como instancias de Cloud SQL o clústeres de GKE. El alcance también debe especificar cualquier dependencia externa, como las APIs de terceros o las interconexiones de nube.
Prepara el entorno para las pruebas
Elige un entorno adecuado, preferiblemente uno de etapa de pruebas o de zona 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 manuales.
Crear un plan de creación de copias de seguridad Toma instantáneas o copias de seguridad de las bases de datos y los servicios esenciales 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, políticas y configuraciones de conmutación por error de Identity and Access Management (IAM) estén configurados correctamente. Verifica que se hayan otorgado los permisos necesarios para las herramientas y las secuencias de comandos de prueba.
Informa a las partes interesadas, incluidos los propietarios de operaciones, DevOps y aplicaciones, sobre el programa, el alcance y el impacto potencial de la prueba. Proporciona a los interesados 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 cierre 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 de forma gradual 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, como el comportamiento de los sistemas de frontend cuando los servicios de backend no están disponibles.
Para validar los cambios de configuración y evaluar la resiliencia del sistema ante errores humanos, prueba situaciones que involucren parámetros de configuración incorrectos. Por ejemplo, ejecuta pruebas con una configuración de conmutación por error de DNS incorrecta 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 herramientas de Google Cloud 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 la capacidad de procesamiento durante y después de la simulación de fallas, y supervisa el impacto general en el rendimiento. Identifica 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. Usa estos datos para verificar la eficacia de tus sistemas de alertas y respuesta ante incidentes.
Verifica la recuperación en función de tus 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 restablezcan a un estado funcional con una interrupción mínima para los usuarios.
Documenta y analiza los resultados
Documenta cada paso de la prueba, la situación de falla y el comportamiento correspondiente del sistema. 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 priorizar las correcciones, categoriza los problemas por gravedad e impacto.
Sugerir mejoras en la arquitectura del sistema, los mecanismos de conmutación por error o las configuraciones 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 Realiza análisis post mortem exhaustivos.
Itera y mejora
Para validar la confiabilidad y la resiliencia 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 autopsia, usa los comentarios de las partes interesadas y los usuarios finales para mejorar el proceso de prueba y la resiliencia del sistema.