„Code Orange: Fail Small“ hat das Cloudflare-Netzwerk weiter gestärkt

In den letzten beiden Quartalen haben wir intensiv daran gearbeitet, die Infrastruktur von Cloudflare für alle Kunden belastbarer, sicherer und robuster zu gestalten. Dieses Projekt wurde intern „Code Orange: Fail Small“ getauft.

Anfang des Monats wurde es vom Cloudflare-Team abgeschlossen.

Die Erhöhung der Ausfallsicherheit sollte nie als abgeschlossene Aufgabe betrachtet werden und wird in unserem gesamten Entwicklungslebenszyklus immer oberste Priorität haben. Doch wir haben nun die Arbeit abgeschlossen, mit der sich die weltweiten Ausfälle vom 18. November 2025 und vom 5. Dezember 2025 hätte vermeiden lassen.

Im Rahmen dieses Vorhabens haben wir mehrere zentrale Bereiche in den Blick genommen: die sicherere Gestaltung von Konfigurationsänderungen, die Reduzierung der Auswirkungen von Fehlern sowie die Überarbeitung unserer Verfahren bei Zwischenfällen und im Vorfallmanagement. Zudem haben wir Maßnahmen eingeführt, die etwaigen mit der Zeit auftretenden Abweichungen und Rückschritten entgegenwirken sollen. Darüber hinaus wurde die Art und Weise optimiert, in der wir während eines Ausfalls mit unseren Kunden kommunizieren.

An dieser Stelle möchten wir näher darauf eingehen, was neu eingeführt wurde und was dies für Sie bedeutet.

Relevanz für Sie: Konfigurationsänderungen innerhalb von Cloudflare werden in den meisten Fällen nicht mehr sofort in unserem gesamten Netzwerk implementiert, sondern schrittweise mit Zustandsüberwachung in Echtzeit. So können unsere Beobachtungstools etwaige Probleme erkennen und beheben, bevor Ihr Traffic davon betroffen ist.

Um potenziell gefährliche Implementierungen im Produktivsystem zu verhindern, haben wir risikobehaftete Konfigurations-Pipelines ermittelt und neue Werkzeuge zur besseren Steuerung von Konfigurationsänderungen geschaffen.

Wir implementieren Konfigurationsänderungen für Produkte, die auf unserem Netzwerk laufen und Kunden-Traffic verarbeiten, inzwischen nicht mehr sofort im gesamten Netzwerk. Stattdessen verfahren die relevanten Abteilungen nun nach dem Prinzip der „zustandsorientierten Implementierung“, das wir auch beim Software-Release anwenden. Das gilt unter anderem für die von den Vorfällen direkt betroffenen Produktteams.

Im Mittelpunkt steht dabei eine neue interne Komponente namens „Snapstone“, mit der wir die zustandsorientierte Implementierung auf Konfigurationsänderungen übertragen haben. Snapstone ist ein System, das Konfigurationsänderungen zu einem Paket bündelt und so einen schrittweisen Rollout gemäß den Regeln einer zustandsorientierten Vorgehensweise ermöglicht. Vor Snapstone war es zwar auch schon möglich, diese Prinzipien auf die Konfiguration anzuwenden, dies gestaltete sich aber schwierig: Es war für die einzelnen Teams mit enormem Aufwand verbunden und ließ sich nicht einfach einheitlich auf das gesamte Netzwerk anwenden. Mit Snapstone wird diese Lücke geschlossen: Das System bietet ab Werk eine übergreifende Lösung für schrittweise Rollouts, Zustandsüberwachung in Echtzeit und das automatische Zurücksetzen neuer Konfigurationen.

Was es besonders wirkungsvoll macht, ist seine Flexibilität. Snapstone dient nicht zur Behebung früherer Fehler, sondern ermöglicht das dynamische Definieren jeder Konfigurationseinheit, deren Zustand überprüft werden muss. Das kann eine Datei mit Daten sein, wie die, die den Ausfall am 18. November verursacht hat. Es kann sich aber auch um ein Kontroll-Flag in unserem globalen Konfigurationssystem handeln wie das, das an dem Ausfall am 5. Dezember beteiligt war. Teams erstellen diese Konfigurationseinheiten bei Bedarf. Snapstone sorgt dann dafür, dass sie überall, wo sie verwendet werden, auf sichere Weise implementiert werden.

Das verschafft uns etwas, über das wir bisher nicht verfügt haben: Wenn bei einer Risikoprüfung oder im Betrieb ein gefährliches Konfigurationsmuster festgestellt wird, lässt sich das Problem leicht beheben. Wir übermitteln es an Snapstone und die sichere Implementierungsversion wird sofort auf das Konfigurationsmuster übertragen. 

