Une politique, chaque région: Google Cloud et la responsabilité d’un plan de contrôle global

Résumé

• Le 12 juin 2025, des champs vides non intentionnels 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 feature flag; le traitement de la politique a provoqué le crash des binaires de Service Control dans chaque région. De nombreuses API de 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 pu continuer à servir en grande partie, mais les chemins de gestion et d'API nécessaires pour inspecter, modifier, dimensionner ou récupérer les services ont été largement perturbés.
• Le bogue immédiat était étroit, mais l'échec de responsabilité était architectural. Google avait des instances de service distribuées régionalement et un déploiement binaire progressif, mais la politique déclencheuse a été répliquée globalement en quelques secondes. Le mécanisme d'arrêt a donc contourné l'apprentissage régional que le déploiement était censé fournir. La récupération a ensuite créé un effet de troupeau contre Spanner dans les grandes régions, car les tâches de redémarrage manquaient de backoff exponentiel 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éschedulé des clusters de plan de contrôle réseau dans plusieurs emplacements physiques, des routes BGP ont été retirées, et les outils nécessaires au diagnostic ont été en compétition pour le réseau congestionné. En février 2021, un bogue latent déclenché lors de modifications de quotas de peering a bloqué la programmation réseau globale. En mars 2021, des routes invalides ont exposé un défaut connu du fournisseur et certains emplacements Cloud Interconnect manquaient de diversité suffisante de fournisseurs de routeurs. Ce ne sont pas un bogue logiciel récurrent; ce sont des tests répétés de confinement en mode commun, d'autorité de changement, de récupération réseau et de visibilité véridique.
• Google est responsable de la validation des données répliquées globalement, de l'isolement des fonctions du plan de contrôle, de la préservation du comportement fail-static ou fail-open lorsque c'est sûr, du maintien des communications d'incident indépendantes et de la preuve que les correctifs promis ont été achevés. 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 de l'extérieur du fournisseur, de tester les modes dégradés et d'acheter une diversité de routes et de fournisseurs plutôt que de compter sur des liens nominaux. Le déploiement multi-région réduit de nombreux risques; il n'échappe pas, en soi, à un plan de politique global ou à un backbone partagé.

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'électricité, 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 demande d'API est dans les limites du 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'identifiants, 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 d'infrastructure totale et plus qu'un problème d'API ordinaire. Le rapport d'incident complet de Service Control de Google indique que les ressources existantes de streaming et d'infrastructure en tant que service n'ont pas été directement affectées par la panne principale.

Pourtant, une longue liste de produits a subi 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 récit public de Google. Le 29 mai, une nouvelle fonctionnalité de Service Control pour des vérifications supplémentaires des politiques de quota a été déployée région par région. Le déploiement binaire s'est terminé sans exposer le défaut 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 flag qui aurait pu l'activer progressivement pour des projets sélectionnés, et son traitement des données invalides permettait à une valeur nulle de faire planter le processus.

Le 12 juin vers 10h45 heure du Pacifique, une politique de quota contenant des champs vides non intentionnels a été écrite dans les tables régionales Spanner utilisées par Service Control. Parce que 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 avait 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 voie d'activation contrôlée 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 malformée est exact mais incomplet. La politique était le déclencheur. Les causes plus larges étaient le degré d'autorité qui lui était attaché 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 politique unique a pu devenir un état d'échec exécutable partout avant qu'une région, une cohorte de projet ou un validateur fantôme 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 à l'analyse des risques. Alors que les tâches Service Control redémarraient, elles ont placé une demande concentrée sur la table Spanner en dessous. Les tâches manquaient du backoff exponentiel aléatoire nécessaire pour éviter les tentatives synchronisées. Google a dû limiter la création de tâches et acheminer le trafic vers des bases de données multi-régions. En d'autres termes, la première panne é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 le danger. Son chapitre sur la gestion des pannes en cascade explique comment les tentatives et les redémarrages peuvent maintenir un backend surchargé et comment un backoff exponentiel aléatoire, une dégradation gracieuse et un écrêtage contrôlé de la charge 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 ce backoff. L'importance n'est pas que Google n'ait pas suivi une phrase dans un livre.

