En este documento del framework de arquitectura de Google Cloud, se proporcionan principios operativos para ejecutar el servicio de manera confiable, como implementar actualizaciones, ejecutar servicios en entornos de producción y probar fallas. La arquitectura para la confiabilidad debe abarcar todo el ciclo de vida del servicio, no solo el diseño de software.
Elige buenos nombres para aplicaciones y servicios
Evita usar nombres de código internos en los archivos de configuración de producción, ya que pueden ser confusos, en especial para los empleados más nuevos, lo que podría aumentar el tiempo de mitigación (TTM) para las interrupciones. En la medida de lo posible, elige buenos nombres para todas tus aplicaciones, servicios y recursos críticos del sistema, como VM, clústeres e instancias de bases de datos, sujetos a sus respectivos límites de longitud. Un buen nombre describe el propósito de la entidad. que sea preciso, específico y distintivo, y es significativo para cualquier persona que lo vea. Un buen nombre evita los acrónimos, los nombres internos, las abreviaturas y la terminología potencialmente ofensiva, y no crea una respuesta pública negativa incluso si se publica de forma externa.
Implementa lanzamientos progresivos con pruebas canary
Los cambios globales instantáneos en la configuración o los objetos binarios del servicio son riesgosos por naturaleza. Lanza versiones nuevas de ejecutables y cambios de configuración de forma incremental. Comienza con un permiso pequeño, como unas pocas instancias de VM en una zona, y expande el alcance de manera gradual. Revierte con rapidez si el cambio no funciona como se espera o si afecta de manera negativa a los usuarios en cualquier etapa del lanzamiento Tu objetivo es identificar y abordar los errores cuando solo afectan una pequeña parte del tráfico de usuarios, antes de lanzar el cambio a nivel global.
Configura un sistema de pruebas canary que esté al tanto de los cambios de servicio y realice una comparación A/B de las métricas de los servidores modificados con los servidores restantes. El sistema debe marcar un comportamiento inesperado o anómalo. Si el cambio no tiene el rendimiento que esperas, el sistema de pruebas canary debe detener de forma automática los lanzamientos. Los problemas pueden ser claros, como errores de usuario, o sutiles, como el aumento de uso de CPU o el aumento de memoria.
Es mejor detener y revertir la primera sugerencia de problemas y diagnosticar problemas sin la presión de tiempo de una interrupción. Después de que el cambio pase las pruebas canary, propágalo a alcances más grandes de forma gradual, como una zona completa y, luego, a una segunda zona. Espera tiempo para que el sistema modificado controle volúmenes de tráfico de usuario cada vez más grandes para exponer cualquier error latente.
Para obtener más información, consulta Estrategias de implementación y prueba de aplicaciones.
Distribuye el tráfico para las promociones y los lanzamientos programados
Puedes tener eventos promocionales, como ventas que comienzan en un momento preciso y alentar a muchos usuarios a conectarse al servicio en simultáneo. Si es así, diseña el código del cliente para que distribuya el tráfico en unos segundos. Usa retrasos aleatorios antes de iniciar solicitudes.
También puedes hacer una preparación previa del sistema. Cuando haces una preparación previa del sistema, envías el tráfico del usuario que anticipas con antelación para asegurarte de que funcione como esperas. Este enfoque evita aumentos repentinos de tráfico instantáneos que podrían causar fallas en los servidores a la hora de inicio programada.
Automatiza la compilación, la prueba y la implementación
Elimina el esfuerzo manual de tu proceso de lanzamiento con canalizaciones de integración continua y entrega continua (CI/CD). Realiza implementaciones y pruebas de integración automatizadas. Por ejemplo, crea un proceso moderno de CI/CD con Anthos.
Para obtener más información, consulta integración continua, entrega continua, automatización de pruebas y automatización de implementaciones.
Defiéndase contra errores del operador
Diseña tus herramientas operativas para rechazar configuraciones potencialmente no válidas. Detecta y alerta cuando una versión de configuración esté vacía, sea parcial o esté truncada, esté dañada, sea incorrecta o inesperado de forma lógica, o no se haya recibido dentro del tiempo esperado. Las herramientas también deben rechazar las versiones de configuración que difieren demasiado de la versión anterior.
No permitas cambios o comandos con un alcance demasiado amplio que pueda ser destructivo. Estos comandos amplios pueden ser “Revocar permisos para todos los usuarios”, “Reiniciar todas las VM de esta región” o “Volver a formatear todos los discos de esta zona”. Estos cambios solo deben aplicarse si el operador agrega la función experimental de línea de comandos de anulación de emergencia o ajustes de opciones cuando implementan la configuración.
Las herramientas deben mostrar la amplitud del impacto de los comandos arriesgados, como la cantidad de VM que afectan el cambio, y requerir una confirmación explícita del operador antes de que la herramienta continúe. También puedes usar funciones para bloquear recursos críticos y evitar su eliminación accidental o no autorizada, como los bloqueos de políticas de retención de Cloud Storage.
Prueba la recuperación de errores
Prueba tus procedimientos operativos con regularidad para recuperarte de las fallas en el servicio. Sin pruebas regulares, es posible que los procedimientos no funcionen cuando los necesites si hay una falla real. Los elementos que se deben probar de forma periódica incluyen la conmutación por error regional, la manera de revertir una actualización y de restablecer los datos de las copias de seguridad.
Realiza pruebas de recuperación ante desastres
Al igual que con las pruebas de recuperación ante fallas, no esperes a que ocurra un desastre. Prueba y verifica de forma periódica los procedimientos y procesos de recuperación ante desastres.
Puedes crear una arquitectura de sistema para proporcionar alta disponibilidad (HA). Esta arquitectura no se superpone por completo con la recuperación ante desastres (DR), pero a menudo es necesario tener en cuenta la HA cuando piensas en los valores de los objetivos de tiempo de recuperación (RTO) y de los objetivos de punto de recuperación (RPO). .
La HA te ayuda a alcanzar o superar un nivel acordado de rendimiento operativo, como el tiempo de actividad. Cuando ejecutas cargas de trabajo de producción en Google Cloud, puedes implementar una instancia en espera pasiva o activa en una segunda región. Con esta arquitectura, la aplicación continúa brindando servicio de la región no afectada si hay un desastre en la región principal. Si deseas obtener más información, consulta Arquitectura de recuperación ante desastres para interrupciones de nube.
Practica la ingeniería de caos
Considera el uso de la ingeniería de caos en tus prácticas de prueba. Ingresa fallas reales en diferentes componentes de los sistemas de producción bajo carga en un entorno seguro. Este enfoque ayuda a garantizar que no haya un impacto general en el sistema porque el servicio maneja las fallas de forma correcta en cada nivel.
Las fallas que inyectas en el sistema pueden incluir tareas fallidas, errores y tiempos de espera en RPC, o reducciones en la disponibilidad de recursos. Usa la inserción de errores aleatorios para probar fallas intermitentes (oscilación) en las dependencias del servicio. Estos comportamientos son difíciles de detectar y mitigar en la producción.
La ingeniería del caos garantiza que las consecuencias de esos experimentos se minimicen y contengan. Trata esas pruebas como práctica para las interrupciones reales y usa toda la información recopilada a fin de mejorar la respuesta de la interrupción.
¿Qué sigue?
- Compila alertas eficientes (siguiente documento de esta serie).
Explora otras categorías en el framework de arquitectura, como el diseño del sistema, la excelencia operativa y la seguridad, la privacidad y el cumplimiento.