Se detiene un centro de datos de Yandex en Kaluga: algunos servicios pueden no funcionar

Yandex advirtió el 9 de octubre de 2026 a sus usuarios de que parte de sus servicios puede no estar disponible debido a un incidente en el centro de datos de Kaluga. El servicio de prensa de la compañía se lo comunicó a Russian Business. Los servicios de emergencia trabajan en el lugar. Yandex no ha indicado la causa, el alcance de las consecuencias ni los plazos de recuperación.

En su titular, RB.RU describe la sede de Kaluga como «otro más» de los centros de datos de la compañía que han detenido su actividad. El comunicado no precisa qué ocurrió en el episodio anterior. Por eso, por ahora no se pueden comparar los incidentes ni buscar una relación entre ellos: no hay datos para hacerlo.

Qué se sabe hasta ahora

Los hechos confirmados son pocos y conviene separarlos con rigor.

• Fuente: el servicio de prensa de Yandex, citado a través de Russian Business
• Lugar: el centro de datos de la compañía en Kaluga
• Estado: actividad suspendida
• En la instalación: servicios de emergencia
• Impacto: parte de los servicios puede no estar disponible de forma temporal; no se indica cuáles
• No se ha revelado: la causa, si hay heridos ni una estimación de los plazos de recuperación

La mención a los servicios de emergencia apunta a un suceso físico, no a un fallo de software. El comunicado no permite saber de qué tipo. Podría ser un incendio, un problema de suministro eléctrico o algo distinto. Mientras la compañía no las confirme, las hipótesis siguen siendo conjeturas y no conviene sacar conclusiones de ellas.

En qué se diferencia un incidente físico de un fallo de software

Un error de software suele resolverse con una marcha atrás: se restaura la versión anterior, se reinician los nodos o se redirige el tráfico. Un suceso físico funciona de otra manera. Mientras los servicios de emergencia trabajan en la instalación, el acceso de los ingenieros a las salas está restringido. La alimentación o la refrigeración pueden cortarse de forma deliberada para evitar consecuencias peores. Después hay que revisar el equipo y ponerlo en marcha por fases, un proceso que lleva tiempo incluso cuando el hardware no ha sufrido daños.

Los grandes operadores incorporan estos riesgos a su arquitectura. Distribuyen los servicios entre varias sedes y, si una falla, desvían el tráfico a las demás. Pero la redundancia no funciona igual para todos los componentes. Los frontends y los servicios stateless se trasladan con rapidez. Los almacenamientos y las bases de datos son más complejos: necesitan replicación entre sedes, que puede ser síncrona o asíncrona, y de eso depende que el usuario note o no el fallo. Por eso la fórmula de Yandex, «parte de los servicios puede no estar disponible», es perfectamente esperable. Algunos productos superarán la caída de una sede sin que nadie lo note; otros no.

Qué vigilar a partir de ahora

Las próximas horas aclararán tres cosas.

• La lista de servicios afectados. Si el fallo afecta solo a productos concretos, significa que el resto se ha trasladado con éxito a otras sedes.
• La causa del incidente. Determinará si se trata de un episodio aislado o de un motivo para revisar los requisitos de seguridad física de las instalaciones.
• El plazo para que la sede vuelva a funcionar. Si hay que revisar o sustituir equipos, puede hablarse de días, no de horas.

También conviene esperar un análisis del propio Yandex. Para una gran empresa de infraestructura, un postmortem público con cronología y conclusiones suele importar más que las primeras declaraciones.

Pasos prácticos para usuarios y empresas

A los usuarios particulares les basta con esperar: reintentar el inicio de sesión o reiniciar las aplicaciones cambia poco si el problema está en la sede. Las empresas cuyos procesos de negocio dependen de los servicios de Yandex, incluida su plataforma en la nube, deberían hacer varias cosas.

• Consultar las páginas de estado y los canales oficiales de la compañía, en lugar de fiarse de los rumores en redes sociales
• Averiguar en qué zonas de disponibilidad están alojados sus recursos y si tienen una copia en otra zona
• No lanzar reinicios masivos ni reintentos agresivos de solicitudes: generan carga adicional durante la recuperación
• Comprobar que las copias de seguridad actualizadas están fuera de la sede afectada
• Preparar con antelación un mensaje para los clientes por si la interrupción se prolonga

Cualquier incidente en un centro de datos recuerda que la fiabilidad de un servicio depende de su creador, pero también de cómo el cliente haya construido su propia arquitectura. La multizona cuesta dinero, pero normalmente sale más barata que una parada del servicio.