Relevanz für Sie: Falls in unserem Netzwerk ein Problem auftritt, erfolgt der Systemausfall weniger abrupt. Dadurch verringert sich der Radius der potenziellen Auswirkungen erheblich, sodass Ihre Daten auch im schlimmsten Fall zuverlässig übertragen werden.

Die Produkteams haben bei die für den Kunden-Traffic maßgeblichen Dienste sowohl manuell als auch automatisiert intensiv auf potenzielle Fehlerquellen hin überprüft. Sie haben nicht unbedingt erforderliche Laufzeitabhängigkeiten beseitigt und bessere Mechanismen zur Fehlerbehandlung implementiert. Wenn möglich erfolgt eine Zurücksetzung auf die letzte bekannte funktionierende Konfiguration („Fail Stale“). Für die Fälle, in denen diese Möglichkeit nicht besteht, haben wir jedes Fehlerszenario analysiert und jeweils entweder die Option „Fail Open“ oder „Fail Close“ festgelegt – je nachdem, ob eine eingeschränkte Funktionsfähigkeit einem vollständigen Ausfall der Traffic-Übermittlung vorzuziehen ist.

Wie das genau funktioniert, schauen wir uns jetzt anhand eines Beispiels an. Unser Ausfall im November 2025 wurde durch die gescheiterte Implementierung unseres Machine Learning einsetzenden Klassifikators im Bot-Management ausgelöst. Gemäß unserer neuen Verfahren würde unser System, falls erneut Daten generiert würden, die es nicht lesen kann, die aktualisierte Konfiguration ablehnen und stattdessen die alte verwenden. Wäre die alte Konfiguration aus irgendeinem Grund nicht verfügbar, würde es zu einem „Fail Open“ kommen. So wäre sichergestellt, dass der Produktivdatenverkehr der Kunden weiterhin übertragen wird. Das wäre deutlich besser, als einen Ausfall in Kauf zu nehmen.

Würde dieselbe Änderung im Bot-Management, die den Ausfall im November verursacht hat, jetzt eingeführt, würde das System folglich den Fehler in einem frühen Stadium der Implementierung erkennen, bevor mehr als ein geringer Prozentsatz des Datenverkehrs davon betroffen ist.

Wir haben auch damit begonnen, unser System weiter zu segmentieren, sodass unabhängige Kopien von Diensten für verschiedene Gruppen von Datenverkehr eingesetzt werden. Cloudflare macht sich diese Kundengruppen für die Schadensbegrenzung bereits zunutze und setzt entsprechende Traffic-Management-Verfahren ein. Diese zusätzliche Prozesssegmentierung bietet uns künftig eine hochwirksame Möglichkeit, Zuverlässigkeit zu gewährleisten.  

So ist das Workers-Laufzeitsystem beispielsweise in mehrere unabhängige Dienste unterteilt, die jeweils unterschiedliche Gruppen von Datenverkehr verarbeiten, wobei einer nur den Traffic unserer Kunden mit Free-Tarif übernimmt. Die Änderungen werden auf Basis von Kundengruppen implementiert. Begonnen wird mit Kunden, die den Free-Tarife nutzen. Außerdem senden wir Updates schneller und häufiger an die Segmente mit der geringsten Bedeutung, während die kritischsten sie langsamer erhalten.

Wäre also eine Änderung im Workers-Laufzeitsystem implementiert und der Traffic dadurch beeinträchtigt worden, würde dies jetzt nur noch einen kleinen Anteil unserer Free-Kunden betreffen, bevor der Fehler automatisch erkannt und die Änderung rückgängig gemacht wird.

Wenn wir beim Beispiel des Workers-Laufzeitsystems bleiben, wurde der Implementierungsprozess in einem Zeitraum von sieben Tagen Anfang des Monats mehr als 50 Mal aktiviert. Man sieht, dass dies jeweils in „Wellen“ geschieht, bis die Änderungen bis zur Edge übernommen werden. Häufig erfolgt dies parallel zu den folgenden und vorherigen Releases:

Künftig soll die Bereitstellung vieler weiterer unserer Systeme auf dieselbe Weise durchgeführt werden.

Relevanz für Sie: Kommt es zu einem Zwischenfall, verfügen wir über die nötigen Tools und Mitarbeitenden für eine klarere Kommunikation und eine schnellere Behebung, sodass Ausfälle auf ein Mindestmaß begrenzt werden.

