Eine Richtlinie, jede Region: Google Cloud und die Rechenschaftspflicht einer globalen Kontrollinstanz

Zusammenfassung

• Am 12. Juni 2025 erreichten unbeabsichtigt leere Felder in einer Kontingentrichtlinie fast gleichzeitig die regionalen Service-Control-Datenspeicher von Google Cloud. Ein zuvor bereitgestellter Codepfad verfügte weder über geeignete Fehlerbehandlung noch über einen Feature-Flag-Schutz; die Verarbeitung der Richtlinie führte dazu, dass Service-Control-Binärdateien in jeder Region abstürzten. Viele APIs von Google Cloud, Google Workspace und Google Security Operations gaben 503-Fehler zurück. Bestehende Streaming- und Infrastructure-as-a-Service-Ressourcen konnten weitgehend weiterarbeiten, aber die Verwaltungs- und API-Pfade, die zur Inspektion, Änderung, Skalierung oder Wiederherstellung von Diensten erforderlich sind, waren weitgehend beeinträchtigt.
• Der unmittelbare Fehler war begrenzt, aber das Versagen der Rechenschaftspflicht war architektonisch. Google hatte regional verteilte Dienstinstanzen und eine gestaffelte Binärauslieferung, doch die auslösende Richtlinie wurde innerhalb von Sekunden global repliziert. Der Kill-Mechanismus umging daher die regionale Lernphase, die die Auslieferung eigentlich ermöglichen sollte. Die Wiederherstellung führte dann zu einem Herdeneffekt auf Spanner in größeren Regionen, da die Neustartaufgaben keinen randomisierten exponentiellen Backoff aufwiesen. Auch die öffentliche Cloud Service Health-Infrastruktur war von der betroffenen Umgebung abhängig, was die erste Benachrichtigung durch Google um etwa eine Stunde verzögerte.
• Frühere Vorfälle zeigen andere Ursachen, aber wiederkehrende Fragen zur logischen Unabhängigkeit. Im Juni 2019 deschedulierte die Wartungsautomatisierung Netzwerk-Kontrollinstanz-Cluster an mehreren physischen Standorten; BGP-Routen wurden zurückgezogen, und die für die Diagnose benötigten Tools konkurrierten um das überlastete Netzwerk. Im Februar 2021 blockierte ein latenter Fehler, der bei Peering-Kontingentänderungen ausgelöst wurde, die globale Netzwerkprogrammierung. Im März 2021 legten ungültige Routen einen bekannten Anbieterfehler offen, und einige Cloud Interconnect-Standorte verfügten nicht über ausreichende Router-Anbieter-Diversität. Dies sind keine wiederkehrenden Softwarefehler; es sind wiederholte Tests der Eindämmung gemeinsamer Ursachen, der Änderungsbefugnis, der Netzwerkwiederherstellung und der wahrheitsgemäßen Transparenz.
• Google ist dafür verantwortlich, global replizierte Daten zu validieren, Kontrollinstanzfunktionen zu isolieren, Fail-static- oder Fail-open-Verhalten (wo sicher) beizubehalten, die Vorfallskommunikation unabhängig zu halten und nachzuweisen, dass zugesagte Abhilfemaßnahmen abgeschlossen wurden. Kunden können diese Plattformkontrollen nicht reparieren, bleiben jedoch dafür verantwortlich, zu identifizieren, welche Vorgänge von Kontrollinstanz-APIs abhängen, von außerhalb des Anbieters zu überwachen, degradierte Modi zu testen und Router- und Anbieter-Diversität zu kaufen, anstatt sich auf nominelle Verbindungen zu verlassen. Multi-Region-Bereitstellung reduziert viele Risiken, schafft aber für sich genommen keine Ausnahme von einer globalen Richtlinienebene oder einem gemeinsam genutzten Backbone.

Der Ausfall war eine überall gleichzeitig getroffene Kontrollentscheidung

Eine Cloud-Region ist leicht vorstellbar. Sie hat Gebäude, Strom, Kühlung, Glasfaser, Maschinen und Zonen, die physikalische Ausfälle isolieren sollen. Eine Kontrollinstanz ist schwerer zu erkennen. Sie ist die Instanz, die entscheidet, ob Ressourcen erstellt werden dürfen, welche Richtlinie gilt, wie Routen programmiert werden sollen, ob eine API-Anfrage innerhalb des Kontingents liegt und wohin der Datenverkehr geleitet wird.

Anwendungen können vorhandene Arbeiten weiterverarbeiten, wenn diese Instanz kurzzeitig nicht verfügbar ist, werden jedoch brüchig, wenn sie eine neue Instanz, eine Konfigurationsänderung, eine Berechtigungsentscheidung, eine Routenaktualisierung oder ein Failover benötigen, das selbst die Kontrollinstanz erfordert.

Diese Unterscheidung erklärt, warum der Vorfall vom 12. Juni 2025 gleichzeitig weniger als ein totaler Infrastruktur-Blackout und mehr als ein gewöhnliches API-Problem war. Googles vollständigerService Control-Vorfallberichtbesagt, dass bestehende Streaming- und Infrastructure-as-a-Service-Ressourcen nicht direkt vom primären Fehler betroffen waren. Dennoch traten bei einer langen Liste von Produkten externe API-Fehler auf, darunter Identity and Access Management, Cloud Storage, BigQuery, Cloud Run, Cloud DNS, Cloud Load Balancing, Hybrid Connectivity, Network Connectivity Center, Spanner, Überwachungsprodukte, die Konsole und mehrere KI-Dienste. Die Fähigkeit, aus bereits programmiertem Zustand weiterzuarbeiten, überlebte besser als die Fähigkeit, die Plattform um eine Entscheidung oder Änderung zu bitten.

Der Mechanismus war in Googles öffentlichem Bericht ungewöhnlich klar. Am 29. Mai wurde eine neue Service Control-Funktion für zusätzliche Kontingentrichtlinienprüfungen Region für Region veröffentlicht. Die Binärauslieferung wurde abgeschlossen, ohne den Fehler zu offenbaren, da der fehlschlagende Codepfad eine spätere Richtlinienänderung erforderte. Die Funktion war nicht durch ein Flag geschützt, das sie schrittweise für ausgewählte Projekte aktivieren könnte, und ihre Verarbeitung ungültiger Daten erlaubte es, dass ein Null-Wert den Prozess zum Absturz brachte. Am 12.

Juni um etwa 10:45 Uhr pazifischer Zeit wurde eine Kontingentrichtlinie mit unbeabsichtigt leeren Feldern in die von Service Control verwendeten regionalen Spanner-Tabellen geschrieben. Da Kontingent-Metadaten so konzipiert waren, dass sie sich mit nahezu sofortiger Konsistenz global bewegen, erschienen die Daten innerhalb von Sekunden in allen Regionen. Jede regionale Service Control-Bereitstellung traf dann auf dieselbe Eingabe und geriet in eine Absturzschleife.

Dies war kein Fall, in dem Redundanz fehlte. Regionale Dienstinstanzen und regionale Datenspeicher existierten. Es war auch nicht einfach ein Fall, in dem ein Ingenieur den falschen Knopf drückte. Ein Produktionssystem akzeptierte strukturell unsichere Richtliniendaten, einem kritischen Pfad fehlte defensive Fehlerbehandlung, eine Funktion erreichte jede Region ohne einen unabhängig gesteuerten Aktivierungspfad, und das Verbreitungssystem war schneller als das Validierungssystem. Die Architektur verwandelte ein einziges ungültiges logisches Objekt in ein globales Ereignis.

