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 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 d'une gestion d'erreur appropriée et d'une protection par indicateur de fonctionnalité; le traitement de la politique a provoqué le plantage 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 largement pu continuer à fonctionner, mais les chemins de gestion et d'API nécessaires pour inspecter, modifier, redimensionner ou récupérer les services ont été largement altérés.
• Le bogue immédiat était étroit, mais l'échec de responsabilité était architectural. Google disposait d'instances de service réparties régionalement et d'un déploiement binaire échelonné, et pourtant la politique déclenchante a été répliquée mondialement 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 troupeau sur Spanner dans les grandes régions, car les tâches redémarrées ne disposaient pas d'un backoff exponentiel aléatoire. L'infrastructure publique de Cloud Service Health dépendait également de l'environnement affecté, retardant la première notification de Google d'environ une heure.
• Les 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ésordonnancé les clusters du plan de contrôle réseau dans plusieurs emplacements physiques, les routes BGP ont été retirées et les outils de diagnostic ont été en concurrence pour le réseau congestionné. En février 2021, un bogue latent déclenché lors des modifications de quota de peering a bloqué la programmation réseau mondiale. En mars 2021, des routes non valides ont révélé un défaut connu d'un fournisseur et certains emplacements Cloud Interconnect manquaient de diversité de fournisseurs de routeurs. Il ne s'agit pas d'un seul défaut logiciel récurrent; ce sont des tests répétés de confinement en mode commun, d'autorité de modification, de récupération réseau et de visibilité véridique.
• Google est responsable de la validation des données répliquées mondialement, de l'isolation des fonctions du plan de contrôle, de la préservation du comportement fail-static ou fail-open lorsque cela est sûr, du maintien de l'indépendance des communications d'incident et de la preuve que les mesures correctives promises ont été achevé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 routes et de fournisseurs plutôt que de compter les liens nominaux. Le déploiement multi-régions réduit de nombreux risques; il ne permet pas, en soi, d'échapper à un plan de politique mondial ou à un backbone partagé.

La panne fut une décision de contrôle prise partout simultanément

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 requête API est dans les quotas, et où le trafic doit aller. Les applications peuvent continuer à traiter le travail existant lorsque cette autorité est momentanément indisponible, mais elles deviennent fragiles lorsqu'elles ont besoin d'une nouvelle instance, d'un changement de configuration, d'une décision de justificatif d'identité, 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 de l'infrastructure et plus qu'un problème API ordinaire. Lerapport complet d'incident 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 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 inhabituellement 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 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 indicateur qui aurait pu l'activer progressivement pour des projets sélectionnés, et son traitement des données non valides permettait à une valeur nulle de faire planter le processus. Le 12 juin, vers 10 h 45, heure du Pacifique, une politique de quota contenant des champs vides non intentionnels a été écrite dans les tables Spanner régionales utilisées par Service Control. Parce que les métadonnées de quota étaient conçues pour se déplacer mondialement 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 ensuite rencontré la même entrée et est entré dans une boucle de plantage.

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 d'un ingénieur appuyant sur le mauvais bouton. Un système de production a accepté des données de politique structurellement non sûres, un chemin critique manquait de gestion d'erreur défensive, une fonctionnalité a atteint toutes les régions sans 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 non valide en un événement mondial.

Qualifier l'incident de panne due à une politique mal formée est exact mais incomplet. La politique était le déclencheur. Les causes plus larges étaient l'étendue de l'autorité qui y é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. Au redémarrage des tâches Service Control, elles ont exercé une demande concentrée sur la table Spanner sous-jacente. Les tâches n'avaient pas le backoff exponentiel aléatoire nécessaire pour empêcher les nouvelles tentatives synchronisées. Google a dû limiter la création de tâches et diriger 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 mondiales; 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 surla gestion des défaillances en cascadeexplique comment les nouvelles tentatives et les redémarrages peuvent maintenir un backend surchargé et comment le backoff exponentiel aléatoire, la dégradation gracieuse et le délestage 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 ce backoff. L'importance n'est pas que Google n'a pas suivi une phrase dans un livre. C'est qu'une classe connue de danger 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 sauvegarde étaient mondiales.

