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

• El 12 de junio de 2025, un aumento de errores 503 en solicitudes a APIs externas afectó a clientes en todo el mundo en Google Cloud, Google Workspace y Google Security Operations
• Una nueva verificación de políticas de cuota en Service Control, al encontrarse con datos de políticas que incluían campos vacíos, provocó un bucle de fallos por null pointer, y esta ruta no se ejecutó durante el rollout
• A medida que un cambio de política se replicó globalmente en segundos desde una tabla regional de Spanner, el despliegue de Service Control en cada región siguió la misma ruta de fallo y se convirtió en una interrupción global
• El equipo de SRE respondió en 2 minutos, identificó la causa en 10 minutos y completó el rollout del red-button en unos 40 minutos, pero us-central1 tardó hasta unas 2 horas y 40 minutos en recuperarse
• Las medidas de prevención se enfocan en congelar cambios de Service Control, dejar desactivados por defecto los feature flags, propagar gradualmente los datos de replicación global y mejorar el manejo de errores y el backoff exponencial aleatorio

---

Alcance y cronología del incidente

• El aumento de errores 503 en solicitudes a APIs externas afectó a clientes de productos de Google Cloud, Google Workspace y Google Security Operations
• Todos los horarios clave están en hora del Pacífico de EE. UU.
  • Inicio del incidente: 12 de junio de 2025 10:49
  • Mitigación en todas las regiones excepto us-central1: 12:48
  • Fin del incidente: 13:49
  • Duración total: 3 horas
  • Alcance del impacto: Global
• Los clientes experimentaron problemas intermitentes de acceso a APIs e interfaces de usuario en los servicios afectados
• Los recursos existentes de streaming e IaaS no se vieron afectados

Ruta de verificación a cargo de Service Control

• Las APIs de Google y Google Cloud se ofrecen a través del plano de gestión y control de Google API
• Este plano de gestión y control verifica lo siguiente en cada solicitud a una API
  • Si la solicitud está autorizada
  • Si pasa verificaciones como políticas y cuotas para poder llegar al endpoint
• El binario principal del sistema de verificación de políticas es Service Control
• Service Control es un servicio regional y usa un datastore regional que lee información de cuotas y políticas
• Los metadatos de ese datastore se replican casi de inmediato a nivel global para la gestión de políticas de cuota de Google Cloud y de los clientes

Causa directa: campo de política vacío y null pointer

• El 29 de mayo de 2025 se agregó a Service Control una nueva función para verificaciones adicionales de políticas de cuota
• El cambio de código y la liberación del binario pasaron por un rollout regional, pero la ruta de código que falló requería un cambio de política específico para ejecutarse, por lo que no se validó durante el rollout
• El código problemático tenía un red-button para desactivar la ruta que entregaba esa política, pero no contaba con manejo de errores adecuado ni protección mediante feature flag
• Un null pointer no se manejó correctamente y eso llevó al fallo del binario de Service Control
• Google indicó que, si hubiera estado protegido con un feature flag, el problema se habría detectado en staging al activarlo gradualmente por región empezando por proyectos internos

Cómo se propagó globalmente

• El 12 de junio de 2025, alrededor de las 10:45 PDT, se insertó un cambio de política en una tabla regional de Spanner que usa Service Control para sus políticas
• Esos datos de política incluían un campo vacío no intencional
• Como la gestión de cuotas opera globalmente, esos metadatos se replicaron a todo el mundo en cuestión de segundos
• Cuando Service Control en cada región realizó verificaciones de cuota sobre las políticas del datastore regional, leyó el campo vacío y se ejecutó la ruta de código que encontraba el null pointer
• Como resultado, el binario entró en crash loop en los despliegues de cada región

Respuesta y demoras en la recuperación