C'est qu'une classe connue de risques 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 manuel. Un système qui peut être désactivé en toute sécurité a besoin d'un mécanisme d'arrêt dont les propres dépendances sont comprises. Une flotte qui peut planter ensemble a besoin d'un régulateur de redémarrage, d'un contrôle d'admission, d'une gigue et d'un taux de récupération maximal testé. Un datastore censé absorber la récupération de la flotte a besoin d'une capacité réservée ou d'un chemin de lecture dégradé.

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

La longue traîne importe également pour la communication avec les clients. Le rapport préliminaire de Google décrivait un événement global de trois heures, tandis que la page d'incident continuait à 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 avait échoué pendant la fenêtre principale a peut-être eu des tentatives, des travaux en file d'attente, des workflows partiels, des caches obsolètes 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 du client, pas la preuve que chaque processus métier est complet.

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

La livraison progressive est supposée transformer la distance en preuve. Un changement atteint une petite population; les opérateurs observent son comportement; ce n'est qu'alors qu'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 ensuite échoué. La politique activatrice a suivi un mécanisme de distribution différent, optimisé pour rendre l'état des quotas global en quelques secondes. Le code était progressif; la signification du code ne l'était pas.

Il s'agit d'un échec de contrôle des changements subtil mais lourd de conséquences. 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 de production, cependant, provient de leur combinaison. Une fonctionnalité dormante peut passer toutes les portes régionales 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 d'urgence peut exister mais dépendre encore du plan de contrôle défaillant pour prendre effet.

Les directives actuelles d'infrastructure de Google reconnaissent ce risque. Le guide des éléments constitutifs de la fiabilité indique que les ressources globales sont résilientes aux incidents d'infrastructure zonaux et régionaux mais peuvent devenir des points uniques de défaillance lorsqu'une erreur de configuration critique a une portée globale. Il recommande un contrôle minutieux des changements et, pour les charges de travail exceptionnellement exigeantes, des replis régionaux de défense en profondeur.

Le guide compagnon de gestion et de surveillance conseille un 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 danger de rayon d'explosion pour les mauvais états logiques.

Une correction complète nécessite un modèle de publication joint. 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. La nouvelle politique doit être lue en ombre avant d'être autoritaire. L'activation doit commencer avec des projets internes ou une région dé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émentielle 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 opportun et cohérent. 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 comme données inertes, être analysée et évaluée par rapport à un trafic semblable à la production, et ne devenir effective qu'après la réussite des vérifications. Les régions peuvent conserver une politique de dernier état connu 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.

L'ouverture en cas d'échec est une décision métier et de sécurité, pas un slogan

Google s'est engagé à modulariser Service Control afin qu'une fonction de politique affectée puisse être isolée et ouverte en cas d'échec, permettant aux demandes d'API de continuer si la vérification correspondante échouait. Il s'agit d'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 de prévention des abus n'ont pas la même conséquence lorsqu'ils sont indisponibles.

Pour un contrôle de quota à faible risque, un service permissif temporaire peut être plus sûr que de rejeter chaque demande d'API client. Le fournisseur peut réconcilier l'utilisation plus tard, plafonner l'exposition par projet et préserver la disponibilité de base. Pour un contrôle d'autorisation, autoriser aveuglément les demandes pourrait créer un incident de sécurité pire qu'un temps d'arrêt. Pour la création de ressources, un cache local limité de la politique récente peut ê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 l'infrastructure de service de Google sépare les plans de gestion, de contrôle et de données tout en montrant à quel point les fonctions de la plateforme sont larges: authentification, autorisation, quota, limitation de débit, audit, facturation, journalisation et surveillance. Cette ampleur est précisément pourquoi un comportement modulaire en cas d'échec est important. 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 données du dernier état connu? 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 le 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 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 obsolètes, 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 garanties non liées. Ils doivent mesurer le comportement visible par le client pendant le fonctionnement dégradé et vérifier que la récupération ne rejoue pas de manière imprévisible des modifications rejetées ou en double.

