Ein Stromausfall wurde zum siebenminütigen Countdown
Gegen 07:08 Uhr BST an einem Dienstag traf ein lokaler Netzausfall die Google Cloud-Zone europe-west2-b in London. Die USV-Batterien sprangen sofort ein – eine lehrbuchmäßige Reaktion. Weder die primäre noch die sekundäre Generatorsteuerung aktivierte jedoch die Dieselgeneratoren, sodass die Anlage vollständig auf Batteriestrom angewiesen war.
Dieses siebenminütige Zeitfenster erwies sich als kritisch. Das Rechenzentrum lief etwa sieben Minuten lang mit Batteriestrom, bevor dieser erschöpft war und die gesamte Zone in Dunkelheit stürzte. Entscheidend ist: Nicht die Batterien versagten, sondern die Startsysteme der Generatoren, was eine Kaskade unerwarteter Ausfälle auslöste.
Revolut, ein Fintech-Riese mit Millionen von Kunden, spürte die Auswirkungen sofort. Nutzer meldeten weitreichende Probleme:
- Fehlgeschlagene Logins
- Blockierte Geldtransfers
- Abgelehnte Kartenzahlungen
Revolut sprach zunächst von einer „Dienstunterbrechung“, bevor der umfangreiche Ausfall auf Google Cloud zurückgeführt wurde. Der Vorfall unterstrich schnell die Fragilität, sich selbst auf die ausgefeilteste Cloud-Infrastruktur zu verlassen, wenn ein einzelner Fehlerpunkt – wie eine Generatorsteuerung – eine derart massive Störung auslösen kann.
Die zwei intakten Zonen waren nicht stabil genug
Multi-Zonen-Regionen versprechen Ausfallsicherheit: Fällt eine Zone aus, verlagern sich die Workloads auf die anderen. Die Google Cloud-Region europe-west2 in London verfügt über drei solcher Zonen (a, b und c). Als Zone b ausfiel, hätte das System nahtlos auf a und c umschalten und den Dienst aufrechterhalten sollen.
Stattdessen überlastete der plötzliche Anstieg des Datenverkehrs die verbleibende Infrastruktur. Dies war kein einfacher Wechsel; es war ein Kapazitätsproblem und ein Koordinationsalbtraum. Abhängigkeiten zwischen den Zonen führten dazu, dass einige Dienste in den Zonen a und c hängen blieben, da sie auf Komponenten oder Zustände warteten, die noch mit der offline gegangenen Zone b verknüpft waren.
Die technische Lektion ist eindeutig: Redundanz ist nur dann effektiv, wenn Zonen wirklich unabhängig sind und über genügend Spielraum verfügen, um einen realistischen Failover-Ansturm abzufangen. Ratenbegrenzungen, kontrollierte Leistungsreduzierung (Graceful Degradation) und streng getestete Wiederherstellungspläne sind entscheidend, um zu verhindern, dass ein „Thundering Herd“-Effekt eine gesamte Region lahmlegt.
Google erholte sich schneller als Revolut
Die schnelle Wiederherstellung der Infrastruktur durch Google führte nicht zu einer sofortigen Wiederherstellung des Dienstes für die Kunden. Google meldete, dass die meisten Kunden etwa sechs bis acht Stunden nach Beginn des Vorfalls, zwischen 13:00 und 15:00 Uhr BST, wieder online waren. Revolut hingegen gab die vollständige Wiederherstellung des Dienstes erst um 18:40 Uhr BST bekannt – eine erhebliche Verzögerung von mehreren Stunden.
Diese Diskrepanz offenbart einen entscheidenden Unterschied: Die Wiederherstellung der Cloud-Kapazität beseitigt nicht sofort den operativen Rückstau eines Kunden. Selbst wenn Rechenleistung und Speicher verfügbar sind, steht ein Finanzinstitut wie Revolut vor komplexen Herausforderungen. Die Abstimmung von Transaktionszuständen, die Abarbeitung von Zahlungsrückständen und die Normalisierung jeder Anwendungsabhängigkeit – von Kartenzahlungen bis hin zu Login-Diensten – erfordert Zeit und eine sorgfältige Abfolge.
Der Ausfall betraf mehr als nur Revolut. Berichte deuteten auf umfassendere Störungen bei anderen britischen Institutionen und Diensten hin, darunter:
- Lloyds
- Halifax
- Videolinks für Fernverhandlungen vor Gericht
Diese weitreichenden Auswirkungen unterstreichen eine grundlegende Schwachstelle gemeinsam genutzter Cloud-Infrastrukturen. Ein Ausfall einer einzelnen Zone in europe-west2-b weitete sich zu einem umfassenden Serviceproblem aus und zeigt, wie vernetzte Abhängigkeiten ein lokal begrenztes Stromereignis in ein landesweites Problem verwandeln können. Weitere Details zum Status des Vorfalls finden Sie im Google Cloud Service Health Dashboard. Interessanterweise sind auch Regulierungsbehörden aufmerksam geworden; so haben die Bank of England und die FCA Anfragen bezüglich des Zeitplans für die Benachrichtigung über den Vorfall erhalten.
Gefällt Ihnen der Artikel? Erhalten Sie jeden Morgen einen wie diesen per E-Mail.
eine E-Mail pro Tag · Abmeldung mit zwei Klicks · kein Tracking durch Dritte
Ein Cloud-Ausfall ist jetzt ein Bankenrisiko
Die Einstufung von Google Cloud als kritischer Drittanbieter für das britische Finanzsystem im Juli verändert die Ausgangslage grundlegend. Nach dem Ausfall forderte der Vorsitzende des Treasury Committee umgehend Antworten von der Bank of England und der FCA bezüglich der Benachrichtigungsfristen. Dies ist nicht nur eine technische Störung, sondern ein systemisches Risiko.
Finanzunternehmen stehen nun vor einer schwierigen Frage: Wie viel Resilienz ist genug? Wenn ein Cloud-Anbieter, eine ganze Region oder sogar die Architektur einer Anwendung zu einem Konzentrationspunkt wird, müssen Unternehmen ihr Risiko genau prüfen. Multi-Region-Designs bieten einen Weg zur Risikominderung, bringen jedoch erhebliche Kompromisse bei Kosten, Latenz und komplexem Datenmanagement mit sich.
Für Kunden und Entwickler ergeben sich daraus praktische Lehren. Überprüfen Sie bei Vorfällen konsequent das Service Health Dashboard von Google Cloud – es bietet die aktuellsten Informationen. Engineering-Teams müssen über bloße Annahmen hinausgehen; testen Sie den Zonenverlust, validieren Sie die Failover-Kapazität und simulieren Sie eingeschränkte Betriebsmodi. Ein Multi-Zonen-Deployment allein garantiert keine Kontinuität.
Häufig gestellte Fragen
Warum war Revolut während des Google Cloud-Ausfalls nicht erreichbar?
Ein Londoner Rechenzentrum verlor nach dem Ausfall der primären und sekundären Generatorsteuerungen die Stromversorgung. Der Datenverkehr verlagerte sich auf die verbleibenden Zonen, die jedoch ebenfalls von Überlastung und Abhängigkeiten von der ausgefallenen Zone betroffen waren.
Wie lange dauerte der Google Cloud-Ausfall in London?
Google gab an, dass die meisten betroffenen Kunden etwa sechs bis acht Stunden nach Beginn des Vorfalls wieder versorgt waren. Revolut teilte mit, dass seine Dienste später, gegen etwa 18:40 Uhr BST, wieder verfügbar waren.
Warum konnten die anderen Londoner Zonen von Google Cloud die Störung nicht verhindern?
Die verbleibenden Zonen waren mit einem plötzlichen Anstieg des Failover-Datenverkehrs konfrontiert, während einige Dienste weiterhin von Komponenten abhingen, die mit der ausgefallenen Zone verbunden waren.
Was bedeutet der Ausfall für britische Finanzdienstleistungen?
Er verdeutlicht, wie sich Störungen bei einem großen Cloud-Anbieter auf Finanzdienstleistungen auswirken können und warum Regulierungsbehörden kritische Drittanbieter genau unter die Lupe nehmen.