Índice de contenidos
Claves de la noticia
- Yandex confirma que su centro de datos de Vladímir ha detenido completamente la actividad tras un ataque con drones, sin heridos.
- La nube opera en emergencia con las zonas ru-central1-a y ru-central1-b indisponibles, mientras mantiene capacidad de cómputo en d y e.
- Los avisos distinguen servicios operativos, limitados y caídos: recuperar una aplicación exige comprobar también sus dependencias.
Yandex ha confirmado este 11 de octubre la parada de su centro de datos de Vladímir, en Rusia, después de que un ataque con drones dañara su infraestructura. La empresa recomienda activar planes alternativos de recuperación. El incidente llega tras los daños en Sasovo y Kaluga y deja una consecuencia técnica concreta: tener recursos repartidos entre zonas no garantiza que una aplicación siga funcionando cuando fallan varias a la vez.
De los problemas eléctricos a la parada completa
El primer aviso de la madrugada consultado en el canal Yandex Cloud Alerts comunicaba problemas de alimentación en ru-central1-a. A las 02:10 UTC, las 04:10 en la España peninsular, un mensaje posterior atribuyó los daños de Vladímir a un ataque con drones y confirmó la suspensión completa del centro. La compañía señaló que no había heridos y que los servicios especializados trabajaban sobre el terreno.
Associated Press sitúa el ataque en una sucesión de tres golpes contra instalaciones de Yandex en cuatro días. La atribución del ataque a Ucrania procede de esa cobertura; la confirmación empresarial que hemos consultado describe los daños y la interrupción, sin identificar por sí misma al responsable. Conviene mantener ambas informaciones diferenciadas.
El antecedente corporativo está fechado el 9 de octubre. Yandex explicó entonces que Sasovo había quedado completamente cerrado tras el ataque de la noche del 7 al 8 y que parte de la infraestructura de Kaluga estaba fuera de servicio después del ataque del día 9. No ofreció una fecha de vuelta a la normalidad. El cierre de Vladímir constituye un hecho adicional, no una reedición de aquellos incidentes.
Una nube disponible por piezas
El balance operativo publicado por Yandex Cloud a las 02:59 UTC identifica dos zonas indisponibles, ru-central1-a y ru-central1-b. Al mismo tiempo, declara accesibles la consola y la API de gestión, y mantiene el servicio de cómputo en ru-central1-d y ru-central1-e. Es una fotografía del estado comunicado entonces, no una medición independiente ni una garantía de disponibilidad posterior.
| Componente | Situación indicada | Límite práctico |
|---|---|---|
| Compute | Disponible en d y e | No prueba que cada aplicación funcione |
| Bases de datos HA | La mayoría había conmutado | Parte en solo lectura o inaccesible |
| Almacenamiento S3 | Lectura disponible | Posibles problemas al escribir |
| Consola, API e IAM | Disponibles | Gestionar recursos no equivale a servir tráfico |
La conclusión de esta matriz es que el estado de una nube no se reduce a encendida o apagada. Una tienda podría disponer de servidores y, aun así, no completar pedidos si su base de datos solo admite lecturas. Es un ejemplo técnico derivado de las limitaciones publicadas, no la afirmación de que una tienda concreta haya sufrido ese fallo.
Tampoco se puede convertir la caída de dos zonas en un porcentaje de capacidad perdida. Los avisos no indican cuántos servidores, clientes o cargas alojaba cada una. Contar nombres de zonas resulta útil para entender la distribución del incidente, pero no permite medir su impacto económico o el volumen de datos afectado.
La IA y la seguridad no comparten un único estado
Un aviso específico de AI Studio de las 05:14 UTC declara disponibles las interfaces Responses y Chat Completions, mientras marca Retrieval, OCR, AliceAI Pro y SpeechSense como indisponibles. SpeechKit y Search presentan restricciones de modalidad. Que se pueda generar una respuesta de texto no demuestra, por tanto, que una aplicación capaz de consultar documentos o reconocer imágenes conserve todas sus funciones.
Un minuto después, el balance de seguridad distingue otro grupo de dependencias. IAM, KMS y Lockbox figuran disponibles; Smart Web Security y SmartCaptcha mantienen limitaciones para cambiar la configuración. Audit Trails, Yandex SIEM y Security Deck aparecen indisponibles en ese mensaje. Estos estados describen disponibilidad, no prueban una intrusión o una filtración de información.
Para un equipo que esté recuperando servicios, esa separación importa: poder autenticar usuarios y utilizar claves no significa conservar simultáneamente todas las herramientas de auditoría. La comprobación de recuperación necesita incluir la observabilidad y los controles que rodean a la aplicación, además de su respuesta al navegador.
Distribuir recursos también exige poder recuperarlos
La documentación de Yandex define las zonas como infraestructuras alojadas en centros de datos y distingue recursos ligados a una zona, como máquinas virtuales y discos, de otros globales, como redes y buckets. Recomienda desplegar aplicaciones en varias zonas para reducir el riesgo de interrupción y pérdida de datos. Esa recomendación describe una estrategia de diseño; no promete inmunidad frente a daños simultáneos.
Su guía de migración añade una dificultad que el simple reparto geográfico oculta: trasladar recursos puede requerir nuevas subredes, restauración mediante copias o instantáneas y cambios en grupos de destino de los balanceadores. También advierte que las direcciones IP públicas no se trasladan directamente entre zonas. Una copia de seguridad y un servidor disponible son condiciones útiles, pero no completan por sí solos la recuperación de la conectividad.
En esta emergencia, la empresa considera inestable la configuración restante y recomienda recurrir a planes alternativos, incluidas instalaciones externas. También avisa de comunicaciones de soporte irregulares y retrasos del panel de estado. La conclusión operativa es comprobar la cadena completa de la aplicación antes de darla por recuperada: cómputo, datos, escritura, conectividad y controles. Los comunicados no permiten fijar un plazo de recuperación ni afirmar que se hayan perdido datos.
Imagen conceptual generada para Tecnología Today; no representa el centro de Vladímir ni los daños del ataque.
