Microsoft atribuyó la caída masiva de Microsoft 365 del 23 de julio a un bug en su propio sistema de conversión de solicitudes de mantenimiento, que marcó como parte del evento a más dispositivos de red de los que correspondía.
El resultado fue el retiro de rutas IP entre el datacenter de West US y la red de área amplia de la compañía, lo que rompió el tráfico que entraba o salía de esa región.
Casi cuatro horas y una lista larga de servicios
El incidente, registrado como MO1437424, arrancó a las 10:44 de la mañana (hora del Este) y se dio por resuelto a las 14:26.
La superficie afectada abarcó buena parte del portafolio de productividad y de la plataforma de datos:
- OneDrive, SharePoint Online, Microsoft Teams y Microsoft Loop.
- El Centro de administración y Power Automate.
- Copilot Chat y Copilot Studio.
- Fabric, Power BI y Power Apps.
- Windows 365 y Microsoft Defender.
Que Defender aparezca en esa lista es un detalle relevante: la misma falla de red que interrumpe la colaboración también degrada la capa de seguridad que debería estar mirando.
La causa raíz: automatización sin red de contención
Según la explicación de Microsoft, «un bug en el sistema de conversión de solicitudes marcó incorrectamente dispositivos de red adicionales como parte del evento de mantenimiento».
El sistema hizo exactamente lo que se le pidió, sobre un conjunto de equipos más amplio del previsto. No hubo intrusión, no hubo hardware fallado, no hubo pico de demanda.
Es la clase de incidente que cuesta más aceptar que un ataque, porque el origen es un cambio rutinario que pasó por el proceso normal.
Cómo se recuperó
Microsoft inició un rollback a las 13:45 y lo completó a las 14:26. Los servicios afectados terminaron de normalizarse a las 15:41.
La compañía se comprometió a realizar «un análisis completo enfocado en los chequeos de seguridad y el proceso de cambio automatizado de solicitudes de mantenimiento», con un Post Incident Review final dentro de los 14 días.
La distancia entre el inicio del problema y el arranque del rollback (unas tres horas) es probablemente el número más interesante para cualquiera que opere servicios: el tiempo de detección y decisión pesó más que el tiempo de ejecución del remedio.
Qué se lleva de esto quien opera infraestructura
El patrón se repite en escalas mucho más chicas que la de Microsoft. Los cambios de red automatizados concentran un riesgo desproporcionado porque afectan la ruta por la que uno mismo llega a arreglarlos.
Tres preguntas que este caso deja sobre la mesa para cualquier equipo:
- ¿El sistema que selecciona el alcance de un mantenimiento tiene validación independiente de ese alcance, o se confía en la conversión?
- ¿Existe un límite duro de cuántos dispositivos puede tocar un cambio antes de exigir aprobación manual?
- ¿El rollback está ensayado con la misma frecuencia que el cambio?
Para las organizaciones argentinas que apoyan su operación diaria en Microsoft 365, el otro recordatorio es más incómodo: cuatro horas sin Teams ni SharePoint no se resuelven con un plan de continuidad que también viva en Microsoft 365.
¿Tienen un plan B que no dependa de la nube que se cayó?
La mayoría de los planes de continuidad que uno ve documentan cómo seguir trabajando si falla la conexión de la oficina, no si falla el proveedor.
¿Cómo se organizaron ustedes durante la caída? Te leemos en los comentarios.
Fuentes
