Google Cloud: Generatoren starten nicht – Londoner Zone geht offline

Unternehmen und Produkt

Google Cloud ist die öffentliche Cloud-Plattform von Google. Die Region europe-west2 befindet sich in London und ist in drei Zonen unterteilt: europe-west2-a, europe-west2-b und europe-west2-c.

In seinem Bericht unterscheidet Google zwischen zwei Arten von Auswirkungen. Zonale Ressourcen wie Compute Engine-VMs, Persistent Disk und Datenbankinstanzen ohne Hochverfügbarkeit sind jeweils einer einzelnen Zone zugeordnet. Regionale Dienste erstrecken sich über mehrere Zonen innerhalb einer Region. Ihre Control Planes (Steuerungsebenen) können dabei von Komponenten in anderen Zonen abhängig sein.

Was war passiert?

Das Rechenzentrum, in dem die Zone europe-west2-b betrieben wird, verfügt über eine vollständig redundante externe Stromversorgung mit zwei unabhängigen Zuleitungen (A und B), eine Reihe von Notstromgeneratoren, die von zwei redundanten speicherprogrammierbaren Steuerungen (SPS) gesteuert werden, sowie Batterien einer unterbrechungsfreien Stromversorgung (USV), die die Zeit bis zum Anlaufen der Generatoren überbrücken sollen. Zusätzlich steht ein Reserveanschluss an das öffentliche Stromnetz zur Verfügung, der bei Wartungsarbeiten oder in Notfällen manuell für den gesamten Rechenzentrumscampus zugeschaltet werden kann.

Ab dem 14. Oktober war eine der beiden Stromzuleitungen aufgrund von Reparaturarbeiten gesperrt. Am 19. Oktober (US-Pazifikzeit) versagten die verbleibenden Absicherungssysteme nacheinander.

1. Eine Stromzuleitung war bereits außer Betrieb: Nachdem bei einem vierteljährlichen Lasttest der Notstromgeneratoren am 14. Oktober Probleme festgestellt worden waren, wurde der Leistungsschalter der Stromzuleitung B für Reparaturarbeiten geöffnet und mechanisch durch eine Schlüsselverriegelung gesperrt. Das Rechenzentrum wurde somit nur noch über Stromzuleitung A versorgt.
2. Die verbleibende Stromzuleitung fiel aus: Am 19. Oktober um 22:53 Uhr US-Pazifikzeit (20. Oktober, 06:53 Uhr britische Sommerzeit) fiel aufgrund eines Defekts an einem externen Erdkabel auch Stromzuleitung A aus.
3. Die Notstromgeneratoren sprangen nicht an: Die speicherprogrammierbaren Steuerungen (SPS), die den Start der Notstromgeneratoren auslösen sollten, prüften lediglich, ob an den Stromzuleitungen Spannung anlag, nicht jedoch, ob die zugehörigen Leistungsschalter geschlossen waren. Die Sensoren waren vor dem gesperrten Leistungsschalter der Stromzuleitung B angeschlossen, wo weiterhin Spannung anlag. Sowohl die primäre als auch die redundante SPS interpretierten dies als funktionierende externe Stromversorgung. Daher wurde kein Startbefehl an die Generatoren gesendet. Google identifizierte diese fehlerhafte Konfiguration der SPS-Steuerungslogik als eigentliche Ursache (Root Cause) des Incidents.
4. Die Batterien waren erschöpft: Die Batterien der unterbrechungsfreien Stromversorgung (USV) haben eine Überbrückungszeit von etwa fünf Minuten. Diese soll ausreichen, damit die SPS eine Unterspannung erkennt, die Generatoren startet und synchronisiert und anschließend die Stromversorgung auf die Generatoren umschaltet. Stromzuleitung A fiel um 22:53 Uhr aus. Um 23:00 Uhr waren die Batterien erschöpft und die gesamte Zone verlor ihre Stromversorgung.

Der Ausfall weitete sich auf andere Zonen aus. Auch die benachbarten Zonen europe-west2-a und europe-west2-c sowie regionale Dienste waren betroffen. Grund dafür waren ein sprunghafter Anstieg der Auslastung und zonenübergreifende Abhängigkeiten zwischen den Control Planes (Steuerungsebenen). Laut Google scheiterten einige Failover-Vorgänge aufgrund von Kapazitätsengpässen und Schwierigkeiten bei der Replikation der zugrunde liegenden Speichermechanismen.

