Post-Mortem-Analyse zum Ausfall der Steuerungsebene und Analysedienste von Cloudflare

Am Donnerstag, den 2. November 2023 um 12:43 Uhr MEZ (alle folgenden Zeitangaben verstehen sich ebenfalls MEZ) kam es zu einem Ausfall der Steuerungsebene und der Analysedienste von Cloudflare. Die Steuerungsebene besteht hauptsächlich aus der für Kunden zugänglichen Schnittstelle für alle unsere Dienste, einschließlich unserer Website und API. Unsere Analysedienste umfassen die Protokollierung und die Erstellung von Analyseberichten.

Die Störung dauerte vom 2. November um 12:44 Uhr bis zum 4. November um 5:25 Uhr. Am 2. November um 18:57 Uhr konnten wir den größten Teil unserer Steuerungsebene an unserem dafür bei Notfällen vorgesehenen Standort wiederherstellen. Nachdem dieser Standort online war, hatten viele Kunden keine Probleme mit den meisten unserer Produkte. Allerdings dauerte die Wiederherstellung bei anderen Diensten länger. Deshalb traten bei Kunden, die diese Services nutzen, bis zur vollständigen Bewältigung des Vorfalls teilweise zu Problemen. So waren unsere Rohdatenprotokolldienste für die meisten Kunden während des Vorfalls nicht verfügbar.

Inzwischen können diese aber von sämtlichen Kunden wieder genutzt werden. Die Netzwerk- und Sicherheitsdienste von Cloudflare haben während des Zwischenfalls weiter wie erwartet funktioniert. Zwischenzeitlich konnten Kunden zwar keine Änderungen an ihren Einstellungen für diese Services vornehmen, doch der über unser Netzwerk laufende Traffic wurde nicht beeinträchtigt.

In diesem Blogbeitrag werden die Ereignisse beschrieben, die zu diesem Vorfall geführt haben. Außerdem gehen wir auf die zur Unterbindung vergleichbarer Probleme geschaffene Architektur ein und wir schauen uns an, was nicht funktioniert hat und warum. Zuletzt stellen wir noch die Änderungen vor, die wir auf Grundlage unserer Erkenntnisse der letzten 36 Stunden vornehmen werden.

Zunächst einmal hätte es niemals zum diesem Vorfall kommen dürfen. Wir waren davon überzeugt, dass unsere Systeme hochverfügbar sind und einen Ausfall wie diesen selbst bei einem katastrophalen Versagen eines unserer wichtigsten Rechenzentrumsanbieter verhindern können. Tatsächlich sind auch viele Systeme wie geplant online geblieben, doch bei einigen kritischen Systemen bestanden Abhängigkeiten, die nicht offenkundig waren und ihre Nichtverfügbarkeit zur Folge hatten. Diesen Vorfall und die Probleme, die er unseren Kunden und unseren Mitarbeitenden bereitet hat, bedauere ich sehr.

Die Steuerungsebene und Analysesysteme von Cloudflare laufen hauptsächlich auf Servern in drei Rechenzentren in Hillsboro im US-Bundesstaat Oregon. Diese Rechenzentren sind unabhängig voneinander und verfügen jeweils über mehrere Stromversorgungen sowie mehrere redundante und separate Netzwerkverbindungen.

Es wurden bewusst Standorte gewählt, die weit voneinander entfernt sind. So sollte möglichst ausgeschlossen werden, dass eine einzige Naturkatastrophe alle drei Rechenzentren in Mitleidenschaft zieht. Gleichzeitig liegen sie aber noch nahe genug beieinander, um redundante Aktiv/Aktiv-Cluster zu betreiben. Das bedeutet, dass die Daten zwischen den drei Standorten kontinuierlich synchronisiert werden. Fällt einer aus, kann der Betrieb mit den verbleibenden Rechenzentren aufrechterhalten werden.