Le système d'état partageait 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 les preuves du service ont échoué ensemble. La panne a non seulement perturbé la production mais aussi le contrôle épistémique: la capacité à savoir ce qui se passait, à décider de basculer et à 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, le rapport d'incident indique que les outils internes de Cloud Support ont été affectés, que les clients ne pouvaient pas créer ou consulter les dossiers de support dans la console et que la communication du tableau de bord a été retardée jusqu'à après la fin de l'impact principal. Cet événement provenait de la gestion automatisée des quotas réduisant la capacité du système d'identité central.

Les configurations existantes du plan de données réseau 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 le même sort que les services qu'ils sont censés diagnostiquer.

Google a depuis documenté un modèle de communication plus explicite. Son guide de communication d'incident distingue Personalized Service Health, qui utilise le contexte du projet et peut s'intégrer aux alertes et aux API, du tableau de bord public Cloud Service Health. Le même guide reconnaît que 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. Ce conseil est judicieux, mais juin 2025 montre que le canal public a également besoin d'indépendance opérationnelle.

L'obligation du fournisseur est de maintenir une voie de publication accessible de l'extérieur, alimentée et administrée indépendamment, avec des modèles d'incident pré-autorisés et des entrées hors bande provenant du commandement des incidents. Elle ne doit pas nécessiter la console normale, le plan d'identité client, la pile de surveillance principale ou le service de contrôle faisant l'objet de l'enquête. 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 la prochaine heure de mise à jour.

Les clients ont une obligation parallèle. Le guide d'intégration pour Personalized Service Health de 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, métriques d'application, télémétrie réseau et alarmes de processus métier. Au moins un chemin doit fonctionner en dehors de Google Cloud et aboutir à un canal d'incident qui ne dépend pas de l'identité Google.

L'état du fournisseur est une corroboration, pas le premier et unique détecteur.

Il y a une raison de gouvernance à cette séparation. Une page d'état retardée modifie le comportement des clients. Les équipes peuvent perdre du temps à chercher dans leurs propres déploiements, effectuer des retours arrière risqués, passer à l'échelle sur un plan de contrôle défaillant ou reporter un basculement en attendant une confirmation. Le silence du support peut également amener les fournisseurs en aval à publier des spéculations. La disponibilité des communications est donc un contrôle des risques avec des objectifs mesurables de détection et de publication, pas une courtoisie ajoutée après le début du travail 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 existantes de streaming et d'infrastructure en tant que service n'ont pas été affectées doit être lue attentivement. Elle démontre une séparation utile entre les parties du plan de données et le chemin de gestion. Elle ne signifie pas qu'une application était sûre simplement parce que ses machines virtuelles en cours d'exécution sont restées opérationnelles.

Les systèmes cloud sont dynamiques. Les auto-scalers 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 les chemins de contrôle du fournisseur derrière une demande apparemment simple. Les intervenants en 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 à transférer tandis que le processus métier autour de lui perd la capacité de s'adapter.

La panne réseau de février 2021 rend cette limite concrète. Le rapport d'incident sur l'échec de programmation réseau de Google indique qu'un bogue latent a été déclenché lorsque le plan de contrôle réseau global a retraité les opérations associées aux modifications de quotas de peering. Les VM et points de terminaison réseau nouveaux, mis à jour, supprimés ou migrés 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 à l'échelle mondiale;

environ 1 000 clusters GKE ont été affectés par l'incapacité de provisionner des nœuds ou des clusters; certaines créations d'instances et mises à jour d'équilibreurs de charge ont échoué à des taux très élevés. Un serveur existant sain n'a pas aidé un groupe d'auto-scaling qui avait besoin d'un nouveau serveur en réseau.

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