Auf Cloudflare läuft Cloudflare. Wir sichern unsere Infrastruktur mit unseren eigenen Zero Trust-Produkten ab. Dadurch wird allerdings eine Abhängigkeit geschaffen. Denn wenn ein das gesamte Netzwerk betreffender Ausfall diese Tools beeinträchtigt, stehen uns die für seine Behebung nötigen Mittel nicht mehr zur Verfügung. Vor der „Code Orange“-Initiative waren unsere Notfall-Optionen auf eine kleine Zahl von Personen beschränkt und sie boten auch nur sehr begrenzten Zugriff auf die erforderlichen Tools. Wir mussten dafür sorgen, dass diese Werkzeuge und Optionen während eines Ausfalls in breiterem Umfang zur Verfügung stehen.

Mit diesem Ziel vor Augen haben wir eine umfassende Überprüfung aller für die Übersicht über das System, das Debugging und Anpassungen im Produktivbetrieb wesentlichen Tools durchgeführt. Zuletzt haben wir Backup-Autorisierungspfade für 18 zentrale Dienste entwickelt, die durch neue Notfallskripte und Proxys unterstützt werden.

Im Verlauf des „Code Orange“-Programms sind wir von der Theorie zur Praxis übergegangen. Nach Testläufen in kleinen Teams haben wir am 7. April 2026 ein Ausbildungsmanöver mit der gesamten Technik-Abteilung durchgeführt, an dem mehr als 200 Teammitglieder beteiligt waren. Automatisierung sorgt dafür, dass diese Pfade erhalten bleiben. Doch Übungen wie diese stellen sicher, dass unsere Techniker auch unter Druck wissen, was zu tun ist, ohne groß darüber nachdenken zu müssen.

Der Fokus lag hier auch auf dem Informationsfluss. Wenn der interne Überblick nicht mehr (vollständig) gegeben ist, können wir auch nicht mehr so schnell reagieren und sind weniger gut in der Lage, mit der Außenwelt zu kommunizieren. Erfahrungsgemäß lassen sich technische Beobachtungen während Krisensituationen nicht automatisch in gut verständliche Informationen für unsere Kunden verwandeln.

Um diese Lücke zu schließen, haben wir ein speziell dafür zuständiges Kommunikationsteam geschaffen, das bei großen Ereignissen Hand in Hand mit den für die Vorfallreaktion zuständigen Beschäftigten arbeitet. Genauso wie unsere Techniker die Abläufe bei Notfällen trainiert haben, hat dieses Team das „Code Orange“-Programm genutzt, um die Kunden schneller und klarer von den aktuellen Entwicklungen unterrichten zu können. Indem wir sicherstellen, dass uns sowohl die Werkzeuge zur Verfügung stehen, mit denen wir uns einen Überblick verschaffen können, als auch die nötigen Kommunikationswege, können wir Vorfälle schneller klären und unsere Kunden besser informieren.

Relevanz für Sie: Wir lernen aus Zwischenfällen und schreiben unsere Lösungen fest. Das macht unser Netzwerk noch belastbarer.

Um zu verhindern, dass im Lauf der Zeit Abweichungen von den im Rahmen von „Code Orange“ vorgenommenen Änderungen auftreten und es zu Rückschritten kommt, hat das Team einen internen Kodex erstellt, der alle unsere Richtlinien in klare und prägnante Regeln fasst.

Dieser ist inzwischen für sämtliche Technik- und Produktteams obligatorisch und integraler Bestandteil der internen Verfahren von Cloudflare. Die Einhaltung dieser Regeln wird durch KI-Codeauswertungen sichergestellt, die auf alle von den Richtlinien auftretenden Abweichungen hinweisen, sodass eine zusätzliche manuelle Prüfung erfolgen kann. Dies wird ohne Ausnahme auf unseren gesamten Quellcode angewandt. Das Ziel ist einfach: Ein institutionelles Gedächtnis schaffen, die seine Regeln selbst durchsetzt.

Die Ausfälle im November und Dezember hatten eines gemeinsamen: Programmcode, der davon ausging, dass Eingaben immer gültig sind, ohne eine ordnungsgemäße Rückstufung bei Hinfälligkeit dieser Annahme zu gewährleisten. Bei einem Rust-Dienst namens .unwrap() hat Lua-Code ein nicht existierendes Objekt indexiert, anstatt einen Fehler zu adressieren. Solche Muster können vermieden werden, wenn die Lehren aus Zwischenfällen gezogen und konsequent angewandt werden.

Der Kodex ist ein Teil unserer Antwort. Es handelt sich um eine sich ständig erweiternde Sammlung von Technikstandards, die von Fachleuten über unseren Request for Comments (RFC)-Prozess erstellt und dann in umsetzbare Regeln übersetzt werden. Best Practices, die früher nur in den Köpfen erfahrener Techniker existierten oder erst nach einem Vorfall entdeckt wurden, werden jetzt zu Allgemeinwissen, das allen zur Verfügung steht. Jede Regel ist nach einem einfachen Format aufgebaut: „Wenn Sie X brauchen, nutzen Sie Y“. Außerdem enthält sie einem Link zur RFC, in der erklärt wird, warum so vorzugehen ist.

