Introducción
El 12 de junio de 2025 pasará a la historia como uno de los días más críticos para los servicios en la nube a nivel global. Una serie de fallos en los sistemas internos de Google Cloud provocaron una caída masiva que afectó a decenas de productos, desde Google Cloud Storage, BigQuery y App Engine, hasta herramientas de inteligencia artificial como Vertex AI y sistemas de seguridad como IAM. Lo más sorprendente: todo comenzó con un puntero nulo (pointer null).
En este artículo analizaremos en detalle qué ocurrió, cómo se propagó el fallo, qué errores de arquitectura se hicieron evidentes y qué lecciones nos deja esta caída masiva.
¿Qué ocurrió realmente?
Según el informe oficial publicado por Google el 13 de junio, la cadena de eventos se inició con una actualización del sistema Service Control, un componente esencial en la gestión de políticas y cuotas para las API de Google Cloud. Esta actualización introdujo un nuevo chequeo de políticas que requería cambios en las tablas de Spanner distribuidas por región.
A pesar de que el nuevo código fue desplegado gradualmente, su ejecución dependía de que se activara una política específica. Esa política, finalmente activada el 12 de junio, contenía campos en blanco que dispararon un error de puntero nulo (null pointer exception). Este error provocó que el binario de Service Control fallara repetidamente (crash loop), afectando a todas las regiones donde la política fue replicada.
Impacto global
La falla afectó múltiples regiones en América, Europa, Asia y Oceanía. Entre los servicios impactados se incluyen:
- Google Cloud APIs
- Google Workspace (Gmail, Drive, etc.)
- Google App Engine
- Google Cloud Storage
- IAM (gestión de identidades)
- BigQuery
- Cloud Logging
- Vertex AI
- reCAPTCHA Enterprise
- Pub/Sub, Cloud SQL, y muchos más
Miles de empresas quedaron momentáneamente sin acceso a sus recursos, y muchas no podían monitorear sus propios sistemas debido a que el mismo sistema de salud de Google Cloud también se encontraba fuera de servicio.
Análisis técnico: ¿cómo un puntero nulo colapsa el mundo?
El origen del problema es un patrón clásico en desarrollo de software: el manejo inapropiado de datos nulos. En concreto:
- Una política con campos en blanco fue replicada globalmente.
- El código que validaba esa política no tenía control de errores suficiente.
- Al ejecutar el chequeo de cuota, el sistema intentó acceder a un campo no inicializado → crash.
- Como el error no estaba contenido, el binario completo fallaba en bucle.
- Cada instancia del servicio entró en modo de error catastrófico en cascada, replicado en todas las regiones.
Este escenario revela una serie de deficiencias estructurales:
- La actualización crítica no estaba protegida con feature flags (banderas de características).
- No había pruebas de staging que simularan entradas con campos nulos.
- No existía un mecanismo de fail-open que permitiera continuar el servicio en caso de error.
- La replicación global de datos fue demasiado rápida y sin validación regional previa.
- No se implementó exponential backoff para prevenir sobrecarga al intentar reiniciar.
Respuesta y recuperación
El equipo de ingeniería de fiabilidad de Google (SRE) tardó apenas 2 minutos en iniciar la evaluación del incidente. En menos de 10 minutos se identificó la causa raíz y se activó un “red-button” (interruptor global de desactivación de la nueva funcionalidad). A pesar de ello, la recuperación total tardó más de 2 horas en regiones grandes como us-central1, debido a sobrecarga de las infraestructuras subyacentes (como Spanner) al reiniciar en masa.
Lecciones para la industria
Este incidente no solo representa una falla puntual de Google, sino también una lección para toda la comunidad tecnológica:
1. Nunca subestimes un null
Un campo vacío puede parecer inofensivo, pero en sistemas distribuidos puede causar efectos dominó globales. Validar datos antes de replicarlos es fundamental.
2. Usa feature flags
Toda funcionalidad nueva debe estar controlada por feature flags que permitan activarla de forma segura y reversible.
3. Pruebas con datos reales e inesperados
El caso demuestra que probar solo caminos felices (happy paths) no es suficiente. Se deben testear escenarios inesperados, como campos vacíos, valores extremos y errores de conectividad.
4. Fail open antes que fail safe
En sistemas críticos, si una validación falla, a veces es mejor continuar sirviendo tráfico de forma limitada que bloquear todo el sistema.
5. Infraestructura de monitoreo resiliente
Si tu sistema de monitoreo cae junto con la aplicación, quedas ciego. Debe haber canales independientes que te permitan detectar y comunicar el estado de salud del sistema.
Conclusión
La caída del 12 de junio de 2025 fue una llamada de atención para toda la industria tecnológica. Incluso empresas del tamaño de Google pueden tropezar con errores aparentemente simples. Sin embargo, también es una muestra de cómo una cultura de post-mortems abiertos, transparencia y aprendizaje continuo puede ayudar a prevenir incidentes futuros.
Hoy más que nunca, debemos construir sistemas pensando en el fallo como una certeza, no como una excepción.