Le guide d'architecture de reprise après sinistre de Google distingue les actions du plan de données des mises à jour du plan de contrôle et explique la résilience spécifique au service. Son guide de conception d'infrastructure fiable recommande d'éviter ou de minimiser les dépendances aux actions non liées au plan de données pendant les pannes, comme 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 frontend global ne tombe en panne.

Les enregistrements DNS, les identifiants, les routes, les images et les manuels peuvent être disponibles sans une opération administrative de dernière minute.

Pour chaque étape de récupération, un opérateur doit 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 doit supprimer ces dépendances une par une. Un plan qui réussit uniquement lorsque la console, IAM, Service Control, la programmation réseau globale et la région principale sont tous sains 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 seule limite d'automatisation

Le 2 juin 2019, les projets Google Cloud dans plusieurs régions américaines ont subi une perte de paquets élevée pendant plus de trois heures. Certains services Google n'ont pas pu rediriger complètement les utilisateurs vers des régions non affectées. Le rapport d'incident réseau décrivait plusieurs défaillances qui se sont combinées en une panne majeure: les tâches du plan de contrôle réseau étaient configurées pour s'arrêter lors d'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éschedulier des clusters logiciels indépendants même lorsqu'ils étaient dans des emplacements physiques différents.

Le réseau a d'abord 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é 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 similarité 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 d'urgence en 2025. Les deux ont perturbé 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 du contrôle réseau et de l'automatisation de la maintenance; l'incident de 2025 était une défaillance des données de politique et du contrôle API. La responsabilité ne doit pas les aplatir en "Google a encore eu une panne". La valeur de la comparaison est de tester si l'organisation découvre de manière répétée que des composants nominativement indépendants partagent toujours 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 locale du plan de contrôle, l'extension de la durée du fonctionnement réseau fail-static, le renforcement des outils d'urgence et l'expansion des tests de reprise après sinistre. La question actuelle de responsabilité n'est pas de savoir si ces actions auraient empêché le pointeur nul non lié de 2025.

Il s'agit de savoir si la méthode de gouvernance qui les sous-tend est devenue une norme: cartographier l'autorité commune, persister l'état sûr, maintenir 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 correction 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é du peering et du transit concerne le destin, pas le nombre de circuits

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

Le rapport d'incident du backbone de Google du 17 mars 2021 illustre cette différence. La connexion de nouveaux routeurs a modifié 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 d'une cascade plus large mais a produit une perte de paquets pendant la convergence. Une atténuation manuelle a provoqué une autre période de congestion, et certains emplacements Cloud Interconnect ont eu un impact prolongé car 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 une revue de résilience doit aller au-delà de "nous avons deux liens". La revue doit demander qui possède chaque chemin de fibre, quel bâtiment et domaine de disponibilité de bord il utilise, quel fournisseur de routeur et train de 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. Elle doit observer les changements de route réels et exécuter des retraits planifiés, pas accepter un diagramme de topologie comme preuve.

L' aperçu de Cloud Interconnect de Google propose des configurations à 99,9 et 99,99 pour cent et explique qu'une seule connexion n'a pas de SLA de disponibilité. Le guide Partner Interconnect demande quatre rattachements VLAN sur deux métros et domaines de disponibilité de bord pour sa topologie recommandée à 99,99 pour cent; il note également que le segment du fournisseur en dehors du réseau de Google nécessite sa propre assurance. L'utilisation de 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 en cas de basculement.

Le peering à l'intérieur du cloud n'est pas un transit par défaut. La documentation VPC Network Peering de Google indique que le peering est non transitif: si le réseau A est en peering avec B et que A est également en peering avec C, B n'obtient pas pour autant la connectivité à C. Cette contrainte peut être une limite 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 car la topologie annoncée n'a jamais été prise en charge.

