Este principio del pilar de confiabilidad del Google Cloud Framework de arquitectura proporciona recomendaciones para ayudarte a diseñar y ejecutar pruebas de recuperación en caso de fallas.
Este principio es relevante para el aprendizaje área de enfoque de confiabilidad.
Descripción general de los principios
Para asegurarte de que tu sistema pueda recuperarse de las fallas, debes ejecutar pruebas de forma periódica que incluyan conmutaciones por error regionales, reversiones de lanzamientos 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 el sistema se comporte según lo previsto durante una interrupción.
En el caso improbable de que una región entera deje de funcionar, debes transferir todo el tráfico a otra región. Durante el funcionamiento normal de tu carga de trabajo, cuando se modifican los datos, se deben sincronizar de la región principal a 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 interrupciones de la sesión. El sistema de balanceo de cargas también debe poder transferir 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. A veces, esta operación se denomina descarga 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 sub secciones.
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.
- Evalúa la resiliencia del sistema y la tolerancia a errores en varias situaciones de fallas.
- 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 específicos de Google Cloud , como instancias de Cloud SQL o clústeres de GKE. El alcance también debe especificar cualquier dependencia externa, como APIs de terceros o interconexiones de nube.
Prepara el entorno para las pruebas
Elige un entorno adecuado, preferiblemente un entorno 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 preparadas las medidas de seguridad, como la supervisión automatizada y los procedimientos de reversión manuales.
Crea un plan de copia de seguridad. Crea 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, políticas y configuraciones de conmutación por error de IAM estén configurados correctamente. Verifica que los permisos necesarios estén configurados para las herramientas y secuencias de comandos de prueba.
Informa a las partes interesadas, incluidos los propietarios de operaciones, DevOps y aplicaciones, sobre el programa de pruebas, el alcance y el posible impacto. 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 cierre de un nodo principal en un clúster de GKE de varias zonas o una instancia de Cloud SQL inhabilitada. También puedes usar secuencias de comandos para simular una interrupción de red en toda la región con reglas de firewall o restricciones de API según el alcance de la prueba. Deriva gradualmente las situaciones de falla para observar el comportamiento del sistema en varias condiciones.
Introduce pruebas de carga junto con situaciones de fallas 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 capacidad de recuperación del sistema ante errores humanos, prueba situaciones que involucren parámetros de configuración incorrectos. Por ejemplo, ejecuta pruebas con parámetros de configuración incorrectos de conmutación por error de 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 las 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 simulation 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 fallas o interrupciones del servicio. Usa estos datos para verificar la eficacia de tus sistemas de alertas y respuesta a incidentes.
Verifica la recuperación en función de tu RTO y RPO
Mide cuánto tarda el sistema en reanudar las operaciones normales después de una falla y, luego, compara estos datos con el RTO definido y documenta las brechas.
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 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 las configuraciones de supervisión En función de los resultados de la prueba, actualiza las políticas y las guías de resguardo relevantes. Presenta 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 cambios en la infraestructura, actualizaciones de software y cargas de tráfico más altas.
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 el análisis post mortem, 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.