Google finalmente explicó cómo una línea aleatoria de código paralizó medio Internet

La semana pasada, el Internet global entró en un estado de inestabilidad: servicios como Cloudflare, Spotify, Discord, Snapchat, Twitch y muchas otras aplicaciones comenzaron a fallar en masa. En el centro de la tormenta estaba la infraestructura de Google Cloud: el 13 de junio, durante casi tres horas, los clientes de todo el mundo perdieron el acceso a sus recursos en la nube. El incidente generó una gran conmoción no solo por su escala, sino también por el efecto en cascada que se extendió desde Google hacia los servicios que dependen de ella.

Ahora, la corporación ha publicado una explicación técnica oficial de lo sucedido. Como en varios grandes incidentes de los últimos años, la raíz del problema no fue un ciberataque ni una acción maliciosa externa, sino una error de programación en el sistema de gestión de cuotas. Y el fallo fue tan “elegantemente” encadenado que sus consecuencias afectaron múltiples capas de infraestructura, incluyendo los sistemas de comunicación y monitoreo.

Todo comenzó con una pequeña actualización: el 29 de mayo, el componente Service Control —un módulo clave que valida cuotas y políticas de acceso a las APIs en la nube— recibió soporte para una nueva lógica de control de recursos. Este componente es fundamental en la arquitectura de Google Cloud, ya que procesa solicitudes a través de instancias regionales distribuidas, asegurando el cumplimiento de cuotas, autenticación y políticas.

La novedad se implementó siguiendo el proceso habitual de despliegue progresivo por regiones, y todo parecía estar en orden. Sin embargo, había un matiz: el código modificado solo se activaba bajo ciertas condiciones —específicamente, cuando se aplicaba una política con una estructura de datos particular. Esa política no se activó durante las pruebas, por lo que el bloque de código problemático no se manifestó ni durante la implementación ni en los despliegues regionales. Simplemente permaneció latente, esperando un detonante.

Ese detonante llegó el 12 de junio, cuando una política incluyó campos vacíos. Esta estructura activó la ruta de ejecución del código inexplorado. El nuevo fragmento intentó acceder a datos inexistentes, lo que generó un error de null pointer. El resultado fue el bloqueo inmediato del binario responsable de Service Control y un bucle de reinicio continuo. El problema se reprodujo sincronizadamente en todas las regiones, ya que todas leían las mismas políticas y ejecutaban la misma secuencia.

Google confirmó que el código no estaba protegido por un feature flag —un mecanismo que permite desactivar nuevas funciones rápidamente en caso de problemas. Si ese flag hubiese existido, los ingenieros habrían podido aislar el fallo de inmediato. Pero no fue el caso. Además, el código carecía de manejo de errores, lo que hizo que el fallo fuera imposible de contener sin intervención manual.

El equipo de SRE de Google reaccionó con rapidez: el incidente fue detectado en dos minutos, la causa se identificó en unos 10 minutos y, en 40, ya se estaban aplicando acciones correctivas. Sin embargo, los problemas no terminaron ahí. En regiones grandes como us-central1, el reinicio de Service Control provocó una sobrecarga en otros sistemas. El mecanismo, diseñado para operaciones planificadas, no estaba preparado para un alud de solicitudes repetidas, lo que generó un efecto de “manada” (herd effect), donde múltiples procesos intentaban acceder simultáneamente a los mismos recursos.

Como Service Control es un sistema distribuido, la sobrecarga en zonas clave se propagó, complicando aún más la recuperación. En algunas regiones, el restablecimiento tardó casi tres horas. Al mismo tiempo, productos de Google que dependen de Service Control comenzaron a caer uno tras otro: Gmail, Drive, Meet, Calendar, Voice —todos sufrieron interrupciones de distinta magnitud. Clientes de Cloudflare, cuyos servicios como Workers KV usan Google Cloud, reportaron una tasa de fallos del 90 % en sus solicitudes.

Aunque para la tarde del 13 de junio la mayoría de sistemas estaban operativos nuevamente, las secuelas del incidente aún se están investigando. Google se comprometió no solo a evitar que esto vuelva a suceder, sino también a introducir cambios estructurales en el manejo del código de infraestructura. Entre ellos: mejorar los sistemas de comunicación, tanto automáticos como manuales, para que los clientes reciban información crítica de forma más rápida y clara.

Además, se extrajo una lección clave: la infraestructura de notificaciones y monitoreo debe estar aislada del resto del entorno en la nube, para seguir funcionando incluso en caso de una caída global.