Les plans de récupération doivent donc être évalués en tant qu'architectures de production, et non comme des paragraphes de manuel. 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 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 de 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égions pendant l'événement, cet itinéraire 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 mondial de trois heures, tandis que la page d'incident continuait de répertorier la récupération des produits jusqu'à 18 h 18. 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 nouvelles tentatives, des travaux en file d'attente, des flux de travail 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 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; ce n'est qu'ensuite qu'il se déplace 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 d'activation a suivi un mécanisme de distribution différent, optimisé pour rendre l'état des quotas mondial en quelques secondes. Le code était progressif; la signification du code ne l'était pas.

Il s'agit d'un échec subtil mais conséquent du contrôle des modifications. Les équipes examinent souvent les binaires, la configuration, le schéma, la politique et les données comme des objets distincts. Le comportement en production provient cependant 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 le rédacteur mais invalide pour un lecteur plus ancien. Une politique répliquée mondialement peut rendre les canaris régionaux inutiles. Un bouton rouge peut exister mais toujours dépendre du plan de contrôle cassé pour prendre effet.

Les directives actuelles d'infrastructure de Google reconnaissent ce risque. Leguide des éléments constitutifs de la fiabilitéindique que les ressources mondiales 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 mondiale. Il recommande un contrôle prudent des modifications et, pour les charges de travail exceptionnellement exigeantes, des solutions de repli régionales de défense en profondeur. Leguide de gestion et de surveillancecompagnon conseille un déploiement progressif et un examen plus approfondi des ressources mondiales. L'incident de 2025 applique la même logique à l'intérieur du fournisseur: la portée mondiale est un avantage de fiabilité contre les pannes physiques et un danger de rayon d'explosion 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 de lecteur, 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 anciennes, nouvelles, manquantes et corrompues. Une nouvelle politique doit faire l'objet d'une lecture fantôme avant de faire autorité. L'activation doit commencer par des projets internes ou une région délimitée et s'arrêter automatiquement en cas de plantage, de latence ou de dépassement 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 mondialement cohérent.

Cela ne signifie pas que chaque politique mondiale devrait 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 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 comme bonne lorsqu'un nouvel objet est invalide. Les lecteurs peuvent distinguer la corruption d'un refus légitime. La cohérence mondiale n'est pas incompatible avec la sécurité échelonnée; elle nécessite simplement plus qu'une réplication rapide.

Le « fail open » est une décision commerciale 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 basculer en mode ouvert, permettant aux demandes 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. Une vérification 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 une vérification de quota à faible risque, un service temporairement permissif peut être plus sûr que de rejeter chaque demande API client. Le fournisseur peut réconcilier l'utilisation ultérieurement, plafonner l'exposition par projet et préserver la disponibilité de base. Pour une vérification d'autorisation, autoriser aveuglément les demandes 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 autorisation 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 l'étendue des fonctions de la plateforme: authentification, autorisation, quota, limitation de débit, audit, facturation, journalisation et surveillance. C'est précisément cette étendue qui rend le comportement modulaire en cas de panne important. Un seul analyseur ou 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 catégories de vérification utilisent les dernières données connues comme bonnes? Lesquelles peuvent temporairement basculer en mode ouvert? Lesquelles basculent 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 légitime de quota client?

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 des sauvegardes 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 les modifications rejetées ou dupliquées de manière imprévisible.

Le système d'état 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 car 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 mondiale de Google du 14 décembre 2020, lerapport d'incidentindique 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'à 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 sort des services qu'ils sont censés diagnostiquer.

Google a depuis documenté un modèle de communication plus explicite. Songuide de communication d'incidentdistingue 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 qu'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 conseil judicieux, 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 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 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 mesures 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. L'état du fournisseur est une corroboration, pas le premier et unique détecteur.

