Zusammenfassung

  • Ein Wartungsbefehl, der die verfügbare Kapazität des globalen Backbones bewerten sollte, nahm das gesamte Backbone von Meta Platforms außer Betrieb; nach Darstellung des Unternehmens erklärten sich die Standorte danach für ungesund und zogen ihre BGP-Ankündigungen zurück, sodass die Namensserver unerreichbar blieben, obwohl sie weiterliefen.
  • Eine externe Messung datiert den Beginn der Störung auf etwa 15:40 UTC, den Rückzug der Routen zu den DNS-Präfixen auf 15:58 UTC und die wiederaufgenommene Routing-Aktivität auf etwa 21:00 UTC mit Spitze um 21:17 UTC.
  • Der bleibende Befund ist strukturell: Ein Betreiber, dessen Wiederherstellungspfad durch dieselbe Routing- und Namensebene läuft, die er wiederherstellen muss, kann seinen eigenen Ausfall weder beobachten noch rückgängig machen. Ungeprüft ist nicht die ursprüngliche Fehlkonfiguration, sondern die Dauerhaftigkeit der Reparatur.

Was der Betreiber über den Ablauf sagte

Meta Platforms veröffentlichte seine Darstellung am Tag nach dem Vorfall auf der eigenen Engineering-Seite (Engineering at Meta). Die entscheidende Passage ist kurz und in der Abfolge ungewöhnlich präzise:

During one of these routine maintenance jobs, a command was issued with the intention to assess the availability of global backbone capacity, which unintentionally took down all the connections in our backbone network, effectively disconnecting Facebook data centers globally. ... In the recent outage the entire backbone was removed from operation, making these locations declare themselves unhealthy and withdraw those BGP advertisements. The end result was that our DNS servers became unreachable even though they were still operational.

Auf Deutsch: Bei einer dieser routinemäßigen Wartungsarbeiten wurde ein Befehl mit der Absicht ausgegeben, die Verfügbarkeit globaler Backbone-Kapazität zu bewerten; er nahm unbeabsichtigt alle Verbindungen im Backbone-Netz herunter und trennte damit die Rechenzentren des Unternehmens weltweit voneinander. Beim jüngsten Ausfall wurde das gesamte Backbone außer Betrieb genommen, wodurch diese Standorte sich für ungesund erklärten und jene BGP-Ankündigungen zurückzogen. Das Ergebnis war, dass unsere DNS-Server unerreichbar wurden, obwohl sie weiterhin betriebsbereit waren.

In diesem Absatz stecken drei Stufen, und sie sollten getrennt betrachtet werden, weil jede eine andere Kontrolle verlangt.

Die erste Stufe ist der Befehl. Sein erklärter Zweck war die Bewertung verfügbarer Kapazität, also eine Messung und keine Änderung der Produktionstopologie. Ein Befehl, dessen Absicht Messung und dessen Wirkung vollständige Trennung ist, hat keinen weiten Wirkungsbereich, sondern einen unbegrenzten.

Die zweite Stufe ist automatisch. Ohne Backbone bewerteten die Standorte ihre eigene Gesundheit, fanden sich isoliert und taten, was ordentlich konfigurierte Router tun: Sie zogen ihre BGP-Ankündigungen zurück. Dieses Glied verwandelt einen internen Fehler in ein im Internet sichtbares Ereignis. Der Rückzug war keine Entscheidung im Krisenstab, sondern die getreue Ausführung einer Richtlinie. Die Unterscheidung zählt für jeden, der eine Wiederholung verhindern will, denn eine getreue Richtlinie korrigiert man nicht, indem man ihr sagt, sie solle lügen.

Man korrigiert sie, indem man entscheidet, was ein Standort noch tun darf, wenn seine Gesundheitsprüfung fehlschlägt.

Die dritte Stufe machte den Ausfall dauerhaft. Nach den Worten des Betreibers wurden die Namensserver unerreichbar, obwohl sie weiterhin betriebsbereit waren. Die Server waren nicht ausgefallen. Das Netz konnte sie nicht mehr erreichen und damit auch die Frage nicht mehr beantworten, wo irgendetwas liegt.

Die abgerufene Darstellung beschreibt zudem zwei Elemente, die hier als Selbstdarstellung des Betreibers und nicht als unabhängig beobachtete Tatsache behandelt werden: einen Fehler in einem Audit-Werkzeug, das genau diese Fehlerklasse hätte abfangen sollen, und eine zirkuläre Abhängigkeit, durch die der Verlust der Namensauflösung den Out-of-Band-Managementzugang mitnahm, sodass Ingenieure physisch zu Rechenzentren fahren mussten. Beides wird hier nicht bezweifelt. Beides beschreibt einen internen Zustand, den keine außenstehende Stelle beobachtet hat.

