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

• Le 12 juin 2025, les services Google Cloud et Google Workspace ont connu une hausse mondiale des erreurs 503 lors des requêtes vers des API externes
• La cause provenait d’une modification de code dans le système Service Control et du déploiement d’une règle erronée contenant un champ vide dans les données de politique
• Une gestion d’erreur insuffisante dans le binaire principal et l’absence d’application d’un feature flag ont aggravé la propagation du problème
• Le rétablissement a pris 2 à 3 heures, et la région us-central-1 a nécessité plus de temps en raison d’une surcharge de l’infrastructure
• Google a annoncé des mesures pour éviter toute récidive, notamment la séparation de l’architecture, l’amélioration de la gestion d’erreur et le renforcement de la validation des données

---

Vue d’ensemble complète de l’incident

Résumé de la panne des services Google Cloud et Google Workspace

• À partir du 12 juin 2025 à 10:49 (PDT), plusieurs services, dont Google Cloud, Google Workspace et Google Security Operations, ont subi une forte augmentation des erreurs 503 sur les requêtes vers des API externes
• Google a présenté ses profondes excuses pour l’impact sérieux causé sur les services clients et la confiance des utilisateurs
• Le plan de gestion et de contrôle des API Google est chargé des vérifications de politiques et de quotas pour chaque requête, et le système de vérification principal fonctionne via un binaire appelé Service Control

Analyse de la cause de l’incident

Évolution de l’architecture système – Service Control

• Le 29 mai 2025, une nouvelle fonctionnalité renforçant les contrôles de politique de quota a été ajoutée à Service Control
• Le déploiement s’est fait progressivement par région, mais le code en cause ne s’exécutait que lorsque la politique était réellement appliquée ; comme il n’avait pas été déclenché auparavant, les tests préalables ont été insuffisants
• Ce nouveau chemin fonctionnel ne disposait ni d’une gestion d’erreur appropriée, ni d’un feature flag, ce qui a provoqué des crashes en chaîne du binaire en situation de pointeur nul

Déroulement de l’incident

• Le 12 juin 2025 à 10:45 (PDT), une modification de politique a été insérée dans une table Regional Spanner
• Ces données de politique contenaient un champ vide (Blank Field) non intentionnel, répliqué presque en temps réel à l’échelle mondiale
• Lorsque Service Control a traité cette politique, un crash dû à un pointeur nul s’est produit, entraînant les instances régionales du monde entier dans une boucle de crash
• En 2 minutes, l’équipe SRE a commencé à identifier le problème ; en moins de 10 minutes, la cause a été trouvée, puis le chemin du binaire a été temporairement bloqué (red-button), permettant à la plupart des régions de se rétablir en 40 minutes

Problèmes supplémentaires lors du rétablissement

• Dans certaines grandes régions, comme us-central-1, le redémarrage des tâches Service Control a provoqué un herd effect qui a surchargé l’infrastructure, notamment les tables Spanner
• Service Control n’appliquait pas de backoff exponentiel aléatoire, ce qui a encore accru la pression sur l’infrastructure
• Dans cette région, le rétablissement a été retardé jusqu’à 2 heures 40 ; l’impact a été réduit grâce à des redirections de trafic, et l’ensemble des services a finalement été restauré

Impact client et périmètre de la panne

• Les clients ont subi des problèmes d’accès aux API et aux interfaces utilisateur, tandis que les ressources de streaming et d’IaaS n’ont pas été affectées
• Les effets de latence et de backlog ont perduré plus d’une heure sur certains services
• La liste des produits Google Cloud et Google Workspace touchés est très large
  • Exemples : IAM, Cloud Build, Cloud Storage, BigQuery, AppSheet, Gmail, Google Drive, ainsi que plusieurs dizaines d’autres services

Pistes d’amélioration à venir