Zum Beispiel heißt es in einer RFC jetzt: „Bitte nutzen Sie .unwrap() außerhalb von Tests und build.rs nicht.“ Eine andere deckt ein breiteres Prinzip ab: „Dienste MÜSSEN vor der Verarbeitung überprüfen, ob der Status vorgelagerter Abhängigkeiten den Erwartungen entspricht.“

Wären diese Regeln früher durchgesetzt worden, hätte es sich bei den Ausfällen im November und Dezember nicht um weltweite Vorfälle gehandelt, sondern lediglich um abgelehnte Merge-Requests.

Werden Richtlinien nicht durchgesetzt, sind es lediglich Empfehlungen. Der Kodex arbeitet in jeder Phase des Lebenszyklus der Softwareentwicklung – von der Designüberprüfung über die Bereitstellung bis zur Vorfallanalyse – mit KI-basierten Agenten. Das bedeutet, dass Maßnahmen früher durchgesetzt werden, sodass aus einem weltweiten Ausfall ein abgelehnter Merge-Request wird. Das Schadensausmaß eines Fehlers schrumpft von Millionen betroffener Anfragen auf einen einzelnen Entwickler, der praktisch anwendbares Feedback erhält, bevor sein Programmcode im Produktivbetrieb übernommen wird.

Der Kodex ist eine lebendige Richtlinie, die kontinuierlich aktualisiert wird. Fachleute verfassen RFC, um Best Practices festzuschreiben. Zwischenfälle fördern Lücken zutage, aus denen neue RFC entstehen. Jede genehmigten RFC erzeugt Kodexregeln. Diese Regeln werden den Agenten vorgegeben, die den nächsten Merge-Request überprüfen. So entsteht ein Flywheel-Effekt: Fachwissen wird zu Standards und Standards werden durchgesetzt, wodurch für alle eine Verbesserung eintritt.

Relevanz für Sie: Wir legen Wert auf Transparenz. Sollte etwas schiefgehen, halten wir Sie bei jedem Schritt auf dem Laufenden, sodass Sie sich auf das für Sie Wesentliche konzentrieren können.

Die weltweiten Ausfälle haben uns dazu gebracht, unsere Kernprozesse und kulturellen Ansätze auch über den Bereiche Technik und Produktentwicklung hinaus auf den Prüfstand zu stellen. Im Rahmen der übergeordneten „Code Orange“-Initiative haben wir zusätzliche Service Level Objectives (SLO) für alle unsere Dienste eingeführt, ein globales Änderungsprotokoll durchgesetzt, alle Teams in unser System zur Koordination der Instandhaltung eingebunden und die unternehmensweite Übersicht über den Rückstand bei Tickets erhöht, deren Bearbeitung Vorfälle verhindern können. 

Wir haben auch die Art und Weise optimiert, in der wir während eines Ausfalls mit unseren Kunden kommunizieren. Unser Ziel ist es, Sie auf ein Problem aufmerksam zu machen, sobald wir uns seiner Existenz vergewissert haben, noch bevor Sie es bemerken. Wenn Sie Verzögerungen oder Fehler registrieren, wird bereits an einem Update gearbeitet, für das Sie kurze Zeit später eine Benachrichtigung erhalten.

Während eines Zwischenfalls veröffentlichen wir jetzt in vorhersehbaren Abständen (alle 30 oder 60 Minuten) Updates, und sei es nur: „Wir testen die Lösung noch, bisher gibt es keine Änderungen.“ Sie können so besser planen und müssen nicht ständig eine Statusseite aktualisieren.

Unsere Aufgabe ist jedoch nicht abgeschlossen, wenn alles wieder normal läuft. Wir führen ausführliche Post-Mortem-Analysen durch. Darin wird dargelegt, was passiert ist, warum es passiert ist und welche strukturellen Maßnahmen ergriffen werden, damit es nicht noch einmal passiert.

Wir nehmen die Zwischenfälle sehr ernst und nehmen das gesamte Unternehmen in die Pflicht, indem wir jedes Team fragen: Was hätte besser laufen können? Dies hat während der letzten beiden Quartal die Grundlage unserer Arbeit gebildet.

Diese kontinuierliche Arbeit wird nie wirklich beendet sein. Wir sind aber überzeugt, dass wir nun erheblich besser aufgestellt sind und hierdurch Cloudflare deutlich gestärkt haben.