Zusammenfassung

  • Google Cloud erklärt den schwerwiegenden us-west1-Vorfall vom 20. August mit geplanter optischer Wartung, die im Großraum The Dalles in Oregon unerwartete Überlastung verursachte. Der offizielle Eintrag führt 27 Produkte auf.
  • Google empfahl, soweit möglich auf andere Regionen auszuweichen. Dafür mussten replizierte Daten, Verkehrssteuerung, Zugangsdaten, externe Abhängigkeiten und Entscheidungskompetenz bereits außerhalb der Region funktionieren.

Geplant war das Wartungsfenster, nicht die Überlastung. Entscheidend ist deshalb die verfügbare Restkapazität während eines Eingriffs. Google zufolge reichte diese Reserve in us-west1 nicht aus, um die Last ohne Folgen für zahlreiche Cloud-Dienste aufzunehmen.

Der Datensatz setzt den Beginn am 20. August um 15:40 UTC. Googles erste öffentliche Meldung folgte um 16:44:37, mehr als eine Stunde später, und nannte Zeitüberschreitungen, Beeinträchtigungen, Fehler und erhöhte Latenz bei mehreren Produkten. Um 17:13:59 und 17:32:15 riet das Unternehmen zum Wechsel in andere Regionen, sofern möglich.

Die abschließende Meldung besagt, dass Techniker Kapazität wiederherstellten und das zugrunde liegende Problem um 17:22 UTC eingedämmt war. Veröffentlicht wurde diese rückblickende Angabe erst um 19:37:40. Dazwischen hieß es, die Gegenmaßnahmen seien abgeschlossen, während einzelne Produkte sich weiter erholten. Der Vorfallseintrag endet um 19:20.

Die vier Zeitpunkte stehen für unterschiedliche Zustände: erfasster Beginn, Eindämmung des Engpasses, Abschluss des Eintrags und Veröffentlichung der Erklärung. Keiner von ihnen belegt allein, wann eine konkrete Anwendung wieder gesund war.

Der Vorfall trägt die hohe Schwere und die Auswirkung SERVICE_OUTAGE; 27 Produkte sind verzeichnet. Sie reichen über Rechenleistung, Speicher, Datenbanken, Datenverarbeitung, Build-Systeme, Monitoring, Identität und Messaging. Genannt werden unter anderem Compute Engine, GKE, Cloud Run, Cloud Storage, Cloud SQL, BigQuery, Pub/Sub, Cloud Monitoring, IAM und Persistent Disk.

Die Breite deutet auf eine gemeinsame regionale Abhängigkeit, aber nicht auf 27 gleichartige Totalausfälle hin. Google veröffentlicht weder produktspezifische Ausfallquoten noch die Zahl fehlgeschlagener Anfragen, Kunden- oder Projektgrundgesamtheiten, eine Zonenaufteilung oder eine Latenzverteilung.

Frühe Meldungen zeigten neben Oregon auch die Ortsmarke Global. Die Beschreibung verortet die Kundensymptome jedoch durchgehend in us-west1. Die Marke kann Produktreichweite oder eine Einordnung der Statusseite abbilden und ist kein Beleg für einen weltweiten Ausfall von Google Cloud.

Googles Architekturdokumentation beschreibt gemeinsame interne Funktionen wie Netzwerk, Rechenzentrumszugang und Identitätsautorisierung. Auch regionsübergreifende Replikation und Failover hängen von physischer Vernetzung ab. Die Rückkehr optischer Kapazität kann daher einen gemeinsamen Engpass lösen, während jeder verwaltete Dienst seine eigene Wiederherstellung fortsetzt.

Für Kunden ist „sofern möglich ausweichen“ eine Bedingung. Eine zweite Region muss vorhanden sein, ihre Daten müssen das Wiederherstellungspunktziel einhalten, und DNS oder Load Balancing, Warteschlangen, Identitäten, externe Dienste und Entscheidungswege müssen unter Störung funktionieren.

Googles Zuverlässigkeitsleitfaden verlangt Tests für regionales Failover, Rollback und Datenwiederherstellung sowie die Prüfung von Verkehrsverlagerung und Replikaten. Ein Architekturdiagramm oder eine ungenutzte Zweitumgebung weist das Wiederherstellungszeitziel nicht nach.

Der öffentliche Datensatz nennt weder optische Strecke, Carrier, Topologie, entnommene Kapazität, Überlastungsschwelle noch den konkreten Wartungsschritt. Er belegt keinen Datenverlust, Faserschnitt, Sicherheitsvorfall oder gescheiterten Failover eines namentlich bekannten Kunden. Google kündigt eine spätere Analyse an; im erfassten Eintrag liegt sie nicht vor.

Belastbar bleibt die engere Aussage: Laut Google verringerte die geplante Arbeit die nutzbare Netzkapazität so weit, dass regionale Überlastung entstand; anschließend erholte sich ein breites Produktspektrum schrittweise. Providerkapazität, Produktzustand und Kundenanwendung sind getrennt zu messen.

Quellen