Wir haben diesen Systemaufbau bereits vor vier Jahren eingeführt. Die meisten für unsere Steuerungsebene kritischen Systeme waren auf den hochverfügbaren Cluster verlagert worden. Doch manche Dienste, insbesondere für einige neuere Produkte, waren noch nicht dort angesiedelt.

Darüber hinaus hatten wir uns bewusst dafür entschieden, unsere Protokollsysteme nicht dort zu platzieren. Unsere Überlegung war dabei, dass beim Protokollieren ohnehin bereits eine Verteilung erfolgt, da die Protokolle an der Edge unseres Netzwerks in eine Warteschlange eingegliedert und dann an das Kernrechenzentrum in Oregon (oder einen anderen regionalen Standort für Kunden, die zur Protokollerstellung regionale Dienste nutzen) zurückgeschickt werden. Sollte unser Protokollstandort offline sein, ist vorgesehen, dass die Analyseprotokolle an unserer Netzwerk-Edge in der Warteschlange verbleiben, bis er wieder über das Internet erreichbar ist. Eine Verzögerung bei den Analysen haben wir damit in Kauf genommen.

Der größte der drei Standorte in Oregon wird von der Firma Flexential betrieben. Wir nennen diese Einrichtung „PDX-DC04“ (im restlichen Text als „PDX-04“ bezeichnet). Cloudflare mietet Platz im PDX-04, wo wir unseren größten Analysecluster sowie mehr als ein Drittel der Rechner für unseren hochverfügbaren Cluster unterbringen. Es ist auch der Standardstandort für Dienste, die noch nicht in unseren hochverfügbaren Cluster integriert wurden. Wir sind ein relativ großer Kunde dieses Anbieters und beanspruchen etwa 10 % der Gesamtkapazität des Rechenzentrums.

Am 2. November um 9:50 Uhr führte der Stromversorger Portland General Electric (PGE), von dem PDX-04 abhängt, eine ungeplante Wartung durch. Diese betraf eine der Stromzuführungen des Gebäudes. Dadurch fiel eine Stromzufuhr von PDX-04 aus. Allerdings wird das Rechenzentrum über mehrere unabhängige Stromzuführungen versorgt. Flexential schaltete jedoch die eigenen Generatoren ein, um den Ausfall zu kompensieren.

Anders als eigentlich empfohlen wurde Cloudflare von der Firma Cloudflare nicht darüber informiert, dass Generatoren die Stromversorgung ausfallbedingt übernommen hatten. Für keines unserer Beobachtungs-Tools war ersichtlich, dass sich die Stromquelle geändert hatte. Wären wir darüber informiert worden, hätten wir für die Zeit der Beeinträchtigung ein Team zur genauen Überwachung des Standorts und zur Verlagerung der von diesem abhängigen Dienste der Steuerungsebene abgestellt.

Es ist auch ungewöhnlich, dass Flexential die verbleibende Stromzufuhr weiter nutzte und zugleich auf Generatoren zurückgriff. Durchaus üblich ist, dass die Stromversorger Rechenzentren bei allgemein hohem Strombedarf auffordern, vom Netz zu gehen und ausschließlich mit Generatoren zu arbeiten. Flexential verfügt über zehn Generatoren, einschließlich redundanter Einheiten, die den Strombedarf des Standorts bei Volllast decken können. Es wäre für Flexential aber auch möglich gewesen, das Rechenzentrum ausschließlich über die verbleibende Stromzufuhr zu betreiben. Die Entscheidung für die Doppelvariante bei der Stromversorgung wurde uns gegenüber bislang nicht eindeutig begründet.

Seit dieser Entscheidung hat sich Flexential uns gegenüber noch nicht klar zu den Ursachen, einigen der von dem Unternehmen gefällten Entscheidungen oder dem Ablauf der Ereignisse geäußert. Wir aktualisieren diesen Beitrag entsprechend, sobald wir weitere Informationen von Flexential und PGE erhalten. Bei Einigem von dem, was nun folgt, handelt es sich um wohl begründete Spekulationen. Diese stützen sich auf die wahrscheinlichste Abfolge der Ereignisse und dem, was uns von einzelnen Flexential-Mitarbeitenden inoffiziell mitgeteilt wurde.

