Zusammenfassung

  • Cloudflare meldete ab dem 2. November 2023 eine Störung von Control Plane und Analytics, während der zentrale Edge-Verkehr weiterlief [1].
  • Auslöser war öffentlich eine Stromausfallkette in PDX-04, einem Standort in Oregon mit kritischen Control-Plane-Abhängigkeiten [1][3].
  • Der Vorfall legte Abhängigkeiten in Kafka, ClickHouse, Identität, internen Werkzeugen und Wiederherstellungssystemen offen [1].
  • Ein weiterer Stromausfall am selben Standort im Jahr 2024 testete die Code-Orange-Vorbereitung und reduzierte den Control-Plane-Effekt [2].
  • Ein glaubwürdiger Abschluss muss Konfiguration, Analytics, Identität, interne Werkzeuge und kundensichtbare Steuerhandlungen während eines vollständigen Standortverlusts beweisen.

Was geschah

Cloudflare setzt den Beginn auf 11:43 UTC am 2. November. Betroffen waren Control Plane und Analytics-Dienste [1]. Kunden konnten also Schwierigkeiten haben, Regeln zu ändern, Metriken zu sehen oder Verwaltungsfunktionen zu nutzen, obwohl verteilter Verkehr ohne neue Steuerentscheidung weiter verarbeitet wurde.

Der physische Ausgangspunkt war PDX-04. Cloudflare beschreibt ein ungeplantes Wartungsereignis von Portland General Electric an einer unabhängigen Einspeisung, danach erschöpfte Batterien, schwierige Generatorwiederanläufe, Gebäudezugang, Austausch von Schutzschaltern und gestaffeltes Hochfahren von Servern [1]. Baxtel verknüpft die Störung ebenfalls mit einem Stromausfall in einem Flexential-Rechenzentrum in Hillsboro, Oregon, und zitiert Cloudflares Darstellung des Einspeiseereignisses [3].

Die praktische Lehre: Ein Cloud-Dienst kann bereits konfigurierte Last weitertragen, während die Ebene für Änderung, Diagnose und Zustandsprüfung beeinträchtigt ist. Wenn diese Ebene verdeckt von einem Standort abhängt, ist Kundenskontinuität an eine physische und organisatorische Wiederherstellungskette gebunden.

Die versteckte Abhängigkeit war kein einzelner Server

Das Postmortem beschreibt keine isolierte Maschine. Es nennt Control-Plane- und Analytics-Komponenten, Kafka, ClickHouse, Identität und Autorisierung, interne Werkzeuge sowie Systeme für Neustart oder Wiederaufbau [1]. Manche Abhängigkeiten waren bekannt, andere wurden erst durch den vollständigen Standortverlust sichtbar.

Damit ist der Fall Netzwerkinfrastruktur-Verantwortung. Die Control Plane ist die Autoritätsoberfläche eines Betreibers. Dort wird eine Änderung zur laufenden Konfiguration, ein Alarm zur Handlung und ein Kundensignal zur Aussage über Dienstzustand. Wenn diese Oberfläche von einem unzureichend getesteten Standort abhängt, ist das öffentliche Risiko nicht nur Ausfallzeit, sondern Verlust von Sichtbarkeit und Änderungsfähigkeit.

Cloudflare trennt außerdem, was weiterlief und was ausfiel. Viel Edge-Verkehr blieb aktiv [1]. Das macht den Vorfall nicht klein; es zeigt, dass Resilienz schichtweise gemessen werden muss. Eine gesunde Data Plane beweist keine wiederherstellbare Control Plane.

Disaster Recovery ist ein Test laufender Systeme

Cloudflare hatte Wiederherstellungspläne, sagt aber, dass einige Dienste nicht für den vollständigen Standortverlust bereit waren und bestimmte Verfahren nicht unter den richtigen Bedingungen getestet waren [1]. Ein Dokument kann einen Ersatzstandort nennen. Erst Replikation, Warteschlangen, Identität, Dashboards und interne Werkzeuge im laufenden Fehlerzustand beweisen die Wiederherstellung.

Die Rückkehr erzeugte zusätzlich Last. Wenn Dienste wiederkommen, wiederholen Kunden und interne Jobs ihre Anfragen. Das Postmortem beschreibt eine Herdenwirkung, die den Neustart in einen zweiten Vorfall verwandeln kann, wenn die Control Plane den Rückstau nicht aufnimmt [1].

Der Bericht 2024 ist ein wichtiger Vergleich. Vier Monate später gab es am selben Standort erneut einen schweren Stromausfall. Cloudflare aktivierte Code Orange und sagte, frühere Änderungen hätten die Wirkung reduziert [2]. Das beweist nicht Vollständigkeit, aber es ist die richtige Evidenzform: ähnliches Ereignis, neue Vorbereitung, anderes Ergebnis.

Physische Grenzen bleiben sichtbar

Cloud-Control-Planes wirken abstrakt, doch der Vorfall umfasst Einspeisungen, Batterien, Generatoren, Gebäudezugang, Standortbetreiber und Serverstartreihenfolge [1][3]. Diese Faktoren liegen unterhalb der API und bestimmen dennoch das sichtbare Kundenergebnis.

Die Nutzung eines externen Rechenzentrums ist nicht automatisch ein Fehler. Verantwortlich wird es dort, wo der Betreiber beweisen muss, wer den Alternativplan aktiviert, welche Kundenfunktionen bleiben, welche Degradierung beabsichtigt ist und welche Übung das Szenario bereits gezeigt hat.

Baxtel ergänzt den Kontext des Rechenzentrumsbetreibers und eine öffentliche Flexential-Antwort zu Stromnetz-Szenarien [3]. Daraus folgt kein vollständiges Ursachenurteil. Es zeigt aber, dass die Wiederherstellung organisatorische Grenzen überschritt.

Heng.lu-Oberfläche: Betreiberkontinuität

Die Heng.lu-Oberfläche ist Betreiberkontinuität und Hosting-/Netzwerkidentität. Ein Verzeichnis oder eine Statusseite kann Betreiber und Standort benennen; es beweist nicht, dass Konfiguration, Analytics, Identität und Werkzeuge einen Gebäudeverlust überstehen. Die Realitätsschicht ist Wiederherstellungsevidenz.

Der öffentliche Test darf kein Schuldtheater sein. Entscheidend ist, welche Abhängigkeit auf dem kritischen Pfad lag, ob Cloudflare sie vorher kannte und welche Übung nun zeigt, dass sie die Kontrollautorität nicht erneut entfernt.

Was zu beobachten ist

Erstens: trennt Cloudflare weiterhin Edge-Traffic-Gesundheit von Control-Plane- und Analytics-Gesundheit? Ein global grüner Status reicht nicht, wenn Kunden ihre Konfiguration nicht ändern oder beobachten können.

Zweitens: wird Code Orange zu einem wiederholbaren Evidenzmuster? Vollständiger Standortverlust, Failover-Test, Rückstaumessung, verfügbare Identität, erfolgreiche Kundenhandlungen und Vergleich mit dem vorherigen Vorfall sind die relevanten Signale. Die dauerhafte Lehre lautet: Verkehr transportieren reicht nicht. Der Betreiber muss den Dienst sehen, ändern, neu starten und erklären können.

Quellen

  1. https://blog.cloudflare.com/post-mortem-on-cloudflare-control-plane-and-analytics-outage/
  2. https://blog.cloudflare.com/major-data-center-power-failure-again-cloudflare-code-orange-tested/
  3. https://baxtel.com/news/cloudflare-blames-flexential-dc-outage-for-its-service-disruption