Résumé
Les produits Google Cloud, Google Workspace et Google Security Operations ont connu une augmentation des erreurs 503 dans les requêtes API externes, ce qui a eu un impact sur les clients.
Nous vous présentons nos sincères excuses pour les désagréments causés par cette interruption. Les clients Google Cloud et leurs utilisateurs font confiance à Google pour leurs activités, et nous nous engageons à faire mieux. Nous sommes désolés pour l'impact que cela a eu non seulement sur les activités de nos clients et leurs utilisateurs, mais aussi sur la confiance accordée à nos systèmes. Nous nous engageons à apporter des améliorations afin d'éviter que de telles interruptions ne se reproduisent à l'avenir.
Que s'est-il passé ?
Les API Google et Google Cloud sont fournies via nos plans de gestion et de contrôle des API Google. Répartis au niveau régional, ces plans de gestion et de contrôle sont chargés de s'assurer que chaque requête API entrante est autorisée et dispose des politiques et des contrôles appropriés (tels que les quotas) pour atteindre ses points de terminaison. Le binaire central qui fait partie de ce système de contrôle des politiques est appelé « Service Control ». Service Control est un service régional qui dispose d'un magasin de données régional à partir duquel il lit les informations relatives aux quotas et aux politiques. Les métadonnées de ce magasin de données sont répliquées presque instantanément à l'échelle mondiale afin de gérer les politiques de quotas pour Google Cloud et nos clients.
Le 29 mai 2025, une nouvelle fonctionnalité a été ajoutée à Service Control pour des vérifications supplémentaires des politiques de quota. Cette modification du code et cette version binaire ont été déployées région par région, mais le chemin d'accès au code qui a échoué n'a jamais été utilisé pendant ce déploiement, car il nécessitait une modification de la politique qui aurait déclenché le code. Par mesure de sécurité, cette modification du code était accompagnée d'un bouton rouge permettant de désactiver ce chemin d'accès particulier à la politique. Le problème avec cette modification était qu'elle ne disposait pas d'une gestion des erreurs appropriée et n'était pas protégée par un indicateur de fonctionnalité. Sans gestion des erreurs appropriée, le pointeur nul a provoqué le plantage du binaire. Les indicateurs de fonctionnalité sont utilisés pour activer progressivement la fonctionnalité région par région, par projet, en commençant par les projets internes, afin de nous permettre de détecter les problèmes. Si cette fonctionnalité avait été protégée par un indicateur, le problème aurait été détecté lors de la mise en place.
Le 12 juin 2025, une modification de politique a été insérée dans les tables Spanner régionales que Service Control utilise pour les politiques. Compte tenu de la nature mondiale de la gestion des quotas, ces métadonnées ont été répliquées à l'échelle mondiale en quelques secondes. Ces données de politique contenaient des champs vides non intentionnels. Service Control a ensuite effectué des vérifications de quotas au niveau régional sur les politiques de chaque magasin de données régional. Cela a entraîné l'apparition de champs vides pour cette modification de politique respective et a déclenché le chemin de code qui a touché le pointeur nul, provoquant une boucle de crash des binaires. Cela s'est produit à l'échelle mondiale, compte tenu de chaque déploiement régional.
En moins de 2 minutes, notre équipe d'ingénierie de fiabilité du site a trié l'incident. En moins de 10 minutes, la cause profonde a été identifiée et le bouton rouge (pour désactiver le chemin de service) a été mis en place. Le bouton rouge était prêt à être déployé environ 25 minutes après le début de l'incident. En moins de 40 minutes après l'incident, le déploiement du bouton rouge était terminé et nous avons commencé à constater une reprise dans toutes les régions, en commençant par les plus petites.
Dans certaines de nos régions plus importantes, telles que us-central-1, le redémarrage des tâches de contrôle des services a créé un effet de troupeau sur l'infrastructure sous-jacente dont elles dépendent (c'est-à-dire la table Spanner), surchargeant ainsi l'infrastructure. Le contrôle des services ne disposait pas du mécanisme de retrait exponentiel aléatoire approprié pour éviter cela. Il a fallu environ 2 heures et 40 minutes pour résoudre complètement le problème dans us-central-1, car nous avons limité la création de tâches afin de minimiser l'impact sur l'infrastructure sous-jacente et avons acheminé le trafic vers des bases de données multirégionales afin de réduire la charge. À ce stade, le contrôle des services et le service API ont été entièrement rétablis dans toutes les régions. Les produits Google et Google Cloud correspondants ont commencé à se rétablir, certains prenant plus de temps en fonction de leur architecture.
Quelle est la marche à suivre immédiate ?
Immédiatement après la reprise, nous avons gelé toutes les modifications apportées à la pile de contrôle des services et les mises à jour manuelles des politiques jusqu'à ce que nous puissions remédier complètement au problème.
Comment avons-nous communiqué ?
Nous avons publié notre premier rapport d'incident sur Cloud Service Health environ une heure après le début des pannes, car l'infrastructure Cloud Service Health était hors service en raison de cette interruption. Pour certains clients, l'infrastructure de surveillance qu'ils utilisaient sur Google Cloud était également défaillante, les laissant sans signal de l'incident et sans compréhension de l'impact sur leur activité et/ou leur infrastructure. Nous allons remédier à cela à l'avenir.
Quelle est notre approche pour l'avenir ?
Au-delà du gel du système mentionné ci-dessus, nous allons hiérarchiser et mener à bien les tâches suivantes en toute sécurité :
- Nous allons modulariser l'architecture de Service Control afin que les fonctionnalités soient isolées et s'ouvrent en cas de défaillance. Ainsi, si une vérification correspondante échoue, Service Control pourra toujours traiter les requêtes API.
- Nous allons auditer tous les systèmes qui consomment des données répliquées à l'échelle mondiale. Indépendamment du besoin commercial d'une cohérence quasi instantanée des données à l'échelle mondiale (c'est-à-dire que les paramètres de gestion des quotas sont globaux), la réplication des données doit être propagée de manière incrémentielle, avec suffisamment de temps pour valider et détecter les problèmes.
- Nous allons imposer que toutes les modifications apportées aux binaires critiques soient protégées par des indicateurs de fonctionnalité et désactivées par défaut.
- Nous allons améliorer nos pratiques d'analyse statique et de test afin de traiter correctement les erreurs et, si nécessaire, de les rendre ouvertes.
- Nous allons auditer et nous assurer que nos systèmes utilisent un backoff exponentiel aléatoire.
- Nous allons améliorer nos communications externes, tant automatisées qu'humaines, afin que nos clients obtiennent les informations dont ils ont besoin dès que possible pour réagir aux problèmes, gérer leurs systèmes et aider leurs clients.
- Nous veillerons à ce que notre infrastructure de surveillance et de communication reste opérationnelle pour servir nos clients même lorsque Google Cloud et nos principaux produits de surveillance sont hors service, afin d'assurer la continuité des activités.
La panne de Google Cloud a été attribuée à une mise à jour de code défectueuse dans son système de contrôle
Pensez-vous que ce rapport est crédible ou pertinent ?
Répondre avec citation
Partager