Informe de incidente de Google Cloud – 2025-06-13

• El 12 de junio de 2025, los errores 503 en solicitudes a APIs externas aumentaron a nivel mundial en los servicios de Google Cloud y Google Workspace
• La causa del error fue un cambio de código en el sistema Service Control y la aplicación de una política incorrecta que incluía campos vacíos en los datos de políticas
• La falta de manejo de errores en el binario principal y la ausencia de aplicación de feature flags ampliaron la propagación del problema
• La recuperación tomó de 2 a 3 horas, y la región us-central-1 tuvo un tiempo de recuperación mayor debido a sobrecarga de infraestructura
• Google anunció medidas para evitar recurrencias, como separación de arquitectura, mejoras en el manejo de errores y refuerzo de la validación de datos

---

Resumen general del incidente

Resumen de la interrupción de servicios de Google Cloud y Google Workspace

• Desde las 10:49 a. m. (PDT) del 12 de junio de 2025, se produjo un fuerte aumento de errores 503 en solicitudes a APIs externas en varios servicios, incluidos Google Cloud, Google Workspace y Google Security Operations
• Google expresó sus más sinceras disculpas por el grave impacto que esto tuvo en los servicios y la confianza de los clientes
• El plano de administración y control de APIs de Google se encarga de las verificaciones de políticas y cuotas de cada solicitud, y el sistema central de verificación funciona como un binario llamado Service Control

Análisis de la causa del incidente

Estructura modificada del sistema – Service Control

• El 29 de mayo de 2025, se agregó a Service Control una nueva función para reforzar la validación de políticas de cuota
• Aunque el despliegue se realizó de forma gradual por región, el código problemático solo se ejecutaba cuando la política se aplicaba realmente, por lo que no se activó antes y las pruebas previas fueron insuficientes
• En la ruta de esta nueva función faltaban un manejo de errores adecuado y feature flags, lo que provocó fallas en cascada del binario ante una situación de null pointer

Cómo ocurrió el incidente

• A las 10:45 a. m. (PDT) del 12 de junio de 2025, se insertó un cambio de política en una tabla Regional Spanner
• Estos datos de política incluían un campo vacío (Blank Field) no intencional, que se replicó globalmente casi en tiempo real
• Cuando Service Control procesó esta política, se produjo una falla por null pointer, y las instancias de cada región entraron globalmente en un crash loop
• El equipo de SRE comenzó a detectarlo en 2 minutos, identificó la causa en menos de 10 minutos y bloqueó temporalmente la ruta del binario (red-button); la mayoría de las regiones se recuperaron en 40 minutos

Problemas adicionales en la recuperación

• Algunas regiones grandes, como us-central-1, sufrieron sobrecarga de infraestructura (tablas de Spanner) por un herd effect al reiniciar las tareas de Service Control
• Como Service Control no aplicaba randomized exponential backoff, la carga sobre la infraestructura aumentó aún más
• En esa región, la recuperación se retrasó hasta 2 horas y 40 minutos; el impacto se minimizó mediante desvío de tráfico, y finalmente se completó la restauración total del servicio

Impacto en clientes y alcance del incidente

• Los clientes experimentaron fallas de acceso a APIs e interfaces de usuario, mientras que los servicios de streaming y los recursos IaaS no se vieron afectados
• El impacto por latencia y backlog continuó durante más de 1 hora en algunos servicios
• Se presentó una lista amplia de productos de Google Cloud y Google Workspace afectados por el incidente
  • Ejemplos: IAM, Cloud Build, Cloud Storage, BigQuery, AppSheet, Gmail, Google Drive y decenas de servicios más

Medidas de mejora a futuro