Den Vorfall als fehlerhafte Richtlinien-Störung zu bezeichnen, ist genau, aber unvollständig. Die Richtlinie war der Auslöser. Die größeren Ursachen waren der Umfang der ihr zugeschriebenen Autorität und das Fehlen einer Eindämmung zwischen Akzeptanz, Replikation, Interpretation und Dienst. Die rechenschaftspflichtige Frage ist nicht nur, warum ein leeres Feld existierte. Es ist, warum eine einzelne Richtlinie überall zu einem ausführbaren Fehlerzustand werden konnte, bevor eine Region, eine Projektkohorte oder ein Schatten-Validator Zeit hatte, sie abzulehnen.

Ein kurzer Auslöser führte zu einer langen und ungleichmäßigen Wiederherstellung

Googles Zeitlinie enthält zwei sehr unterschiedliche Geschichten. Erkennung und Diagnose waren schnell. Die vollständige Wiederherstellung war es nicht.

Der langsamere Pfad in us-central1 ist zentral für die Risikoanalyse. Als Service Control-Aufgaben neu starteten, erzeugten sie konzentrierte Nachfrage auf der darunterliegenden Spanner-Tabelle. Den Aufgaben fehlte der randomisierte exponentielle Backoff, der synchronisierte Wiederholungsversuche verhindert. Google musste die Aufgabenerstellung drosseln und Verkehr zu Multi-Region-Datenbanken umleiten. Mit anderen Worten, der erste Fehler war eine unsichere Interpretation globaler Daten; der zweite war ein Wiederherstellungsverhalten, das eine gemeinsame Abhängigkeit überlastete.

Googles eigene SRE-Literatur hat die Gefahr lange beschrieben. Ihr Kapitel zurBewältigung kaskadierender Ausfälleerklärt, wie Wiederholungsversuche und Neustarts ein Backend überlastet halten können und wie randomisierter exponentieller Backoff, anmutige Degradierung und kontrollierte Lastabwürfe verhindern können, dass ein lokales Kapazitätsproblem zu einer Kaskade wird. Der Bericht von 2025 verpflichtet sich ausdrücklich dazu, Systeme auf diesen Backoff zu prüfen. Die Bedeutung liegt nicht darin, dass Google es versäumt hat, einem Satz in einem Buch zu folgen. Es liegt darin, dass eine bekannte Klasse von Gefahren für verteilte Systeme in einem kritischen Dienst verblieb, dessen Neustartpopulation regional war und dessen zugrundeliegende Daten global waren.

Wiederherstellungspläne sollten daher als Produktionsarchitekturen bewertet werden, nicht als Runbook-Absätze. Ein System, das sicher deaktiviert werden kann, benötigt einen Kill-Mechanismus, dessen eigene Abhängigkeiten verstanden sind. Eine Flotte, die zusammen abstürzen kann, benötigt eine Neustart-Aufsicht, Admission Control, Jitter und eine getestete maximale Wiederherstellungsrate. Ein Datenspeicher, der die Flottenwiederherstellung absorbieren soll, benötigt reservierte Kapazität oder einen degradierten Lesepfad.

Wenn Ingenieure während des Ereignisses zu einer Multi-Region-Datenbank routen müssen, sollte diese Route vor dem Vorfall geübt und beobachtbar sein, mit dem Nachweis, dass sie die Überlastung nicht an einen anderen Ort verschiebt.

Der lange Schwanz ist auch für die Kundenkommunikation wichtig. Googles vorläufiger Bericht beschrieb ein dreistündiges globales Ereignis, während die Vorfallseite weiterhin Produktwiederherstellungen bis 18:18 Uhr auflistete. Einige Produkte hatten nach der Wiederherstellung des API-Betriebs Rückstände. Ein Kunde, dessen Anfrage während des primären Fensters fehlschlug, könnte Wiederholungsversuche, Warteschlangenjobs, partielle Workflows, veraltete Caches oder einen Drittanbieterdienst gehabt haben, der länger zur Wiederherstellung brauchte.

Der grüne Zustand des Anbieters ist der Beginn der Kundenabstimmung, nicht der Beweis, dass jeder Geschäftsprozess intakt ist.

Regionale Bereitstellung schuf kein regionales Lernen

Progressive Auslieferung soll Distanz in Evidenz verwandeln. Eine Änderung erreicht eine kleine Population; Betreiber beobachten ihr Verhalten; erst dann bewegt sie sich weiter. Google verwendete eine Region-für-Region-Binärauslieferung für den neuen Service Control-Code, aber die Bereitstellung führte nie den Codepfad aus, der später fehlschlug. Die aktivierende Richtlinie folgte einem anderen Verteilungsmechanismus, der optimiert war, um Kontingentstatus innerhalb von Sekunden global zu machen. Der Code war schrittweise; die Bedeutung des Codes war es nicht.

Dies ist ein subtiler, aber folgenschwerer Änderungskontrollfehler. Teams überprüfen oft Binärdateien, Konfiguration,, Richtlinie und Daten als separate Objekte. Das Produktionsverhalten ergibt sich jedoch aus ihrer Kombination. Eine ruhende Funktion kann jede regionale Hürde passieren, bis ein Konfigurationswert sie überall aktiviert. Ein kann für den Schreiber gültig, aber für einen älteren Leser ungültig sein. Eine global replizierte Richtlinie kann regionale Canaries irrelevant machen. Ein Notfall-Button kann existieren, aber dennoch von der defekten Kontrollinstanz abhängen, um wirksam zu werden.

Googles aktuelle Infrastrukturleitlinie erkennt dieses Risiko an. DerBausteine-Leitfaden zur Zuverlässigkeitbesagt, dass globale Ressourcen widerstandsfähig gegenüber zonalen und regionalen Infrastrukturvorfällen sind, aber zu einzelnen Fehlerquellen werden können, wenn ein kritischer Konfigurationsfehler globalen Umfang hat. Er empfiehlt sorgfältige Kontrolle von Änderungen und für außergewöhnlich anspruchsvolle Workloads regionale Defense-in-Depth-Fallbacks. Der begleitendeLeitfaden zur Verwaltung und Überwachungrät zu progressiver Bereitstellung und zusätzlicher Prüfung globaler Ressourcen. Der Vorfall von 2025 wendet dieselbe Logik innerhalb des Anbieters an: Globale Reichweite ist ein Zuverlässigkeitsvorteil gegen physische Ausfälle und eine Gefahr für den Explosionsradius bei schlechtem logischem Zustand.

Eine vollständige Abhilfe benötigt ein verbundenes Release-Modell. Die Binärdatei, das Richtlinien-, die Richtlinienwerte, die Datenspeicherreplikation, die Leserversionen, das Fallback-Verhalten und die Notfallsteuerungen sollten als eine Änderungsoberfläche behandelt werden. Neue Leser sollten alte, neue, fehlende und korrupte Werte sicher akzeptieren. Neue Richtlinien sollten im Schatten gelesen werden, bevor sie autoritativ werden. Die Aktivierung sollte mit internen Projekten oder einer begrenzten Region beginnen und bei Absturz, Latenz- oder Fehlerschwellen automatisch stoppen.

Die Replikation sollte inkrementell genug sein, um ein Erkennungsintervall zu bewahren, selbst wenn der endgültige Geschäftszustand global konsistent werden muss.

Das bedeutet nicht, dass jede globale Richtlinie langsam inkonsistent werden sollte. Kontingent- und Autorisierungsentscheidungen können einen zeitnahen, kohärenten Zustand erfordern. Die Designfrage ist, ob Validierung von Autorität getrennt werden kann. Eine Kandidatenrichtlinie kann als inerte Daten repliziert, gegen produktionsähnlichen Verkehr geparst und evaluiert werden und erst wirksam werden, nachdem Prüfungen bestanden wurden. Regionen können eine letzte bekannte gute Richtlinie beibehalten, wenn ein neues Objekt ungültig ist. Leser können Korruption von legitimer Verweigerung unterscheiden.

