Une politique, toutes les régions: Google Cloud et la responsabilité d’un plan de contrôle mondial

Résumé

• Le 12 juin 2025, des champs vides involontaires dans une politique de quota ont atteint les datastores régionaux de Service Control de Google Cloud presque simultanément. Un chemin de code précédemment déployé manquait à la fois de gestion d'erreur appropriée et de protection par indicateur de fonctionnalité; le traitement de la politique a provoqué le crash des binaires Service Control dans toutes les régions. De nombreuses API Google Cloud, Google Workspace et Google Security Operations ont renvoyé des erreurs 503. Les ressources existantes de streaming et d'infrastructure en tant que service ont en grande partie continué à fonctionner, mais les chemins de gestion et d'API nécessaires pour inspecter, modifier, mettre à l'échelle ou récupérer les services ont été largement altérés.
• Le bogue immédiat était limité, mais la défaillance de responsabilité était architecturale. Google disposait d'instances de service distribuées régionalement et d'un déploiement binaire progressif, pourtant la politique déclenchante a été répliquée globalement en quelques secondes. Le mécanisme de neutralisation a donc contourné l'apprentissage régional que le déploiement était censé fournir. La récupération a ensuite créé un effet de ruée contre Spanner dans les grandes régions car les tâches redémarrées manquaient de temporisation exponentielle aléatoire. L'infrastructure publique Cloud Service Health dépendait également de l'environnement affecté, retardant le premier avis de Google d'environ une heure.
• Des incidents antérieurs montrent des causes différentes mais des questions récurrentes sur l'indépendance logique. En juin 2019, l'automatisation de la maintenance a déprogrammé des clusters de plan de contrôle réseau dans plusieurs emplacements physiques, les routes BGP ont été retirées et les outils de diagnostic nécessaires se sont disputé le réseau congestionné. En février 2021, un bogue latent déclenché lors de changements de quotas de peering a bloqué la programmation réseau globale. En mars 2021, des routes invalides ont exposé un défaut connu d'un fournisseur et certains emplacements Cloud Interconnect manquaient de diversité suffisante de routeurs. Ce ne sont pas des défauts logiciels récurrents; ce sont des tests répétés de confinement de mode commun, d'autorité de changement, de récupération réseau et de visibilité véridique.
• Google est responsable de valider les données répliquées globalement, d'isoler les fonctions du plan de contrôle, de préserver un comportement fail-static ou fail-open lorsque sûr, de maintenir des communications d'incident indépendantes et de prouver que les mesures correctives promises ont été réalisées. Les clients ne peuvent pas réparer ces contrôles de plateforme, mais ils restent responsables d'identifier les opérations qui dépendent des API du plan de contrôle, de surveiller depuis l'extérieur du fournisseur, de tester les modes dégradés et d'acheter de la diversité de route et de fournisseur plutôt que de compter les liens nominaux. Le déploiement multi-région réduit de nombreux risques; il n'échappe pas, à lui seul, à un plan de politique global ou à une dorsale partagée.

La panne était une décision de contrôle prise partout à la fois

Une région cloud est facile à imaginer. Elle a des bâtiments, de l'énergie, du refroidissement, de la fibre, des machines et des zones destinées à isoler les pannes physiques. Un plan de contrôle est plus difficile à voir. C'est l'autorité qui décide si des ressources peuvent être créées, quelle politique s'applique, comment les routes doivent être programmées, si une requête API est dans le quota et où le trafic doit aller.

Les applications peuvent continuer à traiter le travail existant lorsque cette autorité est brièvement indisponible, mais elles deviennent fragiles lorsqu'elles ont besoin d'une nouvelle instance, d'un changement de configuration, d'une décision d'identifiant, d'une mise à jour de route ou d'un basculement qui nécessite lui-même le plan de contrôle.

Cette distinction explique pourquoi l'incident du 12 juin 2025 était à la fois moins qu'une panne totale d'infrastructure et plus qu'un problème d'API ordinaire. Lerapport d'incident complet de Service Controlde Google indique que les ressources existantes de streaming et d'infrastructure en tant que service n'ont pas été directement affectées par la défaillance principale. Pourtant, une longue liste de produits a connu des erreurs d'API externes, notamment Identity and Access Management, Cloud Storage, BigQuery, Cloud Run, Cloud DNS, Cloud Load Balancing, Hybrid Connectivity, Network Connectivity Center, Spanner, les produits de surveillance, la console et plusieurs services d'IA. La capacité à continuer à servir à partir d'un état déjà programmé a mieux survécu que la capacité à demander à la plateforme de décider ou de changer quelque chose.

Le mécanisme était exceptionnellement clair dans le compte rendu public de Google. Le 29 mai, une nouvelle fonctionnalité Service Control pour des vérifications supplémentaires de politique de quota a été publiée région par région. Le déploiement binaire s'est terminé sans exposer la faille car le chemin de code défaillant nécessitait un changement de politique ultérieur. La fonctionnalité n'était pas protégée par un indicateur qui aurait pu l'activer progressivement pour des projets sélectionnés, et sa gestion des données invalides permettait à une valeur nulle de faire crasher le processus.

Le 12 juin vers 10h45, heure du Pacifique, une politique de quota contenant des champs vides involontaires a été écrite dans les tables Spanner régionales utilisées par Service Control. Comme les métadonnées de quota étaient conçues pour se déplacer globalement avec une cohérence quasi immédiate, les données sont apparues dans toutes les régions en quelques secondes. Chaque déploiement régional de Service Control a alors rencontré la même entrée et est entré dans une boucle de crash.

Ce n'était pas un cas où la redondance était absente. Des instances de service régionales et des datastores régionaux existaient. Ce n'était pas non plus simplement un cas où un ingénieur aurait appuyé sur le mauvais bouton. Un système de production a accepté des données de politique structurellement non sécurisées, un chemin critique manquait de gestion d'erreur défensive, une fonctionnalité a atteint chaque région sans un chemin d'activation contrôlé indépendamment, et le système de propagation était plus rapide que le système de validation. L'architecture a converti un objet logique invalide en un événement global.