• Modularizar la arquitectura del servicio para separar funciones e introducir procesamiento abierto ante fallas (fail open) cuando ocurra un incidente
• Propagación gradual de la replicación global de datos y fortalecimiento del proceso de validación real
• Reforma de la política para aplicar feature flags y desactivación por defecto a todos los cambios importantes en binarios
• Revisión del diseño para permitir fail open durante incidentes mediante mejoras en análisis estático y pruebas para detectar errores
• Implementación prevista de políticas de randomized exponential backoff y fortalecimiento de la confiabilidad del monitoreo y la comunicación
• Refuerzo de la redundancia de infraestructura y automatización de comunicaciones para que, incluso en situaciones de incidente, sea posible ofrecer a los clientes monitoreo e información de forma rápida

Avisos del incidente y comunicación

• Aunque se publicó un aviso en Cloud Service Health dentro de la primera hora tras el incidente, la propia infraestructura de monitoreo también sufrió fallas
• Algunos clientes tuvieron dificultades para identificar señales e impacto del incidente porque sus sistemas de monitoreo basados en Google Cloud no funcionaban con normalidad
• Google prometió fortalecer en el futuro la infraestructura de monitoreo y comunicación hacia clientes

Línea de tiempo principal del incidente (resumen de mini reporte)

• Inicio del incidente: 12 de junio de 2025, 10:49 (PDT)
• Recuperación de la mayoría de las regiones: 12 de junio de 2025, 12:48 (PDT)
• Fin del incidente: 12 de junio de 2025, 13:49 (PDT)
• Duración total: aproximadamente 3 horas
• Región afectada: global

Resumen de medidas posteriores

• Está previsto incorporar mecanismos de prevención de fallas ante errores o corrupción de datos en la plataforma de gestión de APIs
• Refuerzo de validación, pruebas y monitoreo antes de la propagación de metadatos globales
• Ampliación del manejo de errores del sistema y de las pruebas integrales frente a datos no válidos

Lista de servicios afectados (extracto)

Principales servicios de Google Cloud

• Identity and Access Management, Cloud Build, Google Cloud Storage, Cloud Monitoring, BigQuery, Vertex Gemini API, Cloud Firestore, Looker, Cloud Run, Compute Engine, entre otros

Principales servicios de Google Workspace

• AppSheet, Gmail, Google Drive, Google Meet, Docs, Chat, Calendar, entre otros

Conclusión

• Este incidente fue resultado de una combinación de problemas en la estructura del sistema de gestión de políticas/cuotas, la falta de validación de integridad de datos y la ausencia de un esquema adecuado de manejo de errores
• Google se comprometió a realizar mejoras a nivel de arquitectura y a reforzar su capacidad de respuesta ante incidentes

[kunggom]

Este es el enlace a la versión del artículo que no es GN+.

• https://es.news.hada.io/topic?id=21447

[GN⁺]

Comentarios de Hacker News

• Hablo como alguien interno y estoy usando una cuenta temporal; la causa raíz de este incidente fue que el liderazgo ignoró los principios para ir más rápido, y esta práctica continuó durante años hasta llegar finalmente a su límite; el “query of death” que ocurrió esta vez es un tipo de falla típico e inevitable en servidores viejos de C++ que se caen por una consulta específica; Service Control está escrito en C++ y se intentó minimizar este tipo de fallas usando varias guías de ingeniería; operó durante 10 años sin incidentes graves, pero el problema fue una política global de cuotas hecha apresuradamente bajo presión del liderazgo; una función nueva así debería haberse desarrollado como un servicio aparte o, al menos, haber seguido las guías existentes; el estándar que el equipo solía mantener es mucho más alto que las medidas mencionadas en el informe oficial; el equipo sigue intentando mantener esos estándares previos en la medida de lo posible

  • No se puede echar toda la culpa solo al liderazgo; no evaluar con extremo cuidado un despliegue con alcance global total es una falla de la cultura de ingeniería; como mínimo, la política global debería haberse implementado antes que el despliegue regional de service control