Lorsqu'un transit est requis, il doit être conçu explicitement, avec l'échange de routes, la politique, la capacité, l'inspection de sécurité et le comportement en cas d'échec 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. Un interconnect privé et un VPN Internet peuvent offrir une meilleure diversité administrative, mais tous deux peuvent encore dépendre du backbone de Google ou de la même identité client et du même DNS. Un deuxième cloud peut réduire la concentration du fournisseur uniquement si l'application, les données, l'identité, les outils de déploiement, l'observabilité et le basculement DNS peuvent y fonctionner indépendamment. Un nombre de logos n'est pas une architecture.

Le multi-région est une protection solide 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 panne 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 car une limite d'automatisation du plan de contrôle traversait des emplacements physiques. L'incident de quota de peering de 2021 a affecté la programmation réseau à l'échelle mondiale car le contrôleur concerné et les ressources VPC avaient une portée globale. L'événement Service Control de 2025 a affecté chaque région car le plan de politique était global. Dans chaque cas, davantage de réplicas d'application à l'intérieur du domaine administratif affecté n'auraient 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 uniques de défaillance 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 frontend global. Les clients ont besoin d'un graphe de dépendances qui marque à la fois la géographie et l'autorité.

Ce graphe doit inclure au moins cinq couches. Premièrement, l'exécution: où les processus et les données s'exécutent réellement. Deuxièmement, le contrôle: quelles API créent, acheminent, autorisent, dimensionnent et basculent ces ressources. Troisièmement, l'accès: quels chemins DNS, peering, transit, interconnect, VPN et backbone connectent les utilisateurs et les opérateurs. Quatrièmement, l'observation: où vivent les journaux, les métriques, les flux d'état, les pages et le support. Cinquièmement, la récupération: quels référentiels, identifiants, humains et services externes sont nécessaires pour restaurer le fonctionnement.

Une dépendance est indépendante seulement si le même événement crédible ne peut pas la désactiver avec 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 livrées via 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, référentiel d'artefacts ou connexion d'opérateur vit dans Google Cloud.

Cette analyse ne doit pas devenir une demande coûteuse que chaque petite charge de travail fonctionne sur trois fournisseurs. Les contrôles doivent être proportionnés. Un site d'information publique peut accepter quelques heures d'indisponibilité et garder une page d'état 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 la conséquence et d'obtenir l'acceptation explicite du propriétaire de l'entreprise.

Cloudflare a transformé un incident de fournisseur en une 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. Le propre rapport d'incident de Cloudflare indique 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é perturbés, notamment Access, Gateway, WARP, Turnstile, Images, Stream, des parties du tableau de bord et d'autres services.

Le CDN de base et les services de sécurité de Cloudflare n'étaient pas uniformément en panne, mais la dépendance a rendu une panne du plan de contrôle de Google Cloud visible à travers des produits vendus sous le nom d'un autre fournisseur.

Ce n'est pas une preuve que l'externalisation est intrinsèquement irresponsable. Les fournisseurs achètent logiquement des services les uns aux autres. C'est une preuve que la distance commerciale d'une dépendance ne réduit pas sa conséquence opérationnelle. Un client peut croire qu'il s'est diversifié en achetant Google Cloud pour l'infrastructure et Cloudflare pour la sécurité de périphérie, mais 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 d'opérateur d'un client.

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

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 panne de 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 dispose d'une voie de secours. Ces devoirs sont concomitants, pas mutuellement exclusifs.

Le reportage contemporain de l'Associated Press a enregistré des perturbations visibles dans les services en ligne populaires et des dizaines de milliers de signalements d'utilisateurs. Un tel reportage est utile pour démontrer la portée publique, mais les décomptes de rapports d'incident 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 global précis de pertes n'est disponible.

Les contrats et les revues d'architecture doivent 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, d'état et de récupération. Ils doivent spécifier les devoirs de notification lorsqu'un événement en amont est responsable, conserver les journaux qui permettent aux clients de réconcilier l'impact et définir si le fournisseur dispose d'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 doit 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 car ils définissent un engagement mesurable et un recours. Ils ne constituent pas une évaluation complète des risques. Un pourcentage de disponibilité mensuel moyenne le 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 pannes en dehors du service couvert.

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