Der Incident zeigt, wie ein bislang unentdeckter Fehler, der mehrere redundante Systeme gleichermaßen betrifft (Common-Mode-Fehler), durch den Betrieb mit eingeschränkter Redundanz zum Tragen kommen kann. Der Fehler in der SPS-Steuerungslogik wurde erst relevant, als das Rechenzentrum aufgrund der Wartungsarbeiten von seiner regulären 2N-Stromversorgung auf eine einzelne Stromzuleitung umgestellt wurde. Da beide redundanten SPS dieselbe Steuerungslogik und dieselben Eingangssignale verwendeten, versagten sie auf identische Weise.

Timeline

Alle Zeitangaben entsprechen der US-Pazifikzeit, wie sie im Bericht von Google angegeben sind. Die Londoner Ortszeit (BST) lag acht Stunden voraus.

• 14. Oktober 2026: Bei einem vierteljährlichen Lasttest der Notstromgeneratoren werden Probleme festgestellt. Daraufhin wird der Leistungsschalter der Stromzuleitung B geöffnet und für Reparaturarbeiten durch eine Schlüsselverriegelung gesperrt.
• 19. Oktober 2026
  
  • 22:53 Uhr: Stromzuleitung A fällt aufgrund eines externen Kabeldefekts aus. Die speicherprogrammierbaren Steuerungen (SPS) starten die Notstromgeneratoren nicht.
  • 23:00 Uhr: Die Batterien der unterbrechungsfreien Stromversorgung (USV) sind erschöpft und die Zone europe-west2-b verliert ihre Stromversorgung. Die Auswirkungen des Incidents beginnen.
  • 23:04 Uhr: Das Monitoring alarmiert die Google-Engineers.
  • 23:09 Uhr: Der automatische regionale Failover beginnt.
  • 23:54 Uhr: Die Stromversorgung über den Reserveanschluss wird wiederhergestellt.
• 20. Oktober 2026
  
  • 00:20 Uhr: Die Stromversorgung der Serverräume wird wiederhergestellt.
  • 00:40 Uhr: Die Cluster beginnen mit der Wiederherstellung.
  • 00:45 Uhr: Die Netzwerkgeräte sind wieder online.
  • 00:50 Uhr: Die Wiederherstellung der Speichersysteme beginnt.
  • 01:35 Uhr: Google veröffentlicht das erste Statusupdate.
  • 03:13 Uhr: Die Speichersysteme sind weitgehend wiederhergestellt.
  • 03:45 Uhr: Die kontrollierte Wiederaufnahme des Datenverkehrs in die Zone europe-west2-b beginnt.
  • 04:11 Uhr: Die Google Cloud-Dienste und APIs sind wieder vollständig verfügbar. Einige Compute Engine-VMs sind jedoch weiterhin nicht erreichbar.
  • 04:29 Uhr: Die regionalen Dienste nehmen wieder uneingeschränkt am Datenverkehr teil.
  • 04:46 Uhr: Die Erstellung neuer VMs ist wieder möglich.
  • 05:08 Uhr: Der Großteil der Workloads ist wiederhergestellt. Über 99 % der VMs funktionieren wieder ordnungsgemäß.
  • 07:03 Uhr: Google veröffentlicht die Abschlussmeldung zum Incident.
• 22. Oktober 2026: Google veröffentlicht seinen vorläufigen Incident-Bericht.
• 27. Oktober 2026: Google veröffentlicht den Incident-Bericht mit einer Root-Cause-Analyse und Maßnahmen zur Vermeidung ähnlicher Vorfälle.

Time to Detect (TTD): 4 Minuten (23:00 bis 23:04 Uhr). Laut Google wurden die Engineers durch das Monitoring alarmiert. (Im vorläufigen Bericht wurde 23:08 Uhr als Zeitpunkt der Alarmierung angegeben.)

Time to Resolve (TTR): 6 Stunden und 8 Minuten (23:00 bis 05:08 Uhr). Google meldet eine erste Phase von 5 Stunden und 29 Minuten (23:00 bis 04:29 Uhr), in der die auf die Zone europe-west2-b beschränkten Ressourcen nicht verfügbar waren. Daran schloss sich eine weitere Wiederherstellungsphase an, in der die Erstellung neuer VMs wieder aufgenommen und die verbleibenden Workloads wiederhergestellt wurden.

Die Stromversorgung selbst war bereits nach etwa 1 Stunde und 20 Minuten wiederhergestellt (in den Serverräumen um 00:20 Uhr). Der Großteil der Ausfallzeit entfiel auf die Wiederherstellung der Speichersysteme, Cluster und des Datenverkehrs nach dem unkontrollierten Herunterfahren der Systeme.

