Google-Cloud-Störungsbericht – 2025-06-13

• Am 12. Juni 2025 waren weltweit Kunden betroffen, da bei externen API-Anfragen in Google Cloud, Google Workspace und Google Security Operations vermehrt 503-Fehler auftraten
• Eine neue Prüfung der Quotenrichtlinien in Service Control traf auf Richtliniendaten mit leeren Feldern und löste dadurch eine Null-Pointer-Crash-Schleife aus; dieser Pfad wurde während des Rollouts nicht ausgeführt
• Als die Richtlinienänderung innerhalb von Sekunden von einer regionalen Spanner-Tabelle weltweit repliziert wurde, liefen die Service-Control-Deployments in jeder Region in denselben Fehlerpfad und die Störung weitete sich zu einem globalen Ausfall aus
• Das SRE-Team reagierte innerhalb von 2 Minuten, identifizierte die Ursache innerhalb von 10 Minuten und schloss den Red-Button-Rollout in etwa 40 Minuten ab, doch die Wiederherstellung in us-central1 dauerte bis zu rund 2 Stunden 40 Minuten
• Die Maßnahmen zur Verhinderung eines erneuten Vorfalls konzentrieren sich auf das Einfrieren von Service-Control-Änderungen, standardmäßig deaktivierte Feature-Flags, die schrittweise Verteilung global replizierter Daten sowie Verbesserungen bei Fehlerbehandlung und zufälligem exponentiellem Backoff

---

Umfang und Zeitplan der Störung

• Kunden waren betroffen, da bei externen API-Anfragen in Produkten von Google Cloud, Google Workspace und Google Security Operations vermehrt 503-Fehler auftraten
• Alle wichtigen Zeiten sind in US/Pacific angegeben
  • Beginn der Störung: 12. Juni 2025, 10:49
  • Minderung in allen Regionen außer us-central1: 12:48
  • Ende der Störung: 13:49
  • Gesamtdauer: 3 Stunden
  • Betroffener Bereich: Global
• Kunden hatten bei betroffenen Diensten mitunter Probleme beim Zugriff auf APIs und Benutzeroberflächen
• Bestehende Streaming- und IaaS-Ressourcen waren nicht betroffen

Der von Service Control übernommene Prüfpfad

• Google- und Google-Cloud-APIs werden über die Google-API-Management- und Control-Plane bereitgestellt
• Diese Management- und Control-Plane prüft für jede API-Anfrage Folgendes
  • ob die Anfrage autorisiert ist
  • ob sie Prüfungen wie Richtlinien und Quoten besteht und an den Endpunkt weitergeleitet werden kann
• Das zentrale Binärprogramm des Richtlinienprüfungssystems ist Service Control
• Service Control ist ein regionaler Dienst und verwendet einen regionalen Datenspeicher, aus dem Quoten- und Richtlinieninformationen gelesen werden
• Die Metadaten dieses Datenspeichers werden für die Verwaltung von Quotenrichtlinien in Google Cloud und bei Kunden nahezu sofort weltweit repliziert

Unmittelbare Ursache: leeres Richtlinienfeld und Null-Pointer

• Am 29. Mai 2025 wurde Service Control eine neue Funktion für zusätzliche Prüfungen von Quotenrichtlinien hinzugefügt
• Die Codeänderung und das Binär-Release wurden regionenweise ausgerollt, doch der fehlerhafte Codepfad erforderte eine bestimmte Richtlinienänderung und wurde daher während des Rollouts nicht validiert
• Für den problematischen Code gab es zwar einen Red Button, um diesen Richtlinienbereitstellungspfad abzuschalten, aber es fehlten eine angemessene Fehlerbehandlung und der Schutz durch ein Feature-Flag
• Ein Null-Pointer wurde nicht korrekt behandelt und führte zum Absturz des Service-Control-Binärprogramms
• Google erklärte, dass das Problem bei Absicherung durch ein Feature-Flag bereits in Staging erkannt worden wäre, während die Funktion schrittweise regionenweise zunächst für interne Projekte aktiviert worden wäre

Wie sich der Fehler global ausbreitete

• Am 12. Juni 2025 gegen 10:45 PDT wurde eine Richtlinienänderung in eine regionale Spanner-Tabelle eingefügt, die Service Control für Richtlinien verwendet
• Diese Richtliniendaten enthielten unbeabsichtigt ein leeres Feld
• Da das Quotenmanagement global arbeitet, wurden diese Metadaten innerhalb von Sekunden weltweit repliziert
• Als Service Control in jeder Region Quotenprüfungen für die Richtlinien im regionalen Datenspeicher durchführte, las es das leere Feld und führte den Codepfad aus, der auf den Null-Pointer traf
• Infolgedessen geriet das Binärprogramm in jedem regionalen Deployment in eine Crash-Schleife

Reaktion und Verzögerung bei der Wiederherstellung