Ein Grund dafür, dass die externe Stromzuführung weiter genutzt wurde, könnte in der Teilnahme von Flexential an einem Programm mit PGE namens DSG bestehen. Dieses ermöglicht es dem örtlichen Energieversorger, die Generatoren eines Rechenzentrums zu nutzen, um zusätzliche Elektrizität ins Netz einzuspeisen. Im Gegenzug beteiligt er sich an der Wartung der Generatoren und außerdem liefert er Treibstoff. Wir haben keine Aufzeichnungen finden können, die belegen würden, dass wir von Flexential über das DSG-Programm informiert wurden. Auf unsere Rückfrage, ob es zum Zeitpunkt des Vorfalls lief, haben wir bisher keine Antwort erhalten. Wir wissen also nicht, ob das Programm bei den Entscheidungen von Flexential eine Rolle gespielt hat, es wäre aber eine mögliche Erklärung dafür, dass die externe Stromzufuhr nach dem Einschalten der Generatoren aufrechterhalten wurde.

Um ca. 12:40 Uhr kam es zu einem Erdschluss an einem PGE-Transformator von PDX-04. Wir gehen davon aus, dass dieser Transformator den Netzstrom für die zweite Stromzufuhr unterbrochen hat, die bis zu diesem Zeitpunkt noch funktioniert hatte. Dies wurde uns bislang allerdings weder von Flexential noch von PGE bestätigt. Es ist aber wahrscheinlich, dass der Erdschluss durch die ungeplanten Wartungsarbeiten von PGE verursacht wurde, die die Versorgung über die erste Stromzuleitung beeinträchtigt haben. Möglich ist natürlich auch, dass es sich um einen ausgesprochen unglücklichen Zufall handelte.

Erdschlüsse bei Leitungen mit 12.470 Volt sind sehr gefährlich. Elektrische Systeme sind so konstruiert, dass sie sich zur Schadensvermeidung schnell abschalten, wenn ein solcher Fehler auftritt. Leider wurden in diesem Fall alle Generatoren von PDX-04 abgeschaltet. Somit waren beide Stromquellen des Standorts – sowohl die redundanten externen Stromzuführungen als auch die zehn Generatoren – nicht mehr verfügbar.

Glücklicherweise verfügt PDX-04 neben den Generatoren auch über eine Reihe von USV-Anlagen. Diese reichen angeblich aus, um den Standort für etwa zehn Minuten mit Strom zu versorgen. Das sollte eigentlich genügen, um die Zeit zwischen dem Stromausfall und dem automatischen Start der Generatoren zu überbrücken. Somit könnte eine Unterbrechung vermieden werden, wenn es Flexential gelingt, die Generatoren oder die Stromzufuhr innerhalb von zehn Minuten wiederherzustellen. Doch wie wir anhand der Ausfälle unserer eigenen Ausrüstung nachvollziehen konnten, haben die USV-Anlagen tatsächlich bereits nach vier Minuten begonnen, den Dienst zu versagen. Zudem brauchte Flexential deutlich länger als zehn Minuten, um die Generatoren wieder zum Laufen zu bringen.

Eine offizielle Bestätigung ist zwar ausgeblieben, aber von Mitarbeitenden wurde uns gesagt, dass die Wiederinbetriebnahme der Generatoren durch drei Dinge erschwert wurde. Erstens mussten sie aufgrund der Art und Weise, wie der Erdschluss die Stromkreise ausgelöst hatte, physisch zugänglich gemacht und manuell wieder in Betrieb genommen werden. Zweitens wurde das Zugangskontrollsystem von Flexential nicht von den USV-Anlagen versorgt, sodass es ausfiel. Und drittens war in der Nacht kein erfahrener Betriebs- oder Elektrofachmann vor Ort – die Nachtschicht bestand aus Sicherheitskräften und einem einzelnen Techniker, der diese Stelle erst vor einer Woche angetreten hatte.