Globale Konsistenz ist nicht unvereinbar mit gestaffelter Sicherheit; sie erfordert lediglich mehr als schnelle Replikation.

Fail-Open ist eine Geschäfts- und Sicherheitsentscheidung, kein Slogan

Google hat sich verpflichtet, Service Control zu modularisieren, sodass eine betroffene Richtlinienfunktion isoliert und im Fehlerfall geöffnet werden kann, sodass API-Anfragen fortgesetzt werden können, wenn die entsprechende Prüfung fehlschlägt. Das ist eine sinnvolle Korrektur, aber der Begriff „fail-open" braucht Grenzen. Eine Kontingentprüfung, eine Authentifizierungsentscheidung, eine Abrechnungssteuerung und eine Missbrauchsbekämpfungssteuerung haben nicht dieselbe Konsequenz, wenn sie nicht verfügbar sind.

Bei einer risikoarmen Kontingentprüfung kann ein vorübergehend erlaubnisbasierter Dienst sicherer sein, als jede Kunden-API-Anfrage abzulehnen. Der Anbieter kann die Nutzung später abgleichen, die Exposition pro Projekt begrenzen und die Kernverfügbarkeit bewahren. Bei einer Autorisierungsprüfung könnte das blinde Zulassen von Anfragen einen Sicherheitsvorfall verursachen, der schlimmer ist als eine Ausfallzeit. Bei der Ressourcenerstellung könnte ein begrenzter lokaler Cache der letzten Richtlinie sicherer sein als entweder universelle Verweigerung oder universelle Erlaubnis.

Das richtige degradierte Verhalten hängt vom Zweck der Steuerung, der Aktualität des vertrauenswürdigen Zustands, der Reversibilität von Aktionen und dem Potenzial für Betrug, Datenverlust oder unkontrollierte Ausgaben ab.

GooglesService Infrastructure-Architekturtrennt Verwaltungs-, Steuerungs- und Datenebenen und zeigt gleichzeitig, wie breit die Plattformfunktionen sind: Authentifizierung, Autorisierung, Kontingent, Ratenbegrenzung, Prüfung, Abrechnung, Protokollierung und Überwachung. Diese Breite ist genau der Grund, warum modulares Fehlerverhalten wichtig ist. Ein Parser oder Richtlinienpfad sollte nicht in der Lage sein, jede Art von Entscheidung in dieselbe 503-Antwort zu verwandeln.

Ein rechenschaftspflichtiges Design würde Prinzipien veröffentlichen, anstatt sensible Implementierungsdetails. Welche Klassen von Prüfungen verwenden letzte bekannte gute Daten? Welche können vorübergehend fehlerhaft offen sein? Welche schließen fehlerhaft, weil die Sicherheitsfolge dominiert? Welche harten Grenzen bleiben während des degradierten Dienstes bestehen? Wie wird außergewöhnliche Nutzung abgeglichen? Können Kunden für regulierte Workloads ein strengeres Verhalten wählen? Wie unterscheidet die Plattform eine ungültige Anbieterrichtlinie von einer legitimen Kundenkontingentverweigerung?

Dies ändert auch das Testen. Es reicht nicht aus zu bestätigen, dass eine gute Richtlinie die richtige Antwort zurückgibt. Tests sollten leere Felder, unbekannte Felder, veraltete Versionen, partielle Replikation, korrupte Objekte, nicht verfügbare Datenspeicher, langsame Lesevorgänge und widersprüchliche Richtlinien injizieren. Sie sollten beweisen, dass ein Modul umgangen werden kann, ohne unrelated safeguards zu umgehen. Sie sollten das kundensichtbare Verhalten während des degradierten Betriebs messen und überprüfen, dass die Wiederherstellung nicht abgelehnte oder doppelte Änderungen unvorhersehbar wiederholt.

Das Statussystem teilte den Ausfall, den es beschreiben sollte

Etwa eine Stunde lang erhielten Kunden keinen öffentlichen Cloud Service Health-Vorfallbericht, weil diese Infrastruktur selbst ausgefallen war. Einige Kunden betrieben auch ihre Überwachung auf Google Cloud, sodass sowohl der Dienst als auch ihre Beweise für den Dienst gemeinsam ausfielen. Der Ausfall beeinträchtigte nicht nur die Produktion, sondern auch die epistemische Kontrolle: die Fähigkeit zu wissen, was geschah, zu entscheiden, ob ein Failover durchgeführt werden soll, und die Situation den Benutzern zu erklären.

Dies war nicht beispiellos. Während des globalen Authentifizierungsausfalls von Google am 14. Dezember 2020 besagt derVorfallbericht, dass die internen Tools des Cloud-Supports betroffen waren, Kunden keine Supportfälle in der Konsole erstellen oder anzeigen konnten und die Dashboard-Kommunikation verzögert wurde, bis die Hauptauswirkung endete. Dieses Ereignis resultierte aus einer automatisierten Kontingentverwaltung, die die Kapazität des zentralen Identitätssystems reduzierte. Bestehende Netzwerk-Datenebenen-Konfigurationen blieben betriebsbereit, aber authentifizierte Dienste, API-Zugriff, Konsolen und viele interne Tools waren es nicht. Der Mechanismus unterscheidet sich von 2025; das wiederkehrende Problem ist, dass Identität, Support, Überwachung und Kommunikation ein gemeinsames Schicksal mit den Diensten teilen können, die sie diagnostizieren sollen.

Google hat seitdem ein expliziteres Kommunikationsmodell dokumentiert. SeineLeitlinie zur Vorfallskommunikationunterscheidet Personalized Service Health, das Projektkontext verwendet und mit Warnungen und APIs integriert werden kann, vom öffentlichen Cloud Service Health-Dashboard. Dieselbe Leitlinie erkennt an, dass Personalized Service Health von Diensten wie IAM abhängt und empfiehlt ein Fallback auf das öffentliche Dashboard und den RSS-Feed, wenn personalisierte Systeme nicht verfügbar sind. Das ist ein guter Rat, aber der Juni 2025 zeigt, dass auch der öffentliche Kanal betriebliche Unabhängigkeit benötigt.

Die Verpflichtung des Anbieters besteht darin, einen extern erreichbaren, unabhängig betriebenen und verwalteten Veröffentlichungspfad mit vorautorisierten Vorfallsvorlagen und Out-of-Band-Eingaben von der Einsatzleitung aufrechtzuerhalten. Er sollte nicht die normale Konsole, die Kundenidentitätsebene, den primären Überwachungsstack oder den untersuchten Kontrolldienst erfordern. Die erste Benachrichtigung muss keine Grundursache enthalten.

Sie sollte beobachtete Symptome, bekannten Umfang, Startzeit, ob Kontrollinstanzoperationen oder vorhandene Workloads betroffen sind, verfügbare Workarounds und den nächsten Aktualisierungszeitpunkt angeben.

Kunden haben eine parallele Verpflichtung. GooglesIntegrationsleitfaden für Personalized Service Healthsagt ausdrücklich, dass der Dienst nicht wissen kann, ob jedes Produkt für eine bestimmte Anwendung kritisch ist oder ob die Anwendung fortgesetzt wird, wenn eine Abhängigkeit ausfällt. Betreiber benötigen ihre eigenen User-Journey-Checks, Anwendungsmetriken, Netzwerktelemetrie und Geschäftsprozessalarme. Mindestens ein Pfad sollte außerhalb von Google Cloud laufen und an einen Vorfallskanal liefern, der nicht von der Google-Identität abhängt. Der Anbieterstatus ist eine Bestätigung, nicht der erste und einzige Detektor.