• Modulariser l’architecture des services pour isoler les fonctions et introduire un traitement ouvert en cas de panne (fail open)
• Mettre en place une propagation progressive de la réplication mondiale des données et renforcer les processus de validation réels
• Réviser la politique pour que toutes les modifications importantes de binaires soient placées derrière des feature flags et désactivées par défaut
• Améliorer l’analyse statique et les tests afin de mieux détecter les erreurs et examiner une conception permettant le fail open en cas d’incident
• Renforcer la politique de backoff exponentiel aléatoire ainsi que la fiabilité du monitoring et de la communication
• Compléter la redondance de l’infrastructure et l’automatisation de la communication afin que les clients puissent recevoir rapidement monitoring et informations même en situation de panne

Notification d’incident et communication

• Une annonce a été publiée sur Cloud Service Health dans l’heure suivant l’incident, mais l’infrastructure de monitoring elle-même a également subi une panne
• Pour certains clients, les systèmes de monitoring reposant sur Google Cloud n’ont pas fonctionné correctement, compliquant la détection des signaux de panne et l’évaluation de l’impact
• Google a promis de renforcer à l’avenir les infrastructures de monitoring et de communication client

Chronologie principale de l’incident (résumé du mini-rapport)

• Début de l’incident : 12 juin 2025 à 10:49 (PDT)
• Rétablissement de la plupart des régions : 12 juin 2025 à 12:48 (PDT)
• Fin de l’incident : 12 juin 2025 à 13:49 (PDT)
• Durée totale : environ 3 heures
• Zone touchée : monde entier

Résumé des mesures post-incident

• Mise en place prévue de garde-fous pour éviter les défaillances en cas d’erreur ou de corruption de données dans la plateforme de gestion des API
• Renforcement de la validation, des tests et du monitoring avant la propagation mondiale des métadonnées
• Extension de la gestion des erreurs système et des tests complets pour les données invalides

Liste des services affectés (extrait)

Principaux services Google Cloud

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

Principaux services Google Workspace

• AppSheet, Gmail, Google Drive, Google Meet, Docs, Chat, Calendar, etc.

Conclusion

• Cette panne résulte de l’effet combiné de la structure du système de gestion des politiques et quotas, d’une validation insuffisante de l’intégrité des données et de l’absence d’un véritable mécanisme de gestion des erreurs
• Google s’est engagé à apporter des améliorations au niveau de l’architecture et à renforcer sa capacité de réponse aux incidents

[kunggom]

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

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

[GN⁺]

Avis Hacker News

• Je parle en tant qu’interne et j’utilise donc un compte temporaire ; la cause profonde de cet incident est que la direction a ignoré les principes pour aller plus vite, une pratique qui a duré des années jusqu’à atteindre ses limites. Le « query of death » survenu ici est un mode d’échec typique, pratiquement inévitable, des anciens serveurs C++ qui plantent sur certaines requêtes. Service Control est écrit en C++ et s’est appuyé sur diverses directives d’ingénierie pour minimiser ce type d’échec. Le service a tourné 10 ans sans incident majeur, mais le problème vient d’une politique de quota globale développée à la hâte sous pression de la direction. Une telle nouvelle fonctionnalité aurait dû être développée comme un service séparé ou, au minimum, respecter les directives existantes. Les mesures évoquées dans le rapport officiel sont bien en dessous des standards que l’équipe suivait à l’origine. L’équipe essaie de maintenir autant que possible ses anciens standards.

  • On ne peut pas faire porter toute la responsabilité à la direction : le fait de ne pas avoir examiné avec une extrême prudence un déploiement à l’échelle mondiale relève aussi d’un échec de la culture d’ingénierie. Au minimum, la politique globale aurait dû être déployée avant le déploiement régional de Service Control.

• Je trouve le rapport d’incident intéressant : l’équipe SRE a réagi très vite en deux minutes, et le déploiement du « red button » a commencé. Le problème est qu’au redémarrage des tâches Service Control dans une grande région comme us-central-1, un « herd effect » est apparu en surchargeant l’infrastructure (les tables Spanner). Comme aucun backoff exponentiel aléatoire n’était implémenté dans Service Control, la restauration complète a été retardée jusqu’à 2 h 40. Dans ce genre de situation, les quotas normaux sont vite dépassés, ce qui peut provoquer une nouvelle panne. Dans ce cas, si l’infrastructure peut l’encaisser, il me semble préférable de suspendre temporairement les quotas ou de ralentir volontairement les opérations de restauration.

  • Ici, le backoff exponentiel n’était pas la bonne réponse : au démarrage du serveur, la lecture des données critiques est volontairement traitée sans nouvelle tentative, donc le backoff ne s’applique pas. Une meilleure approche serait de répartir rapidement la charge sur une base de données de secours déjà existante. Il y a aussi d’autres options.

