Resumen

  • Azure afirma que expiró una restricción temporal de actualizaciones del sistema operativo y que muchas puertas de enlace reanudaron sus actualizaciones en poco tiempo. Un cambio anterior también había alargado el procesamiento de las operaciones de configuración.
  • La combinación afectó operaciones de gestión de varios servicios de red en distintas regiones. En algunas puertas ExpressRoute, la actualización de la instancia redundante siguiente avanzó antes de que volvieran por completo la configuración y las rutas.

La explicación más cómoda de una incidencia en la nube suele ser también la más simple: una actualización provocó una caída. La revisión de Azure sobre el episodio del 30 de septiembre al 1 de octubre describe una interacción más importante. Una restricción temporal había detenido las actualizaciones del sistema operativo de un grupo de puertas de enlace. Al expirar, muchas se reanudaron en un periodo breve. A la vez, un cambio ya desplegado había elevado el tiempo de procesamiento de las operaciones de configuración en un plano de control de red regional compartido. Entraron más solicitudes justo cuando cada una tardaba más en completarse.

No es lo mismo que atribuirlo todo a una actualización defectuosa. Microsoft describe un aumento de reinicios y solicitudes de configuración que se encontró con un servicio más lento; los mecanismos existentes de limitación y protección de carga no preservaron suficientemente el procesamiento crítico. La oleada avanzó región por región, por lo que las horas de impacto variaron. Azure enumera ExpressRoute Gateway, Application Gateway, Azure Firewall, Bastion, Virtual WAN y VPN Gateway entre los servicios afectados, en regiones de América, Europa, Asia-Pacífico, África y Oriente Medio.

La revisión pública no ofrece un recuento de afectaciones por cliente.

Un fallo de gestión interrumpió algunas conexiones

Muchas de las operaciones afectadas eran funciones de gestión. En ciertas puertas ExpressRoute, la consecuencia fue más directa: se perdió temporalmente la conectividad con redes locales conectadas. Azure explica que una instancia en reinicio podía marcarse como sana antes de recuperar su configuración y estado de enrutamiento. Entonces la actualización pasaba a la otra instancia redundante. Si ninguna podía obtener la configuración de rutas necesaria, se interrumpía el enlace.

Tras unos 30 minutos de intentos fallidos, las puertas afectadas aplicaron una configuración válida guardada localmente. Ese plazo es el intervalo de intentos que describe Microsoft, no la duración de la caída de cada cliente. El incidente general empezó a las 20:30 UTC del 30 de septiembre y la última oleada se mitigó a las 02:15 UTC del 1 de octubre. Azure advierte que el periodo total no equivale al impacto de cada cliente o recurso.

La secuencia también muestra por qué añadir capacidad no bastó. La degradación de ExpressRoute se detectó a las 20:43 y los problemas más amplios del plano de control, a las 20:58. Pausar nuevas actualizaciones a las 21:45 y desviar tráfico ofreció alivio temporal; los intentos de añadir recursos tampoco resolvieron el problema. A las 23:55, los investigadores vincularon el mayor tiempo de procesamiento con una regresión de rendimiento. La reversión comenzó en una región a la 01:15, se validó y se extendió. El impacto terminó cuando concluyó en todas las regiones afectadas a las 02:15.

La ventana de mantenimiento no diseña cómo vaciar la cola

La documentación de Azure dice que el mantenimiento de puertas de enlace puede incluir parches, mejoras de componentes de red y retirada de hardware. Los clientes pueden escoger ventanas de mantenimiento para ciertos recursos, pero controlar el horario no demuestra cómo se vacía una cola diferida al acabar una pausa. Microsoft dice que está mejorando la reanudación escalonada, los controles que deben confirmar la restauración de configuración y rutas antes de actualizar la otra instancia, las restricciones de escalado y los mecanismos de limitación y descarga de carga.

Son medidas y estimaciones declaradas por la empresa, no una verificación independiente de que estén todas completas.

La guía de Microsoft para despliegues seguros recomienda exposición progresiva, comprobaciones de salud antes de cada fase y detener el despliegue cuando aparece un problema. La pregunta operativa que plantea este caso es más concreta: ¿«sana» significa que el proceso arrancó, o que recuperó y verificó la configuración y las rutas necesarias para dar servicio? La redundancia solo ayuda si la segunda instancia no hereda la misma dependencia inconclusa del plano de control.

Microsoft indica que los clientes no podían evitar ni reducir el impacto de este incidente específico. Aun así, pueden identificar qué cargas dependen de cada puerta, observar su plano de datos por separado de las operaciones de gestión y configurar alertas de Service Health. Estas prácticas mejoran la detección y la respuesta; no convierten el plan de recuperación del proveedor en una garantía bajo control del cliente.

Fuentes: Revisión de Azure 7Q30-010; Puertas de enlace virtuales ExpressRoute; Mantenimiento controlado por el cliente; Despliegues seguros. Marco editorial únicamente: Heng Lu, nota 20.