Postmortem zum Ausfall der Cloudflare-Control-Plane und der Analysesysteme
(blog.cloudflare.com)- Ab dem 2. November 2023 um 11:43 UTC fielen Cloudflares Control Plane und Analysedienste aus; betroffen waren Änderungen über Dashboard/API sowie Logging- und Analysefunktionen
- Ausgangspunkt der Störung war ein Stromausfall in PDX-04 in Oregon, betrieben von Flexential; in dieser Anlage befanden sich der größte Analyse-Cluster und mehr als ein Drittel der Hardware des Hochverfügbarkeits-Clusters
- Da die Wiederherstellung von Utility Feed, Generator, UPS und Leistungsschaltern kaskadenartig ins Wanken geriet, durchbrachen nur in PDX-04 vorhandene Kafka- und ClickHouse-Abhängigkeiten das Hochverfügbarkeitsdesign
- Am 2. November um 13:40 UTC wurde das Failover auf den europäischen Disaster-Recovery-Standort beschlossen; um 17:57 UTC waren die Auswirkungen auf Kunden größtenteils reduziert, doch Logverarbeitung, einige bespoke APIs, manuelle Magic-WAN-Konfigurationen und Stream-Uploads waren länger betroffen
- Cloudflare treibt im Rahmen von Code Orange Hochverfügbarkeitsanforderungen für GA-Produkte, validierte Disaster-Recovery-Pläne, Chaos Testing inklusive vollständiger Entfernung zentraler Rechenzentren sowie Pläne zur Vermeidung von Logverlust voran
Umfang der Störung und Kundenauswirkungen
- Ab dem 2. November 2023 um 11:43 UTC kam es zu einer Störung der Control Plane und der Analysedienste von Cloudflare
- Mit Control Plane sind die kundenseitigen Schnittstellen einschließlich Website und API gemeint
- Zu den Analysediensten gehören Logging und Analyse-Reporting
- Der gesamte Vorfall dauerte vom 2. November um 11:44 UTC bis zum 4. November um 04:25 UTC
- Am 2. November um 17:57 UTC war der Großteil der Control Plane in der Disaster-Recovery-Anlage wiederhergestellt
- Nachdem die Disaster-Recovery-Anlage online war, hatten viele Kunden bei den meisten Produkten möglicherweise keine Probleme mehr
- Einige Dienste brauchten länger zur Wiederherstellung, und Kunden, die diese Dienste nutzten, konnten bis zur vollständigen Behebung weiterhin Probleme sehen
- Der Rohlog-Dienst stand den meisten Kunden während des größten Teils des Vorfalls nicht zur Verfügung
- Cloudflares Netzwerk- und Sicherheitsdienste funktionierten während des gesamten Vorfalls wie erwartet
- Es gab Zeiträume, in denen Kunden diese Dienste nicht ändern konnten
- Der Traffic durch das Cloudflare-Netzwerk war nicht betroffen
Ursprüngliches Design: Hochverfügbarkeit auf Basis von drei Rechenzentren in Oregon
- Cloudflares Control Plane und Analysesysteme laufen hauptsächlich auf Servern in drei Rechenzentren rund um Hillsboro, Oregon
- Die drei Rechenzentren sind voneinander unabhängig und verfügen jeweils über mehrere Utility-Power-Feeds sowie mehrere redundante und unabhängige Netzwerkverbindungen
- Die Standorte wurden so gewählt, dass sie weit genug voneinander entfernt sind, um kaum gleichzeitig von Naturkatastrophen betroffen zu sein, aber nah genug, um active-active redundante Daten-Cluster betreiben zu können
- Die drei Standorte synchronisieren kontinuierlich Daten
- Dem Design nach sollte der Betrieb in den übrigen Standorten weiterlaufen können, wenn ein Standort offline geht
- Dieses Hochverfügbarkeitsdesign wurde vor vier Jahren begonnen umzusetzen
- Die meisten zentralen Control-Plane-Systeme wurden in den Hochverfügbarkeits-Cluster migriert
- Einige Dienste neuer Produkte waren noch nicht in den Hochverfügbarkeits-Cluster aufgenommen
- Das Logging-System wurde bewusst nicht in den Hochverfügbarkeits-Cluster aufgenommen
- Logs werden als verteiltes Problem behandelt: Sie werden am Network Edge in Queues gesammelt und anschließend an den Oregon-Core oder regionale Logging-Standorte übertragen
- Wenn ein Logging-Standort offline ist, warten Analyse-Logs am Edge; Analyseverzögerungen wurden als akzeptabel eingestuft
Beginn des Stromausfalls in PDX-04
- Der größte der drei Oregon-Standorte ist PDX-04, betrieben von Flexential
- Cloudflare betreibt dort seinen größten Analyse-Cluster
- Mehr als ein Drittel der Hardware des Hochverfügbarkeits-Clusters befindet sich ebenfalls in dieser Anlage
- Zudem ist sie der Standardstandort für Dienste, die noch nicht in den Hochverfügbarkeits-Cluster onboarded wurden
- Cloudflare ist dort ein vergleichsweise großer Kunde und nutzt rund 10 % der Gesamtkapazität der Anlage
- Am 2. November um 08:50 UTC kam es bei einem der unabhängigen Strom-Feeds von Portland General Electric (PGE), die PDX-04 versorgen, zu einem ungeplanten Wartungsereignis
- Durch dieses Ereignis fiel ein Feed in PDX-04 aus
- Flexential startete Generatoren, um den ausgefallenen Feed zu kompensieren
- Flexential informierte Cloudflare nicht darüber, dass ein Failover auf Generatorstrom erfolgt war
- Cloudflares Beobachtungswerkzeuge erkannten den Wechsel der Stromquelle nicht
- Mit einer Vorabinformation hätte Cloudflare die Anlage engmaschig überwachen und Control-Plane-Dienste, die von diesem Standort abhängen, an andere Orte verlagern können
- Ungewöhnlich war auch, dass Flexential den verbleibenden Utility Feed und die Generatoren gleichzeitig betrieb
- Flexential betreibt einschließlich redundanter Einheiten 10 Generatoren und kann damit die gesamte Last der Anlage tragen
- Es wäre auch möglich gewesen, die Anlage allein mit dem verbleibenden Utility Feed zu betreiben
- Cloudflare erhielt keine klare Antwort darauf, warum Flexential Utility Power und Generator Power gemeinsam nutzte
Unbestätigte Ursache und Generatorstopp
- Die eigentliche Ursache der folgenden Ereignisse und einige Entscheidungen wurden von Flexential nicht eindeutig bestätigt
- Als eine mögliche Erklärung bleibt, dass Flexential am DSG-Programm von PGE teilgenommen haben könnte
- DSG ist ein Programm, mit dem der lokale Stromversorger Generatoren von Rechenzentren nutzen kann, um zusätzliche Leistung ins Stromnetz einzuspeisen
- Im Gegenzug unterstützt der Stromversorger Wartung und Kraftstoffversorgung der Generatoren
- Cloudflare fand keine Aufzeichnungen darüber, dass Flexential das DSG-Programm offengelegt hatte
- Auch auf die Frage, ob DSG zum Zeitpunkt des Vorfalls aktiv war, erhielt Cloudflare keine Antwort
- Gegen 11:40 UTC trat am PGE-Transformator von PDX-04 ein Ground Fault auf
- Cloudflare vermutet, dass dieser Transformator die Spannung des zweiten Feeds, der ins Rechenzentrum führte, heruntersetzte, bekam dies aber nicht bestätigt
- Ebenfalls unbestätigt ist, ob dieser Ground Fault aus der ungeplanten Wartung von PGE resultierte, die den ersten Feed betroffen hatte
- Bei einem Ground Fault auf einer 12.470-V-Hochspannungsleitung ist das elektrische System darauf ausgelegt, zum Schutz vor Schäden schnell abzuschalten
- Diese Schutzmaßnahme stoppte auch alle Generatoren in PDX-04
- In der Folge waren sowohl die Utility Line als auch alle 10 Generatoren offline
- PDX-04 verfügte über UPS-Batteriebänke, von denen bekannt war, dass sie die Anlage etwa 10 Minuten lang versorgen können
- Diese Zeit soll die Lücke zwischen Stromausfall und automatischem Neustart der Generatoren überbrücken
- Nach Cloudflares Beobachtung von Hardwareausfällen begannen die Batterien nach 4 Minuten zu versagen
- Flexential brauchte deutlich länger als 10 Minuten, um die Generatoren wiederherzustellen
Verzögerte Stromwiederherstellung und erste Benachrichtigung
- Obwohl Cloudflare keine offizielle Bestätigung erhielt, hörte das Unternehmen von Flexential-Mitarbeitern von drei Faktoren, die die Wiederherstellung der Generatoren behinderten
- Aufgrund der Art, wie der Ground Fault die Schaltung ausgelöst hatte, musste physisch auf die Generatoren zugegriffen werden, um sie manuell neu zu starten
- Flexentials Zutrittskontrollsystem hatte keine Batterie-Backup-Stromversorgung und war offline
- In der Nachtschicht gab es keine erfahrenen Betriebs- oder Elektrofachkräfte, sondern nur Sicherheitspersonal und einen erst seit einer Woche beschäftigten, unbegleiteten Techniker
- Zwischen 11:44 und 12:01 UTC entluden sich die UPS-Batterien, während die Generatoren nicht vollständig neu gestartet werden konnten; dadurch verloren alle Kunden im Rechenzentrum die Stromversorgung
- Flexential informierte Cloudflare währenddessen nicht über das Problem in der Anlage
- Cloudflare bemerkte das Rechenzentrumsproblem erstmals um 11:44 UTC, als zwei Router, die die Anlage mit der Außenwelt verbanden, offline gingen
- Als kein direkter Zugriff auf die Router und kein Zugriff über Out-of-band-Management möglich war, kontaktierte Cloudflare Flexential und schickte ein lokales Team zur Anlage
- Die erste Störungsmeldung von Flexential an Cloudflare erfolgte um 12:28 UTC
- Die Nachricht besagte, dass das Stromproblem in PDX-04 gegen 12:00 UTC begonnen habe, ein Ingenieur an der Wiederherstellung arbeite und alle 30 Minuten über den Fortschritt informiert werde
Im Hochverfügbarkeitsdesign sichtbar gewordene Abhängigkeitsprobleme
- PDX-04 hatte vor dem Bau ein Tier-III-zertifiziertes Design erhalten und sollte voraussichtlich ein Hochverfügbarkeits-SLA bieten; dennoch plante Cloudflare auch für die Möglichkeit, dass diese Anlage offline geht
- Erwartete Auswirkungen waren ein Ausfall der Analyse, das Aufstauen und Verzögern von Logs am Edge sowie eine temporäre Unterbrechung niedrig priorisierter Dienste, die nicht in den Hochverfügbarkeits-Cluster integriert waren
- Dass die beiden anderen Rechenzentren den Hochverfügbarkeits-Cluster übernahmen und zentrale Dienste online hielten, funktionierte im Großen und Ganzen wie geplant
- Das Problem war, dass einige Dienste, die im Hochverfügbarkeits-Cluster hätten sein müssen, von Diensten abhingen, die ausschließlich in PDX-04 liefen
- Kafka und ClickHouse, zuständig für Logverarbeitung und Analyse, wurden nur in PDX-04 bereitgestellt
- Einige im Hochverfügbarkeits-Cluster laufende Dienste hingen von ihnen ab
- Diese Abhängigkeit hätte loser sein, eleganter fehlschlagen und im Vorfeld entdeckt werden müssen
- Cloudflare hatte in Tests des Hochverfügbarkeits-Clusters jeweils die beiden anderen Standorte einzeln und beide zusammen vollständig offline genommen
- Auch Tests, bei denen der Hochverfügbarkeitsteil von PDX-04 offline genommen wurde, wurden durchgeführt
- Ein Test, bei dem die gesamte PDX-04-Anlage vollständig offline genommen wurde, fand jedoch nicht statt
- Auch die Anforderungen, damit neue Produkte und zugehörige Datenbanken in den Hochverfügbarkeits-Cluster integriert werden, waren zu locker
- Produktteams hatten unterschiedliche Wege in die Alpha-Phase
- Mit der Zeit sollten Backends auf Best Practices migriert werden, dies wurde vor der GA-Erklärung jedoch nicht formell verlangt
- Dadurch funktionierte der Redundanzschutz je nach Produkt uneinheitlich
Umstellung auf den Disaster-Recovery-Standort
- Um 12:48 UTC startete Flexential die Generatoren neu, und Teile der Anlage erhielten wieder Strom
- Die Wiederherstellung der Stromversorgung eines Rechenzentrums erfolgt normalerweise schrittweise, Stromkreis für Stromkreis
- Als die Cloudflare-Stromkreise wieder eingeschaltet werden sollten, stellte sich heraus, dass Leistungsschalter defekt waren
- Ob diese Leistungsschalter durch den Ground Fault oder eine Überspannung beschädigt wurden oder schon zuvor problematisch waren, ist nicht bekannt
- Flexential begann damit, die defekten Leistungsschalter zu ersetzen
- Es waren mehr Leistungsschalter defekt, als Ersatzteile in der Anlage vorhanden waren, sodass neue Leistungsschalter beschafft werden mussten
- Da mehr Dienste als erwartet offline waren und Flexential keine Wiederherstellungszeit nennen konnte, entschied Cloudflare um 13:40 UTC das Failover auf den europäischen Disaster-Recovery-Standort
- Nur ein kleiner Anteil der gesamten Control Plane musste failovern
- Die meisten Dienste liefen weiterhin auf den Hochverfügbarkeitssystemen der beiden verbleibenden Core-Rechenzentren
- Um 13:43 UTC wurde der erste Dienst am Disaster-Recovery-Standort gestartet
- Dieser Standort ist dafür ausgelegt, im Katastrophenfall zentrale Control-Plane-Dienste bereitzustellen
- Einige Logverarbeitungsdienste unterstützt er nicht
- Nach dem Start der Dienste trafen viele zuvor fehlgeschlagene API-Aufrufe ein, was zu einem Thundering-Herd-Problem führte
- Cloudflare setzte Rate Limits ein, um das Anfragevolumen zu kontrollieren
- Während dieser Zeit konnten Kunden der meisten Produkte beim Vornehmen von Änderungen über Dashboard oder API sporadische Fehler sehen
- Bis 17:57 UTC hatten sich die auf den Disaster-Recovery-Standort verlagerten Dienste stabilisiert, und die direkten Auswirkungen auf die meisten Kunden gingen zurück
- Einige Systeme wie Magic WAN erforderten weiterhin manuelle Konfiguration
- Logverarbeitung und Dienste im Zusammenhang mit einigen bespoke APIs waren bis zur Wiederherstellung von PDX-04 nicht verfügbar
Verzögerte Wiederherstellung einiger Produkte und Neustart von PDX-04
- Einige Produkte liefen am Disaster-Recovery-Standort nicht korrekt
- Es handelte sich hauptsächlich um neue Produkte, deren Disaster-Recovery-Verfahren noch nicht vollständig implementiert und getestet waren
- Dazu gehörten der Stream-Dienst für neue Video-Uploads sowie einige weitere Dienste
- Das Cloudflare-Team verfolgte zwei Wege gleichzeitig
- Die betreffenden Dienste am Disaster-Recovery-Standort erneut implementieren
- Sie in den Hochverfügbarkeits-Cluster migrieren
- Flexential ersetzte die defekten Leistungsschalter, stellte beide Utility Feeds wieder her und bestätigte um 22:48 UTC eine stabile Stromversorgung
- Da das Team den ganzen Tag im Notfallmodus gearbeitet hatte, entschied Cloudflare, dass sich die meisten Mitarbeitenden ausruhen und am nächsten Morgen mit den Arbeiten zur Rückkehr nach PDX-04 beginnen sollten
- Diese Entscheidung verzögerte die vollständige Wiederherstellung, sollte aber die Wahrscheinlichkeit weiterer Fehler reduzieren
- Am Morgen des 3. November begann die Wiederherstellung der PDX-04-Dienste
- Netzwerkgeräte wurden physisch gebootet
- Tausende Server wurden eingeschaltet und Dienste wiederhergestellt
- Da es während des Vorfalls vermutlich mehrere Power Cycles gegeben hatte, war der Zustand der Dienste im Rechenzentrum unbekannt
- Das sichere Wiederherstellungsverfahren bestand darin, einem vollständigen Bootstrap der gesamten Anlage zu folgen
- Konfigurationsmanagement-Server wurden manuell online gebracht, die Neuerstellung dauerte 3 Stunden
- Anschließend wurden die übrigen Server im Bootstrap-Verfahren neu aufgebaut
- Die Neuerstellung einzelner Server dauerte zwischen 10 Minuten und 2 Stunden
- Obwohl mehrere Server parallel bearbeitet wurden, mussten einige wegen Abhängigkeiten zwischen Diensten sequenziell wiederhergestellt werden
- Alle Dienste waren am 4. November 2023 um 04:25 UTC vollständig wiederhergestellt
- Bei den meisten Kunden ist davon auszugehen, dass es bei den meisten Analysen in Dashboard und API keinen Datenverlust gibt, da Analysedaten auch im europäischen Core-Rechenzentrum gespeichert wurden
- Bei einigen Datensätzen, die nicht in die EU repliziert wurden, bleiben dauerhafte Lücken
- Für Kunden, die Logpush nutzen, wurden während des größten Teils des Vorfalls keine Logs verarbeitet; nicht erhaltene Logs werden nicht wiederhergestellt
Code Orange und Verbesserungsplan
- Cloudflare hat viele Fragen, auf die Flexential noch Antworten liefern muss, kam aber zu dem Schluss, dass auch der Ausfall eines gesamten Rechenzentrums antizipiert werden muss
- Ähnlich wie Googles Code Yellow und Code Red führte Cloudflare einen eigenen Prozess namens Code Orange ein, der bei schwerwiegenden Vorfällen oder Krisen Engineering-Ressourcen auf die Problemlösung fokussiert
- Nicht zentrale Engineering-Funktionen werden auf Arbeiten zur Sicherstellung hoher Zuverlässigkeit der Control Plane umgestellt
- Die geplanten Änderungen sind folgende
- Abhängigkeiten von Core-Rechenzentren aus der Control-Plane-Konfiguration aller Dienste entfernen und, wo möglich, so migrieren, dass Cloudflares verteiltes Netzwerk zuerst startet
- Sicherstellen, dass die im Netzwerk laufende Control Plane weiter funktioniert, selbst wenn alle Core-Rechenzentren offline sind
- Für GA-Produkte und -Funktionen, die von Core-Rechenzentren abhängen, verlangen, dass sie ohne Softwareabhängigkeit von einer bestimmten Anlage auf den Hochverfügbarkeits-Cluster setzen
- Für GA-Produkte und -Funktionen getestete und verlässliche Disaster-Recovery-Pläne verlangen
- Den Blast Radius von Systemausfällen testen und die Zahl der von einem Ausfall betroffenen Dienste minimieren
- Strengeres Chaos Testing für alle Rechenzentrumsfunktionen implementieren, einschließlich der vollständigen Entfernung jedes einzelnen Core-Rechenzentrumsstandorts
- Alle Core-Rechenzentren gründlich auditieren und Pläne für erneute Audits erstellen, um die Einhaltung von Standards sicherzustellen
- Disaster-Recovery-Pläne für Logging und Analyse erstellen, damit auch beim Ausfall aller Core-Rechenzentren keine Logs verloren gehen
- Cloudflare fasst zusammen, dass zwar die notwendigen Systeme und Verfahren vorhanden waren, es aber an der Strenge fehlte, deren Einhaltung durchzusetzen und unbekannte Abhängigkeiten zu testen
1 Kommentare
Meinungen auf Hacker News
Es ist eine merkwürdige Entscheidung, den Großteil des Beitrags darauf zu verwenden, einen bestimmten Anbieter namentlich verantwortlich zu machen und über die eigentliche Ursache zu spekulieren.
Dass sie offenlegen, dort ein großer Kunde zu sein, und sogar ein vom Anbieter als vertraulich gekennzeichnetes Stromdiagramm in die Postmortem-Analyse aufnehmen, wirkt ziemlich unangemessen.
Den auslösenden Faktor und den Kontext des Vorfalls zu erklären, ist nachvollziehbar, aber der Fokus einer Postmortem-Analyse sollte nicht auf dem Anbieter liegen, sondern auf dem Ausfall bei Cloudflare.
Flexential sollte sicher auch eine eigene Postmortem-Analyse durchführen, aber Cloudflare muss nicht stellvertretend öffentlich darüber spekulieren.
Es könnte auch darum gehen, dass Cloudflare proaktiv eine Erklärung liefern will, bevor jemand anderes zuerst ein Narrativ setzt.
In einer Situation mit drei Parteien und mehreren miteinander verbundenen Systemen ist es nachvollziehbar, dass Cloudflare bis ins Detail wissen will, was passiert ist, wenn sie solche kombinierten Ausfallmodi künftig in ihr Design einbeziehen wollen.
Persönlich bin ich dankbar für die Informationen, die Cloudflare geteilt hat.
99 % der Verantwortung liegen bei Cloudflare, weil sie ihre Kernaufgabe nicht erfüllt haben.
Dass sie einen Dritten so tiefgehend auseinandernehmen, zeigt eher, wie peinlich die Sache für Cloudflare ist.
Es sieht so aus, als hätten sie nicht einmal die Leistungsschalter ordentlich geprüft, und in einer relativ neuen Anlage hatten sie nicht einmal die Hälfte der zehn Stunden Reserve, um die Generatorbatterien zu laden.
Während dieser Wartung hätten sie komplett auf Generatorbetrieb umschalten müssen; vermutlich konnten sie das nicht, weil sie PGE unterstützt haben.
Ich denke, der CEO von Cloudflare hat recht. Bei Rechenzentrumsdiensten zahlt man in der Erwartung vollständiger Redundanz, und es heißt, an diesem Standort gebe es 18 MW, aber soweit ersichtlich ist nicht einmal klar, ob es nur zwei Einspeisungen gibt.
Wenn eine Einspeisung ausfällt, sollte eine 2N-Konfiguration übernehmen, und mit Generatoren sollte es kein Problem geben.
Dann ist es auch richtig, die bislang bekannten ersten Ereignisse zu beschreiben.
Eine Folgeanalyse scheint sehr wahrscheinlich.
https://twitter.com/eastdakota/status/1720688383607861442?t=...
Den Zitaten nach war die eigentliche Ursache des Ausfalls die Abhängigkeit von einem einzelnen Rechenzentrum.
Der Großteil der zentralen Control-Plane-Systeme sei zwar in Hochverfügbarkeitscluster verschoben worden, einige neue Produkte aber noch nicht; außerdem hingen einige Dienste, die in einem Hochverfügbarkeitscluster laufen sollten, von Diensten ab, die nur in PDX-04 liefen, und einige Produkte seien nicht korrekt am Disaster-Recovery-Standort hochgefahren worden.
Für ein Unternehmen wie Cloudflare, das einen wichtigen Teil des Internets stützt, ist das ziemlich peinlich.
Cloudflare habe mehreren Teams schnelle Innovation erlaubt, sodass Produkte bis zur frühen Alpha jeweils unterschiedliche Wege nahmen; mit der Zeit würden sie zwar zu Best Practices wechseln, das sei aber vor der allgemeinen Verfügbarkeit nicht als Pflichtbedingung verlangt worden.
Das ist ein kompletter Management-Fehler. Im Grunde wurde Kunden Software verkauft, die nach Cloudflares internen Maßstäben Alpha-Qualität hatte, oder nicht?
https://news.ycombinator.com/item?id=38113503
Das wirkt wie mangelnde Selbstwahrnehmung.
Das ist Amateurniveau, besonders gravierend ist, dass neue Dienste ohne Hochverfügbarkeit gestartet wurden.
Als jemand, der von diesem Ausfall ein wenig betroffen war, finde ich diese Postmortem-Analyse unzureichend.
75 % handeln vom Stromausfall in PDX-04 und von Flexentials Verantwortung; dem Text nach war das, was dort passiert ist, nahezu eine Katastrophe, also ist das nachvollziehbar.
Aber laut Bericht war die Stromversorgung am 2. November UTC vollständig wiederhergestellt, und danach brauchte Cloudflare noch etwa 30 weitere Stunden bis zur vollständigen Wiederherstellung.
Die Wiederherstellung dauerte länger als der eigentliche Ausfall, aber der Beitrag sagt nur, dass zu viele Dienste voneinander abhängig waren. Ich würde gern genauer wissen, warum die komplette Betriebswiederherstellung so lange gedauert hat.
Gab es aus dem Wiederherstellungsprozess selbst keine Lehren? Oder hat es wirklich nur so lange gedauert, die Daten vom Edge zurück zum „Gehirn“ zu synchronisieren?
Ein weiterer fehlender Punkt ist insbesondere die mangelnde Kommunikation mit Enterprise-Kunden. Der Cloudflare-Support war abgesehen von der Statusseite praktisch stumm, und selbst wenn es realistisch nicht viel gab, was man tun konnte, hätte es Kommunikationsversuche geben müssen.
Umso mehr, nachdem in der Postmortem-Analyse Flexentials mangelnde Kommunikation kritisiert wurde. Ich mag Cloudflares Produkte, aber aus diesem Vorfall sollten sie mehr Schlussfolgerungen ziehen.
Allerdings ist es etwas verfehlt, das eine Postmortem-Analyse zu nennen. Eine vollständige Postmortem-Analyse müsste Details auf dem oben beschriebenen Niveau enthalten.
Welche Dienste fallen genau aus, wenn das Logging ausfällt? Wurde das unbeabsichtigt so gebaut? Warum hat es niemand bemerkt?
Es ist gut, dass Cloudflares Postmortem so gründlich ist
Die ehrliche und transparente Erklärung wirkt im Vergleich zu den vagen Kommunikationsstrategien fast aller anderen Unternehmen erfrischend
Auch wir waren betroffen, aber gerade wegen solcher Texte möchte man eher nicht weggehen. Jeder macht Fehler und kann einen schlechten Tag haben; den Unterschied macht, wie man danach reagiert
Ein Absatz zum Stromausfall hätte gereicht, danach hätte der Fokus auf Cloudflare wechseln müssen. Ausfälle von Rechenzentren können passieren
Die eigentliche Lehre liegt in der Reaktion von Cloudflare, die diese Situation nicht richtig berücksichtigt und sich nicht davon erholt hat
Wir sind stark auf CloudFlare Images angewiesen, und in den letzten 30 Tagen war es über 67 Stunden ausgefallen
Am 9. Oktober 22 Stunden, vom 2. bis 4. November 42 Stunden, dazwischen immer wieder Ausfälle von etwa einer Stunde; die Verfügbarkeit im letzten Monat lag bei 90,6 %
Transparenz ist ein großartiges Unterscheidungsmerkmal unter Anbietern, die im Bereich von 99,9 % Verfügbarkeit konkurrieren, aber wenn man kaum über eine einzige Neun hinauskommt, bedeutet sie nicht viel
Es hilft nicht wesentlich dabei, das Verhalten zu verbessern, und kann die Anreize sogar verschlechtern
Ich schätze, dass sie die Prozessfehler hier beheben wollen. Allerdings gibt es eine Spannung zwischen schnellem Handeln und sicherem Vorgehen
Üblicherweise wird so etwas wie Wetter behandelt: Man kauft sich einen Regenmantel, nachdem man nass geworden ist
Ich frage mich, wie man Zuverlässigkeit zu einem Teil der Kultur macht, ohne dass Entwicklung durch Prozesse gefesselt wird
Man könnte Systeme per Software modellieren und dieses Modell per Traffic-Analyse validieren. Wenn virtuelle Experimente die Kosten von Zuverlässigkeitsexperimenten senken können, ließe sich vor dem Release vielleicht mehr abfangen
Es ist seltsam, dass mein Vertrauen in Cloudflare nach dem Lesen dieses Textes eher gesunken ist
Sie gehen Flexential hart dafür an, unprofessionell gehandelt zu haben, und das kann durchaus so gewesen sein
Aber die Tatsache, dass das gesamte System, auf das Menschen angewiesen sind, ausgefallen ist, ist auf Cloudflares Seite ein massiver Redundanzfehler. Ein einzelnes Rechenzentrum dieser Art sollte ausfallen können, ohne dass der Dienst ausfällt
Besonders beunruhigend ist, dass das beabsichtigte Design mit „Cloudflares Control Plane und Analysesysteme laufen hauptsächlich auf Servern in drei Rechenzentren nahe Hillsboro, Oregon“ beginnt
Für eine Control Plane, die Menschen weltweit nutzen, braucht es eine viel breitere geografische Verteilung. Noch erstaunlicher ist, dass dies kein fehlerhaftes Implementierungsdetail war, sondern bereits Teil des beabsichtigten Designs
Wenn man ein neues Produkt für Verbraucher herausbringt, sollte Redundanzdesign dann nicht oberste Priorität haben? Dass es offenbar optional war, überrascht mich
Ich nutze Cloudflare ebenfalls für einige Systeme, weil ich davon ausging, dass es bei solchen Vorfällen ein gutes Failover geben würde. Jetzt denke ich erneut darüber nach, ob Cloudflare Workers vor solchen Designentscheidungen wirklich sicher ist
Dass beim Einschalten der Disaster-Recovery-Site zuvor fehlgeschlagene API-Aufrufe hereinströmten und den Dienst überlasteten, sehe ich ebenfalls als Folge davon, dass Cloudflares Kerndesign nicht ausreichend redundant war
Ich bin enttäuscht von diesem Versuch, die Verantwortung auf Flexential zu schieben. Als Kunde erwarte ich, dass Cloudflare elegant damit umgeht, selbst wenn Flexential morgen durch ein Erdbeben verschwindet
Ist es eine gute Idee, einen so wichtigen Cluster vollständig in ein bekanntes Erdbeben- und Tsunamirisikogebiet zu stellen?
Auch die Disaster Recovery in Europa scheint nicht richtig funktioniert zu haben
„Wir hatten nie getestet, die gesamte PDX-04-Anlage vollständig offline zu nehmen“ ist eine schmerzhafte Lektion
Aber wenn man nicht physisch den Strom im Rechenzentrum abschaltet oder zumindest die Netzwerkverbindung zur Außenwelt kappt, hat man keine echte Katastrophe getestet
Man kann dem Betreiber der Anlage die Schuld geben, aber letztlich muss man sich davon erholen können, dass ein Rechenzentrum komplett offline geht und nie wieder zurückkommt
Eine Naturkatastrophe könnte diese Anlage von der Erde tilgen
Gut fand ich den Abschnitt: „Da das Team den ganzen Tag über vollständig in die Notfallreaktion eingebunden war, beschlossen wir, dass die meisten sich ausruhen und am Morgen mit der Rückverlagerung nach PDX-04 beginnen sollten. Diese Entscheidung verzögerte die vollständige Wiederherstellung, aber wir glauben, dass sie die Wahrscheinlichkeit zusätzlicher Fehler verringerte“
Menschliche Ermüdung wird in solchen Berichten oft unterschätzt. Wenn man versucht, einen großen Ausfall in völlig übermüdetem Zustand zu beheben, erzeugt man nur mehr vermeidbare Fehler
Ich weiß nicht, wie das in einer Organisation von Cloudflares Größe funktioniert, aber auch wir haben für große Ausfälle einen Plan, nach dem Mitarbeitende in Schichten arbeiten und schlafen
Das Problem ist, dass man eine Möglichkeit braucht, den aktuellen Störungszustand an neue Personen zu übergeben, die aufwachen oder sich einloggen
Wie Mike Tyson sagte: Jeder hat einen Plan, bis er einen Schlag ins Gesicht bekommt
Die Struktur des Textes ist ziemlich erstaunlich. 75 % des Blogs handeln von einem Dritten, während Cloudflares eigene Wiederherstellungsbemühungen in deutlich weniger Absätzen behandelt werden
Positiv ist, dass sie einen Weg nach vorn aufzeigen, aber ich frage mich, warum sie jetzt nicht einfach die Fehler und die Situation anerkannt und später, wenn sich der Staub gelegt hat, ein vollständiges Postmortem ohne Spekulationen veröffentlicht haben
Investoren lesen nur diesen Text oder eine Zusammenfassung und können es als simples Anbieterproblem abtun, statt als tiefgreifendes Problem, das Monate an Nacharbeit und Kosten in Millionenhöhe erfordert
Das Dokument ist nicht gut
Es gab eine Hochverfügbarkeitskonfiguration aus drei Rechenzentren, und sie ist vollständig gescheitert
Warum füllt man den Anfang des Dokuments damit, dem Rechenzentrumsbetreiber die Schuld zu geben? Das Management der Rechenzentrumsanlage liegt außerhalb von Cloudflares Kontrolle
Cloudflare hat darauf gewettet, dass es schon gutgehen würde, obwohl sie die Tests der Hochverfügbarkeitskonfiguration, die sie kontrollieren können, nicht ordentlich durchgeführt haben
Betriebsprobleme im Rechenzentrum muss man mit dem Betreiber besprechen, aber das ist eine Angelegenheit zwischen beiden Seiten und gehört nicht in dieses Postmortem
Der wirklich wichtige Teil wurde ziemlich tief vergraben. Man muss eine ganze Weile scrollen, bis dieser Satz kommt:
„Einige Dienste, die eigentlich in einem Hochverfügbarkeits-Cluster hätten laufen sollen, waren von Diensten abhängig, die nur in PDX-04 liefen.“
Genau das ist der Kern.
Wenn man eine „Disaster“-Site aufbaut, muss man wohl irgendwie einen Weg finden, sie zu testen.
Als die Dienste wieder hochkamen, entstand ein Thundering-Herd-Problem, bei dem zuvor fehlgeschlagene API-Aufrufe massenhaft eintrafen; um die Anfragemenge zu kontrollieren, habe man Rate Limiting implementiert.
Dieser Punkt scheint in den Aufzählungen am Ende des Artikels aber zu fehlen.
Was mich jetzt interessiert: Wie entwirft man ein kaltes Failover, wenn das System so komplex ist, dass es metastabile Ausfälle[1] verursachen kann, und man keinen Spielraum hat, es mit echtem Traffic zu testen?
Ich kann mir vorstellen, welche Techniken man für die Implementierung nutzt, aber das Problem ist das Design und die Tests, mit denen man verifiziert, dass diese Techniken in der realen Situation funktionieren.
Ein weiterer Punkt, der offenbar völlig fehlt: Der Ausfall begann am 2. November um 11:43 UTC, aber die Entscheidung, auf die europäische Disaster-Recovery-Site umzuschalten, fiel erst um 13:40 UTC.
Warum hat diese Entscheidung so lange gedauert? Ich verstehe, dass das keine Entscheidung ist, die man leichtfertig trifft, aber selbst wenn man die meiste Zeit erwartete, dass die Stromversorgung gleich wiederhergestellt würde, wirken 2 Stunden wie zu langes Zögern.
Es muss einen vorab festgelegten Schwellenwert geben, ab dem man den Schalter umlegt, ganz gleich, welche Zusagen es gibt. Lag dieser Schwellenwert wirklich so weit entfernt?
[1] http://charap.co/metastable-failures-in-distributed-systems/
Oft sind es gerade die redundanten Systeme selbst, die den Ausfall verursachen.