Il y a une raison de gouvernance pour 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 en arrière risqués, redimensionner dans un plan de contrôle cassé ou reporter un basculement en attendant une confirmation. Le silence du support peut également conduire les fournisseurs en aval à publier des spéculations. La disponibilité de la communication est donc un contrôle des risques 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 destinées à les sauver

La déclaration du rapport 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 certaines parties du plan de données et le chemin de gestion. Cela 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 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 les chemins de contrôle du fournisseur derrière une demande apparemment simple. Les intervenants en cas 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 limite concrète. Lerapport d'incident de Google sur la défaillance de programmation réseauindique qu'un bogue latent a été déclenché lorsque le plan de contrôle réseau mondial a retraité des opérations associées aux modifications des quotas de peering. Les machines virtuelles et les 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é à 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'autoscaling 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 récupération sont souvent moins testées et plus dépendantes du plan de contrôle que le service ordinaire. Un manuel 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 de l'équilibreur de charge mondial, 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 propre à chaque service. Songuide de conception d'infrastructure fiablerecommande d'éviter ou de minimiser les dépendances aux actions hors 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 préchauffée plutôt qu'hypothétique. Les points de terminaison régionaux peuvent exister avant que le frontend mondial ne tombe en panne. Les enregistrements DNS, les justificatifs d'identité, les routes, les images et les manuels 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 ne réussit que lorsque la console, IAM, Service Control, la programmation réseau mondiale 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 frontière d'automatisation

Le 2 juin 2019, des 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 entièrement les utilisateurs vers des 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 tâches du plan de contrôle réseau ont été configurées 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ésordonnancer des clusters logiciels indépendants même lorsqu'ils se trouvaient 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é 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 mondiale 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 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 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 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 du plan de contrôle local, l'extension de la durée de fonctionnement du réseau en mode fail-static, le renforcement de l'outillage d'urgence et l'extension 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 sans rapport 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 catastrophiques corrélées. Un programme de remédiation n'a de valeur institutionnelle que lorsque son modèle de contrôle se propage au-delà de 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 alors que les utilisateurs ne peuvent pas l'atteindre parce qu'une périphérie, une route de backbone, 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.

Lerapport d'incident backbonede 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 la défaillance 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é 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 dépasser le « nous avons deux liens ». L'examen doit demander qui possède chaque chemin de fibre, quel bâtiment et domaine de disponibilité périphérique 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, et non accepter un diagramme topologique comme preuve.

Laprésentation 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 Interconnectpréconise quatre attaches VLAN sur deux métros et domaines de disponibilité périphérique pour sa topologie recommandée à 99,99 %; 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 distincts et ont une capacité suffisante lors du basculement.

Le peering à l'intérieur du cloud n'est pas un transit par défaut. Ladocumentation sur le peering de réseau VPCde Google indique que le peering est non transitif: si le réseau A est peeré avec B et que A est également peeré avec C, B n'obtient pas pour autant une connectivité vers 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 concentrateur de transit. Lors d'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 l'échange de routes, la politique, la capacité, l'inspection de sécurité et le comportement en cas 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 toujours entrer dans le réseau de Google via un emplacement de peering commun. Une interconnexion privée 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 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 catégorie de défaillance

La conception multi-régions 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 traversait les emplacements physiques. L'incident de quota de peering de 2021 a affecté la programmation réseau à l'échelle mondiale parce que le contrôleur et les ressources VPC concernés avaient une portée mondiale. L'événement Service Control de 2025 a affecté chaque région parce que le plan de politique était mondial. Dans chaque cas, davantage de réplicas d'application à l'intérieur du domaine administratif affecté n'ont pas pu supprimer la cause commune.