Qualifier l'incident de panne due à une politique mal formée est exact mais incomplet. La politique a été le déclencheur. Les causes plus larges étaient la quantité d'autorité qui lui était attachée et l'absence de confinement entre l'acceptation, la réplication, l'interprétation et le service. La question de responsabilité n'est pas simplement pourquoi un champ vide existait. C'est pourquoi une seule politique a pu devenir un état de défaillance exécutable partout avant qu'une région, une cohorte de projets ou un validateur fantôme n'ait eu le temps de la rejeter.

Un déclencheur court a produit une récupération longue et inégale

La chronologie de Google contient deux histoires très différentes. La détection et le diagnostic ont été rapides. La récupération complète ne l'a pas été.

Le chemin plus lent dans us-central1 est central pour l'analyse des risques. Lorsque les tâches Service Control ont redémarré, elles ont exercé une demande concentrée sur la table Spanner sous-jacente. Les tâches manquaient de la temporisation exponentielle aléatoire nécessaire pour empêcher des tentatives synchronisées. Google a dû limiter la création de tâches et rediriger le trafic vers des bases de données multi-régions. En d'autres termes, la première défaillance était une interprétation non sécurisée de données globales; la seconde était un comportement de récupération qui a surchargé une dépendance partagée.

La propre littérature SRE de Google décrit depuis longtemps ce danger. Son chapitre surla gestion des défaillances en cascadeexplique comment les tentatives et les redémarrages peuvent maintenir un backend surchargé et comment la temporisation exponentielle aléatoire, la dégradation gracieuse et le rejet de charge contrôlé peuvent empêcher un problème de capacité local de devenir une cascade. Le rapport de 2025 s'engage explicitement à auditer les systèmes pour cette temporisation. L'important n'est pas que Google n'ait pas suivi une phrase d'un livre. C'est qu'une classe connue de risque des systèmes distribués est restée dans un service critique dont la population de redémarrage était régionale et dont les données de support étaient globales.

Les plans de récupération doivent donc être évalués comme des architectures de production, pas comme des paragraphes de procédure. Un système qui peut être désactivé en toute sécurité a besoin d'un mécanisme de neutralisation dont les propres dépendances sont comprises. Une flotte qui peut crasher ensemble a besoin d'un régulateur de redémarrage, d'un contrôle d'admission, de gigue et d'un taux de récupération maximal testé. Un datastore censé absorber la récupération de la flotte a besoin de capacité réservée ou d'un chemin de lecture dégradé.

Si les ingénieurs doivent rediriger vers une base de données multi-région pendant l'événement, ce chemin doit être répété et observable avant l'incident, avec la preuve qu'il ne déplacera pas la surcharge ailleurs.

La longue traîne compte également pour la communication client. Le rapport préliminaire de Google décrivait un événement global de trois heures, tandis que la page d'incident continuait de lister la récupération des produits jusqu'à 18h18. Certains produits avaient des arriérés après le retour du service API. Un client dont la demande a échoué pendant la fenêtre principale peut avoir eu des tentatives, des travaux en file d'attente, des flux de travail partiels, des caches périmés ou un service tiers qui a mis plus de temps à récupérer.

L'état vert du fournisseur est le début de la réconciliation client, pas la preuve que chaque processus métier est intact.

Le déploiement régional n'a pas créé d'apprentissage régional

La livraison progressive est censée transformer la distance en preuve. Un changement atteint une petite population; les opérateurs observent son comportement; seulement ensuite il va plus loin. Google a utilisé un déploiement binaire région par région pour le nouveau code Service Control, mais le déploiement n'a jamais exercé le chemin de code qui a échoué par la suite. La politique d'activation a suivi un mécanisme de distribution différent, optimisé pour rendre l'état de quota global en quelques secondes. Le code était progressif; la signification du code ne l'était pas.

C'est une défaillance de contrôle des changements subtile mais conséquente. Les équipes examinent souvent les binaires, la configuration, le schéma, la politique et les données comme des objets séparés. Le comportement en production, cependant, provient de leur combinaison. Une fonctionnalité dormante peut passer chaque barrière régionale jusqu'à ce qu'une valeur de configuration la réveille partout. Un schéma peut être valide pour l'écrivain mais invalide pour un lecteur plus ancien. Une politique répliquée globalement peut rendre les canaris régionaux inutiles.

Un bouton rouge peut exister mais dépendre encore du plan de contrôle cassé pour prendre effet.

Les conseils d'infrastructure actuels de Google reconnaissent ce risque. Leguide des blocs de construction de la fiabilitéindique que les ressources globales sont résilientes aux incidents d'infrastructure zonaux et régionaux mais peuvent devenir des points de défaillance uniques lorsqu'une erreur de configuration critique a une portée globale. Il recommande un contrôle prudent des changements et, pour les charges de travail exceptionnellement exigeantes, des solutions de repli de défense en profondeur régionales. Leguide de gestion et de surveillancecomplémentaire conseille le déploiement progressif et un examen supplémentaire pour les ressources globales. L'incident de 2025 applique la même logique à l'intérieur du fournisseur: la portée globale est un avantage de fiabilité contre les pannes physiques et un risque de rayon d'impact pour un mauvais état logique.

Une remédiation complète nécessite un modèle de publication conjoint. Le binaire, le schéma de politique, les valeurs de politique, la réplication du datastore, les versions des lecteurs, le comportement de repli et les contrôles d'urgence doivent être traités comme une seule surface de changement. Les nouveaux lecteurs doivent accepter en toute sécurité les valeurs anciennes, nouvelles, manquantes et corrompues. Une nouvelle politique doit être lue en mode fantôme avant d'être autoritaire. L'activation doit commencer par des projets internes ou une région limitée et s'arrêter automatiquement en cas de crash, de latence ou de seuils d'erreur.

La réplication doit être suffisamment incrémentale pour préserver un intervalle de détection, même si l'état métier final doit devenir globalement cohérent.

Cela ne signifie pas que chaque politique globale doit devenir lentement incohérente. Les décisions de quota et d'autorisation peuvent nécessiter un état cohérent et opportun. La question de conception est de savoir si la validation peut être séparée de l'autorité. Une politique candidate peut se répliquer en tant que données inertes, être analysée et évaluée par rapport à un trafic de type production, et ne devenir effective qu'après le succès des vérifications. Les régions peuvent conserver une dernière politique connue bonne lorsqu'un nouvel objet est invalide. Les lecteurs peuvent distinguer la corruption d'un refus légitime.

