Editor Top
Los servicios en la nube cambian todo el tiempo, ya sea agregando nuevas funciones o corrigiendo errores y vulnerabilidades de seguridad; esa es una de las grandes ventajas sobre el software local. Pero cada cambio también es una oportunidad para introducir errores y regresiones que son las principales razones de los problemas de confiabilidad y el tiempo de inactividad de la nube. En un intento por evitar problemas como ese, Azure usa un proceso de implementación seguro que implementa actualizaciones en fases, ejecutándolas en anillos de infraestructura progresivamente más grandes y usando monitoreo continuo impulsado por IA para detectar cualquier problema que se haya perdido durante el desarrollo y las pruebas.
Cuando Microsoft lanzó su servicio Chaos Studio para probar cómo las cargas de trabajo se enfrentan a fallas inesperadas el año pasado, el CTO de Azure, Mark Russinovich, explicó el proceso de implementación segura. “Pasamos por un clúster controlado como parte de nuestra implementación segura, que es una región interna de Azure donde tenemos pruebas sintéticas y tenemos cargas de trabajo internas que realmente prueban los servicios antes de que se apaguen. Este es el primer entorno de producción al que llega el código para la actualización del nuevo servicio, por lo que queremos asegurarnos de que podemos validarlo y tener una buena idea de su calidad antes de sacarlo y hacer que llegue a los clientes”.
VER: Kit de contratación: Cloud Engineer (TechRepublic Premium)
Después de la región canaria, el código se implementa en una región piloto, luego en una región con un uso ligero, luego en una región más utilizada y, luego, progresivamente en todas las regiones de Azure (que se agrupan en pares geográficamente, con actualizaciones que van a una región en cada región). par primero y luego al otro). Durante todo el proceso de implementación, explicó: «Tenemos AIOps monitoreando todo para buscar regresiones».
AIOps, técnicas que utilizan big data, aprendizaje automático y visualización para automatizar las operaciones de TI, pueden detectar problemas que los desarrolladores no pueden encontrar mediante la depuración de su código porque pueden ser causados por dependencias o interacciones que solo entrarán en juego cuando el código esté activo y funcionando. se usa junto con otros servicios de Azure.
Una mala implementación puede bloquear las máquinas virtuales, ralentizarlas, hacerlas más lentas para aprovisionarse o detener la comunicación, o puede afectar a los agentes de monitoreo, el almacenamiento, la telemetría o las operaciones en el plano de control; pero esos problemas también pueden ser causados por una falla de hardware, problemas de red temporales o tiempos de espera en las API de servicio que no se solucionarían al revertir la implementación más reciente. Hay cientos de implementaciones al día en Azure, y la mayoría de las implementaciones se dirigen a cientos o miles de clústeres, todos los cuales deben supervisarse, y una implementación puede llevar mucho tiempo (entre diez minutos y 18 horas). Con miles de componentes ejecutándose en más de 200 centros de datos y más de 60 regiones, cuando problemas como una fuga de memoria pueden no aparecer durante varios días, o pueden aparecer como problemas muy sutiles en muchos clústeres que se suman a un problema importante en un toda la región, es difícil para los operadores humanos determinar exactamente qué cambios causan un problema específico, especialmente si son causados por interacciones con otro componente o servicio.
El sistema AIOps que usa Microsoft, llamado Gandalf“observa las señales de implementación y estado en la nueva versión y a largo plazo y encuentra correlaciones, incluso si [they’re] no es obvio”, dijo Microsoft. Gandalf analiza los datos de rendimiento (incluido el uso de la CPU y la memoria), las señales de falla (como bloqueos del sistema operativo, fallas de nodo y reinicios de VM, así como fallas de llamadas API en el plano de control) y toma información de otros servicios de Azure que rastrean fallas para detectar problemas y rastrearlos hasta implementaciones específicas.
Sabe cuándo está ocurriendo una implementación y observa a cuántos nodos, clústeres y clientes afectaría una falla, para recomendar si el nuevo código es seguro para implementar en Azure o si debe bloquearse porque causa problemas en la región canaria que traducirse en problemas significativos en la producción.
Gandalf captura información de fallas una hora antes y después de cada implementación como datos de transmisión en Azure Data Explorer (también conocido como Kusto), que está diseñado para análisis rápidos: por lo general, Gandalf tarda unos cinco minutos en tomar una decisión sobre una implementación. También realiza un seguimiento del comportamiento del sistema durante 30 días después de la implementación, para detectar problemas a más largo plazo (esas decisiones tardan unas tres horas).
VER: iCloud vs. OneDrive: ¿Cuál es mejor para los usuarios de Mac, iPad y iPhone? (PDF gratuito) (República Tecnológica)
No es la única técnica que usa Microsoft para hacer que Azure sea más resistente. “Gandalf detendría una fuga de memoria causada por una nueva carga útil regresiva. Mientras tanto, tenemos un mecanismo de resistencia para mitigar automáticamente los nodos ya implementados con problemas de fugas, como reiniciar el nodo si no hay cargas de trabajo del cliente o migrar en vivo máquinas virtuales en ejecución si el nodo no está vacío”.
“AIOps es bueno para detectar patrones que ocurren naturalmente y hacer correlaciones basadas en datos históricos y capacitación”, dijo Microsoft. Los problemas que encuentra son con la nueva carga útil de implementación, pero hay otros problemas como los errores cero que Azure usa otras técnicas como las pruebas de caos para encontrar. “Los errores del día cero pueden desencadenarse por cargas de trabajo que ocurren raramente, se manifiestan tanto en versiones anteriores como en versiones nuevas y ocurren al azar, o no tienen una fuerte correlación con la nueva implementación. Las pruebas de caos pueden capturar tales errores introduciendo fallas al azar y probando que el sistema se mantiene como se esperaba”.
Gandalf se ha estado ejecutando durante casi cuatro años, inicialmente para algunos componentes clave de la infraestructura de Azure, deteniendo implementaciones que de otro modo habrían causado fallas críticas. Ahora cubre más componentes de Azure, incluidos los hosts de Azure con parches activos; “Estamos creando soluciones de monitoreo holísticas para el estado de los recursos del host de Azure y bloqueando los despliegues que causan fugas de recursos del host como memoria, espacio en disco”, dijo Microsoft.
“Estamos creando inteligencia para medir la calidad de las nuevas versiones de los componentes de la infraestructura de Azure mediante AIOps antes de implementar un componente en producción. La idea clave es crear un entorno de preproducción que pueda ejecutar pruebas A/B para cargas de trabajo de clientes representativas. Este entorno de preproducción también tiene una buena representación de la configuración en un entorno de producción (hardware, SKU de VM, etc.). Este sistema recibe comentarios de Gandalf, por lo que se evitarán problemas similares capturados en el entorno de producción cuando se lance”.
Gandalf ahora mira más señales. “Comenzamos a explorar las ideas de la correlación de señales en toda la pila de Azure desde los centros de datos ([like] temperatura, humedad), hardware, entorno anfitrión, a la experiencia del cliente”. Y se está volviendo más inteligente acerca de la correlación de fallas. “Estamos trabajando para dar mayor peso a las fallas que afectan a los clientes de misión crítica oa los servicios de alto costo”, dijo un vocero.
También se está aplicando a los cambios en la configuración de Azure, así como a los componentes que componen el servicio. “Además de la seguridad en el despliegue de la carga útil, estamos construyendo inteligencia para hacer que cualquier cambio (configuración) en la producción sea seguro”.
AIOps para empresas
Gandalf es parte de cómo Microsoft protege Azure y, al igual que con otras herramientas internas como la ingeniería del caos, la empresa está considerando empaquetar algunas de estas técnicas de implementación de AIOps como un servicio para proteger las cargas de trabajo de los clientes.
Microsoft Defender for Cloud (anteriormente conocido como Azure Security Center) y Sentinel cloud SIEM ya utilizan técnicas similares de aprendizaje automático para la seguridad, señaló Russinovich. “AIOps está operando efectivamente allí para ver los datos y determinar dónde hay un incidente. [The way] hemos estado usando AIOps observando la telemetría dentro de Azure para comprender si hay una regresión o un incidente con hardware o software en algún lugar que aparecerá en los servicios que respaldan los datos de monitoreo que tenemos, como Azure Monitor”, sugirió.
Microsoft ya tiene clientes de Azure que operan a la misma escala que sus propios servicios internos, y las grandes organizaciones ya usan herramientas AIOps para administrar su propia infraestructura, por lo que tiene sentido brindarles estas herramientas para trabajar de manera confiable a escala de la nube.