• El equipo de SRE comenzó la clasificación y respuesta dentro de los 2 minutos posteriores al inicio del incidente
• En 10 minutos identificó la causa raíz y empezó a aplicar el red-button
• El red-button estuvo listo para rollout unos 25 minutos después del inicio del incidente
• El rollout del red-button terminó dentro de los 40 minutos posteriores al inicio del incidente, y las regiones pequeñas empezaron a mostrar señales de recuperación
• En regiones grandes como us-central1, al reiniciarse los trabajos de Service Control se generó un herd effect sobre la infraestructura dependiente, en particular las tablas de Spanner, causando sobrecarga
• Service Control no tenía implementado un backoff exponencial aleatorio adecuado para evitar esto
• En us-central1, tras reducir la creación de trabajos y enrutar tráfico a una base de datos multirregional para bajar la carga, la resolución completa tomó hasta unas 2 horas y 40 minutos
• Después de eso, Service Control y el serving de API se recuperaron por completo en todas las regiones
• Los productos relacionados de Google y Google Cloud se fueron recuperando de forma secuencial según su arquitectura, y algunos tardaron más

Página de estado y comunicación con clientes

• El primer informe del incidente en Cloud Service Health se publicó aproximadamente 1 hora después de que comenzaran los fallos
• La demora se debió a que la propia infraestructura de Cloud Service Health también estaba caída por este incidente
• Algunos clientes tampoco pudieron determinar las señales del incidente ni el alcance del impacto en negocio e infraestructura porque también falló la infraestructura de monitoreo que ejecutaban en Google Cloud
• Google dijo que mejorará las comunicaciones externas automáticas y manuales para que los clientes reciban más rápido la información necesaria para responder al problema, administrar sus sistemas y apoyar a sus propios clientes
• También afirmó que garantizará que la infraestructura de monitoreo y comunicación siga prestando servicio a los clientes incluso si Google Cloud y los productos base de monitoreo están caídos

Acciones inmediatas y plan de prevención

• Justo después de la recuperación se congelaron tanto los cambios del stack de Service Control como los pushes manuales de políticas
• Google afirmó que priorizará y completará de forma segura las siguientes acciones
  • Modularizar la arquitectura de Service Control para aislar funciones y cambiarla a una estructura fail open que permita seguir procesando solicitudes a APIs incluso si fallan verificaciones relacionadas
  • Auditar todos los sistemas que consumen datos replicados globalmente
  • Incluso si existen requisitos de negocio que demanden consistencia casi inmediata a nivel global, hacer que la replicación de datos se propague gradualmente dejando tiempo suficiente para validar y detectar problemas
  • Proteger todos los cambios de binarios críticos con feature flags y dejarlos desactivados por defecto
  • Mejorar el análisis estático y las prácticas de prueba para manejar correctamente los errores y, cuando sea necesario, aplicar fail open
  • Auditar y garantizar que los sistemas utilicen backoff exponencial aleatorio
  • Mejorar la comunicación con clientes
  • Mantener operativa la infraestructura de monitoreo y comunicación incluso durante caídas de Google Cloud y de los productos base de monitoreo

Servicios afectados e impacto residual

• Se vieron afectados numerosos productos de Google Cloud; la lista incluye Identity and Access Management, Cloud Build, Google Cloud Storage, Cloud Monitoring, Cloud Run, Google BigQuery, Vertex Gemini API, Apigee, Google Cloud Bigtable, Cloud Functions, Cloud Load Balancing, Cloud Firestore, Cloud Logging, Cloud Spanner, Google App Engine, Google Cloud Console, Google Compute Engine, Cloud SQL, Cloud Pub/Sub, Persistent Disk y Google Security Operations, entre otros
• Entre los productos de Google Workspace afectados estuvieron AppSheet, Gmail, Google Calendar, Google Drive, Google Chat, Google Voice, Google Docs, Google Meet, Google Cloud Search y Google Tasks
• Algunos productos mantuvieron impacto residual incluso después de mitigarse la interrupción principal
  • En Google Cloud Dataflow, el backlog se fue despejando gradualmente y persistieron demoras en us-central1
  • En Vertex AI Online Prediction continuaron altos errores 5xx en algunos modelos de Model Garden, y luego se informó recuperación completa a las 18:18 PDT
  • Personalized Service Health tuvo retrasos en las actualizaciones y se recomendó a los clientes usar el panel de Cloud Service Health

[kunggom]

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

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