Diario TI

Microsoft atribuye su caída de 24 horas a una ampliación de su red

Acuarela de una nube conectada a una red en obras, con sobres acumulados ante un estrechamiento y otros avanzando hacia unas oficinas.

Según la empresa, que pidió disculpas, el problema se originó en una ampliación previa de capacidad de red y se manifestó tras un cambio reciente. El informe completo aún está pendiente.

Microsoft dio por resuelta el sábado 14 de noviembre la caída global de Microsoft 365 que dejó sin correo, calendarios y otras herramientas a usuarios de decenas de países. Según los registros de los incidentes EX1550543 y MO1550821 recopilados por StatusStack, los problemas en Exchange Online comenzaron el jueves 12 a las 16:17 UTC y Microsoft fijó el fin del impacto el viernes 13 a las 16:10 UTC, casi 24 horas después. La empresa siguió vaciando la cola de correos retenidos durante la noche y cerró ambos incidentes en la madrugada del sábado.

Downdetector acumuló más de 7,4 millones de reportes de fallas en todo el mundo, informó Digital Trends, aunque esa cifra cuenta reportes y no usuarios afectados.

Qué falló, según Microsoft

En su declaración del viernes, Microsoft describió el episodio como un problema técnico no relacionado con ciberataques ni con IA o agentes. Indicó que la falla se introdujo durante una ampliación anterior de capacidad de red y que salió a la luz tras un cambio de red reciente, de acuerdo con Forbes. La empresa no ha detallado en qué consistieron esa ampliación ni ese cambio.

Los avisos publicados durante el incidente muestran cómo se fue entendiendo el problema. Primero, Microsoft habló de una carga elevada en varias regiones. Luego precisó que no se trataba de más tráfico, sino de que muchos servidores habían dejado de responder y fallaban sus controles automáticos de salud, lo que trasladaba la carga al resto. Más tarde identificó que en esos servidores se saturaba el proceso que establece las conexiones seguras. Los equipos que volvían a ponerse en línea caían de nuevo al recibir tráfico, y algunos quedaron en un estado que impedía aplicar los cambios de configuración.

La primera noche, la empresa aseguró que ningún cambio reciente coincidía con el inicio del problema, una evaluación que luego corrigió. La recuperación comenzó la mañana del viernes, cuando aplicó un parche a un componente de autenticación y enrutamiento y lo extendió por etapas, región por región. Para no perder mensajes, amplió a 48 horas el plazo durante el cual el sistema retiene los correos que no ha podido entregar.

Disculpas y un informe pendiente

Charles Lamanna, vicepresidente ejecutivo de Copilot, agentes y plataforma, lamentó el impacto que la caída tuvo en quienes dependen de Microsoft, según Forbes. Ya el jueves había escrito en redes sociales que la empresa lamentaba las interrupciones y que no había indicios de actividad maliciosa, informó Yahoo News UK.

Microsoft prometió un informe posterior al incidente con la causa raíz y las medidas para evitar que se repita. StatusStack sostiene que habrá uno preliminar en dos días hábiles y uno final en cinco, aunque el recuento de Azure Blog UK atribuye esos plazos a un incidente menor de Teams del mismo jueves y señala que, para la caída principal, no hay fecha. Los registros tampoco coinciden en la hora de inicio: las entradas finales de Microsoft citan las 10:05 UTC del jueves, seis horas antes que sus primeros avisos.

Qué conviene hacer ahora

Para los administradores de Microsoft 365, el cierre del incidente abre algunas tareas concretas:

  • Revisar los créditos de servicio. El acuerdo de nivel de servicio de Microsoft contempla compensaciones cuando la disponibilidad mensual cae bajo el umbral comprometido, pero no se aplican de forma automática: el administrador debe presentar la solicitud con el detalle de la interrupción y los usuarios afectados, según la documentación de Microsoft. Como referencia, en la tabla de ejemplo de la empresa una disponibilidad inferior a 99% da derecho a 50% de crédito, y un día completo sin servicio en un mes de 30 días equivale a cerca de 96,7%. El monto real depende del servicio contratado y de la interrupción medida para cada organización.
  • Guardar una copia del informe. Azure Blog UK recuerda que el historial del panel de estado de servicio solo conserva los últimos 30 días, por lo que conviene archivar el informe cuando se publique, junto con el registro interno de áreas afectadas y soluciones provisionales.
  • Preparar la próxima vez. El mismo recuento recomienda activar alertas de estado de servicio hacia al menos una dirección de correo externa a Microsoft 365 y acordar de antemano un canal de comunicación alternativo, porque durante la caída el propio correo era el que fallaba.

El episodio vuelve a mostrar el costo de concentrar el correo, el calendario y la colaboración en un solo proveedor, una preocupación que ya había llevado a Dinamarca a ensayar alternativas de soberanía digital frente a Microsoft.

Fuentes

Ilustración generada por IA.

📬 Newsletter gratuito

Últimos artículos