Es gibt einen Governance-Grund für diese Trennung. Eine verzögerte Statusseite ändert das Kundenverhalten. Teams können Zeit damit verschwenden, ihre eigenen Bereitstellungen zu durchsuchen, riskante Rollbacks durchzuführen, in eine defekte Kontrollinstanz zu skalieren oder ein Failover aufzuschieben, während sie auf Bestätigung warten. Stille des Supports kann auch dazu führen, dass nachgelagerte Anbieter Spekulationen veröffentlichen. Die Verfügbarkeit von Kommunikation ist daher eine Risikokontrolle mit messbaren Erkennungs- und Veröffentlichungszielen, keine Höflichkeit, die nach Beginn der technischen Arbeit hinzugefügt wird.

Vorhandene Workloads überlebten besser als die Maßnahmen, die sie retten sollten

Die Aussage des Berichts von 2025, dass bestehende Streaming- und Infrastructure-as-a-Service-Ressourcen nicht betroffen waren, sollte sorgfältig gelesen werden. Sie zeigt eine nützliche Trennung zwischen Teilen der Datenebene und dem Verwaltungspfad. Sie bedeutet nicht, dass eine Anwendung nur deshalb sicher war, weil ihre derzeit laufenden virtuellen Maschinen betriebsbereit blieben.

Cloud-Systeme sind dynamisch. Autoscaler erstellen Instanzen. Orchestratoren ersetzen fehlerhafte Knoten. Bereitstellungssysteme rufen Artefakte ab und führen API-Aufrufe durch. Datenbanken führen Failover durch. Zertifikate und Token rotieren. Serverlose Dienste rufen hinter einer scheinbar einfachen Anfrage Anbieter-Kontrollpfade auf. Incident Responder ändern Firewall-Regeln, Load Balancer, DNS, Routen, Kontingente und Berechtigungen. Eine statische Datenebene kann weiterleiten, während der Geschäftsprozess um sie herum die Fähigkeit zur Anpassung verliert.

Der Netzwerkausfall vom Februar 2021 macht diese Grenze konkret. GooglesVorfallbericht über Netzwerkprogrammierungsfehlerbesagt, dass ein latenter Fehler ausgelöst wurde, als die globale Netzwerk-Kontrollinstanz Operationen im Zusammenhang mit Peering-Kontingentänderungen neu verarbeitete. Neue, aktualisierte, gelöschte oder migrierte VMs und Netzwerkendpunkte konnten nicht korrekt programmiert werden, während viele unveränderte Instanzen weiterarbeiteten. Google pausierte Live-Migrationen global; rund 1.000 GKE-Cluster waren betroffen, da keine Knoten oder Cluster bereitgestellt werden konnten; einige Instanzerstellungen und Load-Balancer-Aktualisierungen scheiterten mit sehr hohen Raten. Ein gesunder vorhandener Server half einer Autoscaling-Gruppe nicht, die einen neuen vernetzten Server benötigte.

Dies ist das Paradoxon der Kontrollinstanz bei der Notfallwiederherstellung. Die Maßnahmen im Wiederherstellungsplan sind oft weniger getestet und stärker von der Kontrollinstanz abhängig als der normale Betrieb. Ein Runbook mag sagen: „Kapazität in der zweiten Region schaffen" oder „Load Balancer umschalten", aber das sind API-Operationen. Wenn der auslösende Ausfall die Ressourcenerstellung oder globale Load-Balancer-Aktualisierungen beeinträchtigt, ist der Wiederherstellungsschritt genau dann nicht verfügbar, wenn er benötigt wird.

GooglesLeitfaden zur Notfallwiederherstellungsarchitekturunterscheidet Datenebenen-Aktionen von Kontrollinstanzaktualisierungen und erklärt die dienstspezifische Resilienz. SeinLeitfaden für zuverlässiges Infrastrukturdesignempfiehlt, Abhängigkeiten von Nicht-Datenebenen-Aktionen während Ausfällen zu vermeiden oder zu minimieren, z. B. die Erstellung eines neuen Load Balancers. Die praktische Lektion ist, den Wiederherstellungspfad vorzubereiten. Kapazität kann warm statt hypothetisch sein. Regionale Endpunkte können existieren, bevor das globale Frontend ausfällt. DNS-Einträge, Anmeldeinformationen, Routen, Images und Runbooks können ohne administrative Operation in letzter Minute verfügbar sein.

Für jeden Wiederherstellungsschritt sollte ein Betreiber die API, den Identitätsanbieter, den Netzwerkpfad, den DNS-Resolver, das Artefaktlager, das Geheimnis und die menschliche Genehmigung benennen können, die er benötigt. Dann sollte die Übung diese Abhängigkeiten eine nach der anderen entfernen. Ein Plan, der nur erfolgreich ist, während die Konsole, IAM, Service Control, die globale Netzwerkprogrammierung und die primäre Region alle gesund sind, ist ein Expansionsverfahren, keine Notfallwiederherstellung.

Der Ausfall von 2019 zeigte, dass physische Trennung eine gemeinsame Automatisierungsgrenze teilen kann

Am 2. Juni 2019 verzeichneten Google Cloud-Projekte in mehreren US-Regionen mehr als drei Stunden lang erhöhten Paketverlust. Einige Google-Dienste konnten Benutzer nicht vollständig in nicht betroffene Regionen umleiten. DerNetzwerkvorfallberichtbeschrieb mehrere Ausfälle, die sich zu einem größeren Ausfall kombinierten: Netzwerk-Kontrollinstanz-Jobs waren so konfiguriert, dass sie für ein Wartungsereignis gestoppt wurden; mehrere Cluster-Management-Instanzen waren für denselben seltenen Ereignistyp qualifiziert; und ein Softwarefehler erlaubte der Automatisierung, unabhängige Softwarecluster zu deschedulen, selbst wenn sie sich an verschiedenen physischen Standorten befanden.

Das Netzwerk arbeitete zunächst im „Fail-static"-Modus ohne seine Kontrollinstanz weiter. Einige Minuten später wurden BGP-Routen zwischen betroffenen Standorten zurückgezogen, was die Netzwerkkapazität reduzierte und einige Regionen unzugänglich machte. Das Versagen von Diagnosetools im überlasteten Netzwerk verlangsamte die Untersuchung. Als Ingenieure die Kontrollinstanz-Instanzen wiederherstellten, musste die Konfiguration neu aufgebaut und verteilt werden, was die Wiederherstellung verlängerte.

Es gibt eine auffällige strukturelle Parallele zu 2025. Im Jahr 2019 existierten physische Standorte und mehrere Cluster-Manager, aber eine Wartungsabstraktion wählte sie gemeinsam aus. Im Jahr 2025 existierten regionale Service Control-Instanzen, aber eine globale Richtlinie erreichte sie gemeinsam. Beide Vorfälle betrafen einen Sicherheitszeitraum, der sich als zu kurz oder zu abhängig erwies: Fail-static-Routing im Jahr 2019 und ein Notfall-Bypass im Jahr 2025. Beide beeinträchtigten die Werkzeuge, die zum Verständnis oder zur Kommunikation des Ausfalls verwendet wurden.

Beide Wiederherstellungspfade mussten den Kontrollzustand unter degradierten Bedingungen neu aufbauen oder neu verteilen.