Zwischen 12:44 Uhr und 13:01 Uhr, als die Generatoren noch nicht vollständig wieder hochgefahren worden waren, ging den USV-Anlagen der Strom aus. Damit brach die Stromversorgung für alle Kunden des Rechenzentrums zusammen. In dieser Zeit hat Flexential Cloudflare nicht über die Probleme an dem Standort in Kenntnis gesetzt. Dass etwas nicht in Ordnung ist, haben wir erstmals bemerkt, als die beiden Router, die den Standort mit dem Rest der Welt verbinden, um 12:44 Uhr offline gegangen sind. Weil die Router weder direkt noch über Out-of-Band-Management erreichbar waren, haben wir versucht, Flexential zu kontaktieren, und unser Team vor Ort zu dem Standort geschickt. Die erste Mitteilung von Flexential, dass ein Problem besteht, kam um 13:28 Uhr.

Wir verzeichnen seit etwa 13:00 Uhr ein Problem mit der Stromversorgung an unserem Standort [PDX-04]. Unsere Techniker arbeiten daran, es zu beheben und den Betrieb wiederherzustellen. Wir werden Sie alle 30 Minuten über den Fortschritt der Arbeiten informieren bzw. sie darüber in Kenntnis setzen, sobald wir Näheres darüber wissen, wie viel Zeit die Wiederherstellung voraussichtlich in Anspruch nehmen wird. Vielen Dank für Ihre Geduld und Ihr Verständnis.

Obwohl die Konstruktion des PDX-04 vor dem Bau eine „Tier III“-Zertifizierung erhalten hat und die Anlage laut SLA eine hohe Verfügbarkeit bieten soll, hatten wir Pläne für einen Ausfall entwickelt. Schließlich kann auch an gut geführten Standorten einmal etwas schiefgehen. Und dafür hatten wir vorgesorgt. Wir sind davon ausgegangen, dass in diesem Fall unsere Analysedienste nicht mehr erreichbar sein werden, Protokolle an der Edge in eine Warteschlange eingereiht und verzögert werden und bestimmte Services mit geringerer Priorität, die nicht in unseren hochverfügbaren Cluster integriert sind, vorübergehend nicht mehr funktionieren, bis sie an einem anderen Standort wiederhergestellt werden können.

Unsere Annahme war, dass die beiden anderen Rechenzentren in der Region in einem solchen Fall die Verantwortung für den hochverfügbaren Cluster übernehmen und dafür sorgen, dass kritische Dienste weiter nutzbar sind. Im Prinzip hat das auch funktioniert. Doch leider hat sich herausgestellt, dass eine Untergruppe von Diensten, die auf dem hochverfügbaren Cluster laufen sollten, von ausschließlich bei PDX-04 betriebenen Services abhingen.

Insbesondere zwei kritische Dienste, die Protokolle verarbeiten und unsere Analysefunktionen unterstützen – Kafka und ClickHouse – waren nur über PDX-04 verfügbar, hatten aber ihrerseits Services, die von ihnen abhingen und im hochverfügbaren Cluster angesiedelt waren. Diese Abhängigkeiten hätten nicht so eng sein dürfen, es hätte eine elegantere Lösung für damit verbundene Ausfälle existieren müssen und wir hätten sie erkennen müssen.

Wir hatten unseren hochverfügbaren Cluster getestet, indem wir die zwei verbleibenden Rechenzentren einzeln und gemeinsam vollständig außer Betrieb genommen hatten. Außerdem hatten wir erprobt, den hochverfügbaren Teil von PDX-04 vom Netz zu nehmen. Nicht getestet hatten wir jedoch die vollständige Abschaltung des gesamten PDX-04-Standorts. Aus diesem Grund hatten wir die Bedeutung einiger dieser Abhängigkeiten auf unserer Datenebene nicht erkannt.