Le SLA actuel de Cloud Interconnect, par exemple, différencie les topologies de niveau production des connexions uniques et exige des preuves du 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 de l'accès hybride est tolérable. Un SLA par produit ne décrit pas non plus la défaillance corrélée entre l'API utilisée pour modifier 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 doit inclure les produits cloud, les chemins réseau, les services internes et les fournisseurs nécessaires pour réaliser le parcours. Il doit 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 des lectures mais ne peut pas promouvoir un réplica peut avoir une récupérabilité dégradée avant même que les utilisateurs voient des erreurs.

Les conditions de responsabilité et de crédit de Google sont des allocations légales, pas des preuves techniques. Inversement, des excuses publiques d'un fournisseur ne sont pas une preuve de négligence ou un aveu juridique. Cet article attribue une responsabilité opérationnelle et de gouvernance basée sur le 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 correction. La responsabilité légale dépend du contrat, de la juridiction, des faits et de l'adjudication en dehors du champ d'un rapport d'incident technique.

Les conseils d'administration doivent donc demander une exposition quantifiée au-delà de la disponibilité du fournisseur. Combien de revenus ou de services publics dépendent 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 ni 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 registre financier; il ne doit jamais être confondu avec la continuité.

La liste de correctifs de Google est crédible seulement lorsqu'elle devient preuve

Le rapport d'incident de 2025 contient un ensemble solide d'engagements. Google a gelé les modifications de 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 l'ouvrirait en cas d'échec là où c'est approprié, auditerait les systèmes qui consomment des données répliquées globalement, propagerait ces données de manière incrémentielle avec un temps de validation, exigerait que les binaires critiques soient protégés par des feature flags désactivés par défaut, améliorerait l'analyse statique et les tests de données invalides, auditerait le backoff exponentiel aléatoire, améliorerait les communications externes et maintiendrait la surveillance et les communications disponibles lorsque Google Cloud est en panne.

Ces actions correspondent exceptionnellement bien à la chaîne de défaillance observée. La question restante est l'assurance. Une promesse peut fermer une action de post-mortem dans un système de suivi sans prouver que le risque a diminué en production. Google devrait publier l'état d'avancement, la méthode de validation et les limites résiduelles pour les actions les plus impactantes, 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 critiques de politiques derrière une activation progressive; les taux de rejet automatisé pour les données candidates malformées; les intervalles d'observation minimaux avant l'autorité globale; et des exercices réussis dans lesquels un mauvais objet est arrêté dans une cohorte. Pour l'isolement des pannes, elles pourraient inclure des tests montrant qu'un module de quota peut échouer tandis que des vérifications d'API non liées continuent et que les décisions sensibles à la sécurité conservent leur limite prévue.

Pour la récupération, Google devrait montrer les limites de redémarrage de la flotte, la conformité du backoff, la capacité réservée du datastore et les résultats des tests de charge pour la récupération régionale simultanée. Pour la communication, il devrait publier le temps écoulé entre le premier impact client et la détection interne, le premier avis public, la première déclaration d'impact circonscrite et la disponibilité de la voie d'état indépendante 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 corrigés.

Les incidents antérieurs renforcent le besoin de ce suivi. Après 2019, Google a promis un fonctionnement réseau fail-static plus long, une configuration de contrôle persistante, des outils d'urgence robustes et des tests de catastrophe étendus. Après février 2021, il a promis une régionalisation supplémentaire des composants globaux du plan de contrôle réseau, 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 de la politique de routage et une meilleure test de construction de routeurs. Chaque engagement a peut-être été achevé 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 évolué au fil du temps.