La documentation sur la fiabilité de Google fait une distinction utile entre la portée géographique et la fiabilité des applications. Les ressources mondiales peuvent être très résilientes à une panne d'infrastructure régionale tout en devenant des points de défaillance uniques par le biais de la configuration. Les ressources multi-régions peuvent survivre à la perte d'une région mais rester dépendantes de l'identité mondiale, de la gestion des API, du contrôle réseau ou d'un frontend mondial. Les clients ont besoin d'un graphe de dépendances 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 backbone connectent les utilisateurs et les opérateurs. La quatrième est l'observation: où résident les journaux, les métriques, les flux d'état, la radiomessagerie et le support. La cinquième est la récupération: quels dépôts, justificatifs d'identité, humains et services externes sont nécessaires pour rétablir 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 le principal. Deux régions contrôlées par une politique mondiale invalide ne sont pas indépendantes pour cet événement. Deux piles de surveillance fournies 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 préchauffé dans un autre cloud n'est pas indépendant si le seul contrôle DNS, le dépôt d'artefacts ou la connexion de l'opérateur réside dans Google Cloud.

Cette analyse ne doit pas devenir une exigence coûteuse selon laquelle chaque petite charge de travail doit fonctionner 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 d'état externe. Un service d'autorisation de paiement peut avoir besoin d'une capacité pré-provisionnée, d'un transit indépendant, d'une 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 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, notamment Access, Gateway, WARP, Turnstile, Images, Stream, des parties du tableau de bord et d'autres services. Les services principaux de CDN et de sécurité de Cloudflare n'étaient pas uniformément en panne, 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 une preuve que l'externalisation est intrinsèquement irresponsable. Les fournisseurs achètent judicieusement 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 s'est diversifié en achetant Google Cloud pour l'infrastructure et Cloudflare pour la sécurité périphérique, et 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 d'un opérateur client. Sans divulgation et sans test, 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 a décrit les services qui dépendaient de Workers KV, a noté que le service principal n'avait initialement pas basculé du chemin de stockage tiers et a présenté les travaux visant à 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 dispose d'une voie de secours. Ces devoirs sont concomitants et non mutuellement exclusifs.

Unreportage d'Associated Presscontemporain a enregistré une perturbation visible sur des 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, des demandes ou des pertes financières affectées. Les preuves les plus solides proviennent des rapports techniques des fournisseurs et des données transactionnelles des clients. La responsabilité doit résister à la fois à la sous-estimation et au spectacle: une large cascade de dépendances compte même lorsqu'aucun total précis de pertes mondiales 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, d'état et de récupération. Ils devraient spécifier les obligations de notification lorsqu'un événement en amont est responsable, conserver les journaux permettant 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 devrait recevoir suffisamment d'assurance pour comprendre la concentration par cloud, plateforme d'identité, opérateur de 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é mensuelle fait la moyenne du temps et s'applique souvent à un produit spécifique ou à une topologie configurée. Il peut exclure la configuration du 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, et non une compensation pour la perte de revenus, le travail d'urgence, l'exposition réglementaire ou le préjudice causé aux utilisateurs du client.

LeSLA Cloud Interconnectactuel, 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 saine, 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 propre à un 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 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 conditions de responsabilité et de crédit de Google sont des attributions 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 le tester et qui doit vérifier la remédiation. La responsabilité juridique 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 devraient 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 justificatifs d'identité? Quel est le temps nécessaire 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 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 basculerait en mode ouvert le cas échéant, auditerait les systèmes qui consomment des données répliquées à l'échelle mondiale, 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 indicateurs de fonctionnalité 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 la communication disponibles lorsque Google Cloud est en panne.

Ces actions correspondent inhabituellement 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 mondiales, les preuves pourraient inclure le pourcentage de consommateurs de politiques critiques derrière une activation échelonnée; les taux de rejet automatisé des données candidates mal formées; les intervalles d'observation minimum avant l'autorité mondiale; et les exercices réussis dans lesquels un mauvais objet est arrêté dans une cohorte. Pour l'isolation des pannes, cela pourrait inclure des tests montrant qu'un module de quota peut échouer tandis que les vérifications API non liées continuent et que les décisions sensibles en matière de 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 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 d'état indépendant pendant les exercices. Pour l'apprentissage institutionnel, il devrait indiquer si des consommateurs mondiaux similaires en dehors de Service Control ont été trouvés et corrigés.