• Cela ressemble vraiment à une erreur d’amateur : NPE, aucune gestion d’erreur, pas de backoff exponentiel, pas de couverture de test, pas de test en environnement de staging, pas de rollout progressif — ce sont tous des échecs graves. Tout cela est déjà dans les livres SRE : sommaire du Google SRE Book, Building Secure and Reliable Systems TOC. Je me demande si le niveau d’exigence a trop baissé ou si ces livres ne sont que du marketing.

  • À mon avis, qu’il s’agisse d’humains ou d’automatisation, il n’existe pas de défense parfaite ; au final, ce n’est qu’une suite de compromis. Même avec énormément de tests unitaires et d’intégration, de l’analyse statique et des déploiements progressifs, des angles morts imprévus apparaissent inévitablement à grande échelle. C’est la même raison que celle évoquée dans les livres quand ils disent qu’« ajouter un neuf de plus » demande énormément plus d’efforts. Dans le pire des cas, il faudrait peut-être dupliquer toute la stack et rejouer plusieurs mois de trafic, un rapport coût/bénéfice que personne ne peut assumer. J’ai déjà vu la même chose sur OpenZFS : le code semblait correct, mais un edge case de données écrites il y a 10 ans a révélé le problème. Quand un système devient suffisamment complexe, tester toutes les variantes devient impossible ; en pratique, il faut arbitrer selon le rapport coût/utilité. À titre d’info, je suis SRE chez Google, mais dans une équipe sans lien avec cet incident, et ceci est mon opinion personnelle.

  • Presque toutes les pannes globales de Google se déroulent de façon similaire : un système sur mesure déployé rapidement à l’échelle mondiale reçoit une mauvaise configuration. Pour un rollout binaire classique ou un push de configuration, on applique généralement un déploiement progressif. Même dans Google Cloud, beaucoup de systèmes étaient autrefois globalement couplés, mais ils sont aujourd’hui largement plus régionalisés et plus fiables. Avant, il y avait souvent des pannes globales, mais elles n’étaient pas rendues publiques, donc la plupart des utilisateurs pensaient que le problème venait de leur FAI. Je ne pense pas que la situation soit spécialement pire aujourd’hui. Je précise aussi que j’ai de l’expérience SRE.

  • Vu de l’extérieur, après les grands licenciements et les déclarations du CEO sur la « paresse », tout le monde s’est mis à privilégier la vitesse et les résultats visibles plutôt que la qualité. Peu à peu, signaler ces problèmes culturels est devenu quelque chose qui peut vous marginaliser.

  • J’aimerais qu’on publie davantage de détails. À mon avis, il ne s’agit pas d’une absence de tests au sens général, mais plutôt de l’absence de tests sur le champ vide de la politique, c’est-à-dire l’entrée problématique. Le texte ne dit pas qu’il n’y avait pas de test en environnement de staging ; il dit plutôt qu’un flag l’aurait détecté. Avis personnel.

  • Cela me rappelle un rapport de 1864 sur un dépôt de poudre : « même l’outil le plus dangereux, lorsqu’on s’y habitue, finit par faire perdre la prudence, et l’on juge alors les consignes inutilement strictes ».