Die Ursachen sind nicht austauschbar. Der Vorfall von 2019 war ein Netzwerk-Kontroll- und Wartungsautomatisierungsfehler; der Vorfall von 2025 war ein Richtliniendaten- und API-Kontrollfehler. Rechenschaftspflicht sollte sie nicht zu „Google hatte einen weiteren Ausfall" einebnen. Der Wert des Vergleichs besteht darin, zu testen, ob die Organisation wiederholt entdeckt, dass nominell unabhängige Komponenten dennoch eine Verwaltungsdomäne, einen Ausbreitungsmechanismus, ein Notfallwerkzeug oder eine Wiederherstellungsabhängigkeit teilen.

Googles Verpflichtungen von 2019 umfassten die Ablehnung der betreffenden Wartungsanfragen, das Beibehalten der lokalen Kontrollinstanzkonfiguration, die Verlängerung der Dauer des Fail-static-Netzwerkbetriebs, die Härtung von Notfallwerkzeugen und die Erweiterung von Notfallwiederherstellungstests. Die aktuelle Frage der Rechenschaftspflicht ist nicht, ob diese Maßnahmen den unrelated Null Pointer von 2025 verhindert hätten.

Es ist, ob die Governance-Methode dahinter Standard wurde: gemeinsame Autorität kartieren, sicheren Zustand beibehalten, Notfallsteuerungen außerhalb der primären Fehlerdomäne halten und katastrophale korrelierte Ausfälle testen. Ein Sanierungsprogramm hat nur dann institutionellen Wert, wenn sein Kontrollmuster über das Team hinausgeht, das den Postmortem geschrieben hat.

Peering- und Transit-Diversität betrifft das Schicksal, nicht die Anzahl der Schaltungen

Cloud-Verfügbarkeit erreicht Kunden über Netzwerke. Ein Workload kann innerhalb einer Region gesund sein, während Benutzer ihn nicht erreichen können, weil ein Edge-, Backbone-Route, Peering-Session, Transit-Anbieter, DNS-Pfad oder hybrider Interconnect ausgefallen ist. Umgekehrt können zwei Zugangsschaltungen auf einer Bestellung divers erscheinen, während sie auf einem Metro, einem Anbieter, einem Router-Modell, einem Google-Edge oder einem Kontrollsystem konvergieren.

Googles Bericht vom 17. März 2021 über denBackbone-Vorfallveranschaulicht diesen Unterschied. Das Verbinden neuer Router änderte, welche Routen bestimmte Router-Rollen erhielten. Diese Routen legten einen bekannten Fehler in einem bestimmten Router-Modell offen, was dazu führte, dass Routing-Prozesse fehlschlugen. Automatische Umleitung reduzierte das Risiko einer breiteren Kaskade, verursachte aber während der Konvergenz Paketverlust. Eine manuelle Schadensbegrenzung verursachte eine weitere Überlastungsperiode, und einige Cloud Interconnect-Standorte waren aufgrund unzureichender Router-Anbieter-Redundanz länger betroffen. Interregionaler Private-IP-Verkehr, Public-IP-Verkehr, Load Balancer, VPN-Tunnel und externe Konnektivität waren in unterschiedlichem Maße betroffen.

Deshalb muss eine Resilienzüberprüfung über „wir haben zwei Verbindungen" hinausgehen. Die Überprüfung sollte fragen, wem jeder Glasfaserpfad gehört, welches Gebäude und Edge-Verfügbarkeitsdomäne er nutzt, welcher Router-Anbieter und Software-Train ihn terminiert, welcher Cloud Router seine BGP-Sitzungen steuert, wie Routen wieder konvergieren, ob die Failover-Kapazität die gesamte Last tragen kann und ob beide Pfade von derselben Anbieter-Kontrollinstanz abhängen. Sie sollte tatsächliche Routenänderungen beobachten und geplante Rücknahmen durchführen, anstatt ein Topologiediagramm als Beweis zu akzeptieren.

GooglesCloud Interconnect-Übersichtbietet Konfigurationen mit 99,9 und 99,99 Prozent und erklärt, dass eine einzelne Verbindung keine Verfügbarkeits-SLA hat. DiePartner Interconnect-Leitlinieempfiehlt für die empfohlene 99,99-Prozent-Topologie vier VLAN-Anhänge über zwei Metros und Edge-Verfügbarkeitsdomänen; sie weist auch darauf hin, dass das Anbietersegment außerhalb des Google-Netzwerks seine eigene Zusicherung benötigt. Die Verwendung mehrerer Dienstanbieter kann die Verfügbarkeit verbessern, aber nur, wenn ihre zugrundeliegenden Pfade tatsächlich getrennt sind und während des Failovers über ausreichende Kapazität verfügen.

Peering innerhalb der Cloud ist standardmäßig kein Transit. GooglesVPC Network Peering-Dokumentationbesagt, dass Peering nicht-transitiv ist: Wenn Netzwerk A mit B peert und A auch mit C peert, erhält B dadurch keine Konnektivität zu C. Diese Einschränkung kann eine nützliche Eindämmungsgrenze sein, überrascht jedoch Teams, die davon ausgehen, dass ein zentrales VPC automatisch als Transit-Hub fungiert. Während eines Ausfalls kann eine improvisierte Wiederherstellungsroute fehlschlagen, weil die beworbene Topologie nie unterstützt wurde. Wo Transit erforderlich ist, sollte er explizit entworfen werden, mit Routenaustausch, Richtlinie, Kapazität, Sicherheitsinspektion und Fehlerverhalten, das Ende-zu-Ende getestet wurde.

Internet-Transit verdient dieselbe Präzision. Öffentlicher Zugang über zwei ISPs kann dennoch über einen gemeinsamen Peering-Standort in das Google-Netzwerk gelangen. Ein privater Interconnect und ein Internet-VPN können eine bessere administrative Diversität bieten, aber beide können dennoch von Googles Backbone oder derselben Kundenidentität und DNS abhängen. Eine zweite Cloud kann die Anbieterkonzentration nur verringern, wenn die Anwendung, Daten, Identität, Bereitstellungstools, Beobachtbarkeit und DNS-Failover dort unabhängig betrieben werden können. Eine Anzahl von Logos ist keine Architektur.

Multi-Region ist ein starker Schutz gegen die falsche Fehlerklasse

Multi-Region-Design bleibt wertvoll. Es kann vor einem Stromausfall, einem lokalen Kapazitätsverlust, einem zonalen Hardwarefehler und vielen regionalen Softwareproblemen schützen. Der Fehler liegt nicht in der Verwendung mehrerer Regionen; es ist, den Begriff als vollständige Aussage über Unabhängigkeit zu behandeln.

Das Netzwerkereignis von 2019 betraf mehrere Regionen, weil eine Kontrollinstanz-Automatisierungsgrenze physische Standorte überschritt. Der Peering-Kontingent-Vorfall von 2021 betraf die Netzwerkprogrammierung global, weil der betreffende Controller und die VPC-Ressourcen globalen Umfang hatten. Das Service Control-Ereignis von 2025 betraf jede Region, weil die Richtlinienebene global war. In jedem Fall konnten mehr Anwendungsreplikate innerhalb der betroffenen Verwaltungsdomäne die gemeinsame Ursache nicht beseitigen.

Googles Zuverlässigkeitsdokumentation unterscheidet nützlich zwischen Standortumfang und Anwendungszuverlässigkeit. Globale Ressourcen können sehr widerstandsfähig gegenüber einem regionalen Infrastrukturausfall sein, während sie dennoch durch Konfiguration zu einzelnen Fehlerquellen werden können. Multi-Region-Ressourcen können den Verlust einer Region überleben, bleiben aber von globaler Identität, API-Verwaltung, Netzwerksteuerung oder einem globalen Frontend abhängig. Kunden benötigen einen Abhängigkeitsgraphen, der sowohl Geographie als auch Autorität markiert.

