“¿Cuál es la causa principal de los problemas de confiabilidad de los servicios que vemos en Azure, aparte de pequeños, pero comunes, errores de hardware? El cambio. Una de las propuestas de valor de la nube es que mejora y ofrece nuevas características y funcionalidad, así como mejoras en la seguridad y la confiabilidad, de forma constante. Sin embargo, puesto que la plataforma evoluciona continuamente, el cambio es inevitable. Para garantizar la calidad y la estabilidad, se requiere un enfoque muy diferente al de un producto que se vende en una caja o a los enfoques de TI tradicionales, que consisten en realizar pruebas durante largos períodos de tiempo y, una vez que se implementa algo, evitar los cambios. Esta entrada de blog es la quinta de la serie que inicié con la entrada de julio, donde comentaba lo que estamos haciendo para asegurar que la confiabilidad de Azure esté a la altura de sus cargas de trabajo más críticas. Hoy explicamos nuestras prácticas de implementación segura, es decir, cómo administramos nosotros la automatización de los cambios para que todas las actualizaciones de código y de configuración se realicen en fases bien definidas con el fin de detectar regresiones y errores antes de que afecten a los clientes, o bien, si lo hacen después de las primeras fases, que afecten al menor número posible. Cristina del Amo Casado, de nuestro equipo de ingeniería de Compute, escribió esta entrada, ya que ella promueve nuestras iniciativas de implementación segura”. —Mark Russinovich, director de tecnología, Azure

---

 

Al ejecutar sistemas de TI en el entorno local, podría intentar asegurar una disponibilidad perfecta usando un hardware carísimo, cerrando la sala de servidores y tirando la llave. En el caso del software, los departamentos de TI suelen evitar tantos cambios como sea posible, incluidas las actualizaciones del sistema operativo o de las aplicaciones porque son demasiado críticos, y rechazan las solicitudes de cambio de los usuarios. Con todo el mundo moviéndose sigilosamente por el sistema, el método de “que no respire nadie” impide la mejora continua del sistema y, a veces, incluso pone en peligro la seguridad de los sistemas que se consideran demasiado críticos como para aplicarles revisiones periódicamente. Como ha comentado Mark, este método no funciona para la administración de cambios y versiones en una nube pública de hiperescala como Azure. El cambio es tanto inevitable como beneficioso, dada la necesidad de implementar actualizaciones y mejoras en los servicios y dado nuestro compromiso con nuestros clientes para actuar rápidamente ante vulnerabilidades de seguridad. Puesto que no podemos simplemente evitar el cambio, Microsoft, nuestros clientes y nuestros asociados debemos reconocer que se esperan cambios y que nos preparamos para ello. Microsoft sigue trabajando para que las actualizaciones sean lo más transparentes posible e implementará los cambios de forma segura, como se explica a continuación. Dicho esto, nuestros clientes y asociados también deben diseñar soluciones que ofrezcan alta disponibilidad y consumir los eventos de mantenimiento que envía la plataforma para adaptarse según sea necesario. Por último, en algunos casos, los clientes pueden tomar el control de iniciar las actualizaciones de la plataforma en un momento adecuado para su organización.

Aplicación de cambios de forma segura

Cuando nos planteamos cómo implementar versiones en nuestros centros de datos de Azure, una de las principales premisas que tenemos en cuenta para elaborar nuestros procesos es suponer que el cambio que se va a implementar podría dar lugar a un problema desconocido, planear la implementación de manera que se pueda detectar ese problema con un impacto mínimo y automatizar las medidas de mitigación para cuando surja el problema. Aunque un desarrollador considere que un cambio es totalmente inocuo y garantice que no afectará al servicio, hasta el cambio más insignificante que se realiza en un sistema supone un riesgo para su estabilidad, por eso, cuando aquí se habla de “cambios”, se refiere a todos los tipos de versiones nuevas y tanto a los cambios de código como a los cambios de configuración. En la mayoría de los casos, un cambio de configuración tiene un impacto menos drástico en el comportamiento de un sistema, pero, al igual que ocurre con los cambios de código, ningún cambio de configuración está libre del riesgo de activar un defecto de código latente o una nueva ruta de acceso al código.

