En mayo de 2024, miles de afiliados de UniSuper, un fondo de pensiones australiano, intentaron consultar sus cuentas y se encontraron fuera. La aplicación y los servicios en línea dejaron de estar disponibles durante días. En un fondo que administra ahorros para la jubilación, una pantalla inaccesible no se vive como una simple incidencia técnica: para el usuario, por unas horas, la pregunta es si su dinero sigue allí.
UniSuper y Google Cloud tuvieron que emitir una comunicación conjunta para explicar algo extraordinario. El entorno de nube privada del cliente, alojado sobre Google Cloud VMware Engine, había sido eliminado. No se trató de un ataque, ni de una cuenta robada, ni de una decisión tomada por el equipo del fondo. Google declaró que una secuencia de hechos no observada antes durante el aprovisionamiento había provocado una configuración incorrecta y la posterior eliminación automática de la suscripción privada de UniSuper.
La explicación técnica publicada después por Google es especialmente útil porque el incidente no nació en una gran arquitectura incomprensible. Durante la creación del entorno mediante una herramienta interna, un parámetro necesario para la duración de la suscripción quedó vacío. El sistema interpretó la instancia como si tuviera una duración definida. Cuando llegó la fecha asignada, eliminó el entorno. Una ausencia en un campo terminó teniendo más autoridad que la intención de conservar una plataforma productiva.
Hay una parte de la historia que desmonta una comodidad frecuente: UniSuper operaba en dos zonas geográficas de Google Cloud VMware Engine. Sobre el papel, eso protege frente a la caída de una zona. Pero ambas zonas pertenecían a la misma suscripción eliminada. La redundancia estaba dentro del perímetro que desapareció. Cuando el dominio de fallo es administrativo o lógico, duplicar máquinas dentro de él no proporciona la independencia que imaginábamos.
La recuperación fue posible porque UniSuper mantenía copias con otro proveedor. Esa decisión, que en un diagrama puede parecer costosa o exagerada, acabó siendo la salida cuando el proveedor principal perdió el entorno completo. Los servicios se restauraron de forma progresiva mientras los equipos verificaban datos y operaciones. Las cuentas de los afiliados no habían desaparecido, pero el acceso y los procesos necesitaban reconstruirse con cuidado.
La nube no falló aquí por falta de discos, de potencia o de dos zonas. Falló en una capa más difícil de ver: el control que decide cuánto debe existir una infraestructura. Para un ingeniero acostumbrado a revisar balanceadores, firewalls o bases de datos, el caso recuerda que los planos de control y los procesos de aprovisionamiento son también producción. Un valor vacío, una validación ausente o una eliminación demasiado automática pueden atravesar todas las capas que sí habíamos duplicado.
Esta no es una historia para concluir que la nube es insegura o que todo debe regresar a un rack propio. Sería demasiado sencillo. Es una historia para preguntar con precisión dónde viven los backups, qué credenciales y suscripciones pueden borrarlos, cuánto tardaría una recuperación real y quién puede detener una operación destructiva antes de que sea irreversible. Tener dos copias no basta si ambas obedecen al mismo botón.
El caso UniSuper permanece porque su impacto no fue abstracto. La infraestructura estaba lejos de la vista de los afiliados, pero la incertidumbre llegó directamente a sus ahorros. Detrás de una palabra tan limpia como “cloud” seguían existiendo parámetros, herramientas internas, decisiones humanas y una obligación sencilla: que los sistemas críticos continúen ahí cuando alguien los necesite.
Documentos y fuentes
Google Cloud, detalles del incidente de Google Cloud VMware Engine de UniSuper
UniSuper, comunicaciones sobre la interrupción y recuperación del servicio
iTnews, reconstrucción del parámetro vacío en el aprovisionamiento
Conversacion
Se el primero en comentar