Dieser Graph sollte mindestens fünf Ebenen umfassen. Erstens die Ausführung: wo Prozesse und Daten tatsächlich laufen. Zweitens die Steuerung: welche APIs diese Ressourcen erstellen, routen, autorisieren, skalieren und Failover durchführen. Drittens der Zugang: welche DNS-, Peering-, Transit-, Interconnect-, VPN- und Backbone-Pfade Benutzer und Betreiber verbinden. Viertens die Beobachtung: wo Protokolle, Metriken, Status-Feeds, Alarmierung und Support leben. Fünftens die Wiederherstellung: welche Repositories, Anmeldeinformationen, Menschen und externen Dienste benötigt werden, um den Betrieb wiederherzustellen.

Eine Abhängigkeit ist nur dann unabhängig, wenn dasselbe glaubwürdige Ereignis sie nicht zusammen mit der primären deaktivieren kann. Zwei Regionen, die von einer einzigen ungültigen globalen Richtlinie gesteuert werden, sind für dieses Ereignis nicht unabhängig. Zwei Überwachungsstapel, die über dasselbe Identitätssystem geliefert werden, sind für einen Authentifizierungsausfall nicht unabhängig. Zwei Schaltungen auf derselben Router-Software sind für den betreffenden Anbieterfehler nicht unabhängig.

Ein warmer Dienst in einer anderen Cloud ist nicht unabhängig, wenn die einzige DNS-Steuerung, das Artefakt-Repository oder der Betreiber-Login in Google Cloud lebt.

Diese Analyse sollte nicht zu einer teuren Forderung werden, dass jede kleine Arbeitslast über drei Anbieter läuft. Kontrollen müssen verhältnismäßig sein. Eine öffentliche Informationsseite kann ein paar Stunden Ausfallzeit akzeptieren und eine externe Statusseite unterhalten. Ein Zahlungsautorisierungsdienst benötigt möglicherweise vorbereitete Kapazität, unabhängigen Transit, externe Überwachung und einen getesteten sekundären Anbieter. Der rechenschaftspflichtige Akt besteht darin, zu wissen, welche Abhängigkeiten gemeinsam bleiben, die Konsequenz zu bepreisen und eine explizite Akzeptanz vom Geschäftsinhaber zu erhalten.

Cloudflare verwandelte einen Anbieterausfall in eine Abhängigkeitslektion für einen anderen

Das Ereignis vom Juni 2025 überschritt eine Unternehmensgrenze auf besonders lehrreiche Weise. Cloudflareseigener Ausfallberichtbesagt, dass Workers KV teilweise von einem Drittanbieter-Cloud-Dienst abhing. Als diese Abhängigkeit ausfiel, wurde Workers KV nicht mehr verfügbar und eine breite Palette von Cloudflare-Produkten, die es nutzten, war beeinträchtigt, darunter Access, Gateway, WARP, Turnstile, Images, Stream, Teile des Dashboards und andere Dienste. Cloudflares Kern-CDN- und Sicherheitsdienste waren nicht einheitlich ausgefallen, aber die Abhängigkeit machte einen Google Cloud-Kontrollinstanzfehler durch Produkte sichtbar, die unter dem Namen eines anderen Anbieters verkauft wurden.

Dies ist kein Beweis dafür, dass Outsourcing grundsätzlich unverantwortlich ist. Anbieter kaufen sinnvollerweise Dienstleistungen voneinander. Es ist ein Beweis dafür, dass die kommerzielle Distanz einer Abhängigkeit ihre betriebliche Konsequenz nicht verringert. Ein Kunde mag glauben, diversifiziert zu haben, indem er Google Cloud für die Infrastruktur und Cloudflare für die Edge-Sicherheit kauft, dennoch kann ein Cloudflare-Kontrolldienst von Google Cloud abhängen. Die resultierende Kette kann Google Cloud zu Workers KV zu Access zum Betreiber-Login des Kunden sein.

Ohne Offenlegung und Tests kann der Kunde nicht sehen, dass die sekundäre Steuerung die primäre Fehlerdomäne teilt.

Cloudflare akzeptierte seinen Teil der Rechenschaftspflicht. Sein Bericht beschrieb, welche Dienste von Workers KV abhingen, stellte fest, dass der Kerndienst zunächst nicht vom Speicherpfad des Drittanbieters überging, und skizzierte Arbeiten zur Verringerung oder Beseitigung von Abhängigkeiten für kritische Produkte. Google bleibt für den vorgelagerten Plattformfehler verantwortlich; Cloudflare bleibt dafür verantwortlich, zu entscheiden, dass ein kritischer interner Dienst davon ohne angemessene Kontinuität abhängen konnte; der Endkunde bleibt dafür verantwortlich zu bewerten, ob der Zugang zu seinen eigenen Systemen einen Notfallpfad hat.

Diese Pflichten bestehen gleichzeitig, nicht gegenseitig ausschließend.

Die zeitgenössischeAssociated Press-Berichterstattungverzeichnete sichtbare Störungen bei beliebten Online-Diensten und Zehntausende von Benutzermeldungen. Eine solche Berichterstattung ist nützlich, um die öffentliche Reichweite zu demonstrieren, aber die Anzahl der Ausfallmeldungen ist keine Volkszählung der betroffenen Personen, Anfragen oder finanziellen Verluste. Die stärkeren Beweise stammen aus den technischen Berichten der Anbieter und aus den Transaktionsdaten der Kunden. Rechenschaftspflicht sollte sowohl Untertreibung als auch Spektakel widerstehen: Eine breite Abhängigkeitskaskade ist wichtig, selbst wenn keine genaue globale Gesamtverlustzahl verfügbar ist.

Verträge und Architekturüberprüfungen sollten daher Anbieter bitten, materielle Abhängigkeiten von Viertparteien für Steuerungs-, Identitäts-, Konfigurations-, Status- und Wiederherstellungsfunktionen zu identifizieren. Sie sollten Benachrichtigungspflichten festlegen, wenn ein vorgelagertes Ereignis verantwortlich ist, Protokolle aufbewahren, die es Kunden ermöglichen, die Auswirkungen abzugleichen, und definieren, ob der Anbieter eine getestete Alternative hat.

Der Kunde erhält möglicherweise aus Sicherheits- und kommerziellen Gründen keine vollständige Lieferantenkarte, sollte aber genügend Zusicherung erhalten, um die Konzentration nach Cloud, Identitätsplattform, Netzbetreiber und geografischer Kontrollinstanz zu verstehen.

Eine SLA-Gutschrift beweist nicht, dass die Abhängigkeit akzeptabel ist

Service-Level-Agreements sind nützlich, weil sie eine messbare Verpflichtung und ein Rechtsmittel definieren. Sie sind keine vollständige Risikobewertung. Ein monatlicher Verfügbarkeitsprozentsatz mittelt die Zeit und gilt oft für ein bestimmtes Produkt oder eine konfigurierte Topologie. Er kann Kundenkonfiguration, Drittanbietersegmente, Kontingente, Vorschaufunktionen oder Ausfälle außerhalb des gedeckten Dienstes ausschließen. Das Rechtsmittel ist in der Regel eine Gutschrift auf zukünftige Ausgaben, kein Ausgleich für entgangene Einnahmen, Notarbeit, regulatorische Exposition oder Schäden für die Benutzer des Kunden.

Das aktuelleCloud Interconnect-SLAunterscheidet beispielsweise Produktionstopologien von einzelnen Verbindungen und erfordert Kundennachweise für Ansprüche. Dieses Framework kann eine solide Topologie fördern, aber es kann einem Vorstand nicht sagen, ob ein vierstündiger Ausfall des Hybridzugangs tolerierbar ist. Noch beschreibt ein produktspezifisches SLA den korrelierten Ausfall zwischen der API, die zum Ändern eines Dienstes verwendet wird, der Überwachung, die ihn beobachtet, und dem Support-Kanal, der ihn meldet.