La cohérence globale n'est pas incompatible avec la sécurité progressive; elle nécessite simplement plus qu'une réplication rapide.

Fail open est une décision commerciale et de sécurité, pas un slogan

Google s'est engagé à modulariser Service Control pour qu'une fonction de politique affectée puisse être isolée et échouer en mode ouvert, permettant aux requêtes API de continuer si la vérification correspondante échouait. C'est une correction significative, mais l'expression "fail open" a besoin de limites. Un contrôle de quota, une décision d'authentification, un contrôle de facturation et un contrôle anti-abus n'ont pas la même conséquence lorsqu'ils sont indisponibles.

Pour un contrôle de quota à faible risque, un service temporairement permissif peut être plus sûr que de rejeter chaque requête API client. Le fournisseur peut réconcilier l'utilisation plus tard, plafonner l'exposition par projet et préserver la disponibilité essentielle. Pour un contrôle d'autorisation, autoriser aveuglément les requêtes pourrait créer un incident de sécurité pire qu'une panne. Pour la création de ressources, un cache local limité de la politique récente pourrait être plus sûr qu'un refus universel ou une permission universelle.

Le comportement dégradé approprié dépend de l'objectif du contrôle, de la fraîcheur de l'état de confiance, de la réversibilité des actions et du potentiel de fraude, de perte de données ou de dépenses incontrôlées.

L'architecture de Service Infrastructurede Google sépare les plans de gestion, de contrôle et de données tout en montrant la largeur des fonctions de la plateforme: authentification, autorisation, quota, limitation de débit, audit, facturation, journalisation et surveillance. Cette largeur est précisément pourquoi un comportement de défaillance modulaire importe. Un analyseur ou un chemin de politique ne devrait pas pouvoir transformer chaque type de décision en la même réponse 503.

Une conception responsable publierait des principes plutôt que des détails d'implémentation sensibles. Quelles classes de vérification utilisent les dernières données connues bonnes? Lesquelles peuvent temporairement échouer en mode ouvert? Lesquelles échouent en mode fermé parce que la conséquence de sécurité domine? Quelles limites strictes restent pendant un service dégradé? Comment l'utilisation exceptionnelle est-elle réconciliée? Les clients peuvent-ils choisir un comportement plus strict pour les charges de travail réglementées?

Comment la plateforme distingue-t-elle une politique de fournisseur invalide d'un refus de quota client légitime?

Cela change également les tests. Il ne suffit pas de confirmer qu'une bonne politique renvoie la bonne réponse. Les tests doivent injecter des champs vides, des champs inconnus, des versions périmées, une réplication partielle, des objets corrompus, des datastores indisponibles, des lectures lentes et des politiques conflictuelles. Ils doivent prouver qu'un module peut être contourné sans contourner les sauvegardes non liées. Ils doivent mesurer le comportement visible par le client pendant un fonctionnement dégradé et vérifier que la récupération ne rejoue pas les modifications rejetées ou dupliquées de manière imprévisible.

Le système de statut a partagé la panne qu'il était censé décrire

Pendant environ la première heure, les clients n'ont pas reçu de rapport d'incident public Cloud Service Health parce que cette infrastructure était elle-même en panne. Certains clients exécutaient également leur surveillance sur Google Cloud, de sorte que le service et la preuve du service ont échoué ensemble. La panne a altéré non seulement la production mais aussi le contrôle épistémique: la capacité de savoir ce qui se passait, de décider s'il fallait basculer et d'expliquer la situation aux utilisateurs.

Ce n'était pas sans précédent. Lors de la panne d'authentification globale de Google le 14 décembre 2020, lerapport d'incidentindique que les outils internes du support cloud ont été affectés, que les clients ne pouvaient pas créer ou consulter des tickets de support dans la console, et que la communication du tableau de bord a été retardée jusqu'à la fin de l'impact principal. Cet événement est venu de la gestion automatisée des quotas réduisant la capacité du système d'identité central. Les configurations du plan de données réseau existantes sont restées opérationnelles, mais les services authentifiés, l'accès API, les consoles et de nombreux outils internes ne l'étaient pas. Le mécanisme diffère de 2025; la préoccupation récurrente est que l'identité, le support, la surveillance et la communication peuvent partager un destin avec les services qu'ils sont censés diagnostiquer.

Google a depuis documenté un modèle de communication plus explicite. Songuide de communication d'incidentdistingue le Personalized Service Health, qui utilise le contexte de projet et peut s'intégrer aux alertes et API, du tableau de bord public Cloud Service Health. Le même guide reconnaît que le Personalized Service Health dépend de services tels que IAM et recommande un repli vers le tableau de bord public et le flux RSS lorsque les systèmes personnalisés sont indisponibles. C'est un bon conseil, mais juin 2025 montre que le canal public a également besoin d'indépendance opérationnelle.

L'obligation du fournisseur est de maintenir un chemin de publication accessible de l'extérieur, alimenté et administré indépendamment, avec des modèles d'incident pré-autorisés et des entrées hors bande du commandement d'incident. Il ne doit pas nécessiter la console normale, le plan d'identité client, la pile de surveillance principale ou le service de contrôle sous investigation. Le premier avis n'a pas besoin de contenir une cause racine.

Il doit indiquer les symptômes observés, la portée connue, l'heure de début, si les opérations du plan de contrôle ou les charges de travail existantes sont affectées, les solutions de contournement disponibles et l'heure de la prochaine mise à jour.

Les clients ont une obligation parallèle. Leguide d'intégration pour Personalized Service Healthde Google indique explicitement que le service ne peut pas savoir si chaque produit est critique pour une application particulière ou si l'application continue lorsqu'une dépendance échoue. Les opérateurs ont besoin de leurs propres vérifications de parcours utilisateur, de métriques d'application, de télémétrie réseau et d'alarmes de processus métier. Au moins un chemin doit s'exécuter en dehors de Google Cloud et aboutir à un canal d'incident qui ne dépend pas de l'identité Google. Le statut du fournisseur est une corroboration, pas le premier et unique détecteur.

