Bericht zum Google-Cloud-Ausfall – 2025-06-13

 (status.cloud.google.com)
3 Punkte von GN⁺ 2025-06-16 | 2 Kommentare | Auf WhatsApp teilen
  • Am 12. Juni 2025 kam es bei Google Cloud- und Google Workspace-Diensten weltweit zu einem Anstieg von 503-Fehlern bei externen API-Anfragen
  • Ursache war eine Codeänderung im Service-Control-System sowie die Ausrollung einer fehlerhaften Richtlinie, die leere Felder in den Policy-Daten enthielt
  • Unzureichende Fehlerbehandlung im zentralen Binärprogramm und das Fehlen von Feature-Flags verschärften die Ausbreitung des Problems
  • Die Wiederherstellung dauerte 2 bis 3 Stunden; in der Region us-central-1 kam es wegen Infrastrukturüberlastung zu einer längeren Erholungszeit
  • Google kündigte Maßnahmen zur Vermeidung künftiger Vorfälle an, darunter Architekturtrennung, verbesserte Fehlerbehandlung und stärkere Datenvalidierung

Gesamtüberblick über den Ausfall

Zusammenfassung des Ausfalls bei Google Cloud- und Google-Workspace-Diensten

  • Ab 10:49 Uhr (PDT) am 12. Juni 2025 kam es bei mehreren Diensten, darunter Google Cloud, Google Workspace und Google Security Operations, zu einem sprunghaften Anstieg von 503-Fehlern bei externen API-Anfragen
  • Google entschuldigte sich ausdrücklich für die erheblichen Auswirkungen auf Kundendienste und Vertrauen
  • Die API-Verwaltungs- und Kontroll-Ebene von Google ist für Richtlinien- und Quotenprüfungen bei jeder Anfrage zuständig; das zentrale Prüfsystem läuft als Binärprogramm mit dem Namen Service Control

Analyse der Ausfallursache

Geänderte Systemarchitektur – Service Control

  • Am 29. Mai 2025 wurde Service Control um eine neue Funktion zur verschärften Prüfung von Quotenrichtlinien erweitert
  • Die Einführung erfolgte schrittweise nach Regionen, aber der problematische Code wurde erst dann aktiv, wenn die Richtlinie tatsächlich angewendet wurde; da dies zuvor nicht ausgelöst worden war, blieb die Vorabprüfung unzureichend
  • In diesem neuen Funktionspfad fehlten angemessene Fehlerbehandlung und Feature-Flags, sodass das Binärprogramm bei einer Null-Pointer-Situation kaskadierend abstürzte

Ablauf des Vorfalls

  • Am 12. Juni 2025 um 10:45 Uhr (PDT) wurde eine Richtlinienänderung in eine regionale Spanner-Tabelle eingetragen
  • Diese Policy-Daten enthielten ein unbeabsichtigtes leeres Feld (Blank Field), das fast in Echtzeit weltweit repliziert wurde
  • Als Service Control diese Richtlinie verarbeitete, führte ein Null Pointer zum Absturz, wodurch die Instanzen in allen Regionen global in einen Crash Loop gerieten
  • Innerhalb von 2 Minuten begann das SRE-Team mit der Erkennung, identifizierte innerhalb von 10 Minuten die Ursache, blockierte den Binärpfad vorübergehend per Red Button, und die meisten Regionen waren nach 40 Minuten wiederhergestellt

Zusätzliche Probleme bei der Wiederherstellung

  • In einigen großen Regionen wie us-central-1 führte der Herd Effect beim Neustart von Service Control-Tasks zu einer Überlastung der Infrastruktur, insbesondere der Spanner-Tabellen
  • Da Service Control kein zufälliges exponentielles Backoff anwandte, wurde die Belastung der Infrastruktur zusätzlich verstärkt
  • In dieser Region verzögerte sich die Wiederherstellung um bis zu 2 Stunden und 40 Minuten; durch Traffic-Umleitung wurde die Auswirkung minimiert, und insgesamt wurde der Dienst vollständig wiederhergestellt

