This content is currently only available in Spanish. English translation is on the roadmap — in the meantime, here's the original.
Exchange Online: cuando el chequeo de salud tumba el servicio
Lo que más me ha llamado la atención de la caída de Microsoft 365 no es que Outlook dejase de funcionar. Es la explicación. Según las actualizaciones de Microsoft, los servidores de Exchange Online empezaron a fallar las comprobaciones automáticas de salud, se retiraban del servicio y la carga caía sobre los que quedaban, que terminaban cayendo también.
Es decir, el sistema diseñado para apartar a los enfermos acabó vaciando la sala.
Qué ha pasado
El problema arrancó el 12 de noviembre y se siguió en el centro de administración con los incidentes EX1550543 (Exchange Online) y MO1550821 (impacto más amplio en Microsoft 365). Los usuarios afectados no podían acceder al buzón desde Outlook en la web, el Outlook de escritorio, ActiveSync o las conexiones REST, y el correo llegaba con retraso.
Microsoft dejó claro que no veía indicios de ciberataque y que la carga elevada no venía de un aumento de tráfico. Su investigación apuntaba a un componente concreto encargado de procesar la salud de los servidores. Parte de la recuperación consistió, precisamente, en devolver servidores al servicio usando otro método de comprobación y en reintroducir el tráfico poco a poco, región por región.
Hay un detalle que conviene decir: la explicación oficial fue cambiando sobre la marcha, y a fecha de hoy no hay informe post-incidente publicado. Microsoft lo ha prometido, con causa raíz incluida. Hasta entonces, cualquier versión definitiva es especulación, también la mía.
Mi lectura desde el lado de sistemas
Los health checks son una de esas piezas que montas una vez y olvidas. En un balanceador, en Kubernetes o en un simple script que reinicia un servicio, la lógica es la misma: si algo no responde bien, lo sacas. Funciona de maravilla cuando falla un nodo. El problema aparece cuando el fallo está en el propio chequeo, porque entonces todos los nodos parecen enfermos a la vez y el sistema se pone a apagar lo que estaba sano.
Mi postura, y sé que no es la más popular: a esta caída no la explica "la nube es frágil", sino la automatización sin freno. Un mecanismo que puede retirar servidores sin un límite de cuántos retira a la vez es una bala en la recámara. Si más de cierto porcentaje de la flota suspende el chequeo, lo razonable es sospechar del chequeo antes que de la flota.
El mejor argumento en contra lo entiendo: a la escala de Microsoft no puedes tener a una persona validando cada decisión, y un umbral mal puesto te deja servidores rotos sirviendo tráfico. También es verdad. Pero entre "todo manual" y "todo automático sin tope" hay bastante terreno, y ahí es donde se diseñan los sistemas que caen con elegancia.
Desde el soporte también hay lectura. Cuando cae el correo de toda una organización, lo primero que llega no es un ticket técnico, es la pregunta de "¿es mi ordenador?". Tener a mano el panel de estado de servicio y saber leerlo ahorra muchas reinstalaciones de Outlook inútiles.
Lo que me llevo
Para quien estudia IA o ingeniería, este incidente es un buen ejemplo de bucle de realimentación positiva en un sistema real: una acción local razonable que, repetida por todos los nodos a la vez, desestabiliza el conjunto. Me apetece leer el informe final para ver si confirman la hipótesis del componente de salud o si sale otra cosa.
Mientras tanto me quedo con una pregunta incómoda: ¿cuántos de nuestros scripts de "si falla, reinícialo" tienen un límite de cuántas veces, o de cuántas máquinas a la vez, pueden hacerlo?