Yandex Cloud permanece interrumpido tras el ataque de dron que cierra el centro de datos de Vladimir
Yandex Cloud permaneció en operación limitada el lunes 12 de octubre, después de que un ataque de dron dañara el centro de datos de la compañía en Vladimir, Rusia, y obligara al sitio a suspender operaciones. La última interrupción siguió al daño a otras dos instalaciones de Yandex a principios de la semana, sumando dificultades para negocios y usuarios dependientes de la infraestructura de la empresa.
La BBC informó que un ataque de dron ucraniano golpeó la instalación de Vladimir, al este de Moscú, durante la noche del domingo. Yandex dijo que las operaciones en el sitio habían sido completamente suspendidas y que nadie había resultado herido. La empresa estaba trabajando para restaurar la conectividad, pero algunos servicios seguían sin estar disponibles.
Los servicios en la nube operan de manera irregular
En su última actualización de estado de Yandex Cloud, publicada a las 08:17 UTC del 12 de octubre, el operador indicó que su plataforma seguía funcionando en modo limitado. El trabajo de restauración se continuaba las 24 horas, mientras que un mayor volumen de solicitudes de soporte podría significar tiempos de respuesta más largos. Continuó recomendando plataformas alternativas para alojar recursos y proporcionar redundancia.
Eso no es una señal de todo claro. La actualización no dio un tiempo para la restauración completa. Yandex dijo que su próxima actualización de estado se publicaría a las 19:00 hora de Moscú, equivalente a las 16:00 UTC; ese aviso programado no debe confundirse con una promesa de que los servicios se recuperarían para entonces.
Las actualizaciones del operador del domingo mostraron una imagen mixta en lugar de un cierre uniforme. En un resumen a las 08:14 UTC, Yandex dijo que su consola y las interfaces de programación de aplicaciones estaban disponibles, mientras que los recursos de computación solo estaban parcialmente disponibles. El almacenamiento de objetos admitía lecturas y escrituras, pero podría ser más lento. Los servicios de Kubernetes estaban disponibles con posibles problemas en clústeres individuales, y persistían las dificultades con su servicio gestionado de Apache Kafka. Yandex también dijo que los aumentos en las cuotas para recursos de nube adicionales seguían suspendidos.
Estas actualizaciones a nivel de componentes describen las condiciones en los tiempos indicados. No establecen que cada aplicación cliente que utilice esos componentes se haya recuperado, o que todas las cargas de trabajo enfrentaran el mismo nivel de interrupción.
Los efectos se extienden más allá de los clientes de la nube
El informe del 12 de octubre de The Record describió la interrupción extendiéndose a pagos, entregas y otros servicios en línea, junto con Yandex Cloud. Informó problemas que involucraban correo electrónico, reservas de taxis, pedidos de comida y algunas funciones de hogar conectado, así como negocios de terceros que utilizan la infraestructura de Yandex. La magnitud completa de la interrupción seguía sin estar clara, y Yandex no había revelado cuántos clientes de la nube se vieron afectados.
El incidente de Vladimir se produjo después de ataques a la instalación de Yandex en Sasovo, en la región de Ryazan, el 8 de octubre, y su instalación en Kaluga el 9 de octubre. Esas interrupciones anteriores forman el contexto para la última falla; no significan que todos los productos de Yandex estén completamente fuera de línea o que los usuarios en todas las regiones estén experimentando problemas idénticos.
El aviso del domingo de Yandex describió la configuración de recursos restante como inestable y instó a los clientes a considerar otros planes de recuperación ante desastres. Para las empresas dependientes, el problema inmediato es si sus propios servicios pueden operar, no simplemente si una consola de gestión en la nube es accesible. Un panel restaurado y un servicio al cliente plenamente funcional son hitos de recuperación diferentes.
La restauración continúa en progreso
Según la actualización del operador de la mañana del lunes, el estado apropiado era operación limitada con restauración en curso, no completamente restaurado. La causa reportada fue daño físico a la infraestructura tras un ataque de dron; las fuentes revisadas no describieron este evento como un incidente de ransomware o intrusión de software.
Sigue las señales de servicio actuales a través de el panel en tiempo real de Status Is Down y navega por el archivo de noticias para otras interrupciones verificadas. Los propietarios de sitios web pueden explorar los planes de Status Is Down y crear una cuenta para seguir los servicios de los que dependen sus operaciones.
Crédito de la imagen: ID 76688877 © Ralwel | Dreamstime.com