• J’appartiens à une autre équipe au sein de Cloud. En général, tout code a des tests unitaires et d’intégration, et les changements de binaire ou de configuration se font progressivement, par tâche et par région, sur plusieurs jours, avec analyse de canari. Même les rollbacks se font lentement, car aller trop vite peut empirer la situation. Par exemple, on peut juger qu’une coupure de 40 minutes vaut mieux qu’une panne de 4 heures si cela évite de surcharger instantanément une base de données globale. Je n’ai pas été directement impliqué dans cet incident, mais d’après le PM, le code était testé, simplement cet edge case a été oublié. Le problème est que la politique de quota a été appliquée par une mise à jour de base de données — et non via un binaire ou un fichier de configuration — ce qui a propagé le changement à toutes les bases du monde en quelques secondes. Le problème de pointeur nul aurait très bien pu aussi se produire avec assert() dans un autre langage. Plutôt que de réécrire ce service critique dans un autre langage, avec les risques que cela comporte, il semble plus raisonnable d’ajouter des garde-fous par flag sur toutes les vérifications de politique, de faire échouer les vérifications de politique de quota en mode ouvert, et de diffuser lentement les changements de DB région par région. Avis personnel.

  • Une structure avec assert est de toute façon bien plus facile à interdire par politique.

  • Le contre-argument est que si le code a été testé mais que cet edge case a été oublié, cela revient malgré tout à dire qu’il n’a pas été réellement testé.

  • Le fait qu’un changement de DB ne soit ni un changement de binaire ni de configuration ne change rien au fond : si le changement se propage globalement et simultanément, quel qu’en soit le type, c’est la recette du désastre. C’est exactement le même schéma que l’affaire Crowdstrike.

  • Si l’on dit que « réécrire en changeant de langage présente un risque trop élevé », on peut se demander si cela signifie que les exigences du service ne sont pas bien comprises, ou bien que le service n’est pas assez important pour justifier une migration prudente.

• Le texte dit qu’un pointeur nul a fait planter le binaire faute de gestion d’erreur adéquate. À ce stade, la blague sur « l’erreur à un trillion de dollars » semble méritée.

  • Je me demande combien de SLA annuels ont été anéantis par cet incident.

  • On se prend à souhaiter qu’il existe un langage capable d’empêcher ce genre de problème /s

• Service Control (Chemist) est un service assez ancien, qui joue un rôle central dans l’authentification, les autorisations, la supervision, les quotas et d’autres fonctions pour plusieurs API GCP. Dans le flux des requêtes, la plupart des API GCP passent par Chemist, ce qui me fait penser qu’une atténuation en fail open n’aurait pas été réellement efficace. Chemist comme le proxy sont écrits en C++, avec beaucoup de code legacy accumulé au fil des ans. Chaque équipe dispose d’analyse statique, de tests, de déploiements progressifs, de feature flags, d’un red button, et de systèmes robustes de monitoring et d’alerting ; les équipes SRE sont particulièrement excellentes. Mais comme Chemist vérifie toutes sortes de politiques — IAM, quotas, etc. — de nombreuses équipes contribuent à la codebase. Pour éviter d’avoir à passer systématiquement par le processus d’approbation de Chemist à chaque changement, de plus en plus de développements ont emprunté des raccourcis. Ces derniers temps, avec les réorganisations et l’offshore, l’accent est mis sur les nouveaux projets spectaculaires pilotés par des profils L8/L9, tandis que la qualité, la maintenance et la fiabilité passent au second plan ; c’est d’ailleurs à cause de ce changement culturel que j’ai quitté Cloud. Les bonnes pratiques habituelles de Google pour les serveurs et services n’y sont souvent pas respectées. Ce problème semble davantage relever d’un code et d’une code review insuffisants : un code défectueux a été approuvé, puis le fait de répercuter immédiatement les changements de configuration via Spanner a amplifié l’incident.

• Des données de politique de service contenaient involontairement un champ vide, et Service Control a levé une exception en lisant ce champ vide (nul) lors des vérifications de quota dans chaque région. C’est un nouvel exemple de la « billion-dollar mistake » de Hoare qui se répète dans divers systèmes Google. Le vrai problème, c’est qu’on ait autorisé dès le départ l’existence de ce « champ vide » (null) ; le schéma aurait dû imposer NOT NULL. Malheureusement, dans Spanner, les colonnes sont nullable par défaut et il faut le préciser explicitement. Il y avait aussi une autre occasion d’empêcher les états invalides au niveau du code applicatif via le système de types ou le langage de schéma. On pourrait également ajouter une validation de schéma forcée lors de la désérialisation des objets applicatifs depuis le datastore. Comme le problème décrit ici s’est produit dans un nouveau chemin de code, je soupçonne que le filtrage n’a pas eu lieu au niveau de la couche de données. Le fait que le programme Service Control lui-même soit écrit dans un langage autorisant la déréférence de pointeurs nuls est aussi un problème. Si c’était moi qui en avais la charge, j’envisagerais un plan d’intervention minimal pour transformer la politique en code applicatif vers une structure de type « tagged enum » incapable de représenter null. proto3 n’offre pas cette contrainte, mais il existe cet exemple.