Wer war betroffen?

Laut Googles Incident-Bericht waren insgesamt 40 Produkte in der Region europe-west2 betroffen. Außerhalb dieser Region stellte Google keine Auswirkungen fest. Kundennamen werden im Bericht nicht genannt.

• Zonale Ressourcen in europe-west2-b: Compute Engine-VMs, Persistent Disk und Hyperdisk, zonale GKE-Cluster und -Nodes, Cloud SQL- und AlloyDB-Instanzen ohne Hochverfügbarkeit (HA), Cloud SQL-Lesereplikate in der Zone europe-west2-b sowie Bigtable-Instanzen mit nur einem Cluster waren nicht verfügbar.
• Übrige Region: In den benachbarten Zonen und bei regionalen Diensten kam es zu erhöhten Latenzen, HTTP-Fehlern (500 und 503), Warteschlangen bei der Annahme neuer Anfragen und vorübergehenden Schreibfehlern in den Speichersystemen. Ursache waren sprunghafte Lastanstiege und zonenübergreifende Abhängigkeiten zwischen den Control Planes (Steuerungsebenen).

Die Auswirkungen beschränkten sich nicht auf die Dienste von Google Cloud. Mindestens eine Banking-App meldete eine vorübergehende Dienstunterbrechung, die sie auf den Google Cloud-Ausfall zurückführte. Später bestätigte der Anbieter, dass die Dienste wiederhergestellt waren.

Wie reagierte Google?

Nachdem die SPS eine ferngesteuerte Lastumschaltung verhindert hatte, schaltete das technische Team vor Ort die Stromversorgung des Rechenzentrums auf den Reserveanschluss um. Ab 23:54 Uhr US-Pazifikzeit stand wieder Strom zur Verfügung. Um 00:20 Uhr war auch die Stromversorgung der Serverräume wiederhergestellt.

Die anschließende Wiederherstellung der Systeme dauerte jedoch noch mehrere Stunden. Die Speichergeräte mussten sich zunächst von den Folgen des unkontrollierten Herunterfahrens erholen. Um diesen Prozess nicht zusätzlich zu beeinträchtigen, verzögerten die Einsatzteams bewusst die Wiederinbetriebnahme bestimmter Dienste. Ab 03:45 Uhr wurde der Datenverkehr schrittweise und kontrolliert wieder in die betroffene Zone geleitet. Nach dem Incident konfigurierten die Mitarbeiter die speicherprogrammierbaren Steuerungen (SPS) neu und überprüften ihre Funktionsfähigkeit.

In seinem Bericht kündigt Google Präventivmaßnahmen in fünf Bereichen an:

• Externe Stromversorgung: Behebung des Defekts am externen Stromkabel und Wiederherstellung der regulären Stromversorgung über zwei unabhängige Zuleitungen.
• Notstromgeneratoren und SPS: Wiederholung von Lastumschalttests der Notstromgeneratoren, Überprüfung des SPS-Programmcodes gemeinsam mit den Herstellern, Validierung der SPS-Telemetriedaten und weltweite Kontrolle der SPS-Konfigurationen an Standorten mit vergleichbarer Infrastruktur.
• Betriebsabläufe: Aktualisierung der Notfallverfahren und Üben der Durchführung zweimal pro Schicht.
• Change Management: Vorübergehende Aussetzung geplanter Wartungsarbeiten an vergleichbaren Standorten und Einführung strengerer Genehmigungsverfahren für nicht standardmäßige Änderungen.
• Cloud-Dienste: Schnellere Benachrichtigung von Kunden bei Incidents, die einen gesamten Standort betreffen, und Ausweitung von Plattformtests für Ausfälle auf Infrastrukturebene.

‍

Wie kommunizierte Google?

Der Incident wurde schnell erkannt, doch bis zur ersten öffentlichen Statusmeldung verging deutlich mehr Zeit.