Wir waren auch viel zu lax, was die Integration neuer Produkte und der dazugehörigen Datenbanken in den hochverfügbaren Cluster angeht. Cloudflare ermöglicht es zahlreichen Teams, Innovationen schnell zu entwickeln. Daher ist der Weg zur ersten Alpha-Version unserer Produkte nicht immer der gleiche. Bei uns hat es sich eingebürgert, für das Backend dieser Services unsere Best Practices schrittweise einzuführen. Doch bisher war dies keine Grundvoraussetzung für die Einstufung dieser Produkte als „allgemein verfügbar“. Das war ein Fehler, weil deshalb die von uns eingeführten redundanzbasierten Schutzmaßnahmen bei den einzelnen Produkten unterschiedlich gut funktionieren.

Außerdem hängen viel zu viele unserer Dienste von der Verfügbarkeit unserer Kernstandorte ab. Zwar werden viele Softwaredienste auf diese Weise geschaffen, aber es kommt der Stärke von Cloudflare nicht entgegen. Diese liegt bei dezentralen Systemen. Unser weltumspannendes Netzwerk hat während des Vorfalls weiterhin wie erwartet funktioniert. Einige unserer Produkte und Funktionen können über die Edge unseres Netzwerks konfiguriert und gewartet werden, ohne auf die Kernstandorte zurückzugreifen. Doch aktuell fallen noch zu viele dieser Dienste aus, wenn die Hauptrechenzentren nicht verfügbar sind. Wir müssen die auf dezentrale Systeme bezogenen Produkte, die wir allen unseren Kunden zur Verfügung stellen, für unsere gesamten Dienste nutzen, damit diese auch bei einer Störung unserer Kernstandorte weitgehend normal funktionieren.

Um 13:48 Uhr gelang es Flexential, die Generatoren wieder in Gang zu setzen. Damit wurde die Stromversorgung des Standorts teilweise wiederhergestellt. Um das System nicht zu überlasten, wird bei der Wiederherstellung der Stromversorgung eines Rechenzentrums in der Regel schrittweise vorgegangen und ein Stromkreis nach dem anderen wieder in Betrieb genommen. Wie bei Privathaushalten existieren auch für jeden Kunden redundante Leistungsschutzschalter. Als Flexential versucht hat, die Stromkreise von Cloudflare wieder in Betrieb zu nehmen, stellte man fest, dass diese Sicherungen defekt waren. Wir wissen nicht, ob die Leistungsschutzschalter durch den Erdschluss oder eine andere Überspannung infolge des Vorfalls beschädigt wurden oder ob sie schon vorher defekt waren und dies erst nach dem Ausschalten bemerkt wurde.

Flexential hat dann mit dem Austausch der defekten Sicherungen begonnen. Dazu mussten neue Leistungsschutzschalter beschafft werden, weil eine größere Zahl defekt war, als vor Ort vorrätig war. Da mehr Dienste ausgefallen waren als erwartet und Flexential uns keinen Zeitpunkt für die Wiederherstellung unserer Services nennen konnte, entschieden wir uns um 14:40 Uhr für ein Failover zu den europäischen Disaster Recovery-Standorten von Cloudflare. Glücklicherweise musste dieser Wechsel nur für einen kleinen Teil der gesamten Steuerungsebene von Cloudflare vorgenommen werden. Die meisten unserer Dienste wurden weiterhin über unsere hochverfügbaren Systeme in den beiden aktiven Kernrechenzentren betrieben.

Die ersten Dienste am Disaster-Recovery-Standort wurden um 14:43 Uhr in Betrieb genommen. Die Disaster Recovery-Standorte von Cloudflare stellen im Notfall kritische Services für die Steuerungsebene bereit. Sie unterstützen zwar einige unserer Protokollverarbeitungsdienste nicht, dafür aber die anderen Teile unserer Steuerungsebene.