Les incidents antérieurs renforcent la nécessité de ce suivi. Après 2019, Google a promis un fonctionnement plus long du réseau en mode fail-static, une configuration de contrôle persistante, un outillage d'urgence robuste et des tests de catastrophe étendus. Après février 2021, il a promis une régionalisation plus poussée des composants de contrôle du réseau mondial, des pauses automatiques pour les migrations et une meilleure résilience du plan de données lorsque les contrôleurs ne répondaient pas. Après mars 2021, il a promis des domaines fonctionnels pour l'application des politiques de routage et des tests de construction de routeurs améliorés. Chaque engagement a peut-être été réalisé dans le cadre de 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 lespost-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 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 des risques 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 indiquer 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 mondial

Aucun client ne peut activer par indicateur le binaire interne Service Control de Google ou modifier la façon dont ses tables de politiques se répliquent. Les conseils qui disent simplement aux clients de « mieux concevoir » 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 quant à l'autorité qu'une panne de fournisseur a sur leur activité.

Commencez par le chemin de service. Identifiez les transactions utilisateur qui continuent si toutes les API de gestion Google Cloud sont indisponibles pendant trois heures. Testez avec les nouveaux déploiements suspendus, la mise à l'échelle automatique gelée, les modifications IAM indisponibles, les modifications d'équilibreur de charge bloquées et le support inaccessible. Mesurez quand la capacité, les justificatifs d'identité, 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 des opérateurs. Conservez des justificatifs d'identité 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 de 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 détecter les dépendances cachées au DNS, au courrier électronique, à 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é de charge complète. Vérifiez que le repli Internet public n'est pas bloqué par le pare-feu, le routage ou les hypothèses 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éé lors d'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 dernière configuration connue comme bonne reste utilisable. Pratiquez un mode dégradé qui abandonne les fonctionnalités non essentielles au lieu d'émettre une rafale de nouvelles tentatives ou de demandes de mise à l'échelle vers un fournisseur altéré.

Enfin, réconciliez après l'exercice. Déterminez les transactions qui ont échoué, celles qui ont été réessayées, celles qui ont été dupliquées, celles qui sont restées en file d'attente et les clients qui ont besoin d'une notification. La restauration du fournisseur ne garantit pas l'exactitude de l'application. Les objectifs de récupération devraient inclure l'apurement des arriérés et la validation des données, et 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 justification du coût du multi-cloud. La responsabilité n'est pas synonyme d'architecture maximale. C'est la capacité de montrer qu'une décision consciente sur les risques 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 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.

Le tableau de bord doit être lu en lignes. Un indicateur de fonctionnalité sans état indépendant ne suffit pas. Quatre attaches d'interconnexion sans diversité de fournisseur et de routeur peuvent ne pas suffire. Une application multi-régions sans récupération pré-provisionnée peut encore dépendre du contrôleur mondial. La fiabilité provient 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 du 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 ne doit donc pas être retenue 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 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 cloisonnée.

La réponse de Google a identifié les bons thèmes: propagation incrémentielle, indicateurs de fonctionnalité, défaillance modulaire, backoff et communication indépendante. Les clients devraient s'attendre à des preuves 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 plusieurs régions tout en dépendant d'une seule décision mondiale. Une entreprise peut acheter deux réseaux tout en utilisant un seul chemin vers le destin. Une page d'état peut être publique tout en résidant à l'intérieur de l'incident.

La norme de responsabilité appropriée n'est pas qu'un cloud mondial ne doit jamais tomber en panne. C'est que l'autorité mondiale 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écurisé; que les chemins réseau et de récupération doivent être indépendants en fonctionnement, pas seulement en nom; 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 imposer des limites à l'endroit où ce pouvoir peut voyager.