Cuando se cae la nube: la avería de Microsoft 365 y qué sacar en claro

El 12 de noviembre, a las 18:17 hora de Kyiv, comenzó en Microsoft 365 una avería que continúa en el momento de publicar este artículo. Dejaron de abrirse los buzones de correo, los calendarios, Teams y SharePoint. Se vieron afectadas empresas de todo el mundo, también ucranianas, porque aquí la mayor parte del correo corporativo funciona sobre Microsoft 365.

Lo notamos en nuestro propio buzón y comprobamos qué se había roto exactamente. A continuación, los hechos que verificamos nosotros mismos, la posición oficial de Microsoft y, sobre todo, lo que debería sacar en claro cualquier propietario de un negocio, use o no Microsoft.

Qué es lo que no funciona

La primera reacción ante «el correo no se abre» es siempre la misma: la culpa es nuestra, de la contraseña, de internet, de la configuración del dominio. Por eso empezamos comprobando nuestro propio lado, y el resultado fue claro.

• El inicio de sesión funciona. Microsoft reconoce la cuenta y concede el acceso, así que ni la contraseña, ni los permisos, ni la configuración de acceso tienen nada que ver.
• La petición de los mensajes devuelve un error de servidor: código 502. No «acceso denegado», ni «contraseña incorrecta», sino «el servidor no pudo responder».
• El calendario falla igual: código 503. Es decir, no se trata solo del correo, sino de todo lo que vive en Exchange Online.
• Los registros de correo del dominio (MX) no se han modificado y siguen apuntando a Microsoft. El correo se envía exactamente adonde debe.

La conclusión es sencilla: nuestro lado está intacto, es el propio servicio el que no responde. Esta misma comprobación conviene que la haga cualquiera que tenga dudas: lleva unos minutos y resuelve la mitad de las preguntas.

Cronología oficial

Microsoft sigue la avería con dos números: EX1550543, el acceso a los buzones de Exchange Online, y MO1550821, todo lo que depende de Exchange. Una incidencia aparte de Teams (TM1550488) ya está cerrada. Al principio se hablaba de América; más tarde la formulación cambió a «puede afectar a usuarios de cualquier región».

Las horas que siguen son de Kyiv.

• 18:17 del 12 de noviembre. Los usuarios no pueden abrir sus buzones. Microsoft informa de que investiga un problema de acceso al correo.
• 20:19. Se registra una carga elevada en varias regiones a la vez.
• 21:18. Precisión: la carga creció no por un aumento del tráfico. Parte de los servidores dejó de estar disponible de repente y el resto asumió su trabajo.
• 21:43. Se comprueba que los servidores afectados no superan la comprobación automática de estado, y el sistema los retira de servicio por sí mismo.
• 21:57. «No hemos identificado ningún cambio reciente relacionado con el inicio del impacto».
• 00:00 del 13 de noviembre. «Un proceso central de los servidores afectados se está saturando, lo que provoca pérdida de capacidad».
• De madrugada. Nueva precisión: lo que se satura es justamente el proceso encargado de establecer conexiones seguras. En paralelo, Microsoft empieza a revertir un cambio reciente de configuración de red que coincide en el tiempo con el inicio de la avería.
• 06:11. «Confirmamos que no hay indicios de que esto sea resultado de actividad maliciosa».
• 13:04. La recuperación se completa en la región de Asia-Pacífico, el tráfico se restablece de forma gradual y el trabajo se extiende a otras regiones.

La causa: todavía sin nombre

Lo más honesto que puede decirse en el momento de publicar: no hay causa oficial. Las explicaciones de Microsoft fueron cambiando a lo largo del día, desde «no vemos ningún cambio reciente» hasta «estamos revirtiendo un cambio reciente de configuración de red que coincide con el inicio del impacto». La compañía promete publicar un informe completo con la causa una vez terminada la recuperación.

Hay algo que Microsoft afirma sin matices: no es un ciberataque. Esa formulación se repitió dos veces, con varias horas de diferencia.

Lo más instructivo de esta historia no es la causa, sino por qué se alargó la reparación. Los servidores devueltos al servicio volvían a caer en cuanto les llegaba tráfico. Microsoft reconoció abiertamente que los cambios «no están funcionando como se esperaba». Después vino el trabajo en círculo: todas las implantaciones y cambios de configuración detenidos, reinicios, un método alternativo de comprobación de estado, parte de los servidores reconstruidos con una configuración de software anterior, capacidad adicional mediante máquinas virtuales. El avance solo llegó tras un parche al componente responsable de la autenticación y el enrutado de las peticiones.

Qué ocurre con los mensajes