Was ein externer Beobachtungspunkt maß

Betreiberberichte erklären die Ursache; bei der Uhr sind sie schwächer. Für die Chronologie maßgeblich ist die unabhängige Messung, die Cloudflare am Tag des Vorfalls veröffentlichte (Cloudflare Blog) und die mit Zeitstempeln festhält, was ein großes Resolver-Netz sah:

At around 15:40 UTC we saw a peak of routing changes from Facebook. That's when the trouble began. ... At 15:58 UTC we noticed that Facebook had stopped announcing the routes to their DNS prefixes. ... At around 21:00 UTC we saw renewed BGP activity from Facebook's network which peaked at 21:17 UTC.

Auf Deutsch: Gegen 15:40 UTC sahen wir eine Spitze von Routing-Änderungen von Facebook; dort begann die Störung. Um 15:58 UTC bemerkten wir, dass Facebook aufgehört hatte, die Routen zu seinen DNS-Präfixen anzukündigen. Gegen 21:00 UTC sahen wir erneute BGP-Aktivität aus dem Netz von Facebook, die um 21:17 UTC ihren Höhepunkt erreichte.

Drei Zeitstempel und eine Kurve. Etwas begann gegen 15:40 UTC. Bis 15:58 UTC wurden die Routen zu den DNS-Präfixen des Unternehmens nicht mehr angekündigt — achtzehn Minuten, in denen Routing-Änderungen sichtbar wurden, bevor die Namensebene aus der globalen Routing-Tabelle verschwand. Gegen 21:00 UTC setzte neue Aktivität ein, mit Spitze um 21:17 UTC; die vollständige Wiederanbindung an das globale Internet war nach dieser Analyse gegen 21:28 UTC offenbar erreicht.

Diese Endpunkte erlauben eine Subtraktion, die keine der Quellen dem Leser abnimmt. Zwischen dem Rückzug der DNS-Präfixankündigungen um 15:58 UTC und der offenbar vollständigen Wiederherstellung gegen 21:28 UTC liegen rund fünfeinhalb Stunden. Diese Zahl ist die Differenz zweier berichteter Zeiten, keine unabhängig gemessene Ausfalldauer, und sie ist mit genau diesem Vorbehalt zu lesen. Sie bleibt trotzdem die konkreteste Angabe dazu, wie lange die Wiederherstellung am Rand des Internets dauerte.

Was externe Messung nicht liefern kann, zählt ebenso. Ein Beobachtungspunkt außerhalb des betroffenen Netzes sieht Ankündigungen erscheinen und verschwinden. Er sieht nicht die Change-Freigabe, nicht den Alarm, der auslöste oder ausblieb, nicht das interne Dashboard, das im selben Moment dunkel wurde wie das, was es überwachen sollte, und nicht die Abfolge der Entscheidungen, nachdem der Betreiber begriffen hatte, dass seine eigenen Werkzeuge fort waren. Cloudflare maß eine Oberfläche; der Betreiber beschrieb einen Mechanismus. Keine der beiden Unterlagen belegt den Kausalzusammenhang allein.

Belegt wird er dadurch, dass der beschriebene Mechanismus genau jene Oberfläche erzeugen würde: ein Netz, das aufhört, seine Namensserver anzukündigen, bevor diese aufhören zu funktionieren.

Für die Frage der Kontrolle ist der wichtigste Befund dieser Messung nicht die Dauer, sondern die Reihenfolge. Zwischen dem Beginn der Routing-Änderungen und dem Verschwinden der Namensebene lagen achtzehn Minuten, in denen das Netz bereits in Bewegung war. Ob in diesem Fenster ein Signal existierte, das jemand hätte sehen können, lässt sich von außen nicht beantworten. Es ist aber die einzige Spanne im gesamten Ablauf, in der eine Erkennung vor dem endgültigen Kontrollverlust möglich gewesen wäre.

Erkennung lief auf derselben Ebene wie das Erkannte

Der stärkste Satz in der Darstellung des Betreibers ist beiläufig formuliert: Die Namensserver wurden unerreichbar, obwohl sie weiterhin betriebsbereit waren. Darin steckt die eigentliche Kontrollfrage dieses Vorfalls, und sie ist von der Ursache zu trennen.

Ein Betreiber, dessen Reaktionsweg über dieselbe Routing- und Namensebene läuft, auf die er reagieren muss, kann einen Ausfall dieser Ebene weder beobachten noch beheben. Das ist keine Frage der Einsatzbereitschaft und keine der Kompetenz. Es ist eine Frage der Topologie: Wenn das Werkzeug, mit dem man nachsieht, hinter dem liegt, was man nicht mehr sieht, dann ist die Erkennung nicht langsam, sondern blind. Die Länge dieser Blindphase wird dann nicht von der Reaktionsfähigkeit des Bereitschaftsdienstes bestimmt, sondern von der Zeit, die ein Mensch braucht, um an einen Ort zu kommen.