• On parle souvent du multirégion comme d’un moyen d’améliorer la résilience et la disponibilité, mais il est intéressant de voir qu’en pratique, même chez les grands fournisseurs cloud, les régions restent fortement imbriquées en situation d’incident.

  • C’est particulièrement visible chez GCP, qui traite les régions différemment des autres acteurs. Du point de vue de la résilience, il faut plutôt voir GCP comme une seule région composée de plusieurs zones.

  • Malgré cela, il peut toujours exister des pannes « que nous ne connaissons pas », donc il ne faut pas sous-estimer excessivement l’intérêt du sharding par région/zone.

  • De nombreux incidents ont aussi été évités grâce au déploiement multirégion ; il faut donc d’abord identifier les cas réels avant de tirer une conclusion.

• Je suis toujours impressionné par le niveau de détail des post-mortems Google, autant en interne qu’en externe. Ils apprennent pour éviter de répéter les mêmes erreurs, renforcent les protocoles et la gestion des erreurs, et font évoluer les systèmes vers plus de robustesse. À l’échelle de Google, il y a toujours quelque chose qui tourne mal, mais l’essentiel est de contenir l’impact pour qu’il n’affecte pas les clients, les utilisateurs ou les autres systèmes. Même en interne, selon les équipes, on ne voit pas les mêmes problèmes. À mes yeux, cela fait partie des systèmes les plus complexes jamais construits par l’être humain ; sauf AGI, je ne vois pas comment des humains pourraient faire significativement mieux.

  • Mais dans cet incident, on a vu s’enchaîner des erreurs de niveau junior : incapacité à gérer des données nulles, tests insuffisants, absence de couverture de test pour la nouvelle fonctionnalité, absence de validation sur un petit périmètre de production avant le déploiement général. Je suis convaincu qu’au Google d’il y a 10 ans, tout le monde se serait moqué de ce genre d’erreurs.

  • Si je comprends bien, la panne vient de 1) une fonctionnalité globale déployée d’un coup partout, 2) une déréférence de pointeur nul, 3) l’absence de politique de retry adéquate entraînant un problème de « thundering herd ». Ce sont des erreurs familières pour tous les gens du métier. Il ne s’agit pas d’une logique de système distribué particulièrement nouvelle ou complexe, mais d’un cumul très classique « d’erreurs de débutant ».

  • On dit souvent « on ne répète jamais deux fois la même erreur », mais en pratique le changement a été déployé sans feature flag, les clients n’avaient pas de backoff exponentiel, et le serveur n’avait pas de load shedding. Tout cela figure depuis des années dans le Google SRE Book.

  • Cette erreur venait d’un problème de pointeur nul qui n’a pas été détecté à temps. Voir une entreprise de la taille et du niveau de qualité supposé de Google mettre à terre l’essentiel de sa stack de cette manière peut être interprété comme le signe que les mesures de prévention contre la réapparition de problèmes graves sont insuffisantes.

  • C’est la même erreur répétée d’innombrables fois : « on déploie prudemment une nouvelle fonctionnalité, mais le bug ne se révèle que lorsque de nouvelles données arrivent » résume à peu près la plupart des pannes globales. Aucun système n’est parfait ; dans les débats sur les pannes des FAANG, les seuls irréprochables sont les experts de fauteuil de HN.

• La plupart du temps, face à la panne des autres, on la qualifie facilement « d’erreur de junior », alors que pour son propre travail on invoque l’inévitable ou l’imprévisible. L’erreur humaine est inévitable, et le niveau d’attente est lui-même trop élevé. Quand un magasin physique ferme soudainement, un simple « désolé » suffit ; seul le secteur IT semble se mettre dans un état de stress excessif pour une panne de quelques heures. J’aimerais que tout le monde prenne un peu plus de recul.