Es la pregunta que más preocupa, así que va aparte.

• La entrega se retrasa: Microsoft lo reconoce directamente en la descripción de la avería.
• La ventana de espera de los mensajes se ha ampliado a 48 horas. Normalmente, un servidor que no logra entregar un mensaje en cierto plazo lo devuelve al remitente como fallido. La ventana ampliada significa que los mensajes no rebotarán, sino que esperarán en cola.
• Microsoft no ha comunicado pérdida de datos. Pero conviene ser precisos: tampoco ha dicho explícitamente que no se haya perdido nada. Lo que dijo, literalmente, es que los mensajes retrasados se conservan.

Consecuencia práctica: no reenvíe los mensajes. Están en cola y, cuando el servicio se recupere, el destinatario recibirá duplicados. Prepárese más bien para una avalancha: llegará de golpe todo un día de correo.

Qué hacer ahora mismo

1. Asegúrese de que el problema no es suyo. Si el inicio de sesión funciona pero el correo no se abre, el fallo es del proveedor. El estado se ve en el centro de administración de Microsoft 365, apartado «Estado del servicio», incidencias EX1550543 y MO1550821.
2. No toque la configuración. Durante una avería ajena, el mayor daño lo causan los intentos de «arreglarlo» en casa: registros de dominio modificados, programas de correo reinstalados, contraseñas restablecidas. Cuando el servicio vuelva, tendrá que desenredar sus propias consecuencias.
3. Active un canal alternativo. Traslade los asuntos urgentes con clientes a una aplicación de mensajería o al teléfono mientras dure. Avise a quien espera respuesta: un breve «tenemos una avería de correo, escríbanos por Telegram» es mejor que el silencio.
4. Documente la parada. Si la interrupción le costó dinero, anote las horas y las consecuencias. Microsoft tiene compromisos de nivel de servicio; si esta avería le da derecho a una compensación en su caso concreto es una cuestión para su contrato de licencias y para el socio a través del cual las compró.

Cuatro conclusiones

Una avería de esta magnitud es rara, y concluir que «la nube es mala» sería un error: el servidor propio del cuarto trastero cae más a menudo y tarda más en volver. Las conclusiones son otras.

1. El canal alternativo debe existir antes de la avería, no inventarse durante ella. Si toda la comunicación con los clientes pasa por el correo de un único proveedor, su fallo le detiene por completo. Un bot de Telegram, una aplicación de mensajería corporativa, el teléfono: lo que sea, siempre que los clientes ya lo conozcan.
2. No lo ponga todo en la misma cesta. Correo, documentos, conversación, autenticación y protección en un solo proveedor resulta cómodo justo hasta el día en que algo se rompe allí. Entonces se detiene todo a la vez. Eso fue exactamente lo ocurrido: junto al correo cayeron Teams, SharePoint y Defender.
3. Lo que genera ingresos debe estar bajo su control. El sitio web, los pedidos, el catálogo y las solicitudes conviene tenerlos donde usted mismo pueda comprobar el estado, levantar una copia y responder a un cliente sin esperar el informe de otro.
4. Sepa distinguir «lo nuestro» de «lo suyo». La comprobación sencilla del principio de este artículo ahorra horas de nervios y evita cambios innecesarios en la configuración.

Cómo lo tenemos organizado

Usamos Microsoft 365 para el correo y los documentos, y durante esta avería nuestro buzón tampoco se abría. En cambio, lo que hacemos para los clientes siguió funcionando: los sitios web sobre nuestro propio Smart CMS, los chatbots, los paneles de cliente y la telefonía viven en servidores propios, separados del correo. Ni un solo sitio de cliente se vio afectado.

Ese es precisamente el reparto del riesgo del que hablan las conclusiones: las herramientas de oficina, en manos de un proveedor externo fiable; y lo que vende y recibe pedidos, allí donde respondemos nosotros mismos.

Sobre las fuentes

Las comprobaciones de acceso, de los registros de correo y de los códigos de respuesta las hicimos nosotros. La cronología y las citas de Microsoft proceden de sus avisos en el centro de administración y en la página de estado del servicio, en la versión de observadores del sector, contrastada entre sí, porque ambas fuentes solo están disponibles para los administradores de cada cliente. Para cada propietario, la fuente primaria es su propio centro de administración.

---

Si no está seguro de cuánto depende su negocio de un único proveedor ni de qué pasaría con su sitio web en un día así, escríbanos. Lo miramos juntos y le decimos con franqueza qué conviene repartir en cestas distintas. Y el estado del propio sitio puede comprobarlo gratis en tres minutos en audit.sgt.com.ua.