Als die Services dort hochgefahren wurden, sorgte die Flut der zuvor fehlgeschlagenen API-Aufrufe dafür, dass sie unter der Last gleich wieder zusammenbrachen. Um das Anfragevolumen in den Griff zu bekommen, haben wir Durchsatzbegrenzungen eingeführt. Während dieser Zeit traten bei den meisten Produkten zeitweise Fehler auf, wenn über unser Dashboard oder unsere API Änderungen an den Einstellungen vorgenommen wurden. Um 18:57 Uhr waren die Services, die erfolgreich auf den Disaster Recovery-Standort verlagert worden waren, stabil und die meisten Kunden waren nicht mehr direkt betroffen. Einige Systeme (z. B. Magic WAN) mussten jedoch noch manuell konfiguriert werden. Ein paar andere Dienste, die vor allem mit der Protokollverarbeitung und einigen maßgeschneiderten API in Zusammenhang standen, waren erst wieder verfügbar, als wir den Betrieb bei PDX-04 wiederherstellen konnten.

Eine Handvoll Produkte wurde bei unseren Disaster Recovery-Standorten nicht richtig hochgefahren. Dabei handelte es sich in der Regel um neuere Lösungen, für die wir noch kein vollständiges Notfallwiederherstellungsverfahren implementiert und getestet hatten. Unter anderem gehörte dazu unser Stream-Dienst zum Hochladen neuer Videos. Unser Team musste zur Wiederherstellung dieser Services gleichzeitig an zwei Aufgaben erfüllen: 1. Ihre Neuimplementierung bei unseren Disaster Recovery-Standorten. 2. Ihre Migration zu unserem hochverfügbaren Cluster.

Flexential hat unterdessen die ausgefallenen Leistungsschutzschalter ausgetauscht, beide Stromzuführungen wiederhergestellt und um 23:48 Uhr bestätigt, dass die Stromversorgung nun wieder einwandfrei funktioniert. Nachdem unser Team den ganzen Tag mit dem Notfall zu tun hatte, habe ich entschieden, dass die meisten von uns sich ausruhen und am Folgetag mit dem Rückumzug zu PDX-04 beginnen sollten. Dadurch verzögerte sich die vollständige Wiederherstellung unseres Normalbetriebs. Doch meiner Einschätzung nach hat sich auf diese Weise die Wahrscheinlichkeit verringert, die Situation durch weitere Fehler noch zu verschlimmern.

Gleich am Morgen des 3. November hat unser Team dann damit begonnen, bei PDX-04 den Betrieb wiederherzustellen. Dies umfasste zunächst das physische Booten unserer Netzwerkausrüstung, das Hochfahren tausender Server und die Wiederherstellung ihres Betriebs. Der Zustand unserer Services im Rechenzentrum war unbekannt, da wir davon ausgingen, dass es während des Vorfalls zu mehreren Stromausfällen gekommen sein dürfte. Das einzige sichere Verfahren zur Wiederherstellung, das uns offenstand, war das vollständige Bootstrapping des gesamten Standorts.

Das beinhaltete einen manuellen Prozess, bei dem unsere Konfigurationsmanagement-Server online gebracht wurden, um mit der Wiederherstellung des Betriebs bei dem Standort zu beginnen. Dieser Prozess nahm drei Stunden in Anspruch. Dann konnte unser Team das Bootstrapping der übrigen Server, auf denen unsere Dienste laufen, in Angriff nehmen. Die Wiederinbetriebnahme erforderte pro Server zwischen zehn Minuten und zwei Stunden. Wir waren zwar in der Lage, diesen Vorgang parallel für mehrere Server durchzuführen, doch aufgrund bestehender Abhängigkeiten zwischen Diensten mussten einige Server nacheinander wieder online gebracht werden.