• Me parece interesante el informe del incidente; el equipo de SRE respondió rápido en 2 minutos y comenzó el rollout del “red button”; el problema fue que, cuando las tareas de Service Control se reiniciaron en una región grande como us-central-1, apareció un “herd effect” que sobrecargó la infraestructura (la tabla de Spanner); como Service Control no tenía implementado backoff exponencial aleatorio, la recuperación completa se retrasó hasta 2 horas y 40 minutos; en una situación así, las cuotas normales se agotan rápido y eso lleva a nuevas fallas; en estos casos, si la infraestructura lo soporta, me parece bien desactivar temporalmente las cuotas o limitar lentamente las tareas de recuperación

  • En esta situación, el backoff exponencial no era la medida adecuada; al leer datos críticos durante el arranque del servidor, eso se procesa intencionalmente sin reintentos, así que no se aplica backoff; una mejor opción es distribuir rápidamente la carga al respaldo de base de datos que ya existe; también hay otras formas

• Esto de verdad parece un error muy amateur; NPE, sin manejo de errores, sin backoff exponencial, sin cobertura de pruebas, sin pruebas en staging, sin rollout gradual, todo eso son fallas graves; todo eso ya aparece en el libro de SRE índice de Google SRE Book, Building Secure and Reliable Systems TOC; me pregunto si el estándar bajó demasiado o si el libro era solo marketing

  • En mi opinión, no existe la perfección en las defensas, ya sean humanas o automatizadas, y al final todo es una sucesión de trade-offs; por más unit tests, pruebas de integración, análisis estático y despliegues secuenciales que hagas, cuando la escala crece inevitablemente aparecen huecos inesperados; es la misma razón de lo que dice el libro sobre “el esfuerzo mucho mayor que requiere agregar otro 9”; en el peor caso, quizá habría que duplicar todo el stack y reproducir varios meses completos de tráfico, pero nadie puede asumir un costo/beneficio de ese nivel; en trabajo con OpenZFS también vi casos donde el código en sí parecía correcto, pero el problema apareció en un edge case de datos escrito hace 10 años; cuando el sistema se vuelve lo bastante complejo, probar todas las variantes es imposible, así que en la práctica solo se puede decidir según la utilidad frente al costo; por cierto, soy SRE de Google pero de un equipo no relacionado con este incidente, y esta es mi opinión personal

  • Casi todas las caídas globales de Google se desarrollan de forma parecida: un sistema personalizado desplegado rápidamente a nivel global recibe una configuración errónea; en rollouts binarios o pushes de configuración normales, lo usual es que se aplique rollout gradual; incluso en Google Cloud antes varios sistemas estaban atados globalmente, pero ahora están bastante más regionalizados y son más confiables; antes también había caídas globales con frecuencia, pero no se hacían públicas y la mayoría de usuarios pensaba que era un problema de su ISP; no creo que la situación esté empeorando en particular; además, también tengo experiencia en SRE

  • Visto desde afuera, después de los grandes recortes y del comentario del CEO sobre la “pereza”, todo quedó más enfocado en la velocidad y en resultados visibles que en la calidad; poco a poco surgió un entorno donde, si señalas problemas de esa cultura, terminas siendo apartado

  • Ojalá se publicara información más detallada; yo no creo que, como se menciona aquí, no se haya probado en absoluto, sino que faltó una prueba para el campo vacío de la política, es decir, la entrada problemática; tampoco veo que se diga que no hubo pruebas en staging, sino que se menciona que con un flag probablemente se habría detectado; es una opinión personal

  • Me recordó un informe de un polvorín de 1864: “Hasta la herramienta más peligrosa, cuando uno se acostumbra a ella, hace que se pierda la cautela y se piense que las directrices son innecesariamente estrictas”

