Der Abschlussbericht von Google Cloud zum Ausfall in europe-west4-a im Juli 2026 ist aufschlussreich, weil er die physische Kette hinter einer Cloud-Störung offenlegt. Ein Spannungseinbruch von drei Millisekunden betraf beide Einspeisungen. Eine Seite wechselte erfolgreich auf eine dieselrotierende USV, während auf der anderen Komponenten ausfielen. Anschließend konnte eine Serverreihe wegen eines ausgelösten Überlastschutzschalters nicht auf die verbliebene Einspeisung wechseln. Google Cloud VMware Engine, Bare Metal Solution und Google Cloud NetApp Volumes waren innerhalb eines insgesamt 14 Stunden und 55 Minuten langen Vorfalls beeinträchtigt.
Bedeutung für den Betrieb
Genau hier liegt der Unterschied zwischen doppelt vorhandenen Komponenten und unabhängigen Ausfalldomänen. Die Anlage besaß die Einspeisungen A und B, Notstrom, automatische Umschaltung und mehrere Reihen. Dennoch erreichte dasselbe vorgelagerte Ereignis beide Einspeisungen, ein Notstrompfad versagte und eine Abweichung in der Lastverteilung verhinderte, dass eine Reihe die verbleibende Seite nutzen konnte. Ein Architekturdiagramm kann zwei Linien zeigen und trotzdem den gemeinsamen Schalter, Controller, Wartungszustand oder die verbindende Kapazitätsannahme verbergen.
Die Kühlung vergrößerte die Abhängigkeitskette. Während desselben Spannungseinbruchs fiel ein Kältemaschinen-Controller aus und startete die Pumpen des Kaltwasserkreislaufs nicht neu. Die redundante Quelle stand wegen Bauarbeiten nicht zur Verfügung. Die Hallentemperatur stieg auf 44 Grad Celsius, worauf Hosts, Switches und Storage-Cluster zum Schutz abgeschaltet wurden. Compute, Storage, Netzwerk, Strom und Kühlung waren deshalb keine getrennten Störungen, sondern die Ausbreitung eines einzigen Fehlers durch mehrere Steuerungssysteme.
Für Kunden lautet die Lehre nicht, dass Cloud-Infrastruktur keine Redundanz besitzt. Entscheidend ist, dass ein zonaler Dienst eine zonale Abhängigkeit bleibt, solange die Arbeitslast keinen getesteten Pfad an einen anderen Ort hat. Google empfahl Kunden mit multiregionalen Bereitstellungen, den Verkehr an einen alternativen Standort zu leiten. Diese Möglichkeit besteht jedoch nur, wenn Anwendungen, Daten, Identität, Netzwerkrichtlinien, Kapazität und betriebliche Entscheidungsbefugnis außerhalb des betroffenen Standorts bereits vorbereitet sind. Eine zweite Region im Design ist noch kein tatsächlich nutzbarer Ausweichdienst.
Auch die Wiederherstellung erfolgte schichtweise. Zuerst wurden Kühlung und Strom stabilisiert, danach Konsolen- und Netzwerkinfrastruktur wiederhergestellt, Storage-Cluster hochgefahren, Server und Private Clouds gestartet und schließlich die Kunden zur Prüfung ihrer Arbeitslasten aufgefordert. Diese Reihenfolge gehört auch in die Runbooks der Kunden. Wiederherstellungsziele müssen Plattformverfügbarkeit, Datenzugriff, Anwendungsstartfolge, Identitätsabhängigkeiten und den Nachweis umfassen, dass ein Dienst nach der Entstörungsmeldung des Providers wirklich gesund ist.
Praktische Konsequenz
Die praktische Schlussfolgerung lautet, Cloud-Resilienz anhand gemeinsamer physischer und betrieblicher Abhängigkeiten zu prüfen und nicht anhand der Zahl redundanter Bezeichnungen. Für jede kritische zonale Arbeitslast muss klar sein, was zusammen mit der Zone ausfällt, wo aktuelle Daten außerhalb liegen, wie der Verkehr wechselt, wer den Failover freigibt und wie der Rückweg getestet wird. Redundanz ist erst belastbar, wenn der alternative Pfad dasselbe auslösende Ereignis übersteht und das Team seine Nutzung unter Druck nachgewiesen hat.