Nach der Darstellung des Betreibers war genau das der Fall: Der Verlust der Namensauflösung erzeugte eine zirkuläre Abhängigkeit, die den Out-of-Band-Managementzugang mitnahm, sodass Ingenieure physisch zu Rechenzentren gelangen mussten, um Router neu zu konfigurieren. Diese Schilderung ist die des Betreibers über seinen eigenen internen Zustand; keine außenstehende Stelle hat die Eingriffe in den Gebäuden beobachtet.

Als Beschreibung eines Kontrollversagens ist sie dennoch schlüssig, weil sie zu der von außen gemessenen Abfolge passt: achtzehn Minuten zwischen beginnender Routing-Unruhe und dem Verschwinden der Namensebene, danach mehr als fünf Stunden bis zur vollständigen Wiederanbindung.

Für Betreiber, die daraus etwas mitnehmen wollen, ist die praktische Lehre unbequem und billig zugleich. Sie lautet nicht, mehr zu überwachen. Sie lautet, den Beobachtungs- und Steuerungspfad so zu bauen, dass er nicht durch denselben Fehler ausfällt wie das Beobachtete — also Zugang, der funktioniert, während die eigenen Ankündigungen zurückgezogen sind, und ein Signal, das von außerhalb des eigenen Netzes kommt. Der zweite Teil ist der wichtigere, weil er sich nicht selbst bescheinigen lässt.

Die Last trugen Dritte

Der Ausfall blieb nicht beim Betreiber. Anwendungen, die sich über die Plattform authentifizieren, Händler, deren Kassensysteme davon abhängen, und Resolver, deren Abfragelast während des Wiederholungssturms anstieg, trugen die Wirkung mit. Cloudflare berichtet für die Dauer der Störung einen Anstieg des globalen DNS-Abfrageaufkommens, weil Anwendungen und Nutzer gegen Namensserver wiederholten, die nicht erreichbar waren.

Das ist der unangenehme Teil jeder Abhängigkeit: Im Normalbetrieb ist sie unsichtbar. Ein Unternehmen, das seine Ausfallsicherheit als Eigenschaft der eigenen Systeme begreift, hat in Wahrheit eine Eigenschaft eingekauft, die es nicht kontrolliert und häufig nicht einmal dokumentiert hat. Die daraus folgende Frage ist keine technische, sondern eine der Beschaffung: Wer im eigenen Haus weiß, welche Prozesse aufhören zu funktionieren, wenn ein Dritter seinen Namen nicht mehr auflösen kann?

Die Fachpresse hat den Vorfall überwiegend über BGP erzählt. TechTarget etwa behandelte BGP als frühen Verdacht und den Ausfall als einen der größten in der Geschichte des Unternehmens (TechTarget). Als Beschreibung der Rezeption ist das zutreffend und als Beleg wenig wert: Der Text ist Kommentar, keine Messung, und liefert weder Routing-Daten noch Architekturdetails aus erster Hand.

Der Verzeichniseintrag zu Meta Platforms bündelt die frühere Berichterstattung über den Konzern und ist der Ort, an dem diese Analyse fortgeschrieben wird (Meta Platforms im Verzeichnis).

Ein falscher Befehl und ein falscher Prüfschritt sind zwei verschiedene Fehler

Es liegt nahe, diesen Vorfall als einen Ausfall mit einer Ursache zu behandeln. Die Aufzeichnung stützt mindestens zwei Fehler, und ihre Vermischung führt zum falschen Mittel.

Ein Wartungsbefehl, der ein ganzes Backbone entfernt, ist ein technischer Fehler. Das Mittel sind engere Reichweite, stufenweise Ausführung, vorherige Trockenprüfung und harte Grenzen dafür, was eine einzelne Bewertungshandlung berühren darf. Solche Grenzen sind unspektakulär und wirken. Sie kosten einen Betreiber die Bequemlichkeit, eine Frage in einem einzigen Schritt gegen die ganze Produktion zu beantworten, und genau diese Bequemlichkeit war hier die Schwachstelle.

Nach der Darstellung des Betreibers kam ein zweiter Fehler hinzu: ein Audit-Werkzeug, das Befehle dieser Art hätte abfangen sollen, enthielt selbst einen Fehler. Das ist ein Governance-Fehler, und das Mittel ist anderer Art. Es fragt, warum ein einzelner Wächter die ganze Last trug, ob seine Abdeckung dem Wirkungsbereich entsprach, ob er gegen die genaue Klasse von Änderung getestet worden war, die er stoppen sollte, und wer dafür zuständig war zu bemerken, dass der Wächter nicht mehr wachte.

