Cuando la nube se cae: la avería de Microsoft 365 y qué debe extraer de ella un negocio

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 material. Dejaron de abrirse los buzones, los calendarios, Teams y SharePoint. Resultaron afectadas empresas de todo el mundo, entre ellas las 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, la posición oficial de Microsoft y, sobre todo, qué debe extraer de ello el dueño 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 lado, y el resultado fue claro.

• El inicio de sesión en la cuenta funciona. Microsoft reconoce al usuario y concede el acceso, de modo que ni la contraseña, ni los permisos, ni la configuración de acceso tienen nada que ver.
• La petición de mensajes devuelve un error del servidor — código 502. No «sin acceso», no «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 reside en Exchange Online.
• Los registros de correo del dominio (MX) no han cambiado y siguen apuntando a Microsoft. El correo se envía adonde debe.

La conclusión es sencilla: nuestro lado está intacto, quien no responde es el propio servicio. Esta misma comprobación debería hacerla cualquiera que tenga dudas: lleva unos minutos y despeja la mitad de las preguntas.

La cronología oficial

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

Las horas que siguen son de Kyiv.

• 18:17, 12 de noviembre. Los usuarios no pueden abrir los buzones. Microsoft comunica 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 una afluencia de tráfico. Parte de los servidores dejó de estar disponible de golpe y los demás asumieron su trabajo.
• 21:43. Se detecta que los servidores afectados no superan la comprobación automática de estado, y el propio sistema los retira del servicio.
• 21:57. «No hemos detectado ningún cambio reciente relacionado con el inicio del fallo».
• 00:00, 13 de noviembre. «El proceso principal en los servidores afectados se sobrecarga, con la consiguiente pérdida de capacidad».
• De madrugada. Precisión: lo que se sobrecarga es justamente el proceso responsable de establecer conexiones seguras. En paralelo, Microsoft empieza a revertir un cambio reciente de configuración de redque coincide en el tiempo con el inicio de la avería.
• 06:11. «Confirmamos: no hay indicio alguno de que esto sea consecuencia de acciones malintencionadas».
• 13:04. La recuperación se ha completado en Asia-Pacífico; el tráfico se admite de forma gradual y el trabajo se extiende a otras regiones.

La causa: aún sin nombrar

Lo más honesto que puede decirse en el momento de publicar esto: no hay causa oficial. Las explicaciones de Microsoft cambiaron a lo largo del día: de «no vemos ningún cambio reciente» a «estamos revirtiendo un cambio reciente de configuración de red que coincide con el inicio de la avería». La empresa promete publicar un análisis completo con la causa cuando termine la recuperación.

Lo que Microsoft afirma sin ambigüedad es que esto no es un ciberataque. Esa formulación se oyó dos veces, con unas horas de diferencia.

Lo más interesante 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 se les dejaba pasar tráfico. Microsoft admitió abiertamente que los cambios «no funcionan como se esperaba». Después vino el trabajo en círculo: detención de todas las actualizaciones y cambios de configuración, reinicios, un rodeo para la comprobación de estado, reconstrucción de parte de los servidores con la configuración anterior, adición de capacidad con máquinas virtuales. El avance llegó solo tras un parche en el componente responsable de la autorizació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 admite directamente en la descripción de la avería.
• La ventana de espera de un mensaje se ha ampliado a 48 horas. Normalmente, un servidor que no logra entregar un mensaje en cierto tiempo lo devuelve al remitente con marca de fallo. Una ventana ampliada significa que los mensajes no rebotarán, sino que esperarán en cola.
• Microsoft no ha informado de pérdida de datos. Pero conviene ser precisos: tampoco ha dicho literalmente «no se ha perdido nada». Lo dicho al pie de la letra es que los mensajes retenidos se conservan.

Consecuencia práctica: no reenvíe los mensajes. Están en cola y, cuando el servicio los suelte, el cliente recibirá duplicados. Prepárese para una avalancha: llegará de golpe todo lo de un día.

Qué debe hacer un negocio ahora mismo

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

Cuatro lecciones para el futuro

Una avería de esta magnitud es rara, y concluir de ella que «la nube es mala» sería erróneo: el servidor propio en un trastero se cae más a menudo y tarda más en volver. Las lecciones son otras.

1. El canal de reserva 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 proveedor, su fallo lo detiene a usted por completo. Un bot de Telegram, un mensajero corporativo, el teléfono: cualquier cosa que los clientes conozcan de antemano.
2. No ponga todo en la misma cesta. Correo, documentos, comunicación, autenticación y protección con un solo proveedor resulta cómodo justo hasta el día en que algo se le rompe. Entonces se detiene todo a la vez. Así ocurrió: junto con el correo cayeron Teams, SharePoint y Defender.
3. Lo que da dinero debe estar bajo su control. El sitio web, los pedidos, el catálogo, las solicitudes: conviene tenerlos donde usted mismo pueda comprobar el estado, levantar una copia y responder al cliente sin esperar el informe de otro.
4. Sepa distinguir «lo nuestro» de «lo suyo». La sencilla comprobación del principio de este artículo ahorra horas de pánico y evita cambios innecesarios en la configuración.

Cómo lo tenemos montado nosotros

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 funcionaba y funciona: los sitios sobre nuestro sistema Smart CMS, los chatbots, las áreas de cliente y la telefonía viven en servidores propios, separados del correo. Ni un solo sitio de cliente se vio afectado por esta avería.

Esa es precisamente la distribución del riesgo de la que hablan las lecciones: las herramientas de oficina, con 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 están tomadas de sus avisos en el centro de administración y en la página de estado del servicio, según el relato de observadores del sector, contrastados entre sí, porque ambas fuentes solo son accesibles para los administradores de cada cliente. La fuente primaria, para cada propietario, es su propio centro de administración.

---

Este material lo ha preparado el equipo de SmartGT. Si no está seguro de cuánto depende su negocio de un único proveedor y de qué le ocurriría a su sitio en un día así, escríbanos: center@uvc.in.net o +38 073 949 61 79. Lo miramos juntos y le decimos con franqueza qué conviene repartir en cestas distintas.