Seit dem 4. November 2023 um 5:25 Uhr sind alle Services nun vollständig wiederhergestellt. Da wir auch Analysen in unseren europäischen Kerndatenzentren speichern, dürften die meisten Kunden bei der überwiegenden Zahl der Analysen in unserem Dashboard und unseren API keine Datenverluste verzeichnet haben. Im Fall einiger Datensätze, die nicht in der Europäischen Union repliziert werden, wird es allerdings dauerhafte Lücken geben. Bei Kunden, die unsere Log-Push-Funktion nutzen, wurden die Protokolle während eines Großteils des Ereignisses nicht verarbeitet. Somit kann das, was sie nicht erhalten haben, auch nicht wiederhergestellt werden.

Wir erwarten von Flexential eine Antwort auf eine Reihe von Fragen. Doch grundsätzlich müssen wir damit rechnen, dass ganze Rechenzentren ausfallen. Google wendet ein Verfahren an, bei dem im Falle eines schwerwiegenden Vorfalls oder einer Krise ein „Code Yellow“ oder „Code Red“ ausgerufen werden kann. Dann werden die meisten oder alle technischen Ressourcen auf die Lösung des jeweiligen Problems verwendet.

Wir verfügen bislang nicht über einen solchen Prozess. Doch jetzt ist klar, dass wir eine Version davon einführen müssen: „Code Orange“. Wir verlagern alle nicht kritischen technischen Funktionen auf die Gewährleistung einer hohen Zuverlässigkeit unserer Steuerungsebene. In diesem Zusammenhang streben wir die folgenden Änderungen an:

• Abschaffung der Abhängigkeiten von unseren zentralen Rechenzentren für die Konfiguration der Steuerungsebene aller Dienste und Verlagerung dieser Services, wo immer dies möglich ist, auf unser dezentrales Netzwerk

• Sicherstellung der Funktionsfähigkeit unserer Steuerungsebene im Netzwerk selbst beim Ausfall aller unserer Kernrechenzentren

• Zwingender Rückgriff aller Produkte und Funktionen, die als allgemein verfügbar eingestuft sind, auf den hochverfügbaren Cluster (bei Rückgriff auf eines unserer Kernrechenzentren), ohne dass Software-Abhängigkeiten von bestimmten Standorten bestehen

• Zwingendes Vorhandensein eines zuverlässigen, getesteten Notfallwiederherstellungsplans für alle als allgemein verfügbar eingestuften Produkte und Funktionen

• Testen des Schadensausmaßes von Systemausfällen und Minimierung der Anzahl der von einem Ausfall betroffenen Dienste

• Implementierung strengerer Chaostests aller Rechenzentrumsfunktionen, einschließlich der vollständigen Nichtverfügbarkeit aller unserer zentralen Rechenzentrumsstandorte

• Gründliche Überprüfung aller zentralen Rechenzentren und Erstellung eines Plans zur erneuten Überprüfung, um sicherzustellen, dass sie unseren Standards entsprechen

• Erstellung eines Notfallwiederherstellungsplans für die Protokollierung und Analyse, um zu gewährleisten, dass selbst bei einem Ausfall aller unserer Kernstandorte keine Protokolle verloren gehen

Ich möchte wiederholen, dass ich diesen Vorfall und die Schwierigkeiten, die er unseren Kunden und unseren Mitarbeitenden bereitet hat, zutiefst bedauere. Wir verfügen über die richtigen Systeme und Verfahren, um selbst einer solchen Kaskade von Ausfällen, wie wir sie bei unserem Rechenzentrumsbetreiber erlebt haben, standhalten zu können. Doch wir müssen strenger darauf achten, dass diese Verfahren befolgt und die Systeme daraufhin getestet werden, ob unbekannte Abhängigkeiten bestehen. Darauf werden sowohl ich als auch ein Großteil unseres Teams den Rest des Jahres unsere volle Aufmerksamkeit richten. Und sie können sich sicher sein: Wir werden aus den schmerzlichen Erfahrungen der letzten Tage lernen.