Rapport d’incident Google Cloud – 13/06/2025

• Le 12 juin 2025, une hausse des erreurs 503 sur les requêtes d’API externes dans Google Cloud, Google Workspace et Google Security Operations a affecté des clients dans le monde entier
• Une nouvelle vérification de politique de quota dans Service Control, confrontée à des données de politique contenant un champ vide, a provoqué une boucle de crash liée à un pointeur nul ; ce chemin n’avait pas été exécuté pendant le déploiement
• La modification de politique s’est répliquée en quelques secondes dans le monde entier depuis une table Spanner régionale, et les déploiements Service Control de chaque région ont emprunté le même chemin d’échec, entraînant un incident mondial
• Les équipes SRE ont commencé à intervenir en moins de 2 minutes, identifié la cause en moins de 10 minutes et terminé le déploiement du red-button en environ 40 minutes, mais la récupération de us-central1 a pris jusqu’à environ 2 h 40
• Les mesures de prévention se concentrent sur le gel des changements de Service Control, la désactivation par défaut des feature flags, la propagation progressive des données répliquées mondialement, ainsi que l’amélioration de la gestion des erreurs et du backoff exponentiel aléatoire

---

Périmètre et chronologie de l’incident

• Une hausse des erreurs 503 sur les requêtes d’API externes dans les produits Google Cloud, Google Workspace et Google Security Operations a affecté les clients
• Tous les horaires principaux sont indiqués en heure US/Pacific
  • Début de l’incident : 12 juin 2025 à 10:49
  • Atténuation dans toutes les régions sauf us-central1 : 12:48
  • Fin de l’incident : 13:49
  • Durée totale : 3 heures
  • Portée de l’impact : mondiale
• Les clients ont rencontré des problèmes intermittents d’accès aux API et aux interfaces utilisateur des services affectés
• Les flux existants et les ressources IaaS n’ont pas été affectés

Le chemin de vérification assuré par Service Control

• Les API Google et Google Cloud sont fournies via le plan de gestion et de contrôle des API Google
• Ce plan de gestion et de contrôle vérifie, pour chaque requête API :
  • si la requête est autorisée
  • si elle peut atteindre l’endpoint après avoir passé des contrôles tels que les politiques et les quotas
• Le binaire central du système de vérification des politiques est Service Control
• Service Control est un service régional qui utilise un datastore régional lisant les informations de quotas et de politiques
• Les métadonnées de ce datastore sont répliquées presque instantanément dans le monde entier pour la gestion des politiques de quota de Google Cloud et des clients

Cause directe : champ de politique vide et pointeur nul

• Le 29 mai 2025, une nouvelle fonctionnalité de vérification supplémentaire des politiques de quota a été ajoutée à Service Control
• Le changement de code et la version binaire ont fait l’objet d’un déploiement par région, mais le chemin de code défaillant nécessitait une modification de politique spécifique pour être exécuté, et n’a donc pas été validé pendant le déploiement
• Le code problématique disposait bien d’un red-button permettant de désactiver le chemin de fourniture de cette politique, mais il ne comportait pas de gestion d’erreur appropriée ni de protection par feature flag
• Le pointeur nul n’ayant pas été correctement traité, le binaire Service Control a crashé
• Google indique que si la fonctionnalité avait été protégée par un feature flag, le problème aurait été détecté en staging lors d’une activation progressive, d’abord sur des projets internes puis région par région

Processus de propagation mondiale

• Le 12 juin 2025 vers 10:45 PDT, une modification de politique a été insérée dans une table Spanner régionale utilisée par Service Control pour les politiques
• Ces données de politique contenaient un champ vide non intentionnel
• Comme la gestion des quotas fonctionne globalement, ces métadonnées ont été répliquées dans le monde entier en quelques secondes
• Dans chaque région, Service Control a effectué la vérification de quota sur les politiques du datastore régional, lu le champ vide, et exécuté le chemin de code rencontrant le pointeur nul
• En conséquence, le binaire de chaque déploiement régional est entré dans une boucle de crash

Réponse et retards de récupération