Il y a une raison de gouvernance à cette séparation. Une page de statut retardée modifie le comportement des clients. Les équipes peuvent perdre du temps à chercher dans leurs propres déploiements, effectuer des retours en arrière risqués, mettre à l'échelle dans un plan de contrôle cassé ou reporter un basculement en attendant la confirmation. Le silence du support peut également amener les fournisseurs en aval à publier des spéculations. La disponibilité de la communication est donc un contrôle de risque avec des objectifs de détection et de publication mesurables, pas une courtoisie ajoutée après le début des travaux d'ingénierie.

Les charges de travail existantes ont mieux survécu que les actions censées les sauver

La déclaration du rapport de 2025 selon laquelle les ressources de streaming et d'infrastructure en tant que service existantes n'ont pas été affectées doit être lue attentivement. Elle démontre une séparation utile entre des parties du plan de données et le chemin de gestion. Cela ne signifie pas qu'une application était en sécurité simplement parce que ses machines virtuelles en cours d'exécution sont restées actives.

Les systèmes cloud sont dynamiques. Les autoscalers créent des instances. Les orchestrateurs remplacent les nœuds défaillants. Les systèmes de déploiement récupèrent des artefacts et émettent des appels API. Les bases de données basculent. Les certificats et les jetons tournent. Les services sans serveur invoquent des chemins de contrôle du fournisseur derrière une requête apparemment simple. Les intervenants d'incident modifient les règles de pare-feu, les équilibreurs de charge, le DNS, les routes, les quotas et les autorisations.

Un plan de données statique peut continuer à transmettre tandis que le processus métier qui l'entoure perd la capacité de s'adapter.

La panne réseau de février 2021 rend cette frontière concrète. Lerapport d'incident sur l'échec de programmation réseaude Google indique qu'un bogue latent a été déclenché lorsque le plan de contrôle réseau global a retraité des opérations associées aux changements de quota de peering. Les VM nouvelles, mises à jour, supprimées ou migrées et les points de terminaison réseau n'ont pas pu être programmés correctement, tandis que de nombreuses instances inchangées ont continué à fonctionner. Google a suspendu les migrations en direct globalement; environ 1 000 clusters GKE ont été affectés par l'incapacité à provisionner des nœuds ou des clusters; certaines créations d'instances et mises à jour d'équilibreur de charge ont échoué à des taux très élevés. Un serveur existant en bonne santé n'a pas aidé un groupe d'autoscaling qui avait besoin d'un nouveau serveur réseau.

C'est le paradoxe du plan de contrôle de la reprise après sinistre. Les actions du plan de récupération sont souvent moins testées et plus dépendantes du plan de contrôle que le service ordinaire. Une procédure peut dire "créer de la capacité dans la deuxième région" ou "basculer l'équilibreur de charge", mais ce sont des opérations API. Si la panne initiale altère la création de ressources ou les mises à jour globales de l'équilibreur de charge, l'étape de récupération est indisponible exactement au moment où elle est demandée.

Leguide d'architecture de reprise après sinistrede Google distingue les actions du plan de données des mises à jour du plan de contrôle et explique la résilience spécifique à chaque service. Songuide de conception d'infrastructure fiablerecommande d'éviter ou de minimiser les dépendances aux actions non liées au plan de données pendant les pannes, telles que la création d'un nouvel équilibreur de charge. La leçon pratique est de pré-provisionner le chemin de récupération. La capacité peut être chaude plutôt qu'hypothétique. Les points de terminaison régionaux peuvent exister avant que le frontal global ne tombe en panne. Les enregistrements DNS, les identifiants, les routes, les images et les procédures peuvent être disponibles sans opération administrative de dernière minute.

Pour chaque étape de récupération, un opérateur devrait pouvoir nommer l'API, le fournisseur d'identité, le chemin réseau, le résolveur DNS, le magasin d'artefacts, le secret et l'approbation humaine qu'elle nécessite. Ensuite, l'exercice devrait supprimer ces dépendances une par une. Un plan qui réussit seulement lorsque la console, IAM, Service Control, la programmation réseau globale et la région principale sont tous en bonne santé est une procédure d'expansion, pas une reprise après sinistre.

La panne de 2019 a montré que la séparation physique peut partager une frontière d'automatisation

Le 2 juin 2019, les projets Google Cloud dans plusieurs régions des États-Unis ont connu une perte de paquets élevée pendant plus de trois heures. Certains services Google n'ont pas pu rediriger complètement les utilisateurs vers les régions non affectées. Lerapport d'incident réseaua décrit de multiples défaillances qui se sont combinées en une panne majeure: les travaux du plan de contrôle réseau ont été configurés pour s'arrêter pour un événement de maintenance; plusieurs instances de gestion de cluster étaient éligibles pour le même type d'événement rare; et un bogue logiciel a permis à l'automatisation de déprogrammer des clusters logiciels indépendants même lorsqu'ils se trouvaient dans des emplacements physiques différents.

Le réseau a initialement continué en mode "fail static" sans son plan de contrôle. Plusieurs minutes plus tard, les routes BGP entre les emplacements affectés ont été retirées, réduisant la capacité du réseau et rendant certaines régions inaccessibles. La défaillance des outils de diagnostic sur le réseau congestionné a ralenti l'enquête. Lorsque les ingénieurs ont restauré les instances du plan de contrôle, la configuration a dû être reconstruite et redistribuée, prolongeant la récupération.

Il y a une rime structurelle frappante avec 2025. En 2019, des emplacements physiques et plusieurs gestionnaires de cluster existaient, mais une abstraction de maintenance les a sélectionnés ensemble. En 2025, des instances régionales de Service Control existaient, mais une politique globale les a atteintes ensemble. Les deux incidents impliquaient une période de sécurité qui s'est avérée trop courte ou trop dépendante: le routage fail-static en 2019 et un contournement par bouton rouge en 2025. Les deux ont altéré les outils utilisés pour comprendre ou communiquer la panne.

Les deux chemins de récupération ont dû reconstruire ou redistribuer l'état de contrôle dans des conditions dégradées.