Los equipos de Azure siguen un proceso similar para evitar o, al menos, minimizar el impacto relacionado con los cambios. En primer lugar, se aseguran de que los cambios alcancen el listón de calidad antes de iniciar la implementación, mediante validaciones de integración y pruebas. Una vez que se aprueba un cambio, se implementa de manera gradual y se miden las señales de mantenimiento de forma constante, con el fin de poder detectar en un aislamiento relativo si hay algún impacto inesperado asociado al cambio que no se había producido durante las pruebas. Puesto que no queremos que un cambio cause problemas en un entorno de producción a gran escala, tomamos medidas para asegurarnos de que podamos evitarlo en cuanto sea posible. La implementación gradual nos ofrece una buena oportunidad para detectar problemas a una escala más reducida (o con un efecto menor) antes de que llegue a tener un impacto generalizado.

En línea con este proceso general, Azure lleva a cabo la automatización de los cambios a través de un marco de trabajo de prácticas de implementación segura (SDP), cuyo objetivo es asegurarse de que todos los cambios de configuración y de código pasen por un ciclo de vida con fases específicas, donde se supervisan métricas de mantenimiento de forma constante para desencadenar acciones y alertas en el caso de que se detecte algún tipo de problema. Estas fases (que se muestran en el diagrama siguiente) reducen el riesgo de que los cambios de software afecten negativamente a las cargas de trabajo de Azure.

Esto muestra una simplificación de nuestra canalización de implementación, que comienza a la izquierda con los desarrolladores que modifican el código, lo prueban en sus propios sistemas y lo envían a entornos de ensayo. Por lo general, este entorno de integración está dedicado a los equipos de un subconjunto de servicios de Azure que necesitan probar las interacciones de sus componentes particulares juntos. Por ejemplo, los equipos de la infraestructura principal, como proceso, redes y almacenamiento, comparten un entorno de integración. Cada equipo ejecuta pruebas sintéticas y de estrés en el software de ese entorno, iteran los procesos hasta que son estables y, una vez que los resultados de calidad indican que una versión, una característica o un cambio determinados están listos para producción, implementan los cambios en regiones controladas.

Regiones controladas

Nos referimos públicamente a regiones controladas como regiones del “programa de acceso a actualizaciones anticipadas”, que son auténticas regiones de Azure con la gran mayoría de los servicios de la plataforma. Una de las regiones controladas se crea con Availability Zones y la otra sin esta característica, y ambas regiones forman un par de regiones para poder validar la funcionalidad de replicación geográfica de datos. Estas regiones controladas se utilizan para llevar a cabo validaciones completas de nivel de producción y de cobertura de escenarios a gran escala. Hospedan algunos servicios de Microsoft (para clientes internos), varios servicios de terceros y un pequeño conjunto de clientes externos que invitamos al programa para enriquecer los escenarios cubiertos y aumentar su complejidad, todo ello para asegurar que las regiones controladas tengan patrones de uso representativos de nuestras regiones de Azure públicas. Los equipos de Azure también realizan pruebas de estrés y sintéticas en estos entornos y, periódicamente, insertamos errores o realizamos simulacros de recuperación ante desastres a nivel de región o zona de disponibilidad para practicar los flujos de trabajo de detección y recuperación que se ejecutarían si esto sucediese en la vida real. Por separado y juntos, estos ejercicios intentan asegurar que el software sea de la máxima calidad antes de que los cambios lleguen a cargas de trabajo más amplias de los clientes en Azure.

Fase piloto

Una vez que los resultados en regiones controladas indican que no se han detectado problemas conocidos, se puede iniciar la implementación progresiva en producción, con lo que comienza lo que denominamos nuestra fase piloto. Esta fase nos permite probar los cambios, aún a una escala relativamente pequeña, pero con más diversidad de hardware y configuraciones. Esta fase es especialmente importante para el software como el de los servicios de almacenamiento y de infraestructura de proceso principales, que tienen dependencias del hardware. Por ejemplo, Azure ofrece servidores con GPU, servidores con gran cantidad de memoria, servidores estándar, varias generaciones y tipos de procesadores, InfiniBand, etc. Esto permite probar los cambios y permitir la detección de problemas que no se manifestaron durante las pruebas a una escala más reducida. En cada paso del proceso, una supervisión exhaustiva del mantenimiento y “tiempos de horneado” prolongados permiten que se muestren posibles patrones de error y aumentan la confianza en los cambios, al tiempo que reducen en gran medida el riesgo global para nuestros clientes.