• Soy de otro equipo dentro de Cloud; en general, todo el código tiene pruebas unitarias y de integración; los cambios binarios o de configuración se hacen de forma gradual por tarea y por región durante varios días, acompañados de análisis canary; incluso los rollbacks se hacen despacio porque si se hacen demasiado rápido pueden empeorar la situación; por ejemplo, se puede considerar que 40 minutos de caída son preferibles a 4 horas de interrupción si eso evita sobrecargar una base de datos global de una sola vez; no participé directamente en este incidente, pero por el PM parece que el código sí fue probado y lo que faltó fue este edge case; el problema fue que la configuración de la política de cuotas no se aplicó como binario ni como archivo de configuración, sino como actualización de base de datos, y el cambio se propagó a todas las bases de datos del mundo en segundos; el problema del puntero nulo podría haber ocurrido también en otros lenguajes mediante assert(); en vez del riesgo de reescribir un servicio tan crítico en otro lenguaje, parece más razonable poner flag guards a todas las validaciones de políticas, hacer que las validaciones de política de cuotas fallen en abierto, y propagar los cambios de DB lentamente por región; opinión personal

  • assert es una estructura mucho más fácil de prohibir como política

  • Si el código se probó pero faltó este edge case, entonces el contraargumento es que, al final, equivale a decir que no se probó

  • Que el cambio de DB no sea un cambio binario o de configuración no cambia el problema; si el cambio en sí se propaga de forma global al mismo tiempo, sea del tipo que sea, es semilla de desastre; es exactamente el mismo patrón que el caso de Crowdstrike

  • Si la postura es que “cambiar de lenguaje y reescribir tiene un riesgo demasiado alto”, entonces me pregunto si eso significa que los requisitos del servicio no están bien entendidos, o que el servicio no es lo bastante importante como para requerir una migración cuidadosa

• El punto es que el binario se cayó por un puntero nulo sin manejo de errores adecuado; a estas alturas ya da para el chiste del “error del trillón de dólares”

  • Me pregunto cuántos SLA habrán perdido en un año por este incidente

  • Uno piensa que ojalá existiera un lenguaje que evitara este tipo de problemas /s

• Service Control (Chemist) es un servicio bastante antiguo y cumple un rol central en autenticación, autorización, monitoreo, cuotas y más en varias APIs de GCP; por el flujo de solicitudes, la mayoría de APIs de GCP pasan por Chemist, por eso no creo que una mitigación de fail open sea realmente efectiva; tanto Chemist como el proxy están escritos en C++ y han acumulado mucho código legacy durante años; cada equipo cuenta con análisis estático, pruebas, despliegue gradual, feature flags, red button, monitoreo sólido y sistemas de alerta; en particular, el equipo de SRE es excelente; como en Chemist se validan políticas diversas como IAM y cuotas, varios equipos contribuyen a la codebase; para evitar pasar por el proceso de aprobación de Chemist cada vez que hacen cambios, se fue desarrollando mucho por atajos; últimamente, con tantas reorganizaciones y offshoring, se da prioridad a proyectos nuevos vistosos impulsados por gente nivel L8/L9, mientras que calidad, mantenimiento y confiabilidad quedan en segundo plano; me fui de Cloud por este cambio cultural; muchas veces aquí no se siguen las mejores prácticas generales de servidores/servicios de Google; este problema se parece más a una falla de calidad de código y code review; se aprobó código defectuoso y luego se reflejó de inmediato el cambio de configuración vía Spanner, amplificando el problema

• Los datos de la política del servicio incluyeron un campo vacío no intencionalmente, y Service Control leyó ese campo vacío (null) al verificar cuotas por región, lo que causó la excepción; es otro ejemplo de cómo el “error de mil millones de dólares” de Hoare se repite en varios sistemas de Google; el problema empieza porque se permitió desde el principio que pudiera entrar ese “campo vacío” (null), cuando debió haberse especificado NOT NULL en el esquema; por desgracia, en Spanner el valor por defecto es nullable, así que hay que indicarlo aparte; también hubo otra oportunidad de diseñar el sistema de forma que los estados inválidos fueran imposibles a nivel de código de aplicación, mediante el sistema de tipos o el lenguaje de esquemas; otra opción era agregar validación forzada del esquema al deserializar desde el datastore a objetos de aplicación; dado que este problema apareció en una ruta de código nueva, sospecho que no se filtró en la capa de datos; también es un problema que el programa Service Control mismo esté escrito en un lenguaje que permite dereferencias de punteros nulos; si yo fuera responsable de mantenimiento, pensaría en un plan de mínima intervención para cambiar las políticas en el código de aplicación a una estructura como un “tagged enum type” donde no se pueda representar null; proto3 no tiene esa restricción, pero existe este ejemplo