Les causes ne sont pas interchangeables. L'incident de 2019 était une défaillance de contrôle réseau et d'automatisation de maintenance; l'incident de 2025 était une défaillance de données de politique et d'API de contrôle. La responsabilité ne doit pas les aplatir en "Google a eu une autre panne". La valeur de la comparaison est de tester si l'organisation découvre à plusieurs reprises que des composants nominalement indépendants partagent encore un domaine administratif, un mécanisme de propagation, un outil d'urgence ou une dépendance de récupération.

Les engagements de Google en 2019 comprenaient le rejet des demandes de maintenance impliquées, la persistance de la configuration du plan de contrôle local, l'extension de la durée de fonctionnement du réseau fail-static, le renforcement de l'outillage d'urgence et l'expansion des tests de reprise après sinistre. La question de responsabilité actuelle n'est pas de savoir si ces actions auraient empêché le pointeur nul non lié de 2025.

C'est de savoir si la méthode de gouvernance qui les sous-tendait est devenue standard: cartographier l'autorité commune, persister l'état sûr, garder les contrôles d'urgence en dehors du domaine de défaillance principal et tester les défaillances corrélées catastrophiques. Un programme de remédiation n'a de valeur institutionnelle que lorsque son modèle de contrôle dépasse l'équipe qui a rédigé le post-mortem.

La diversité de peering et de transit concerne le destin, pas le nombre de circuits

La disponibilité du cloud atteint les clients par les réseaux. Une charge de travail peut être saine dans une région tandis que les utilisateurs ne peuvent pas l'atteindre parce qu'une périphérie, une route de dorsale, une session de peering, un fournisseur de transit, un chemin DNS ou une interconnexion hybride a échoué. Inversement, deux circuits d'accès peuvent sembler diversifiés sur un bon de commande tout en convergeant vers un même métro, un même fournisseur, un même modèle de routeur, une même périphérie Google ou un même système de contrôle.

Le rapport d'incident de dorsale du17 mars 2021de Google illustre cette différence. La connexion de nouveaux routeurs a changé les routes que certains rôles de routeur recevaient. Ces routes ont exposé un défaut connu dans un modèle de routeur spécifique, provoquant l'échec des processus de routage. La redirection automatique a réduit le risque de cascade plus large mais a produit une perte de paquets pendant la convergence. Une atténuation manuelle a causé une autre période de congestion, et certains emplacements Cloud Interconnect ont eu un impact prolongé parce que la redondance des fournisseurs de routeurs était insuffisante. Le trafic IP privé interrégional, le trafic IP public, les équilibreurs de charge, les tunnels VPN et la connectivité externe ont été affectés dans des proportions différentes.

C'est pourquoi un examen de résilience doit aller au-delà de "nous avons deux liens". L'examen doit demander qui possède chaque chemin de fibre, quel bâtiment et domaine de disponibilité de périphérie il utilise, quel fournisseur de routeur et train logiciel le termine, quel Cloud Router contrôle ses sessions BGP, comment les routes reconvergent, si la capacité de basculement peut supporter toute la charge et si les deux chemins dépendent du même plan de contrôle du fournisseur. Il doit observer les changements de route réels et exécuter des retraits planifiés, ne pas accepter un diagramme de topologie comme preuve.

L'aperçu de Cloud Interconnectde Google propose des configurations à 99,9 et 99,99 % et explique qu'une connexion unique n'a pas de SLA de disponibilité. Leguide Partner Interconnectdemande quatre attaches VLAN sur deux métros et domaines de disponibilité de périphérie pour sa topologie recommandée à 99,99 %; il note également que le segment du fournisseur en dehors du réseau de Google a besoin de sa propre assurance. Utiliser plusieurs fournisseurs de services peut améliorer la disponibilité, mais seulement si leurs chemins sous-jacents sont réellement séparés et ont une capacité suffisante pendant le basculement.

Le peering à l'intérieur du cloud n'est pas du transit par défaut. Ladocumentation VPC Network Peeringde Google indique que le peering est non transitif: si le réseau A est appairé avec B et que A est également appairé avec C, B ne gagne pas pour autant une connectivité à C. Cette contrainte peut être une frontière de confinement utile, mais elle surprend les équipes qui supposent qu'un VPC central agit automatiquement comme un hub de transit. Pendant une panne, une route de récupération improvisée peut échouer parce que la topologie annoncée n'a jamais été prise en charge. Lorsque le transit est requis, il doit être conçu explicitement, avec échange de routes, politique, capacité, inspection de sécurité et comportement de défaillance testés de bout en bout.

Le transit Internet mérite la même précision. L'accès public via deux FAI peut encore entrer dans le réseau de Google par un emplacement de peering commun. Une interconnexion privée et un VPN Internet peuvent offrir une meilleure diversité administrative, mais les deux peuvent encore dépendre de la dorsale de Google ou de la même identité client et du même DNS. Un deuxième cloud ne peut réduire la concentration du fournisseur que si l'application, les données, l'identité, l'outillage de déploiement, l'observabilité et le basculement DNS peuvent y fonctionner indépendamment. Un décompte de logos n'est pas une architecture.

La multi-région est une forte protection contre la mauvaise classe de défaillance

La conception multi-région reste précieuse. Elle peut protéger contre un événement électrique, une perte de capacité locale, une défaillance matérielle zonale et de nombreux problèmes logiciels régionaux. L'erreur n'est pas d'utiliser plusieurs régions; c'est de traiter l'expression comme une déclaration complète d'indépendance.

L'événement réseau de 2019 a affecté plusieurs régions parce qu'une frontière d'automatisation du plan de contrôle a traversé les emplacements physiques. L'incident de quota de peering de 2021 a affecté la programmation réseau globalement parce que le contrôleur concerné et les ressources VPC avaient une portée globale. L'événement Service Control de 2025 a affecté toutes les régions parce que le plan de politique était global. Dans chaque cas, plus de réplicas d'application à l'intérieur du domaine administratif affecté n'ont pas pu supprimer la cause commune.

La documentation de fiabilité de Google fait une distinction utile entre la portée géographique et la fiabilité des applications. Les ressources globales peuvent être très résilientes à une panne d'infrastructure régionale tout en devenant des points de défaillance uniques par la configuration. Les ressources multi-régions peuvent survivre à la perte d'une région mais rester dépendantes de l'identité globale, de la gestion des API, du contrôle réseau ou d'un frontal global. Les clients ont besoin d'un graphe de dépendance qui marque à la fois la géographie et l'autorité.