Die Unterscheidung ist nicht akademisch. Ein Betreiber, der nur den ersten Fehler repariert, hat den Befehl entschärft und die Prüfung unverändert gelassen. Ein Betreiber, der nur den zweiten repariert, hat die Prüfung verschärft und den Befehl scharf gelassen. Erst beide zusammen ergeben eine Kontrolle, die diesen Namen verdient, und nur die zweite Frage berührt die Frage, wer im Unternehmen was entscheiden durfte.

Die Reparatur ist die ungeprüfte Hälfte

Der Vorfallbericht ist reich an Ursache und dünn an Reparatur. Das ist kein Vorwurf an ein einzelnes Unternehmen, sondern eine Eigenschaft dieser Textgattung: Postmortem-Berichte erklären, was kaputtging, und schweigen darüber, was danach anders ist. Für eine Prüfung der Widerstandsfähigkeit ist das die falsche Reihenfolge.

Eine belastbare Reparatur müsste drei Bedingungen erfüllen, und jede lässt sich von außen prüfen, ohne Betriebsgeheimnisse zu verlangen.

Erstens müsste der Out-of-Band-Zugang unabhängig von der produktiven Routing- und Namensebene sein. Prüfbar ist das durch eine einzige Frage: Funktioniert ein Zugriffspfad noch, während die eigenen Ankündigungen zurückgezogen sind? Wer diese Frage nicht mit einem Test beantworten kann, hat keine Trennung, sondern eine Absicht.

Zweitens müsste der Wirkungsbereich eines einzelnen Wartungsbefehls begrenzt sein. Prüfbar ist das nicht durch die Zusicherung sorgfältiger Ausführung, sondern durch die Angabe einer Obergrenze und der Stelle, die sie durchsetzt.

Drittens müsste die Reparatur Belege erzeugen, die Dritte testen können. Eine Zusicherung, man habe es behoben, ist keine Prüfung; eine Änderung, die sich nachweisen lässt, ist eine.

Für diese Prüfung war keine erste Veröffentlichung von Meta Platforms auffindbar, die eine solche Trennung des Out-of-Band-Managements von den Ebenen, die es verwaltet, beschreibt, und keine unabhängige Bewertung einer solchen Änderung. Das ist ein datierter negativer Befund über die aufgefundene öffentliche Aufzeichnung, kein Beweis dafür, dass keine Änderung vorgenommen wurde. Der Unterschied ist wichtig: Ein Betreiber kann vieles getan haben, was er nicht veröffentlicht, und eine Prüfung, die daraus ein Versäumnis macht, behauptet mehr, als sie weiß.

Was daraus folgt, ist dennoch unbequem und unabhängig von diesem Einzelfall. Wer einem Betreiber glauben soll, dass eine Kontrolle existiert, braucht etwas, das sich nachvollziehen lässt. Die Praxis, den Nachweis der Reparatur der Selbstauskunft zu überlassen, ist die eigentliche Schwachstelle im Umgang mit Ausfällen dieser Größe — nicht der einzelne Befehl, der sie ausgelöst hat.

Was dieser Fall für Dritte bedeutet

Der Vorfall hatte eine Form, die sich wiederholen lässt. Ein Wartungszugang, der mehr erreicht, als sein Zweck verlangt. Eine Gesundheitslogik, die bei fehlender Sichtbarkeit lieber abschaltet als abzuwarten. Ein Namenssystem, dessen Verlust den Zugang mitnimmt, der es hätte reparieren sollen. Und eine Öffentlichkeit, die den Ablauf nur deshalb rekonstruieren kann, weil ein Dritter mitgemessen hat.

Für Unternehmen außerhalb der Branche ist die praktische Lehre nicht technisch. Sie lautet, die eigene Abhängigkeit von fremden Namens- und Routingentscheidungen zu benennen: Welche Prozesse funktionieren nicht mehr, wenn ein Anbieter seinen Namen nicht mehr auflösen kann, und wer im Haus weiß das? Die Frage ist billig zu stellen und unangenehm zu beantworten, was erklärt, warum sie selten gestellt wird.

Für Betreiber ist die Lehre unangenehmer, weil sie die eigene Organisation betrifft. Ein Netz, das sich nur über einen einzigen Kanal steuern lässt, ist nicht robust, sondern nur schnell — solange der Kanal offen ist. Die rund fünfeinhalb Stunden zwischen dem Rückzug der DNS-Präfixankündigungen und der offenbar vollständigen Wiederanbindung sind kein Maß für Kompetenz. Sie sind ein Maß dafür, wie lange ein Unternehmen brauchte, um zu einem Gebäude zu kommen.