2025 war das Jahr, in dem uns die Cloud daran erinnerte, wer tatsächlich die Kontrolle hat.
Warum Ausfälle immer wieder auftreten und was Sie dagegen tun können
2025 war ein schwieriges Jahr, wenn Sie mit Ihrem Unternehmen auf einen einzigen Cloud-Anbieter gesetzt hatten. Im Dezember sahen Snowflake-Kunden hilflos zu, wie ein Schema-Update über mehrere Regionen kaskadiert wurde und Abfragen 13 Stunden lang blockierte. Databricks-Benutzer hatten tagelang mit verschlechterten KI-Diensten zu kämpfen.
Im Oktober fiel die US-East-1-Region von Amazon Web Services (AWS) für 15 Stunden aus – ein DNS-Fehler bei DynamoDB brachte über 1.000 Unternehmen zum Erliegen. Im Juni führte eine Null-Pointer-Ausnahme in der Binärdatei „Service Control“ von Google Cloud dazu, dass mehrere Systeme, darunter Cloud Storage, Compute Engine und BigQuery, für mehrere Stunden außer Betrieb waren, was Auswirkungen auf Spotify, Discord und OpenAI hatte.
Bei all diesen Vorfällen war das Muster dasselbe: Die Kunden aktualisierten die Statusseiten und warteten darauf, dass jemand anderes das Problem behob. Der Unterschied zwischen den Anbietern besteht nicht darin, ob Ausfälle auftreten, sondern darin, welche Optionen Sie bei einem Ausfall haben.
Das Muster: Einzelne Fehlerquellen mit globaler Reichweite
Der Vorfall von Snowflake im Dezember wurde durch eine rückwärtsinkompatible Aktualisierung des Datenbankschemas ausgelöst. Versionskonfliktfehler führten dazu, dass Vorgänge in mehreren Regionen auf AWS, Microsoft Azure und Google Cloud Platform (GCP) fehlschlugen oder unbegrenzt hängen blieben. In den Mitteilungen von Snowflake hieß es, dass es keine Ausweichmöglichkeiten gebe, außer für Kunden, die die Replikation in nicht betroffene Regionen vorkonfiguriert hatten. Alle anderen mussten warten.
Der Ausfall von Databricks im Dezember (der sich über mehrere Tage erstreckte) umfasste Probleme mit dem Unity Catalog, eine Beeinträchtigung der Rechenleistung in mehreren Regionen und eine mehrtägige Störung von Mosaic AI. In den Statusaktualisierungen wurde wiederholt darauf hingewiesen, dass „mit dem Cloud-Anbieter an möglichen Lösungsansätzen gearbeitet“ wird. Dieser Satz sagt alles über die Abhängigkeitskette aus: Wenn Azure einen schlechten Tag hat, haben auch die Databricks-Kunden in den Azure-Regionen einen schlechten Tag.
Der Vorfall in der Google Cloud im Juni offenbarte dieselbe Schwachstelle. Eine fehlerhafte Richtlinie mit leeren Feldern wurde in globale Konfigurationstabellen eingefügt und innerhalb von Sekunden weltweit repliziert. Die beschädigten Daten lösten eine Reihe von Abstürzen aus, die zu einem Ausfall der wichtigsten Dienste für 7,5 Stunden führten. Die Status-Dashboards von Google waren zunächst nicht verfügbar – die SRE-Teams konnten das Ausmaß des Problems nicht einmal bestätigen.
Regionale Redundanz hilft nicht, wenn der Fehler logischer und nicht physischer Natur ist. Wenn eine Plattform auf global koordinierte Metadaten oder geteilte Konfigurationen angewiesen ist, verbreitet sich ein einzelnes fehlerhaftes Update überall. Das Scheitern verfolgt Sie von Region zu Region.
Darüber hinaus ist in diesen Szenarien die Infrastruktur zwar verteilt, die Steuerung bleibt jedoch zentralisiert. Wenn die Steuerungsebene von Snowflake ausfällt, spielt es keine Rolle, dass sie im Hintergrund auf AWS, Azure und Google Cloud ausgeführt wird. Wenn Databricks darauf wartet, dass Azure ein Problem behebt, hilft Multi-Cloud-Marketing nicht weiter. Die einzige Fehlerquelle ist die proprietäre Ebene darüber.
Was Analysten sagen
Laut der Analyse von Gartner® zu Cloud-Einführungstrends für 2025 werden mehr als 50 % der Unternehmen bis 2029 nicht die erwarteten Ergebnisse aus ihren Multi-Cloud-Implementierungen erzielen. Das Kernproblem: mangelnde Interoperabilität zwischen Umgebungen.
In den Prognosen 2026 von Forrester: Cloud-Ausfälle, private KI in Private Clouds und der Aufstieg der Neoclouds prognostiziert das Forschungsunternehmen für 2026 mindestens zwei größere mehrtägige Cloud-Ausfälle. Die Cloud-Branche befindet sich in einem massiven Infrastrukturwandel, da Hyperscaler um den Aufbau von KI-nativen Rechenzentren wetteifern. Diese Investition hat ihren Preis: Ältere x86- und ARM-Umgebungen werden zurückgestellt, was dazu führt, dass die alternde Infrastruktur angesichts wachsender Komplexität ins Stocken gerät.
In derselben Prognose von Forrester werden laut Schätzungen mindestens 15 % der Unternehmen bis 2026 auf private KI-Implementierungen umsteigen, die auf Private Clouds basieren. Die Treiber: steigende KI-Kosten, Bedenken hinsichtlich der Datenbindung und das betriebliche Risiko, von einer Infrastruktur abhängig zu sein, die zunehmend für die Prioritäten anderer optimiert wird. Die Ausfälle im Jahr 2025 waren ein Vorgeschmack darauf, was passiert, wenn Ihre Workloads nicht das Hauptanliegen des Anbieters sind.
Architekt für Resilienz mit Cloudera
Die meisten Unternehmen verfügen über „zufällige Multi-Cloud“-Architekturen, die durch Übernahmen, Schatten-IT oder die Auswahl der besten Tools entstanden sind – und nicht durch bewusste Architekturplanung. Ihre Workloads sind auf verschiedene Anbieter verteilt, doch fehlt ihnen im Falle von Problemen die Möglichkeit, Daten und Workloads zu verschieben.
Der Aufbau einer Architektur für Datenresilienz umfasst die Gewährleistung der Portabilität Ihrer Daten und KI-Plattform sowie die Beseitigung einzelner Ausfallpunkte.
Die Cloudera-Plattform ist auf Portabilität ausgelegt und bietet Ihnen die Möglichkeit, zwischen Umgebungen zu wechseln, um den Betrieb aufrechtzuerhalten – Workloads und Daten können ohne Neuprogrammierung, Reibungsverluste oder Herstellerabhängigkeit zwischen AWS, Azure, Google Cloud und lokalen Umgebungen verschoben werden. Updates werden nicht als globale, rückwärtsinkompatible Änderungen erzwungen.
Im Falle eines unvermeidbaren Ausfalls haben Sie mehrere Optionen: Sie können auf eine andere Cloud ausweichen oder die Workloads zurück in Ihr Rechenzentrum verlagern. Sie müssen sich keine Statusseite ansehen – Sie behalten die Kontrolle über Ihre Daten und können einheitliche Abläufe und Vorschriften aufrechterhalten, unabhängig davon, wo sich die Daten befinden.
Weitere Informationen zum Aufbau einer resilienten Architektur mit Cloudera finden Sie in unserem Blog: Architektur für Datenresilienz: Gewährleistung der Geschäftskontinuität mit Cloudera
Der Blick nach vorn
Der Ausbau der KI belastet die Infrastruktur, und Analystenunternehmen weisen auf weitere Turbulenzen in der Zukunft hin: Forrester prognostiziert mehrtägige Ausfälle und Gartner prognostiziert eine defensive Multi-Cloud-Einführung. Die Unternehmen, die das Jahr 2026 gut überstehen, werden diejenigen sein, die Resilienz als architektonisches Prinzip und nicht als bloße Pflichterfüllung betrachten.
Cloudera bietet keine sofort einsatzbereite, cloudübergreifende Failover-Funktion per Knopfdruck – wie übrigens kein anderer Anbieter auch. Doch wir sind architektonisch so aufgestellt, dass wir diese Resilienz auf eine Weise unterstützen können, wie es proprietäre Plattformen nicht können.
Wenn Ihnen die Ausfälle im Jahr 2025 Unbehagen bereitet haben, würden wir gerne darüber sprechen. Denn die Cloud ist im Grunde nur der Computer von jemand anderem. Und wenn dieser Computer mal einen schlechten Tag hat, sollten Sie eine Alternative haben.
Wenn Sie mehr darüber erfahren möchten, wie Sie mit Cloudera eine resiliente Architektur aufbauen können, wenden Sie sich an unser Team für professionelle Dienstleistungen, sehen Sie sich unsere Produktdemos an oder melden Sie sich für eine kostenlose 5-Tage-Testversion an.