Le livre SRE de Google décrit les post-mortems comme un système d'apprentissage, avec des actions liées aux causes et sans réduire les incidents complexes à un blâme individuel. Le même principe soutient la responsabilité externe. Le but de publier des 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 temporaire d'un contrôle durable, de voir ce qui reste ouvert et de décider si leur propre traitement des risques est adéquat.

Une revue indépendante ajouterait de la valeur pour les contrôles les plus globaux. Elle pourrait échantillonner des documents de conception, des enregistrements de déploiement, des résultats d'injection de pannes, l'indépendance du bouton d'urgence et la clôture des actions. La sortie publique pourrait indiquer la portée, les exceptions et les conclusions sans révéler des éléments internes exploitables. L'auto-rapport fournit une profondeur technique; l'assurance indépendante fournit la 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 doivent tester avant le prochain incident mondial

Aucun client ne peut activer un feature flag du binaire interne Service Control de Google ni modifier la façon dont ses tables de politique se répliquent. Les conseils qui disent aux clients simplement de "mieux architecturer" après une panne à l'échelle du fournisseur transfèrent la responsabilité de manière injuste. Néanmoins, les clients font des choix conséquents sur le degré 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 suspendus, l'auto-scaling 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 un certain temps, puis se dégrade à mesure que les actions de contrôle de routine s'accumulent.

Ensuite, testez l'accès des opérateurs. Conservez des identifiants de secours 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 manuels, des diagrammes d'architecture et un éditeur d'état 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 en matière de DNS, de messagerie, d'authentification unique et de secrets.

Testez ensuite les chemins réseau. Retirez chaque session BGP et attachement d'interconnect lors d'un exercice contrôlé. Confirmez que le trafic se déplace via le métro et le fournisseur prévus, mesurez la perte de convergence et vérifiez que l'alternative a la capacité de charge complète. Vérifiez que le repli Internet public n'est pas bloqué par des hypothèses de pare-feu, de routage ou d'adresse source. Pour le peering VPC, prouvez les routes importées et exportées exactes 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 des équilibreurs de charge régionaux, des enregistrements DNS, des clusters secondaires, des bases de données de secours, des quotas, des comptes de service, des artefacts et des tunnels réseau. Gardez les modifications suffisamment petites pour qu'une configuration de dernier état connu reste utilisable. Entraînez 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 défaillant.

Enfin, réconciliez après l'exercice. Déterminez quelles transactions ont échoué, lesquelles ont été retenté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 doivent inclure le traitement des arriérés et la validation des données, pas seulement une vérification de santé HTTP.

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

Un tableau de bord pour la responsabilité du plan de contrôle et du réseau

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

Le tableau de bord doit être lu en lignes. Un feature flag sans état indépendant ne suffit pas. Quatre attaches d'interconnect 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 panne.

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 le trafic entre les continents. Une API peut créer une infrastructure en quelques secondes. Le même effet de levier détermine le rayon d'explosion de l'erreur.

La panne de juin 2025 n'est donc pas mieux mémorisée comme un pointeur nul. Les pointeurs nuls sont des défauts logiciels ordinaires. Ce qui a rendu celui-ci mondialement conséquent, c'est que du code dormant, une politique invalide, une réplication rapide, des lecteurs régionaux, un redémarrage synchronisé, une surveillance partagée et des fournisseurs en aval formaient 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émentielle, feature flags, échec modulaire, backoff et communication indépendante. Les clients doivent s'attendre à des preuves que ces changements fonctionnent, tout en étant honnêtes quant aux risques qu'ils possèdent encore. Une charge de travail peut être répartie sur plusieurs régions et dépendre encore d'une seule décision globale. Une entreprise peut acheter deux réseaux et utiliser encore une seule route vers le destin. Une page d'état peut être publique et vivre encore à l'intérieur de l'incident.

Le niveau de responsabilité approprié n'est pas qu'un cloud global ne doit jamais échouer. C'est que l'autorité globale ne doit pas se déplacer 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ûr; 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 panne alors 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 à l'endroit où ce pouvoir peut voyager.