• A menudo se menciona multirregión como una medida de resiliencia y disponibilidad, pero es interesante ver que en una falla real incluso un gran proveedor cloud está fuertemente acoplado entre regiones

  • Eso se nota especialmente en GCP, porque GCP trata las regiones de forma distinta a otros proveedores; desde el punto de vista de la resiliencia, hay que ver GCP como si fuera una sola región compuesta por múltiples zonas

  • Aun así, sigue pudiendo haber “fallas que no conocemos”, así que tampoco conviene subestimar demasiado el efecto del sharding por región/zona

  • También ha habido muchos casos en los que un despliegue multirregión evitó incidentes, así que lo correcto sería identificar esos casos reales antes de sacar conclusiones

• Siempre me sorprende el nivel de detalle de los postmortems de Google, tanto dentro como fuera de la empresa; aprenden para no repetir errores, refuerzan protocolos y manejo de errores, y evolucionan hacia sistemas más robustos; en un lugar del tamaño de Google siempre hay algo que sale mal, pero lo importante es contenerlo para que no afecte a clientes/usuarios ni a otros sistemas; incluso estando dentro, hay muchos problemas distintos que no ves según el equipo; creo que esto está entre los sistemas creados por humanos más complejos que existen; salvo que haya AGI, no es un área donde los humanos puedan hacerlo mucho mejor

  • Pero en este incidente hubo una cadena de errores de nivel junior; no manejar datos nulos, falta de pruebas, falta de cobertura para la nueva funcionalidad, no validar en producción pequeña antes del despliegue total, todo eso es un problema; estoy seguro de que en el Google de hace 10 años todos se habrían burlado de errores así

  • Según entiendo, las causas de esta caída fueron 1) una función global desplegada a toda la infraestructura de una sola vez 2) una desreferencia de puntero nulo 3) ausencia de una política de reintentos adecuada, lo que provocó un problema de “thundering herd”; todos son errores conocidos por cualquiera del sector; no fue una lógica distribuida novedosa o compleja, sino una combinación de errores típicos de principiante

  • Se dice “no volvemos a repetir el mismo error”, pero en la práctica hicieron rollout del cambio sin feature flags, y el cliente no tenía backoff exponencial ni el servidor tenía load shedding; todo eso aparece desde hace años en el google SRE book

  • Este error fue un problema de puntero nulo que no se detectó a tiempo; que una empresa del tamaño y con los estándares de calidad de Google tire abajo gran parte de su stack de esta manera puede interpretarse como una señal de que faltan medidas serias para prevenir recurrencias

  • Es el mismo error repetido incontables veces; “desplegamos con cuidado una función nueva, pero el bug solo se revela cuando entran datos nuevos” resume la mayoría de las caídas globales; no existe un sistema perfecto; los únicos impecables en los debates sobre caídas de FAANG son los expertos de sillón de HN

• En la mayoría de los casos, cuando vemos el downtime ajeno, es fácil criticarlo como un “error de nivel junior”, pero en nuestro propio trabajo siempre quedan excusas como que era inevitable o impredecible; el error humano es inevitable y las expectativas mismas son demasiado altas; si una tienda física cierra de repente, todo termina con un simple “lo siento”; solo la industria de IT se estresa en exceso por caídas de unas pocas horas, y ojalá todos pudiéramos tomarlo con un poco más de calma