Ce graphe devrait inclure au moins cinq couches. La première est l'exécution: où les processus et les données s'exécutent réellement. La deuxième est le contrôle: quelles API créent, acheminent, autorisent, mettent à l'échelle et basculent ces ressources. La troisième est l'accès: quels chemins DNS, de peering, de transit, d'interconnexion, de VPN et de dorsale connectent les utilisateurs et les opérateurs. La quatrième est l'observation: où résident les journaux, les métriques, les flux de statut, la pagination et le support.

La cinquième est la récupération: quels dépôts, identifiants, humains et services externes sont nécessaires pour restaurer le fonctionnement.

Une dépendance n'est indépendante que si le même événement crédible ne peut pas la désactiver en même temps que la primaire. Deux régions contrôlées par une politique globale invalide ne sont pas indépendantes pour cet événement. Deux piles de surveillance délivrées par le même système d'identité ne sont pas indépendantes pour une panne d'authentification. Deux circuits sur le même logiciel de routeur ne sont pas indépendants pour le défaut du fournisseur concerné. Un service chaud dans un autre cloud n'est pas indépendant si le seul contrôle DNS, dépôt d'artefacts ou connexion opérateur réside dans Google Cloud.

Cette analyse ne doit pas devenir une exigence coûteuse que chaque petite charge de travail fonctionne sur trois fournisseurs. Les contrôles doivent être proportionnés. Un site d'information public peut accepter quelques heures d'indisponibilité et conserver une page de statut externe. Un service d'autorisation de paiement peut avoir besoin de capacité pré-provisionnée, de transit indépendant, de surveillance externe et d'un fournisseur secondaire testé. L'acte responsable est de savoir quelles dépendances restent communes, d'évaluer les conséquences et d'obtenir l'acceptation explicite du propriétaire métier.

Cloudflare a transformé un incident de fournisseur en leçon de dépendance pour un autre

L'événement de juin 2025 a franchi une frontière d'entreprise d'une manière particulièrement instructive. Lepropre rapport de panne de Cloudflareindique que Workers KV dépendait en partie d'un fournisseur de cloud tiers. Lorsque cette dépendance a échoué, Workers KV est devenu indisponible et un large ensemble de produits Cloudflare qui l'utilisaient ont été altérés, y compris Access, Gateway, WARP, Turnstile, Images, Stream, des parties du tableau de bord et d'autres services. Les services CDN et de sécurité de base de Cloudflare n'étaient pas uniformément hors service, mais la dépendance a rendu une défaillance du plan de contrôle de Google Cloud visible à travers des produits vendus sous le nom d'un autre fournisseur.

Ce n'est pas la preuve que l'externalisation est intrinsèquement irresponsable. Les fournisseurs achètent logiquement des services les uns aux autres. C'est la preuve que la distance commerciale d'une dépendance ne réduit pas sa conséquence opérationnelle. Un client peut croire qu'il a diversifié en achetant Google Cloud pour l'infrastructure et Cloudflare pour la sécurité périphérique, pourtant un service de contrôle de Cloudflare peut dépendre de Google Cloud. La chaîne résultante peut être Google Cloud vers Workers KV vers Access vers la connexion opérateur d'un client.

Sans divulgation et test, le client ne peut pas voir que le contrôle secondaire partage le domaine de défaillance primaire.

Cloudflare a accepté sa part de responsabilité. Son rapport décrivait quels services dépendaient de Workers KV, notait que le service de base n'a pas initialement basculé du chemin de stockage tiers, et décrivait les travaux pour réduire ou supprimer les dépendances pour les produits critiques. Google reste responsable de la défaillance de la plateforme en amont; Cloudflare reste responsable d'avoir décidé qu'un service interne critique pouvait en dépendre sans continuité adéquate; le client final reste responsable d'évaluer si l'accès à ses propres systèmes a une route de verre brisé. Ces devoirs sont simultanés, pas mutuellement exclusifs.

Lesreportages contemporainsde l'Associated Press ont enregistré des perturbations visibles sur les services en ligne populaires et des dizaines de milliers de signalements d'utilisateurs. De tels reportages sont utiles pour démontrer la portée publique, mais les décomptes de signalements de panne ne sont pas un recensement des personnes affectées, des demandes ou des pertes financières. Les preuves les plus solides proviennent des rapports techniques des fournisseurs et des données de transaction des clients. La responsabilité doit résister à la fois à la sous-estimation et au spectacle: une cascade de dépendances large importe même lorsqu'aucun total précis de perte globale n'est disponible.

Les contrats et les examens d'architecture devraient donc demander aux fournisseurs d'identifier les dépendances matérielles de quatrième partie pour les fonctions de contrôle, d'identité, de configuration, de statut et de récupération. Ils devraient spécifier les obligations de notification lorsqu'un événement en amont est responsable, préserver les journaux qui permettent aux clients de réconcilier l'impact, et définir si le fournisseur a une alternative testée.

Le client peut ne pas recevoir une carte complète des fournisseurs pour des raisons de sécurité et commerciales, mais il devrait recevoir suffisamment d'assurance pour comprendre la concentration par cloud, plateforme d'identité, opérateur réseau et plan de contrôle géographique.

Un crédit SLA ne prouve pas que la dépendance est acceptable

Les accords de niveau de service sont utiles parce qu'ils définissent un engagement mesurable et un recours. Ils ne sont pas une évaluation complète des risques. Un pourcentage de disponibilité mensuelle fait la moyenne du temps et s'applique souvent à un produit spécifique ou à une topologie configurée. Il peut exclure la configuration client, les segments tiers, les quotas, les fonctionnalités en aperçu ou les défaillances en dehors du service couvert.

Le recours est généralement un crédit sur les dépenses futures, pas une compensation pour les revenus perdus, le travail d'urgence, l'exposition réglementaire ou le préjudice aux utilisateurs du client.

LeSLA Cloud Interconnectactuel, par exemple, différencie les topologies de niveau production des connexions uniques et exige des preuves client pour les réclamations. Ce cadre peut encourager une topologie solide, mais il ne peut pas dire à un conseil d'administration si une perte de quatre heures d'accès hybride est tolérable. Un SLA spécifique à un produit ne décrit pas non plus la défaillance corrélée entre l'API utilisée pour changer un service, la surveillance utilisée pour l'observer et le canal de support utilisé pour le signaler.