Kundenauswirkungen und Umfang des Ausfalls

  • Für Kunden kam es zu Störungen beim Zugriff auf APIs und Benutzeroberflächen; Streaming- und IaaS-Ressourcen waren nicht betroffen
  • Auswirkungen durch Latenzen und Backlogs hielten bei einigen Diensten noch über eine Stunde an
  • Die Liste der betroffenen Google-Cloud- und Google-Workspace-Produkte war umfangreich
    • Beispiele: IAM, Cloud Build, Cloud Storage, BigQuery, AppSheet, Gmail, Google Drive und Dutzende weitere Dienste

Geplante Verbesserungsmaßnahmen

  • Modularisierung der Service-Architektur, um Funktionen voneinander zu trennen und bei Störungen ein offenes Fehlerverhalten (fail open) zu ermöglichen
  • Schrittweise Verbreitung globaler Datenreplikation und stärkere praktische Validierungsprozesse
  • Richtlinienänderung, nach der bei allen wichtigen Binäränderungen Feature-Flags und standardmäßige Deaktivierung verpflichtend angewendet werden
  • Überprüfung des Designs, damit durch verbesserte statische Analyse und Tests Fehler besser erkannt und Systeme im Störungsfall fail open reagieren können
  • Geplant sind außerdem zufälliges exponentielles Backoff sowie stärkere Zuverlässigkeit bei Monitoring und Kommunikation
  • Auch im Störungsfall soll Kunden eine schnelle Überwachung und Informationsbereitstellung ermöglicht werden; dazu werden Infrastrukturredundanz und automatisierte Kommunikation verbessert

Störungsmeldung und Kommunikation

  • Zwar wurde der Vorfall innerhalb einer Stunde bei Cloud Service Health bekannt gemacht, doch auch die Monitoring-Infrastruktur selbst war vom Ausfall betroffen
  • Für einige Kunden funktionierten Monitoring-Systeme auf Basis von Google Cloud selbst nicht ordnungsgemäß, was die Erkennung von Störungssignalen und die Einschätzung der Auswirkungen erschwerte
  • Google versprach, künftig die Monitoring- und Kundenkommunikations-Infrastruktur auszubauen

Wichtige Zeitleiste des Vorfalls (Kurzbericht)

  • Beginn des Ausfalls: 12. Juni 2025, 10:49 Uhr (PDT)
  • Wiederherstellung in den meisten Regionen: 12. Juni 2025, 12:48 Uhr (PDT)
  • Ende des Ausfalls: 12. Juni 2025, 13:49 Uhr (PDT)
  • Gesamtdauer: etwa 3 Stunden
  • Betroffene Regionen: weltweit

Zusammenfassung der Nachbesserungen

  • Für die API-Management-Plattform sollen Schutzmechanismen gegen Datenfehler oder Beschädigungen eingeführt werden
  • Vor der globalen Metadatenverteilung werden Validierung, Tests und Monitoring verstärkt
  • Die Fehlerbehandlung im System und umfassende Tests für ungültige Daten werden ausgeweitet

Liste betroffener Dienste (Auszug)

Wichtige Google-Cloud-Dienste

  • Identity and Access Management, Cloud Build, Google Cloud Storage, Cloud Monitoring, BigQuery, Vertex Gemini API, Cloud Firestore, Looker, Cloud Run, Compute Engine usw.

Wichtige Google-Workspace-Dienste

  • AppSheet, Gmail, Google Drive, Google Meet, Docs, Chat, Calendar usw.

Fazit

  • Dieser Ausfall war das Ergebnis eines Zusammenwirkens von Problemen in der Architektur des Richtlinien-/Quotenverwaltungssystems, unzureichender Prüfung der Datenintegrität und fehlender Fehlerbehandlungsmechanismen
  • Google sagte Verbesserungen auf Architekturebene sowie eine stärkere Reaktionsfähigkeit bei Störungen zu

Verwandte Beiträge

2 Kommentare

 
kunggom 2025-06-16

Hier ist der Link zur Version des Artikels, die nicht GN+ ist.
 