• Interne Alarmierung nach 4 Minuten: Das Monitoring alarmierte die Google-Engineers um 23:04 Uhr US-Pazifikzeit, nur vier Minuten nach Beginn des Incidents.
• Erstes Statusupdate nach 2 Stunden und 35 Minuten: Die erste Meldung auf der Statusseite von Google erschien um 01:35 Uhr US-Pazifikzeit (09:35 Uhr britische Sommerzeit). Darin berichtete Google über Probleme bei mehreren Diensten in der Region europe-west2. Zu diesem Zeitpunkt war die Stromversorgung der Serverräume bereits wiederhergestellt.
• Betroffene Zone erst nach 5 Stunden und 12 Minuten benannt: Die Statusupdates um 01:35, 02:24 und 04:00 Uhr US-Pazifikzeit berichteten über erhöhte Fehlerraten und zeitweise Netzwerkausfälle in der Region europe-west2. Erst um 04:12 Uhr, fast vier Stunden nach Wiederherstellung der Stromversorgung der Serverräume, erwähnte Google erstmals einen Stromausfall in der Zone europe-west2-b. Bis dahin wussten Kunden, die eine Verlagerung ihrer Workloads aus Zone b in Betracht zogen, nicht, welche Zone konkret betroffen war.
• Konkrete Handlungsempfehlungen in den Statusupdates: Google empfahl seinen Kunden, ihre Workloads nach Möglichkeit in andere Zonen oder Regionen zu verlagern. Betroffene Kunden wurden außerdem gebeten, Support-Tickets zu erstellen.
• Abschlussmeldung und weitere Berichte: Google veröffentlichte die Abschlussmeldung zum Incident um 07:03 Uhr US-Pazifikzeit, einen vorläufigen Incident-Bericht am 22. Oktober und den vollständigen Incident-Bericht am 27. Oktober.

Eine der von Google angekündigten Maßnahmen betrifft die Kundenkommunikation. Um Kunden bei Incidents, die einen gesamten Standort betreffen, künftig schneller informieren zu können, plant Google einen automatisierten Mechanismus, der Monitoring-Alarme direkt in Kundenbenachrichtigungen umwandelt.

Zwischen 07:00 und 09:35 Uhr Londoner Ortszeit, also zu Beginn des britischen Arbeitstags, gab es keine öffentliche Statusmeldung.

Wichtige Erkenntnisse für andere Teams

• Redundanz ist nur so zuverlässig wie ihr aktueller Zustand: Das Rechenzentrum war mit zwei unabhängigen Stromzuleitungen und Notstromgeneratoren ausgestattet. Durch die Sperrung einer Zuleitung für Wartungsarbeiten stand jedoch nur noch eine zur Verfügung. Deshalb ist es wichtig, zu erfassen, wann geplante Arbeiten die Redundanz einschränken, und diese Zeiträume als Phasen mit erhöhtem Risiko zu behandeln.
• Sensoren müssen die tatsächliche Stromversorgung der Verbraucher erfassen: Die SPS prüften lediglich, ob Spannung anlag, nicht jedoch, ob die Leistungsschalter geschlossen waren. Da die Messung vor einem geöffneten Leistungsschalter erfolgte, registrierten die Sensoren eine vorhandene Stromversorgung, obwohl die Serverräume keinen Strom erhielten. Ein Steuersignal ist nur dann zuverlässig, wenn es den tatsächlichen Zustand des Systems widerspiegelt, das geschützt werden soll.
• Redundante Steuerungen mit denselben fehlerhaften Eingangssignalen versagen gemeinsam: Google setzte eine primäre und eine redundante SPS ein. Da beide dieselbe Steuerungslogik verwendeten und die Spannung an derselben Stelle vor dem Leistungsschalter erfassten, startete keine der beiden die Notstromgeneratoren. Redundanz schützt nur vor Fehlern, die nicht alle redundanten Komponenten gleichermaßen betreffen.
• Backup-Systeme auch bei eingeschränkter Redundanz testen: Eine Notstromversorgung, die bei zwei aktiven Stromzuleitungen zuverlässig funktioniert, kann sich anders verhalten, wenn eine davon gesperrt ist. Deshalb sollten Failover-Tests auch Konfigurationen berücksichtigen, die während Wartungsarbeiten auftreten.
• Die Wiederherstellung der Stromversorgung bedeutet nicht, dass alle Dienste wieder verfügbar sind: Die Stromversorgung war nach etwa 1 Stunde und 20 Minuten wiederhergestellt. Die Wiederherstellung der Speichersysteme, Cluster und des Datenverkehrs dauerte jedoch mehrere Stunden länger. Die Einsatzteams verzögerten bewusst die Wiederinbetriebnahme bestimmter Dienste, um die Wiederherstellung der Speichersysteme nicht zu beeinträchtigen. Deshalb sollten Teams nicht nur die Umschaltung auf die Notstromversorgung, sondern auch die Wiederherstellung nach einem unkontrollierten Herunterfahren planen und üben. Dazu gehört auch, festzulegen, welche Dienste nicht zuerst wiederhergestellt werden sollten.
• Zonale Failover erfordern ausreichende Kapazitätsreserven: Als eine Zone ausfiel, führten sprunghafte Lastanstiege und zonenübergreifende Abhängigkeiten zu Problemen in den beiden verbleibenden Zonen. Einige Failover-Vorgänge scheiterten an Kapazitätsengpässen. Architekturen mit mehreren Zonen benötigen daher ausreichende Kapazitätsreserven und möglichst wenige gemeinsame Abhängigkeiten zwischen den Control Planes (Steuerungsebenen).
• Den potenziellen Auswirkungsbereich eines Provider-Ausfalls kennen: Wenn der Ausfall einer einzelnen Zone dazu führen kann, dass Anmeldefunktionen, Zahlungssysteme oder APIs nicht mehr verfügbar sind, müssen diese Abhängigkeiten identifiziert, überwacht und bei der Ausfallplanung berücksichtigt werden. Dies gilt insbesondere für regulierte Branchen.
• Die Zeitspanne zwischen Erkennung und Kommunikation verkürzen: Google erkannte den Ausfall innerhalb von vier Minuten, veröffentlichte jedoch erst nach 2 Stunden und 35 Minuten eine öffentliche Statusmeldung. Die konkret betroffene Zone wurde sogar erst nach 5 Stunden und 12 Minuten genannt. Kunden benötigen nicht nur schnelle Informationen, sondern auch genaue Angaben zum Ausmaß des Incidents. Erst wenn bekannt ist, welche Zone ausgefallen ist, können sie fundiert entscheiden, ob ein Failover erforderlich ist.