Le client a besoin d'un objectif de niveau de service pour son propre parcours utilisateur. Cet objectif devrait inclure les produits cloud, les chemins réseau, les services internes et les fournisseurs nécessaires pour terminer le parcours. Il devrait mesurer à la fois le service en régime permanent et les actions de récupération. Un flux de paiement qui reste opérationnel mais ne peut pas ajouter de capacité peut être sain maintenant et à risque immédiat. Une base de données qui sert les lectures mais ne peut pas promouvoir un réplica peut avoir une capacité de récupération dégradée avant même que les utilisateurs ne voient des erreurs.

Les termes de responsabilité et de crédit de Google sont des allocations juridiques, pas des preuves d'ingénierie. Inversement, les excuses publiques d'un fournisseur ne sont pas une preuve de négligence ou un aveu juridique. Cet article attribue la responsabilité opérationnelle et de gouvernance en fonction du contrôle: qui a conçu le chemin de propagation, qui a accepté la dépendance, qui pouvait la tester et qui doit vérifier la remédiation. La responsabilité juridique dépend du contrat, de la juridiction, des faits et de l'arbitrage en dehors du cadre d'un rapport d'incident technique.

Les conseils d'administration devraient donc demander une exposition quantifiée au-delà de la disponibilité du fournisseur. Combien de revenus ou de service public dépend d'une opération du plan de contrôle? Combien de temps les ressources déjà en cours d'exécution peuvent-elles servir sans mise à l'échelle ou identifiants? Quel est le temps pour déplacer les utilisateurs via un chemin de transit alternatif? Quelles récupérations nécessitent le fournisseur défaillant? Quelles preuves existent du dernier exercice? Un crédit de service appartient au dossier financier; il ne doit jamais être confondu avec la continuité.

La liste de remédiation de Google n'est crédible que lorsqu'elle devient une preuve

Le rapport d'incident de 2025 contient un ensemble solide d'engagements. Google a gelé les changements Service Control et les poussées manuelles de politique après la récupération.

Il a déclaré qu'il modulariserait le service et échouerait en mode ouvert lorsque approprié, auditerait les systèmes qui consomment des données répliquées globalement, propagerait ces données de manière incrémentale avec un temps de validation, exigerait que les binaires critiques soient protégés par des indicateurs de fonctionnalité désactivés par défaut, améliorerait l'analyse statique et les tests de données invalides, auditerait la temporisation exponentielle aléatoire, améliorerait les communications externes et maintiendrait la surveillance et la communication disponibles lorsque Google Cloud est en panne.

Ces actions correspondent particulièrement bien à la chaîne de défaillance observée. Le problème restant est l'assurance. Une promesse peut clore une action post-mortem dans un système de suivi sans prouver que le risque a diminué en production. Google devrait publier l'état d'achèvement, la méthode de validation et les limites résiduelles pour les actions à plus fort impact, même si l'architecture détaillée reste confidentielle.

Pour la sécurité des politiques globales, les preuves pourraient inclure le pourcentage de consommateurs de politique critiques derrière une activation progressive; les taux de rejet automatisés pour les données candidates mal formées; les intervalles d'observation minimum avant l'autorité globale; et les exercices réussis où un mauvais objet est arrêté dans une cohorte. Pour l'isolement des défaillances, cela pourrait inclure des tests montrant qu'un module de quota peut échouer tandis que les vérifications d'API non liées continuent et que les décisions sensibles à la sécurité conservent leur frontière prévue.

Pour la récupération, Google devrait montrer les limites de redémarrage de la flotte, la conformité de la temporisation, la capacité réservée du datastore et les résultats des tests de charge pour une récupération régionale simultanée. Pour la communication, il devrait publier le temps entre le premier impact client et la détection interne, le premier avis public, la première déclaration d'impact délimitée et la disponibilité du chemin de statut indépendant pendant les exercices. Pour l'apprentissage institutionnel, il devrait signaler si des consommateurs globaux similaires en dehors de Service Control ont été trouvés et remédiés.

Les incidents antérieurs renforcent la nécessité de ce suivi. Après 2019, Google a promis un fonctionnement réseau fail-static plus long, une configuration de contrôle persistante, un outillage d'urgence robuste et des tests de catastrophe élargis. Après février 2021, il a promis une régionalisation supplémentaire des composants de contrôle réseau globaux, des pauses automatiques pour les migrations et une meilleure résilience du plan de données lorsque les contrôleurs étaient non réactifs. Après mars 2021, il a promis des domaines fonctionnels pour l'application des politiques de route et des tests de construction de routeur améliorés.

Chaque engagement peut avoir été réalisé dans son propre programme; le dossier public ne fournit pas une vue d'assurance continue montrant comment le risque de mode commun de la plateforme a changé au fil du temps.

Le livre SRE de Google décrit lespost-mortems comme un système d'apprentissage, avec des éléments d'action liés aux causes et sans réduire les incidents complexes à un blâme individuel. Le même principe soutient la responsabilité externe. Le but de la publication de preuves n'est pas d'exposer un employé ou d'inviter les clients à gérer le réseau de Google. C'est de permettre aux clients de distinguer une solution de contournement temporaire d'un contrôle durable, de voir ce qui reste ouvert et de décider si leur propre traitement du risque est adéquat.

Un examen indépendant ajouterait de la valeur pour les contrôles les plus globaux. Il pourrait échantillonner les documents de conception, les enregistrements de déploiement, les résultats d'injection de fautes, l'indépendance du bouton rouge et la clôture des actions. La sortie publique pourrait énoncer la portée, les exceptions et les conclusions sans révéler les détails internes exploitables. L'auto-déclaration fournit une profondeur technique; l'assurance indépendante donne confiance que les critères de clôture n'ont pas été définis uniquement par l'équipe responsable de la livraison.

Ce que les clients devraient tester avant le prochain incident global