• Das SRE-Team begann innerhalb von 2 Minuten nach Störungsbeginn mit Triage und Reaktion
• Innerhalb von 10 Minuten wurde die Grundursache identifiziert und die Anwendung des Red Button eingeleitet
• Der Red Button war etwa 25 Minuten nach Störungsbeginn zum Rollout bereit
• Innerhalb von 40 Minuten nach Störungsbeginn war der Red-Button-Rollout abgeschlossen, und aus kleineren Regionen kamen erste Signale der Wiederherstellung
• In großen Regionen wie us-central1 erzeugten Neustarts von Service-Control-Aufgaben einen Herd Effect auf abhängige Infrastruktur, insbesondere auf Spanner-Tabellen, was zu Überlastung führte
• In Service Control war kein angemessener zufälliger exponentieller Backoff implementiert, um dies zu vermeiden
• In us-central1 wurde die Erzeugung von Aufgaben gedrosselt und Traffic auf eine multi-regionale Datenbank umgeleitet, um die Last zu senken; bis zur vollständigen Behebung dauerte es dort bis zu etwa 2 Stunden 40 Minuten
• Danach waren Service Control und API Serving in allen Regionen vollständig wiederhergestellt
• Zugehörige Google- und Google-Cloud-Produkte wurden je nach Architektur zum Teil später und schrittweise wiederhergestellt

Statusseite und Kundenkommunikation

• Der erste Störungsbericht auf Cloud Service Health wurde etwa 1 Stunde nach Beginn der Abstürze veröffentlicht
• Der Grund für die Verzögerung war, dass die Cloud-Service-Health-Infrastruktur selbst von dieser Störung betroffen war
• Bei einigen Kunden fiel auch die in Google Cloud betriebene Monitoring-Infrastruktur aus, sodass sie weder Störungssignale noch das Ausmaß der geschäftlichen und infrastrukturellen Auswirkungen erkennen konnten
• Google erklärte, die automatische und manuelle externe Kommunikation zu verbessern, damit Kunden die Informationen, die sie zum Reagieren auf Probleme, zum Verwalten ihrer Systeme und zur Unterstützung ihrer Kunden benötigen, schneller erhalten
• Außerdem erklärte Google, sicherzustellen, dass Monitoring- und Kommunikationsinfrastruktur Kunden weiterhin zur Verfügung steht, auch wenn Google Cloud und grundlegende Monitoring-Produkte ausfallen

Sofortmaßnahmen und Plan zur Verhinderung weiterer Vorfälle

• Unmittelbar nach der Wiederherstellung wurden sowohl Änderungen am Service-Control-Stack als auch manuelle Richtlinien-Pushes eingefroren
• Google erklärte, die folgenden Maßnahmen priorisiert und sicher umzusetzen
  • die Service-Control-Architektur zu modularisieren, um Funktionen zu isolieren, und sie auf eine Fail-Open-Struktur umzustellen, damit API-Anfragen auch dann weiterverarbeitet werden können, wenn zugehörige Prüfungen fehlschlagen
  • alle Systeme zu prüfen, die weltweit replizierte Daten konsumieren
  • Datenreplikation schrittweise zu verteilen, selbst wenn geschäftliche Anforderungen nahezu sofortige globale Konsistenz verlangen, damit genügend Zeit für Problemvalidierung und Erkennung bleibt
  • alle kritischen Binäränderungen durch Feature-Flags zu schützen und standardmäßig zu deaktivieren
  • statische Analyse und Testverfahren zu verbessern, damit Fehler korrekt behandelt und bei Bedarf Fail Open angewendet werden kann
  • zu prüfen und sicherzustellen, dass Systeme zufälligen exponentiellen Backoff verwenden
  • die Kundenkommunikation zu verbessern
  • den Betrieb der Monitoring- und Kommunikationsinfrastruktur auch während Ausfällen von Google Cloud und grundlegenden Monitoring-Produkten aufrechtzuerhalten

Betroffene Dienste und verbleibende Auswirkungen

• Zahlreiche Produkte von Google Cloud waren betroffen; dazu gehörten unter anderem Identity and Access Management, Cloud Build, Google Cloud Storage, Cloud Monitoring, Cloud Run, Google BigQuery, Vertex Gemini API, Apigee, Google Cloud Bigtable, Cloud Functions, Cloud Load Balancing, Cloud Firestore, Cloud Logging, Cloud Spanner, Google App Engine, Google Cloud Console, Google Compute Engine, Cloud SQL, Cloud Pub/Sub, Persistent Disk und Google Security Operations
• Bei Google Workspace waren AppSheet, Gmail, Google Calendar, Google Drive, Google Chat, Google Voice, Google Docs, Google Meet, Google Cloud Search und Google Tasks betroffen
• Bei einigen Produkten blieben auch nach der Minderung der Hauptstörung Restauswirkungen bestehen
  • Bei Google Cloud Dataflow wurde der Rückstau schrittweise abgebaut, in us-central1 blieben Verzögerungen bestehen
  • Bei Vertex AI Online Prediction traten bei einigen Modellen in Model Garden weiterhin hohe 5xx-Fehler auf; vollständige Wiederherstellung erfolgte später um 18:18 PDT
  • Bei Personalized Service Health kam es zu Verzögerungen bei Updates; Kunden wurde die Nutzung des Cloud-Service-Health-Dashboards empfohlen

[kunggom]

Hier ist der Link zur Version des Artikels, die nicht GN+ ist.

• https://de.news.hada.io/topic?id=21447