Zusammenfassung

Am Morgen des 20. Oktober 2026 (Londoner Ortszeit) wurde das Google Cloud-Rechenzentrum, in dem die Zone europe-west2-b in London betrieben wird, nur über eine einzige Stromzuleitung versorgt, da die zweite aufgrund von Reparaturarbeiten gesperrt war. Als die verbleibende Zuleitung wegen eines externen Kabeldefekts ausfiel, sprangen die Notstromgeneratoren nicht an. Die Steuerungslogik prüfte lediglich, ob Spannung anlag, nicht jedoch, ob die Leistungsschalter geschlossen waren. Zudem befanden sich die Sensoren vor dem gesperrten Leistungsschalter, wo weiterhin Spannung anlag.

Nachdem die Batterien der unterbrechungsfreien Stromversorgung (USV) erschöpft waren, fiel die Stromversorgung der Zone vollständig aus. Gleichzeitig führte die Verlagerung des Datenverkehrs auf andere Zonen vorübergehend zu erhöhten Latenzen und Fehlern in der gesamten Region. Mindestens eine Banking-App führte eine vorübergehende Dienstunterbrechung auf den Ausfall zurück.

Google konnte die wesentlichen Auswirkungen des Incidents nach 6 Stunden und 8 Minuten eindämmen und kündigte mehrere Präventivmaßnahmen an. Dazu gehören die Korrektur der SPS-Steuerungslogik und die Überprüfung vergleichbarer Standorte, aktualisierte Notfallverfahren, die vorübergehende Aussetzung von Wartungsarbeiten mit strengeren Genehmigungsprozessen sowie eine schnellere, automatisierte Kundenkommunikation.

Die wichtigste Erkenntnis für alle Teams: Redundante Systeme müssen unter den tatsächlichen Betriebsbedingungen getestet werden. Ebenso wichtig ist es, die Wiederherstellung der Dienste nach einem Stromausfall sorgfältig zu planen

So kann ilert helfen

• Incidents selbst erkennen: Wenn die Statusseite Ihres Cloud-Anbieters keine Informationen liefert, müssen Sie sich auf Ihre eigenen Alarmierungen verlassen können. Mit Dienstplänen und Eskalationsrichtlinien stellen Sie sicher, dass die zuständigen Engineers innerhalb weniger Minuten per Push-Benachrichtigung, SMS oder Sprachanruf erreicht werden.
• Bereitstellung von Statusseiten, die den tatsächlichen Zustand widerspiegeln: Die Statusseiten von ilert lassen sich innerhalb weniger Sekunden oder automatisch auf Basis von Incidents aktualisieren. So müssen Ihre Kunden nicht stundenlang auf eine erste Statusmeldung warten, selbst wenn Ihr Cloud-Anbieter noch keine Informationen veröffentlicht hat.
• Schnellere Ursachenanalyse dank integriertem AI SRE: Die AI SRE-Funktionen von ilert helfen den Einsatzteams, während eines Incidents Alarmierungen, kürzlich vorgenommene Änderungen und relevante Kontextinformationen zusammenzuführen. Anschließend unterstützen sie auch bei der Erstellung des Postmortems.