Der Kunde benötigt ein Service-Level-Objective für seine eigene User Journey. Dieses Ziel sollte die Cloud-Produkte, Netzwerkpfade, internen Dienste und Lieferanten umfassen, die zum Abschließen der Reise erforderlich sind. Es sollte sowohl den stationären Betrieb als auch Wiederherstellungsmaßnahmen messen. Ein Checkout-Flow, der betriebsbereit bleibt, aber keine Kapazität hinzufügen kann, mag jetzt gesund sein und unmittelbar gefährdet. Eine Datenbank, die Lesevorgänge bedient, aber kein Replikat befördern kann, kann eine verschlechterte Wiederherstellbarkeit aufweisen, noch bevor Benutzer Fehler sehen.

Googles Haftungs- und Gutschriftsbedingungen sind rechtliche Zuweisungen, keine technischen Nachweise. Umgekehrt ist eine öffentliche Entschuldigung eines Anbieters kein Beweis für Fahrlässigkeit oder ein rechtliches Eingeständnis. Dieser Artikel weist operative und Governance-Rechenschaftspflicht auf der Grundlage von Kontrolle zu: wer den Ausbreitungspfad entworfen hat, wer die Abhängigkeit akzeptiert hat, wer sie testen konnte und wer die Abhilfe überprüfen muss. Die rechtliche Haftung hängt vom Vertrag, der Gerichtsbarkeit, den Tatsachen und einer Entscheidung außerhalb des Rahmens eines technischen Vorfallberichts ab.

Vorstände sollten daher nach quantifizierter Exposition über die Anbieterverfügbarkeit hinaus fragen. Wie viel Umsatz oder öffentlicher Dienst hängt von einer Kontrollinstanz-Operation ab? Wie lange können bereits laufende Ressourcen ohne Skalierung oder Anmeldeinformationen dienen? Wie lange dauert es, Benutzer über einen alternativen Transitpfad zu bewegen? Welche Wiederherstellungen erfordern den ausgefallenen Anbieter? Welche Nachweise gibt es aus der letzten Übung? Eine Service-Gutschrift gehört in die Finanzunterlagen; sie sollte niemals mit Kontinuität verwechselt werden.

Googles Liste der Abhilfemaßnahmen ist nur glaubwürdig, wenn sie zu Nachweisen wird

Der Vorfallbericht von 2025 enthält einen starken Satz von Verpflichtungen. Google fror Service Control-Änderungen und manuelle Richtlinien-Pushes nach der Wiederherstellung ein.

Es sagte zu, den Dienst zu modularisieren und gegebenenfalls fail-open zu gestalten, Systeme zu prüfen, die global replizierte Daten konsumieren, solche Daten inkrementell mit Validierungszeit zu verbreiten, kritische Binärdateien durch standardmäßig deaktivierte Feature-Flags zu schützen, die statische Analyse und das Testen ungültiger Daten zu verbessern, den randomisierten exponentiellen Backoff zu prüfen, die externe Kommunikation zu verbessern und Überwachung und Kommunikation verfügbar zu halten, wenn Google Cloud ausfällt.

Diese Maßnahmen stimmen mit der beobachteten Fehlerkette ungewöhnlich gut überein. Das verbleibende Problem ist die Sicherheit. Ein Versprechen kann eine Postmortem-Aktion in einem Trackingsystem abschließen, ohne zu beweisen, dass das Risiko in der Produktion gesunken ist. Google sollte den Fertigstellungsstatus, die Validierungsmethode und die verbleibenden Grenzen für die Maßnahmen mit den größten Auswirkungen veröffentlichen, selbst wenn die detaillierte Architektur vertraulich bleibt.

Für die Sicherheit globaler Richtlinien könnten Nachweise den Prozentsatz kritischer Richtlinienkonsumenten hinter gestaffelter Aktivierung, automatische Ablehnungsraten für fehlerhafte Kandidatendaten, minimale Beobachtungsintervalle vor globaler Autorität und erfolgreiche Übungen umfassen, bei denen ein schlechtes Objekt in einer Kohorte gestoppt wird. Für die Fehlerisolierung könnten Tests zeigen, dass ein Kontingentmodul fehlschlagen kann, während unrelated API-Prüfungen fortgesetzt werden, und dass sicherheitsempfindliche Entscheidungen ihre beabsichtigte Grenze behalten.

Für die Wiederherstellung sollte Google Flotten-Neustart-Grenzen, Backoff-Konformität, reservierte Datenspeicherkapazität und Lasttestergebnisse für die gleichzeitige regionale Wiederherstellung zeigen. Für die Kommunikation sollte es die Zeit vom ersten Kundenimpact bis zur internen Erkennung, ersten öffentlichen Benachrichtigung, ersten umfassten Impact-Erklärung und Verfügbarkeit des unabhängigen Statuspfads während Übungen veröffentlichen. Für das institutionelle Lernen sollte es berichten, ob ähnliche globale Konsumenten außerhalb von Service Control gefunden und behoben wurden.

Frühere Vorfälle schärfen die Notwendigkeit dieser Nachverfolgung. Nach 2019 versprach Google einen längeren Fail-static-Netzwerkbetrieb, persistente Steuerungskonfiguration, robuste Notfallwerkzeuge und erweiterte Katastrophentests. Nach Februar 2021 versprach es eine weitere Regionalisierung globaler Netzwerk-Kontrollinstanz-Komponenten, automatische Pausen für Migrationen und bessere Datenebenen-Resilienz, wenn Controller nicht reagierten. Nach März 2021 versprach es funktionale Domänen für die Durchsetzung von Routenrichtlinien und verbesserte Router-Build-Tests.

Jede Verpflichtung mag innerhalb ihres eigenen Programms abgeschlossen worden sein; die öffentliche Aufzeichnung bietet keine fortlaufende Sicherheitsansicht, die zeigt, wie sich das Common-Mode-Risiko der Plattform im Laufe der Zeit verändert hat.

Googles SRE-Buch beschreibtPostmortems als ein Lernsystem, mit Aktionspunkten, die mit Ursachen verbunden sind, ohne komplexe Vorfälle auf individuelle Schuld zu reduzieren. Dasselbe Prinzip unterstützt die externe Rechenschaftspflicht. Der Zweck der Veröffentlichung von Nachweisen ist nicht, einen Mitarbeiter bloßzustellen oder Kunden einzuladen, Googles Netzwerk zu betreiben. Es geht darum, Kunden zu ermöglichen, einen temporären Workaround von einer dauerhaften Kontrolle zu unterscheiden, zu sehen, was offen bleibt, und zu entscheiden, ob ihre eigene Risikobehandlung angemessen ist.

Eine unabhängige Überprüfung würde für die globalsten Kontrollen einen Mehrwert bieten. Sie könnte Designdokumente, Rollout-Aufzeichnungen, Ergebnisse von Fehlerinjektionen, Unabhängigkeit des Notfall-Buttons und den Abschluss von Maßnahmen stichprobenartig prüfen. Die öffentliche Ausgabe könnte Umfang, Ausnahmen und Schlussfolgerungen nennen, ohne ausnutzbare Interna preiszugeben. Selbstberichterstattung bietet technische Tiefe; unabhängige Sicherheit bietet Vertrauen, dass die Abschlusskriterien nicht allein vom für die Lieferung verantwortlichen Team definiert wurden.

Was Kunden vor dem nächsten globalen Vorfall testen sollten

