Yandex bloquea parte de las funciones de 360 y Disk tras el ataque de un dron contra su tercer centro de datos

Yandex ha limitado parte de las funciones clave de la plataforma Yandex 360 y del almacenamiento en la nube Disk. El detonante fue el ataque de un dron contra el tercer centro de datos de la compañía. RBK informa de que la dirección tomó la decisión de forma urgente para proteger la infraestructura informática de una sobrecarga crítica. Los materiales disponibles no incluyen la lista de funciones desactivadas ni datos sobre daños físicos, por lo que parte de las conclusiones que siguen son todavía hipótesis de trabajo.

Qué se sabe hasta ahora

Hay pocos hechos y caben en una lista breve:

• Productos afectados: Yandex 360 (la plataforma de trabajo de la compañía) y el almacenamiento en la nube Disk.
• Naturaleza de las medidas: bloqueo de parte de las funciones clave, no desconexión completa de los servicios.
• Motivo: evitar una sobrecarga crítica de la infraestructura.
• Fuente: RBK, con la información recogida por Hi-Tech el 12 de octubre de 2026.
• Número del incidente: el titular habla del tercer centro de datos, lo que implica que no es un episodio aislado.

No se ha revelado cuánta capacidad se ha perdido, si la replicación de datos se ha visto interrumpida ni cuándo se levantarán las restricciones.

Por qué la sobrecarga puede ser tan peligrosa como el ataque

Cuando una parte de la capacidad deja de estar disponible, la carga se redistribuye entre los centros que siguen operativos. Mientras tanto, los clientes no se quedan quietos. Las aplicaciones reintentan las solicitudes fallidas, los clientes de escritorio de Disk intentan sincronizar archivos y los servicios de correo y ofimática golpean los mismos backends. Se produce una avalancha que puede derribar incluso nodos que no han sufrido daños.

Por eso los ingenieros recurren al load shedding: desactivan deliberadamente las funciones menos críticas y más costosas para mantener el funcionamiento básico. Lo habitual es sacrificar las operaciones pesadas en segundo plano, como la sincronización masiva, la generación de miniaturas, la indexación o la subida de grandes volúmenes de datos. Es una práctica común en el sector. En los materiales citados, la compañía no precisa qué opciones ha desactivado Yandex.

Para el almacenamiento, la situación es más delicada. Si se ha visto afectada una parte de las réplicas, el sistema dedica recursos a restaurar la redundancia de los datos, y cada solicitud adicional de un usuario resta recursos a la tarea más crítica: la integridad de los archivos. En ese régimen, la limitación de funciones parece más una medida de precaución para proteger los datos que una molestia para los usuarios.

Qué falta todavía para tener la imagen completa

Las preguntas principales siguen abiertas. ¿Cuántos centros y qué parte de la capacidad total han resultado afectados? ¿Se han visto afectados los servicios en la nube para clientes corporativos o solo los productos de consumo? ¿Dispone la compañía de regiones de reserva con capacidad suficiente para sustituir por completo a los centros dañados? Un tercer incidente consecutivo, si nos fiamos del titular, convierte la cuestión en un problema de diseño y deja de ser una avería puntual: la protección física y la distribución geográfica de los centros de datos pasan a ser parte de la arquitectura, igual que la redundancia de suministro eléctrico.

Conviene vigilar por separado cómo afectará la reducción de capacidad al resto de las cargas de la compañía, incluidos el servicio en la nube y los servicios de ML que comparten centros. No hay confirmación directa de ello, pero cuando escasea la capacidad de cómputo, las prioridades se reordenan de forma inevitable.

Qué deben hacer usuarios y empresas

Mientras Yandex no publique los detalles, lo razonable es aplicar medidas básicas de higiene:

• Haga una copia local o externa de los archivos críticos de Disk si la sincronización aún funciona. No lance una descarga masiva de todo: así añadiría carga al sistema.
• Compruebe qué procesos de negocio dependen de Yandex 360: calendario, correo, documentos compartidos. Prepare canales de comunicación alternativos para el equipo.
• Revise las condiciones del SLA y el procedimiento de compensaciones, si utiliza los servicios en un contrato corporativo.
• Siga los comunicados oficiales de la compañía: ellos determinarán cuándo y en qué orden volverán las funciones.

Para los responsables de TI, la lección es práctica: una dependencia única de la nube, sin un plan de degradación controlada, se convierte en un punto único de fallo, incluso si el proveedor tiene varios centros de datos.