GN⁺ 2025-06-16
Hacker-News-Kommentare

  • Ich schreibe hier mit einem temporären Konto aus Insider-Perspektive. Die eigentliche Ursache dieses Vorfalls war, dass die Führung Prinzipien ignoriert hat, um mehr Geschwindigkeit zu erzwingen. Diese Praxis hat sich über Jahre fortgesetzt und schließlich ihren Grenzpunkt erreicht. Die diesmal aufgetretene „query of death“ ist ein typischer Fehlermodus, der bei älteren C++-Servern unvermeidlich auftritt, wenn ein bestimmter Query den Server zum Absturz bringt. Service Control wurde in C++ geschrieben und hat versucht, solche Fehler mit verschiedenen Engineering-Richtlinien zu minimieren. Zehn Jahre lang lief es ohne größeren Vorfall, aber die jüngst unter Führungsdruck hastig entwickelte globale Quota-Policy war das Problem. Solche neuen Funktionen hätten als eigener Service entwickelt werden sollen oder zumindest den bestehenden Richtlinien folgen müssen. Die Standards, die das Team ursprünglich eingehalten hat, liegen deutlich höher als die im offiziellen Bericht genannten Maßnahmen. Das Team versucht, die bisherigen Maßstäbe so gut wie möglich aufrechtzuerhalten.

    • Man kann nicht die gesamte Verantwortung nur der Führung zuschieben. Dass ein Rollout mit globalem Radius nicht extrem vorsichtig geprüft wurde, ist ein Versagen der Engineering-Kultur. Zumindest hätte die globale Policy vor dem regionalen Service-Control-Rollout erfolgen müssen.

  • Ich finde den Incident-Report interessant. Das SRE-Team hat innerhalb von 2 Minuten schnell reagiert, und der „red button“-Rollout wurde gestartet. Das Problem war, dass beim Neustart der Service-Control-Tasks in großen Regionen wie us-central-1 ein „herd effect“ auftrat, der die Infrastruktur (Spanner-Tabellen) überlastete. Da in Service Control kein zufälliger exponentieller Backoff implementiert war, verzögerte sich die vollständige Wiederherstellung auf bis zu 2 Stunden und 40 Minuten. In solchen Situationen werden normale Quotas schnell überschritten, was zu neuen Störungen führt. Wenn die Infrastruktur das aushält, wäre es meiner Meinung nach sinnvoll, Quotas vorübergehend auszusetzen oder die Recovery-Arbeiten absichtlich langsamer zu drosseln.

    • In dieser Situation war exponentieller Backoff keine geeignete Maßnahme. Beim Lesen wichtiger Daten beim Serverstart wird absichtlich ohne Retry gearbeitet, daher greift Backoff dort nicht. Besser wäre es, die Last schnell auf die bereits vorhandene Backup-Datenbank zu verteilen. Es gibt auch andere Möglichkeiten.

  • Das wirkt auf mich wie ein wirklich amateurhafter Fehler. NPE, keine Fehlerbehandlung, kein exponentieller Backoff, keine Testabdeckung, keine Tests in der Staging-Umgebung, kein schrittweiser Rollout — alles schwerwiegende Fehlleistungen. Das alles steht bereits im SRE-Buch: Google SRE Book Inhaltsverzeichnis, Building Secure and Reliable Systems TOC. Ich frage mich, ob der Standard so stark gesunken ist oder ob das Buch einfach nur Marketing ist.

    • Meiner Meinung nach gibt es weder bei Menschen noch bei Automatisierung perfekte Schutzmechanismen, am Ende ist alles eine Folge von Trade-offs. Egal wie viele Unit-Tests, Integrationstests, statische Analysen und schrittweise Deployments man macht: In ausreichend großem Maßstab entstehen zwangsläufig unerwartete Lücken. Das ist derselbe Grund, warum im Buch steht, dass „jede zusätzliche 9“ unverhältnismäßig mehr Aufwand kostet. Im schlimmsten Fall müsste man den gesamten Stack duplizieren und monatelangen Traffic komplett erneut abspielen, aber dieses Kosten-Nutzen-Verhältnis kann niemand tragen. Ich habe Ähnliches bei Arbeiten an OpenZFS erlebt: Der Code selbst sah korrekt aus, aber das Problem zeigte sich in einem Daten-Edge-Case aus vor zehn Jahren. Sobald ein System komplex genug wird, ist es unmöglich, alle Varianten zu testen, also kann man realistisch nur nach Kosten-Nutzen entscheiden. Zur Einordnung: Ich bin bei Google SRE, aber in einem Team, das mit diesem Vorfall nichts zu tun hat; das ist nur meine persönliche Meinung.

    • Fast alle globalen Google-Ausfälle laufen so ähnlich ab: Ein schnell global ausgerolltes maßgeschneidertes System übernimmt eine fehlerhafte Konfiguration. Bei normalen Binary-Rollouts oder Config-Pushes ist ein schrittweiser Rollout üblich. Auch bei Google Cloud waren früher viele Systeme global gekoppelt, inzwischen ist vieles stärker regionalisiert und zuverlässiger. Früher gab es ebenfalls öfter globale Ausfälle, sie wurden nur nicht veröffentlicht, sodass die meisten Nutzer dachten, es liege an ihrem ISP. Ich glaube nicht, dass sich die Lage derzeit besonders verschlechtert. Zur Einordnung: Ich habe ebenfalls SRE-Erfahrung.

    • Aus Sicht eines Außenstehenden wirkt es so, als habe sich nach den großen Entlassungswellen und den Aussagen des CEO über „Faulheit“ alles auf Geschwindigkeit und sichtbare Ergebnisse statt auf Qualität fokussiert. Allmählich entstand ein Umfeld, in dem man eher ausgegrenzt wird, wenn man diese Kultur problematisiert.

    • Ich wünschte, es gäbe mehr veröffentlichte Details. Meiner Ansicht nach wurde nicht, wie hier behauptet, gar nicht getestet, sondern es fehlte ein Test für ein leeres Feld in der Policy, also genau den problematischen Input. Es wird auch nicht gesagt, dass es keine Tests in der Staging-Umgebung gab; eher wird angedeutet, dass ein Flag das abgefangen hätte. Persönliche Meinung.

    • Das erinnert mich an einen Bericht über ein Schießpulverlager von 1864: „Selbst beim gefährlichsten Werkzeug verliert man mit der Gewöhnung seine Vorsicht und hält die Vorschriften irgendwann für unnötig streng.“

  • Ich bin in einem anderen Team innerhalb von Cloud. Im Allgemeinen hat jeder Code Unit- und Integrationstests. Binary- oder Konfigurationsänderungen werden pro Task und pro Region über mehrere Tage schrittweise ausgerollt, begleitet von Canary-Analysen. Selbst ein Rollback wird langsam durchgeführt, weil ein zu hektisches Vorgehen die Lage verschlimmern kann. Zum Beispiel sind 40 Minuten Ausfall besser als 4 Stunden Störung, wenn man damit vermeidet, eine globale Datenbank auf einmal zu überlasten. Ich war an diesem Vorfall nicht direkt beteiligt, aber laut PM wurde der Code getestet, nur dieser Edge-Case wurde übersehen. Das Problem war, dass die Quota-Policy-Konfiguration nicht als Binary oder Konfigurationsdatei ausgerollt wurde, sondern als Datenbank-Update, das sich innerhalb von Sekunden auf alle Datenbanken weltweit ausbreitete. Das Null-Pointer-Problem hätte in anderen Sprachen womöglich ebenfalls über assert() auftreten können. Statt die Risiken eines Rewrite dieses kritischen Dienstes in eine andere Sprache einzugehen, erscheint es vernünftiger, alle Policy-Checks mit Flag-Guards zu versehen, Quota-Policy-Checks fail-open zu gestalten und DB-Änderungen langsam regionenweise zu verteilen. Persönliche Meinung.

    • assert lässt sich strukturell sehr viel leichter per Policy verbieten.

    • Wenn der Code getestet wurde, dieser Edge-Case aber fehlte, dann wurde er letztlich eben doch nicht getestet.

    • Dass DB-Änderungen keine Binary- oder Konfigurationsänderungen sind, macht das Problem nicht grundlegend anders. Wenn sich eine Änderung gleichzeitig global ausbreitet, ist sie unabhängig vom Typ ein Keim für eine Katastrophe. Das ist derselbe Ablauf wie beim Crowdstrike-Vorfall.

    • Wenn die Aussage lautet, dass „ein Rewrite in eine andere Sprache zu riskant ist“, frage ich mich, ob die Service-Anforderungen dann nicht sauber verstanden sind oder ob der Dienst nicht wichtig genug ist, um eine sorgfältige Migration zu rechtfertigen.

  • Hier steht, dass das Binary wegen eines Null-Pointers ohne angemessene Fehlerbehandlung abgestürzt ist. Da ist der Witz von einem „Trillion-Dollar-Mistake“ fast schon naheliegend.

    • Ich frage mich, wie viele SLAs durch diesen Vorfall für ein ganzes Jahr ruiniert wurden.

    • Man wünscht sich fast, es gäbe eine Sprache, die so etwas verhindern könnte. /s

  • Service Control (Chemist) ist ein ziemlich alter Dienst und übernimmt eine zentrale Rolle bei Authentifizierung, Berechtigungen, Monitoring, Quotas usw. für viele GCP-APIs. Im Request-Flow laufen die meisten GCP-APIs über Chemist, weshalb ich fail-open als wenig wirksame Abmilderung ansehe. Sowohl Chemist als auch der Proxy sind in C++ geschrieben, und über die Jahre hat sich viel Legacy-Code angesammelt. Die einzelnen Teams verfügen über statische Analyse, Tests, schrittweise Deployments, Feature-Flags, red button sowie starke Monitoring- und Alerting-Systeme; besonders die SRE-Teams sind hervorragend. Da Chemist viele Policies wie IAM und Quotas prüft, tragen viele Teams zum Codebestand bei. Um nicht bei jeder Änderung den Chemist-Genehmigungsprozess durchlaufen zu müssen, wurde viel über Abkürzungen entwickelt. In jüngerer Zeit lag der Schwerpunkt wegen Reorganisationen und viel Offshoring auf spektakulären neuen Projekten unter Führung von L8/L9-Leuten, während Qualität, Wartbarkeit und Zuverlässigkeit nachrangig wurden; wegen dieses Kulturwandels habe ich Cloud verlassen. Allgemeine Best Practices für Google-Server und -Services werden hier oft nicht eingehalten. Dieses Problem lag eher an mangelhaftem Code und Code-Review; fehlerhafter Code wurde freigegeben, und dass Konfigurationsänderungen per Spanner sofort wirksam wurden, hat die Lage verschärft.

  • Die Service-Policy-Daten enthielten unbeabsichtigt ein leeres Feld, und als Service Control dieses leere Feld (null) bei Quota-Checks pro Region las, trat eine Exception auf. Das ist ein weiteres Beispiel dafür, wie Hoares „Billion-Dollar-Mistake“ sich in mehreren Google-Systemen wiederholt. Das eigentliche Problem ist, dass ein solches „leeres Feld“ (null) überhaupt zugelassen wurde; im Schema hätte NOT NULL festgelegt werden müssen. Unglücklicherweise ist der Standard in Spanner nullable, sofern man es nicht ausdrücklich anders angibt. Es gab außerdem weitere Chancen, auf Anwendungsebene über das Typsystem oder eine Schema-Sprache ungültige Zustände unmöglich zu machen. Man hätte auch beim Deserialisieren aus dem Datastore in App-Objekte eine erzwungene Schema-Validierung hinzufügen können. Da das Problem in einem neuen Codepfad auftrat, vermute ich, dass es auf der Datenschicht nicht herausgefiltert wurde. Dass das Service-Control-Programm selbst in einer Sprache geschrieben ist, die Null-Pointer-Dereferenzierung zulässt, ist ebenfalls ein Problem. Wenn ich dafür verantwortlich wäre, würde ich einen Plan mit minimalem Eingriff erwägen, bei dem Policies im Anwendungscode in eine Struktur wie einen „tagged enum type“ überführt werden, die null nicht ausdrücken kann. Proto3 bietet diese Einschränkung nicht, aber so ein Beispiel gibt es.

  • Multi-Region wird oft als Mittel für Resilienz und Verfügbarkeit genannt, aber es ist interessant zu sehen, wie stark sogar große Cloud-Anbieter im Störungsfall tatsächlich regionsübergreifend miteinander verknüpft sind.

    • Das ist besonders bei GCP ausgeprägt, weil GCP Regionen anders behandelt als andere Anbieter. Unter Resilienzgesichtspunkten sollte man GCP eher wie eine einzelne Region mit mehreren zusammengebundenen Zonen betrachten.

    • Trotzdem sollte man die Wirkung von Sharding über Regionen und Zonen nicht zu sehr unterschätzen, denn es kann immer noch „Ausfälle geben, von denen wir nichts wissen“.

    • Es gibt auch viele Fälle, in denen Multi-Region-Deployments Vorfälle verhindert haben. Man sollte solche Fälle erst betrachten, bevor man ein Urteil fällt.

  • Ich bin immer wieder beeindruckt von der Detailtiefe in Googles Postmortems, sowohl innerhalb als auch außerhalb des Unternehmens. Man lernt daraus, damit sich Fehler nicht wiederholen, stärkt Protokolle und Fehlerbehandlung und entwickelt robustere Systeme. In einem Unternehmen von Googles Größe läuft immer irgendwo etwas schief, aber entscheidend ist, die Auswirkungen auf Kunden, Nutzer und andere Systeme einzudämmen. Selbst intern gibt es je nach Team viele unsichtbare Probleme. Das gehört meiner Ansicht nach zu den komplexesten Systemen, die Menschen je gebaut haben. Wenn es nicht gerade AGI ist, gibt es kaum einen Bereich, in dem Menschen es besser machen könnten.

    • Bei diesem Vorfall traten allerdings mehrere Anfängerfehler hintereinander auf. Dass man Null-Daten nicht behandeln konnte, zu wenig Tests hatte, keine Testabdeckung für neue Funktionen besaß und vor dem flächendeckenden Rollout nicht in kleinem Produktionsmaßstab validiert hat, ist alles problematisch. Ich bin sicher, dass man bei Google vor 10 Jahren über solche Fehler gelacht hätte.

    • So wie ich es verstehe, bestand die Ursache dieses Ausfalls aus 1) einer globalen Funktion, die auf einen Schlag komplett ausgerollt wurde, 2) einer Null-Pointer-Dereferenzierung und 3) fehlenden angemessenen Retry-Strategien, die ein „thundering herd“-Problem auslösten. Das sind alles Fehler, die jedem in der Branche vertraut sind. Es war keine neuartige oder besonders komplexe Logik verteilter Systeme, sondern eine typische Kombination aus „Anfängerfehlern“.

    • Man sagt zwar „denselben Fehler machen wir nie wieder“, aber tatsächlich wurde die Änderung ohne Feature-Flag ausgerollt, und auf Client-Seite gab es weder exponentiellen Backoff noch auf Server-Seite Load Shedding. All das steht seit Jahren im google SRE book.

    • Dieser Fehler war ein nicht abgefangener Null-Pointer. Dass ein Unternehmen mit Googles Größe und Qualitätsanspruch auf diese Weise den Großteil seines Stacks lahmlegt, kann als Signal gelesen werden, dass die Maßnahmen zur Verhinderung einer Wiederholung schwerwiegender Probleme unzureichend sind.

    • Das ist derselbe Fehler, der unzählige Male wiederholt wurde. „Neue Funktionen werden vorsichtig ausgerollt, aber der Bug zeigt sich erst, wenn neue Daten eintreffen“ fasst die meisten globalen Ausfälle gut zusammen. Perfekte Systeme gibt es nicht; in FAANG-Ausfalldebatten sind nur die Sessel-Experten auf HN fehlerfrei.

  • Meistens kritisiert man fremde Downtime leichtfertig als „Anfängerfehler“, aber bei der eigenen Arbeit bleibt dann immer die Ausrede, es sei unvermeidbar oder unvorhersehbar gewesen. Menschliche Fehler sind unvermeidlich, und die Erwartungen sind von vornherein zu hoch. Wenn ein Laden vor Ort plötzlich schließt, endet es auch mit einem einfachen „Entschuldigung“. Nur in der IT-Branche setzt man sich wegen eines mehrstündigen Ausfalls übermäßig unter Stress; ich wünschte, alle könnten etwas gelassener damit umgehen.