• Les équipes SRE ont commencé le triage et l’intervention dans les 2 minutes suivant le début de l’incident
• En moins de 10 minutes, elles ont identifié la cause racine et commencé l’application du red-button
• Le red-button était prêt à être déployé environ 25 minutes après le début de l’incident
• Le déploiement du red-button a été terminé en moins de 40 minutes après le début de l’incident, et des signaux de récupération sont apparus dans les petites régions
• Dans les grandes régions comme us-central1, le redémarrage des tâches Service Control a créé un herd effect sur l’infrastructure dépendante, en particulier les tables Spanner, provoquant une surcharge
• Service Control ne disposait pas d’un backoff exponentiel aléatoire approprié pour éviter ce phénomène
• Pour us-central1, la création de tâches a été throttlée et le trafic routé vers une database multirégionale afin de réduire la charge ; la résolution complète a pris jusqu’à environ 2 h 40
• Par la suite, Service Control et le service des API ont été entièrement rétablis dans toutes les régions
• Les produits Google et Google Cloud associés ont récupéré progressivement, certains plus lentement selon leur architecture

Page de statut et communication client

• Le premier rapport d’incident Cloud Service Health a été publié environ 1 heure après le début des crashs
• Ce retard s’explique par le fait que l’infrastructure Cloud Service Health elle-même était indisponible à cause de l’incident
• Certains clients ont également vu leur infrastructure de monitoring exécutée sur Google Cloud échouer, les empêchant d’identifier les signaux d’incident ou l’étendue de l’impact sur leur activité et leur infrastructure
• Google indique vouloir améliorer les communications externes automatiques et manuelles afin que les clients reçoivent plus rapidement les informations nécessaires pour répondre aux problèmes, gérer leurs systèmes et assister leurs propres clients
• Google indique aussi vouloir garantir que l’infrastructure de monitoring et de communication continue de servir les clients même en cas d’indisponibilité de Google Cloud et des produits de monitoring de base

Mesures immédiates et plan de prévention

• Juste après la récupération, tous les changements de la stack Service Control et les pushs manuels de politiques ont été gelés
• Google indique donner la priorité aux mesures suivantes et les mener à bien en toute sécurité :
  • Modulariser l’architecture de Service Control afin d’isoler les fonctionnalités et passer à une structure fail open permettant de continuer à traiter les requêtes API même si les vérifications associées échouent
  • Auditer tous les systèmes consommant des données répliquées mondialement
  • Même en présence d’un besoin métier de cohérence quasi instantanée à l’échelle mondiale, propager progressivement les données répliquées afin de laisser suffisamment de temps à la validation et à la détection des problèmes
  • Protéger tous les changements critiques de binaires par des feature flags et les désactiver par défaut
  • Améliorer l’analyse statique et les pratiques de test afin de gérer correctement les erreurs et de pouvoir, si nécessaire, fonctionner en fail open
  • Auditer et garantir l’utilisation d’un backoff exponentiel aléatoire par les systèmes
  • Améliorer la communication client
  • Maintenir l’exploitation de l’infrastructure de monitoring et de communication même pendant une panne de Google Cloud et des produits de monitoring de base

Services affectés et impacts résiduels

• De nombreux produits Google Cloud ont été affectés, notamment 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 et Google Security Operations
• Parmi les produits Google Workspace, AppSheet, Gmail, Google Calendar, Google Drive, Google Chat, Google Voice, Google Docs, Google Meet, Google Cloud Search et Google Tasks ont été affectés
• Certains produits ont conservé des impacts résiduels après l’atténuation de l’incident principal
  • Le backlog de Google Cloud Dataflow s’est résorbé progressivement, avec des retards persistants dans us-central1
  • Vertex AI Online Prediction a continué à connaître un taux élevé d’erreurs 5xx sur certains modèles de Model Garden, avant une récupération complète à 18:18 PDT
  • Personalized Service Health a connu des retards de mise à jour, et il a été recommandé aux clients d’utiliser le tableau de bord Cloud Service Health

[kunggom]

Voici le lien vers la version non GN+ de l’article.

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