Una vez que determinamos que los resultados de la fase piloto son buenos, los sistemas de implementación continúan permitiendo que el cambio se implemente en más regiones gradualmente. Durante la implementación en las regiones de Azure en general, los sistemas de implementación intentan respetar las zonas de disponibilidad (un cambio solo se implementa en una zona de disponibilidad dentro de una región) y el emparejamiento de regiones (cada región se “empareja” con una segunda región para el almacenamiento con redundancia geográfica), de modo que un cambio se implementa primero en una región y, después, en su pareja. En general, los cambios solo se implementan mientras no se detecte ninguna señal negativa.

Prácticas de implementación segura en acción

Dada la escala global de Azure, todo el proceso de implementación se automatiza y controla totalmente con directivas. Estas directivas y procesos declarativos (no los desarrolladores) determinan la rapidez con la que se puede implementar el software. Las directivas se definen de forma centralizada e incluyen señales de estado obligatorias para la supervisión de la calidad del software, así como los “tiempos de horneado” obligatorios entre las distintas fases descritas anteriormente. El motivo para probar y preparar el software en diferentes períodos de tiempo en cada fase es asegurar que el cambio se exponga a un abanico completo de cargas en ese servicio. Por ejemplo, diversos usuarios de organizaciones pueden conectarse por la mañana, los clientes de juegos podrían conectarse por la tarde y las nuevas creaciones de máquinas virtuales o recursos de los clientes pueden producirse durante un período de tiempo prolongado.

Los servicios globales, que no pueden adoptar el método de implementación progresiva en diferentes clústeres, regiones o anillos de servicio, también utilizan un tipo de implementaciones progresivas en línea con las prácticas de implementación segura. Estos servicios siguen el modelo de actualización de las instancias del servicio en varias fases, desviando el tráfico progresivamente hacia las instancias actualizadas a través de Azure Traffic Manager. Si las señales son positivas, se va desviando más tráfico a las instancias actualizadas, lo que aumenta la confianza y permite que la implementación se aplique a más instancias del servicio a lo largo del tiempo.

Por supuesto, la plataforma Azure también tiene la capacidad de implementar un cambio simultáneamente en todo Azure, en el caso de que fuese necesario para mitigar una vulnerabilidad extremadamente crítica. Aunque nuestra directiva de implementación segura es obligatoria, tenemos la opción de acelerarla cuando se dan ciertas condiciones de emergencia. Por ejemplo, para lanzar una actualización de seguridad que requiere un proceso más rápido del que seguiríamos normalmente, o para una corrección donde el riesgo de regresión pierde importancia ante el hecho de que la corrección mitiga un problema que ya está afectado mucho a los clientes. Estas excepciones son muy poco frecuentes. En general, nuestras herramientas y procesos de implementación sacrifican intencionadamente la velocidad para maximizar la posibilidad de que se produzcan señales y de probar escenarios y flujos de trabajo a gran escala, ya que esto nos da la oportunidad de detectar problemas con el menor impacto posible.

Continuación de las mejoras

Nuestras prácticas y herramientas de implementación continúan evolucionando con el aprendizaje que nos han aportado interrupciones y eventos de mantenimiento anteriores, y en línea con nuestro objetivo de detectar problemas a una escala considerablemente menor. Por ejemplo, hemos aprendido la importancia de seguir enriqueciendo las señales de mantenimiento y de usar aprendizaje automático para mejorar la correlación de los errores y detectar anomalías. También seguimos mejorando la forma en la que realizamos las pruebas piloto para cubrir una diversidad de hardware más amplia con un riesgo menor. Seguimos mejorando nuestra capacidad de revertir los cambios automáticamente si muestran posibles indicios de problemas. También seguimos invirtiendo en características de la plataforma que reduzcan o eliminen el impacto de los cambios en general.

Con más de mil características nuevas publicadas el año pasado, sabemos que el ritmo del cambio en Azure puede resultar abrumador. Como ha mencionado Mark, la agilidad y la mejora continua de los servicios en la nube constituyen una de las propuestas de valor fundamentales de la nube: el cambio es una característica, no un error. Para obtener información sobre las últimas versiones, recomendamos a los clientes y asociados que se mantengan al día en Azure.com/Updates. Nos esforzamos por mantener esta página como el único lugar para obtener información sobre las actualizaciones de productos de Azure recientes y futuras, incluida la hoja de ruta de las innovaciones que están en desarrollo. Para conocer las regiones en las que estos servicios están disponibles o cuándo lo estarán, puede usar también nuestra herramienta de Azure.com/ProductsbyRegion.