Interrupción de Azure OpenAI Service en Sweden Central: fallos en cascada y errores OOM
La interrupción de Azure OpenAI Service en Sweden Central dejó a clientes sin acceso efectivo a los modelos y APIs durante gran parte de la jornada laboral, tras una cadena de fallos provocada por un servicio backend dependiente que degradó la disponibilidad y disparó errores en las peticiones. El incidente vuelve a poner el foco en la resiliencia regional de los servicios de IA gestionados y en la necesidad de estrategias multi-región para cargas críticas.
Según la cronología comunicada por Microsoft, el problema fue reconocido a primera hora de la mañana (alrededor de las 09:00 UTC, con una detección reflejada poco después en su panel de estado). La compañía atribuyó el origen a “an unhealthy backend dependent service”, que derivó en cascading failures y, por tanto, en errores sostenidos para los usuarios en Sweden Central.
Qué se vio afectado durante la interrupción de Azure OpenAI Service en Sweden Central
Microsoft señaló impactos al utilizar varios modos y despliegues del servicio, incluyendo referencias a modelos como GPT-5.2, GPT-5 Mini y GPT-4.1, además de APIs asociadas. En la práctica, esto se tradujo en fallos de disponibilidad (errores de acceso y respuesta) para aplicaciones que dependen de inferencia en tiempo real, flujos RAG y automatizaciones basadas en llamadas a la API.
Para contexto oficial del producto y sus integraciones, Microsoft mantiene la documentación del servicio en su portal: Microsoft Learn: Azure OpenAI. También es posible contrastar el estado de los servicios Azure desde el panel corporativo: Azure Status.
Mitigación: reinicio de un servicio y escalado del clúster
Como parte de las medidas de mitigación, Microsoft indicó que deshabilitó y volvió a habilitar el servicio IRM (una acción equivalente a reiniciar un componente problemático) alrededor de las 12:36 UTC. Sin embargo, la incidencia persistió y el equipo de operaciones continuó aplicando cambios para recuperar la estabilidad.
Poco después, Microsoft reportó que pods del clúster en Suecia estaban fallando por errores de out-of-memory (OOM). La respuesta operativa incluyó el escalado horizontal del clúster (añadiendo nodos para mejorar la gestión de solicitudes y la resiliencia) y, más tarde, el incremento de memoria asignada a los pods, un ajuste orientado a reducir reinicios y colapsos por presión de memoria.
Línea temporal del incidente (UTC)
- ~09:00: Microsoft reconoce problemas de disponibilidad en la región Sweden Central.
- 12:36: acción de mitigación con reinicio del componente IRM.
- 12:46: reporte de pods con crashes por OOM en el clúster de Sweden.
- 15:30–15:53: incremento de memoria disponible para pods (según la actualización del proveedor).
- 16:12: Microsoft confirma la resolución del incidente.
Implicaciones para clientes y arquitectura de resiliencia
Aunque el incidente estuvo acotado a una región, su duración evidencia un riesgo recurrente para equipos que operan cargas de IA con SLA estrictos: la dependencia de una única región puede convertir un fallo de backend o un problema de capacidad en una interrupción completa de productos, canales de soporte o pipelines de automatización. En redes sociales, algunos usuarios indicaron que la caída sirvió como impulso para desplegar en múltiples regiones con automatic failover, una práctica habitual en arquitecturas críticas de Cloud Computing.
Microsoft no publicó, en el material citado, detalles adicionales sobre el componente dependiente que se degradó ni una causa raíz final, más allá del diagnóstico operativo (fallos en cascada y OOM en pods) y las acciones ejecutadas (reinicio, escalado y aumento de memoria).
A cierre del incidente, el servicio volvió a operar con normalidad, pero la interrupción de Azure OpenAI Service en Sweden Central deja un recordatorio claro para el mercado: la IA gestionada es tan robusta como su cadena completa de dependencias, y los fallos de capacidad y estabilidad a nivel de clúster siguen siendo un punto crítico en la producción de modelos y APIs.
