Introducción
Entre el 8 y el 11 de octubre de 2026, Yandex perdió tres centros de datos en cuatro días. El resultado: 84 servicios de Yandex Cloud declarados fuera de línea, un tráfico de red desplomado al 0,4 % de su nivel habitual según Cloudflare Radar, y una plataforma que se vio obligada a activar lo que ella misma denominó un «modo de emergencia». El incidente, sin precedentes a esta escala para un proveedor cloud de primer nivel, ofrece una lección de arquitectura que ningún CIO ni responsable de infraestructura puede permitirse ignorar.
La geografía del desastre
Los tres centros afectados se ubican en regiones distintas alrededor de Moscú: Sasovo (región de Riazán), Kaluga y Vladímir. Cada uno alojaba componentes críticos de la infraestructura de Yandex Cloud. El datacenter de Sasovo concentraba dos de los tres supercomputadores destinados a los proyectos de inteligencia artificial de la compañía; su caída supuso la pérdida inmediata de una capacidad de cómputo considerable. Kaluga fue desactivado parcialmente al día siguiente, antes de que Vladímir quedara completamente fuera de servicio el 11 de octubre.
La plataforma no se limitó a ralentizarse: colapsó. Los servicios Yandex Disk y Yandex Documents, junto con aplicaciones de terceros alojadas en Yandex Cloud, quedaron inaccesibles. La compañía reconoció que «la configuración de infraestructura restante se considera inestable».
Lo que revela el fallo en cascada
Un proveedor cloud de este tamaño debería, en teoría, absorber la pérdida de uno o dos sitios gracias a mecanismos de conmutación automática. No fue lo que ocurrió. Varios factores explican la magnitud del incidente.
En primer lugar, la concentración geográfica: cuando los centros de datos se ubican en un radio regional reducido, una perturbación simultánea en esa zona anula por completo el efecto de la redundancia. El «multi-site» solo protege realmente si los nodos están suficientemente distantes e independientes, tanto en alimentación eléctrica como en conectividad de red y condiciones físicas.
En segundo lugar, la velocidad de propagación de los fallos: perder un sitio puede generar una sobrecarga en los nodos supervivientes, que terminan cediendo a su vez. Es exactamente el escenario que describe la activación del modo de emergencia: el sistema no conmutó de forma ordenada, sino que colapsó de manera progresiva.
Por último, la dependencia de servicios de terceros: organizaciones que no gestionan su propia infraestructura quedaron sin servicio sin ningún control sobre la situación ni palanca de remediación inmediata.
Las preguntas que todo CIO debería hacerse
El incidente no plantea únicamente una cuestión geopolítica. Formula interrogantes de arquitectura concretos a cualquier organización que dependa de un proveedor cloud:
- ¿Cuál es la distribución geográfica real de las zonas de disponibilidad en las que residen sus cargas críticas? ¿Son verdaderamente independientes, o simplemente se encuentran en edificios distintos del mismo campus?
- ¿Se ha probado su plan de recuperación ante desastres (DRP) en un escenario de pérdida simultánea de varias zonas, y no solo de un único nodo?
- ¿Están documentadas sus dependencias con servicios gestionados? ¿Sabe con exactitud qué servicios de terceros alimentan sus aplicaciones y en qué región están alojados?
- La concentración en un único proveedor o en una sola geografía equivale a asumir que su fragilidad estructural se convierte en la suya propia, independientemente de la causa del incidente.
Revisar la arquitectura antes de que el evento la revele
Las caídas masivas siempre evidencian las mismas carencias: una redundancia teórica que nunca se ha puesto a prueba, planes de conmutación diseñados para un único escenario de fallo, y un mapa de dependencias incompleto. El incidente de Yandex dejó al descubierto en pocas horas lo que años de decisiones de arquitectura habrían debido prevenir. Para los equipos de infraestructura, es la oportunidad de revisar sus esquemas de resiliencia antes de que sea su propia plataforma la que sirva de ejemplo.