Kein Kunde kann Googles internes Service Control-Binärprogramm mit einem Feature-Flag versehen oder ändern, wie sich seine Richtlinientabellen replizieren. Ratschläge, die Kunden lediglich sagen, sie sollen nach einem anbieterweiten Ausfall „besser architekturieren", übertragen Verantwortung unfair. Dennoch treffen Kunden folgenreiche Entscheidungen darüber, wie viel Autorität ein Anbieterausfall über ihr Geschäft hat.

Beginnen Sie mit dem Serving-Pfad. Identifizieren Sie, welche Benutzertransaktionen fortgesetzt werden, wenn alle Google Cloud-Verwaltungs-APIs für drei Stunden nicht verfügbar sind. Testen Sie mit pausierten neuen Bereitstellungen, eingefrorenem Autoscaling, nicht verfügbaren IAM-Änderungen, blockierten Load-Balancer-Modifikationen und nicht erreichbarem Support. Messen Sie, wann Kapazität, Anmeldeinformationen, Zertifikate, Warteschlangen oder geplante Aufgaben zum limitierenden Faktor werden.

Das Ergebnis wird oft eine Kurve und keine binäre Antwort sein: Der Dienst wird bei aktueller Last für einen Zeitraum fortgesetzt, verschlechtert sich dann, wenn sich Routine-Kontrollaktionen ansammeln.

Testen Sie als Nächstes den Betreiberzugang. Halten Sie Break-Glass-Anmeldeinformationen bereit, deren Abruf und Verifizierung nicht den primären Cloud-Identitätspfad erfordern. Unterhalten Sie einen minimalen Vorfall-Arbeitsbereich, eine Kontaktliste, Runbooks, Architekturdiagramme und einen Status-Publisher außerhalb von Google Cloud. Stellen Sie sicher, dass das Team Netzbetreiber und kritische Lieferanten ohne die Unternehmenskollaborationssuite erreichen kann, wenn diese Suite die Google-Identität teilt. Prüfen Sie jedes Notfallwerkzeug auf versteckte DNS-, E-Mail-, Single-Sign-On- und Geheimnisabhängigkeiten.

Testen Sie dann Netzwerkpfade. Ziehen Sie jede BGP-Session und Interconnect-Verbindung während einer kontrollierten Übung zurück. Bestätigen Sie, dass der Datenverkehr durch die beabsichtigte Metro und den Anbieter läuft, messen Sie den Konvergenzverlust und überprüfen Sie, ob die Alternative volle Lastkapazität hat. Stellen Sie sicher, dass der öffentliche Internet-Fallback nicht durch Firewall, Routing oder Source-Address-Annahmen blockiert wird. Beweisen Sie für VPC-Peering die genau importierten und exportierten Routen und gehen Sie nicht von Transitivität aus. Testen Sie für Multi-Cloud-Transit Datenkonsistenz und Identität sowie Pakete.

Stellen Sie vorab bereit, was während eines Kontrollinstanz-Ausfalls nicht erstellt werden kann. Dies kann regionale Load Balancer, DNS-Einträge, sekundäre Cluster, Standby-Datenbanken, Kontingente, Dienstkonten, Artefakte und Netzwerktunnel umfassen. Halten Sie Änderungen klein genug, dass eine letzte bekannte gute Konfiguration verwendbar bleibt. Üben Sie einen degradierten Modus, der nicht wesentliche Funktionen abwirft, anstatt eine Reihe von Wiederholungsversuchen oder Skalierungsanfragen an einen beeinträchtigten Anbieter zu senden.

Stimmen Sie schließlich nach der Übung ab. Stellen Sie fest, welche Transaktionen fehlschlugen, welche wiederholt wurden, welche dupliziert wurden, welche in der Warteschlange blieben und welche Kunden benachrichtigt werden müssen. Die Wiederherstellung des Anbieters garantiert keine Anwendungskorrektheit. Die Wiederherstellungsziele sollten die Abarbeitung des Rückstaus und die Datenvalidierung umfassen, nicht nur einen HTTP-Health-Check.

Für kleinere Organisationen kann die verhältnismäßige Version bescheiden sein: ein externer Verfügbarkeits-Check, eine Statusseite bei einem anderen Anbieter, exportierte Kontaktdaten und Runbooks, getestete Backups, bekannte manuelle Verfahren und eine dokumentierte Entscheidung, ob Multi-Cloud-Kosten gerechtfertigt sind. Rechenschaftspflicht ist nicht gleichbedeutend mit maximaler Architektur. Es ist die Fähigkeit zu zeigen, dass eine bewusste Risikoentscheidung eine versehentliche Abhängigkeit ersetzt hat.

Eine Bewertungstafel für Kontrollinstanz- und Netzwerk-Rechenschaftspflicht

Ein Vorstand, eine Regulierungsbehörde oder ein Großkunde benötigt keinen proprietären Quellcode, um präzise Fragen zu stellen. Es benötigt Nachweise, die auf die beobachteten Fehlermodi abgebildet sind.

Die Bewertungstafel sollte zeilenübergreifend gelesen werden. Ein Feature-Flag ohne unabhängigen Status ist nicht genug. Vier Interconnect-Verbindungen ohne Anbieter- und Router-Diversität reichen möglicherweise nicht aus. Eine Multi-Region-Anwendung ohne vorbereitete Wiederherstellung kann dennoch vom globalen Controller abhängen. Zuverlässigkeit ergibt sich aus der Zusammensetzung von Kontrollen und aus dem Nachweis, dass die Zusammensetzung unter Fehlerbedingungen funktioniert.

Das dauerhafte Signal ist die Geschwindigkeit geteilter Autorität

Cloud-Plattformen schaffen Wert, indem sie Entscheidungen zentralisieren. Eine Richtlinie kann Tausende von Projekten regieren. Ein Netzwerk kann Datenverkehr zwischen Kontinenten transportieren. Eine API kann Infrastruktur in Sekunden erstellen. Dieselbe Hebelwirkung bestimmt den Explosionsradius von Fehlern.

Der Ausfall vom Juni 2025 sollte daher nicht am besten als Nullpointer in Erinnerung bleiben. Nullpointer sind gewöhnliche Softwarefehler. Was diesen global folgenreich machte, war, dass ruhender Code, ungültige Richtlinie, schnelle Replikation, regionale Leser, synchronisierter Neustart, gemeinsame Überwachung und nachgelagerte Anbieter eine Kette bildeten. Das System war verteilt, aber die Autorität war nicht ausreichend partitioniert.

Googles Antwort identifizierte die richtigen Themen: inkrementelle Verbreitung, Feature-Flags, modulare Fehler, Backoff und unabhängige Kommunikation. Kunden sollten erwarten, dass diese Änderungen funktionieren, während sie ehrlich über die Risiken sind, die sie noch besitzen. Ein Workload kann über Regionen verteilt sein und dennoch von einer globalen Entscheidung abhängen. Ein Unternehmen kann zwei Netzwerke kaufen und dennoch eine Route zum Schicksal verwenden. Eine Statusseite kann öffentlich sein und dennoch innerhalb des Vorfalls leben.

Der richtige Maßstab für Rechenschaftspflicht ist nicht, dass eine globale Cloud niemals ausfallen darf. Es ist, dass sich globale Autorität nicht schneller bewegen darf als die Kontrollen, die sie validieren; dass regionale Systeme in der Lage sein müssen, unsichere gemeinsame Zustände abzulehnen oder zu überleben; dass Netzwerk- und Wiederherstellungspfade betrieblich unabhängig sein müssen, nicht nur dem Namen nach; und dass Kunden den Ausfall sehen können müssen, während noch Zeit zum Handeln bleibt. In einer Cloud-Kontrollinstanz ist Geschwindigkeit Macht. Resilienz beginnt damit, Grenzen zu setzen, wohin diese Macht reisen kann.