Este principio del pilar de fiabilidad del Google Cloud framework Well-Architected proporciona recomendaciones para ayudarte a diseñar y ejecutar pruebas de recuperación en caso de fallos.
Este principio se aplica al área de aprendizaje de la fiabilidad.
Descripción general de los principios
Para asegurarte de que tu sistema puede recuperarse de los fallos, debes realizar periódicamente pruebas que incluyan conmutaciones por error regionales, reversiones de lanzamientos y restauración de datos a partir de copias de seguridad.
Estas pruebas te ayudan a practicar las respuestas a eventos que suponen un riesgo importante para la fiabilidad, como la interrupción del servicio en toda una región. Estas pruebas también te ayudan a verificar que tu sistema se comporta como debería durante una interrupción.
En el improbable caso de que se produzca una interrupción del servicio 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, deben sincronizarse de la región principal a la de conmutación por error. Debes verificar que los datos replicados sean siempre muy recientes para que los usuarios no sufran pérdidas de datos ni interrupciones de sesión. El sistema de balanceo de carga también debe poder desviar el tráfico a la región de conmutación por error en cualquier momento sin que se produzcan interrupciones en el servicio. Para minimizar el tiempo de inactividad después de un fallo 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 se denomina a veces desactivación de 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 de recuperación tras fallos, ten en cuenta las recomendaciones de las siguientes subsecciones.
Definir los objetivos y el alcance de las pruebas
Define claramente qué quieres conseguir 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 el artículo Conceptos básicos de la planificación de la recuperación ante desastres.
- Evalúa la resiliencia y la tolerancia a fallos del sistema en diferentes situaciones de fallo.
- Prueba la eficacia de los mecanismos de conmutación por error automatizados.
Decide qué componentes, servicios o regiones se incluirán en las pruebas. El ámbito puede incluir niveles de aplicación específicos, como el frontend, el backend y la base de datos, o recursos específicos, como instancias de Cloud SQL o clústeres de GKE. Google Cloud El ámbito también debe especificar las dependencias externas, como las APIs de terceros o las interconexiones en la nube.
Preparar el entorno para las pruebas
Elige un entorno adecuado, preferiblemente un entorno de staging o de pruebas, que replique tu configuración de producción. Si realizas la prueba en producción, asegúrate de tener listas medidas de seguridad, como la monitorización automatizada y los procedimientos de reversión manual.
Crea un plan de copia de seguridad. Haz copias de seguridad o instantáneas 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úrese de que los roles y las políticas de gestión de identidades y accesos, así como las configuraciones de conmutación por error, estén configurados correctamente. Verifica que se hayan concedido los permisos necesarios a las herramientas y las secuencias de comandos de prueba.
Informa a las partes interesadas, como los equipos de operaciones, DevOps y los propietarios de las aplicaciones, sobre la programación, el alcance y el posible impacto de las pruebas. Proporciona a las partes interesadas una cronología estimada y los comportamientos esperados durante la prueba.
Simular situaciones de fallo
Planifica y ejecuta fallos con herramientas como Chaos Monkey. Puedes usar secuencias de comandos personalizadas para simular fallos 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 una región mediante reglas de cortafuegos o restricciones de API en función del ámbito de la prueba. Aumenta gradualmente los casos de fallo para observar el comportamiento del sistema en diferentes condiciones.
Introduce pruebas de carga junto con situaciones de fallo para replicar el uso real durante las interrupciones. Prueba los efectos de los fallos en cascada, como el comportamiento de los sistemas de frontend cuando los servicios de backend no están disponibles.
Para validar los cambios en la configuración y evaluar la resiliencia del sistema frente a errores humanos, prueba situaciones que impliquen configuraciones incorrectas. Por ejemplo, ejecuta pruebas con ajustes de conmutación por error de DNS incorrectos o permisos de IAM incorrectos.
Monitorizar el comportamiento del sistema
Monitoriza cómo los balanceadores de carga, las comprobaciones del estado y otros mecanismos redirigen el tráfico. Usa Google Cloud herramientas como Cloud Monitoring y Cloud Logging para registrar métricas y eventos durante la prueba.
Observa los cambios en la latencia, las tasas de errores y el rendimiento durante y después de la simulación de fallos, y monitoriza el impacto general en el rendimiento. Identifica cualquier degradación o incoherencia en la experiencia de usuario.
Asegúrate de que se generen registros y se activen alertas para eventos clave, como interrupciones de servicio o conmutaciones por error. Utilice estos datos para verificar la eficacia de sus sistemas de alertas y de respuesta a incidentes.
Verificar la recuperación en función de los objetivos de tiempo de recuperación y de punto de recuperación
Mide el tiempo que tarda el sistema en volver a funcionar con normalidad después de un fallo y, a continuación, compara estos datos con el RTO definido y documenta las diferencias.
Asegúrate de que la integridad y la disponibilidad de los datos se ajusten al RPO. Para probar la coherencia de la base de datos, compara las copias o las copias de seguridad de la base de datos antes y después de un fallo.
Evalúa la restauración del servicio y confirma que todos los servicios se han restaurado a un estado funcional con una interrupción mínima para los usuarios.
Documentar y analizar los resultados
Documenta cada paso de la prueba, cada caso de error y el 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 hayan observado 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 monitorización. Según los resultados de las pruebas, actualice las políticas de conmutación por error y los manuales pertinentes. 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 Realizar análisis post mortem exhaustivos.
Repetir y mejorar
Para validar la fiabilidad y la resiliencia continuas, planifica pruebas periódicas (por ejemplo, trimestrales).
Realiza pruebas en diferentes situaciones, como cambios en la infraestructura, actualizaciones de software y aumento de las cargas de tráfico.
Automatiza las pruebas de conmutación por error usando las cadenas de CI/CD para integrar las pruebas de fiabilidad en tu ciclo de vida de desarrollo.
Durante el análisis post mortem, utiliza los comentarios de las partes interesadas y los usuarios finales para mejorar el proceso de prueba y la resiliencia del sistema.