Aucun client ne peut mettre un indicateur de fonctionnalité sur le binaire Service Control interne de Google ou changer la façon dont ses tables de politique se répliquent. Les conseils qui disent simplement aux clients de "mieux architecturer" après une défaillance à l'échelle du fournisseur transfèrent la responsabilité de manière injuste. Néanmoins, les clients font des choix conséquents sur la quantité d'autorité qu'une panne de fournisseur a sur leur entreprise.

Commencez par le chemin de service. Identifiez quelles transactions utilisateur continuent si toutes les API de gestion Google Cloud sont indisponibles pendant trois heures. Testez avec les nouveaux déploiements en pause, l'autoscaling gelé, les modifications IAM indisponibles, les modifications d'équilibreur de charge bloquées et le support inaccessible. Mesurez quand la capacité, les identifiants, les certificats, les files d'attente ou les travaux planifiés deviennent le facteur limitant.

Le résultat sera souvent une courbe plutôt qu'une réponse binaire: le service continue à la charge actuelle pendant une période, puis se dégrade à mesure que les actions de contrôle de routine s'accumulent.

Ensuite, testez l'accès opérateur. Conservez des identifiants de verre brisé dont la récupération et la vérification ne nécessitent pas le chemin d'identité cloud principal. Maintenez un espace de travail d'incident minimal, une liste de contacts, des procédures, des diagrammes d'architecture et un éditeur de statut en dehors de Google Cloud. Assurez-vous que l'équipe peut joindre les opérateurs réseau et les fournisseurs critiques sans la suite de collaboration d'entreprise si cette suite partage l'identité Google. Auditez chaque outil d'urgence pour les dépendances cachées au DNS, à l'email, à l'authentification unique et aux secrets.

Testez ensuite les chemins réseau. Retirez chaque session BGP et attachement d'interconnexion lors d'un exercice contrôlé. Confirmez que le trafic passe par le métro et le fournisseur prévus, mesurez la perte de convergence et vérifiez que l'alternative a une capacité à pleine charge. Vérifiez que le repli Internet public n'est pas bloqué par le pare-feu, le routage ou des hypothèses d'adresse source. Pour le peering VPC, prouvez les routes exactes importées et exportées et ne supposez pas la transitivité. Pour le transit multi-cloud, testez la cohérence des données et l'identité ainsi que les paquets.

Pré-provisionnez ce qui ne peut pas être créé pendant une panne du plan de contrôle. Cela peut inclure les équilibreurs de charge régionaux, les enregistrements DNS, les clusters secondaires, les bases de données de secours, les quotas, les comptes de service, les artefacts et les tunnels réseau. Gardez les changements suffisamment petits pour qu'une dernière configuration connue bonne reste utilisable. Pratiquez un mode dégradé qui abandonne les fonctionnalités non essentielles au lieu d'émettre une rafale de tentatives ou de demandes de mise à l'échelle vers un fournisseur altéré.

Enfin, réconciliez après l'exercice. Déterminez quelles transactions ont échoué, lesquelles ont été réessayées, lesquelles ont été dupliquées, lesquelles sont restées en file d'attente et quels clients ont besoin d'un avis. La restauration du fournisseur ne garantit pas l'exactitude de l'application. Les objectifs de récupération devraient inclure la résorption des arriérés et la validation des données, pas seulement un contrôle de santé HTTP.

Pour les petites organisations, la version proportionnée peut être modeste: une vérification de disponibilité externe, une page de statut sur un autre fournisseur, des coordonnées et procédures exportées, des sauvegardes testées, des procédures manuelles connues et une décision documentée sur la justification du coût multi-cloud. La responsabilité n'est pas synonyme d'architecture maximale. C'est la capacité de montrer qu'une décision de risque consciente a remplacé une dépendance accidentelle.

Une fiche de score pour la responsabilité du plan de contrôle et du réseau

Un conseil d'administration, un régulateur ou un client majeur n'a pas besoin de code source propriétaire pour poser des questions précises. Il a besoin de preuves qui correspondent aux modes de défaillance observés.

La fiche de score doit être lue en travers des lignes. Un indicateur de fonctionnalité sans statut indépendant ne suffit pas. Quatre attaches d'interconnexion sans diversité de fournisseur et de routeur peuvent ne pas suffire. Une application multi-région sans récupération pré-provisionnée peut encore dépendre du contrôleur global. La fiabilité vient de la composition des contrôles et de la preuve que la composition fonctionne en cas de défaillance.

Le signal durable est la vitesse de l'autorité partagée

Les plateformes cloud créent de la valeur en centralisant les décisions. Une politique peut régir des milliers de projets. Un réseau peut transporter du trafic entre les continents. Une API peut créer une infrastructure en quelques secondes. Le même levier détermine le rayon d'impact de l'erreur.

L'incident de juin 2025 n'est donc pas mieux retenu comme un pointeur nul. Les pointeurs nuls sont des défauts logiciels ordinaires. Ce qui a rendu celui-ci globalement conséquent, c'est que le code dormant, la politique invalide, la réplication rapide, les lecteurs régionaux, le redémarrage synchronisé, la surveillance partagée et les fournisseurs en aval ont formé une seule chaîne. Le système était distribué, mais l'autorité n'était pas suffisamment partitionnée.

La réponse de Google a identifié les bons thèmes: propagation incrémentale, indicateurs de fonctionnalité, défaillance modulaire, temporisation et communication indépendante. Les clients devraient s'attendre à la preuve que ces changements fonctionnent, tout en étant honnêtes sur les risques qu'ils possèdent encore. Une charge de travail peut être répartie sur les régions et dépendre encore d'une décision globale. Une entreprise peut acheter deux réseaux et utiliser encore une seule route vers le destin. Une page de statut peut être publique et vivre encore à l'intérieur de l'incident.

La norme de responsabilité appropriée n'est pas qu'un cloud global ne doit jamais échouer. C'est que l'autorité globale doit se déplacer pas plus vite que les contrôles qui la valident; que les systèmes régionaux doivent pouvoir rejeter ou survivre à un état commun non sécurisé; que les chemins réseau et de récupération doivent être indépendants en fonctionnement, pas seulement en noms; et que les clients doivent pouvoir voir la défaillance pendant qu'il est encore temps d'agir. Dans un plan de contrôle cloud, la vitesse est le pouvoir. La résilience commence par placer des limites sur où ce pouvoir peut voyager.