Código mal configurado causó la interrupción de Azure el 18 de noviembre – Microsoft

Table Of Contents

• Microsoft dice que la interrupción de Azure el 18 de noviembre se debió a un código mal configurado
• Protocolo de anulación
• La declaración

Microsoft dice que la interrupción de Azure el 18 de noviembre se debió a un código mal configurado

Microsoft Azure, su plataforma en la nube para empresas, sufrió una importante interrupción el 18 de noviembre que dejó a muchos usuarios en una situación difícil. En una declaración, Microsoft afirmó que la interrupción fue causada por sus desarrolladores que implementaron un código defectuoso.

Protocolo de anulación

Parece que los desarrolladores de Microsoft estaban trabajando para resolver un error en su software. La solución al error, aparentemente, causó la masiva interrupción de los servicios en la nube de Azure. Microsoft dijo que había probado la actualización antes de implementarla. Pero no siempre es posible predecir con precisión el resultado de una actualización de software en una plataforma tan grande bajo un entorno de prueba controlado. Por lo tanto, Microsoft sigue una política de implementar cualquier nueva actualización sección por sección, algo que ellos denominan flighting, es decir, limitando el despliegue. Sin embargo, esta vez, probablemente debido a un exceso de entusiasmo, los desarrolladores implementaron todo el paquete de actualización de una vez, lo que causó un efecto en cascada en todos sus servidores. En una declaración emitida en el blog de Azure, Jazon Zander, CVP, equipo de Azure, señaló que,

Como consecuencia, las tasas de conexión a Azure el 18 de noviembre cayeron del 97% al 7%-8% después de las 7 p.m. hora del Este en Virginia del Norte. El centro de datos de Azure en Dallas sufrió una interrupción completa por un corto tiempo. Los centros de datos en Europa no se recuperaron hasta bien entrada la siguiente jornada.

Agregó además que, aunque tienen una política de despliegue estándar para la actualización/parcheo de errores, hubo comunicaciones erróneas evidentes, “La política de despliegue estándar de flighting de implementar cambios de manera incremental a través de pequeñas secciones no se siguió”, escribió Zander. Zander dijo que su equipo había identificado el problema clave, que era un problema de configuración en los frontales de almacenamiento de Azure Table. “El interruptor de configuración se habilitó incorrectamente para los frontales de almacenamiento de Azure Blob”, escribió Zander.

Los frontales de almacenamiento de tablas registran la secuencia de los diferentes tipos de datos que ingresan a un Blob (un servicio para almacenar grandes cantidades de datos no estructurados) y pueden usarse para guiar la recuperación de datos. El error en el interruptor de configuración parece haber causado un bucle infinito que, en última instancia, resultó en la interrupción del servicio en la nube de Azure.

La declaración

La actualización original estaba destinada a corregir algunos errores encontrados por el equipo de Azure y mejorar el rendimiento de la plataforma en la nube. La actualización se demostró en cada prueba en la fase de prueba alfa. Los resultados exitosos de la prueba alfa probablemente entusiasmaron demasiado a los desarrolladores para omitir el método de despliegue de flighting y implementaron la actualización de una vez. El resultado, como se vio el 18 de noviembre, fue una interrupción total que causó problemas a los usuarios. Como respuesta, los administradores de Azure ahora han implementado una práctica de actualización automatizada, que no permitirá que ocurra un evento así nuevamente.

En quizás el resultado más claro del incidente, Zander escribió: “Microsoft Azure tenía pautas operativas claras, pero había una brecha en las herramientas de despliegue que dependían de decisiones humanas… Con las actualizaciones de herramientas, la política ahora es aplicada por la propia plataforma de despliegue.”

Zander reconoció que las operaciones en la nube deben volverse más confiables y dijo que Microsoft continuará trabajando en ese objetivo. “Nos disculpamos sinceramente y reconocemos el impacto significativo que esta interrupción del servicio puede haber tenido en sus aplicaciones y servicios”, escribió.

Zander puede haber pedido disculpas sinceramente por el exceso de entusiasmo de su equipo de desarrollo, pero el hecho es que Microsoft está lanzando parches y actualizaciones con prisa sin las pruebas necesarias. Este problema ya ha llevado a Microsoft a lanzar parches/actualizaciones defectuosos que provocan BSOD, en sus actualizaciones de Patch Tuesday dos veces, una en octubre con KB 2949927 y en diciembre con KB 3004394, solo para retirarlos más tarde. Los usuarios esperarán que Microsoft presente un SOP para lanzar solo aquellas actualizaciones/parches que hayan sido verificadas en un entorno de trabajo en tiempo real.