Drones dejan fuera de servicio el tercer centro de datos de Yandex, en Vladímir

Los drones han atacado el tercer centro de datos de Yandex, esta vez en Vladímir. Según CNews, la instalación ha quedado completamente fuera de servicio. La compañía tiene cinco centros de datos en total, de modo que tres de ellos, más de la mitad de la infraestructura, han sufrido daños físicos. El día anterior se añadió al acuerdo de usuario de los servicios de Yandex una cláusula por la que la empresa no responde ante los clientes por los servicios que no funcionen a causa de ataques con drones.

Qué se sabe hasta ahora

La fuente aporta pocos detalles, y conviene tenerlo presente. El mensaje no incluye confirmaciones públicas de la magnitud del daño, de los plazos de recuperación ni de qué servicios se han visto afectados. La expresión «completamente fuera de servicio» es del medio, no de la documentación técnica del operador. Por eso, a continuación figura solo lo que puede darse por establecido según CNews:

• Instalación: centro de datos de Yandex en Vladímir.
• Estado: completamente fuera de servicio.
• Total de centros de datos de la compañía: 5.
• Afectados ya por ataques: 3.
• Cambio en los términos del servicio: se ha añadido una cláusula que exime de responsabilidad por las caídas de los servicios en caso de ataques con drones.

El artículo no revela las fechas ni la ubicación de los dos ataques anteriores. Tampoco se sabe qué servicios funcionaban en la instalación de Vladímir, y de ello depende que los usuarios llegaran siquiera a notar la caída.

La cláusula del acuerdo como señal

La enmienda al acuerdo de usuario es más interesante que el ataque en sí. Casi cualquier servicio en la nube o de internet incluye cláusulas de fuerza mayor: fenómenos naturales, cortes de electricidad, actos de terceros. Pero la mención explícita de los drones indica que la compañía considera estos episodios no un riesgo puntual, sino un factor recurrente. Los abogados redactan este tipo de cláusulas cuando la probabilidad del suceso deja de ser teórica.

Para el usuario común de Yandex esto apenas cambia nada: el correo, los mapas y el buscador ya no contemplaban de por sí una compensación económica por las caídas. Para las empresas el panorama es distinto. Si una compañía construye su producto sobre Yandex Cloud u otros servicios de plataforma y cuenta con un SLA con penalizaciones, la referencia a los ataques con drones puede hacer que esas penalizaciones resulten inalcanzables. Los detalles dependen de cada contrato: el acuerdo de usuario y las condiciones corporativas no siempre coinciden, y conviene comprobarlo.

Por qué un centro de datos es tan vulnerable

Un centro de datos es una instalación grande, estacionaria y de dirección conocida. Necesita un suministro eléctrico potente, refrigeración y canales de comunicación, y cada uno de esos elementos puede dejarse fuera de servicio sin un impacto directo en las salas de servidores. La tolerancia a fallos se basa en la redundancia geográfica: los datos y la carga se duplican entre instalaciones. Cuando tres de cinco instalaciones no están disponibles, el margen de seguridad se reduce a dos. Incluso con una buena replicación, aumentan la carga sobre la capacidad restante, el riesgo de degradación y el tiempo de recuperación tras el siguiente incidente.

Hay también un aspecto de ingeniería. Trasladar la carga desde una instalación perdida exige recursos de cómputo y almacenamiento libres, y con la escasez de servidores y las restricciones al suministro de equipos no son infinitos. Reemplazar rápidamente y con el mismo volumen la capacidad perdida resulta difícil.

Qué deben hacer los equipos que dependen de Yandex

Lo primero es leer la versión vigente del acuerdo y del contrato corporativo: qué dicen exactamente sobre fuerza mayor y compensaciones. Después, revisar la arquitectura. Los datos críticos y las copias de seguridad deben estar al menos en dos ubicaciones geográficas independientes y, mejor aún, también con otro proveedor.

Los scripts de conmutación hay que probarlos con regularidad en la práctica, no limitarse a tenerlos como documento. Para un negocio al que una caída le cuesta dinero, conviene calcular de antemano el tiempo de recuperación admisible (RTO) y el volumen de pérdida de datos admisible (RPO), y compararlos con sinceridad con lo que el proveedor puede garantizar de verdad. Si la brecha es grande, un esquema multinube saldrá más barato que una sola mala semana sin servicio.