Zusammenfassung

  • Am 4. Oktober 2021 riss ein Befehl, der während einer Wartung ausgegeben wurde und die freie Kapazität des globalen Backbones bemessen sollte, alle Verbindungen in diesem Netz ab und schnitt die Rechenzentren von Facebook weltweit vom Internet.
  • Die automatische Prüfung, die genau diese Art von Befehl abfangen sollte, hat es nicht getan. Der Verlust des Produktionsnetzes und der Verlust des Blicks auf das Geschehen fielen in ein und dasselbe Ereignis.
  • Der geprüfte öffentliche Bestand reicht bis zu Metas Zusage, Tests und Übungen zu verstärken. Er enthält keine datierte Unterlage, die den Fehler in der Prüf-Software als behoben zeigt oder eine von außen beobachtete Übung belegt.

Am Nachmittag des 4. Oktober 2021 antworteten Facebook, Instagram und WhatsApp in großen Teilen der Welt mehrere Stunden lang nicht. Am Tag darauf veröffentlichte der Betreiber seine eigene Darstellung im Engineering-Beitrag, und diese Darstellung beschreibt keinen Angriff und keinen Ausfall fremder Netze. Sie beschreibt eine Wartungsaufgabe in der eigenen Infrastruktur:

"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 connections in our backbone network, effectively disconnecting Facebook data centers globally."

Der Satz setzt den Ausgangspunkt ungewöhnlich genau: Gemessen werden sollte, wie viel Backbone-Kapazität verfügbar ist; bewirkt wurde, dass sämtliche Verbindungen dieses Netzes wegfielen. Zwischen beidem müsste ein breiter Puffer liegen, und das Interessante an diesem Fall ist, dass der Puffer im Entwurf vorhanden war und im Ernstfall nicht wirkte.

Die Sperre, die nicht sperrte

Der Betreiber sagt das so klar, dass eine Abschwächung fehl am Platz wäre: Es gab eine automatische Prüfung, die Befehle dieser Art abfangen sollte, und diese Prüfung war fehlerhaft.

"Our systems are designed to audit commands like these to prevent mistakes like this, but a bug in that audit tool prevented it from properly stopping the command."

Hier trennt sich dieser Vorfall von einer gewöhnlichen Störung. Der Organisation fehlte keine Sicherung; sie hatte eine Sicherung, deren erklärter Zweck genau darin bestand, einen Wartungsbefehl davon abzuhalten, das globale Backbone abzuschalten. Ein Kontrollelement zu haben ist nicht dasselbe wie geschützt zu sein. Eine Prüfung, die läuft, die als überwacht gilt und die dennoch den Befehl durchlässt, den sie hätte blockieren müssen, erzeugt den Eindruck von Abdeckung — und genau dieser Eindruck lässt sich hinterher am schwersten prüfen.

Nichts in dem geprüften öffentlichen Bestand benennt, wer den Befehl ausgegeben und wer ihn genehmigt hat; nichts darin erlaubt es, das Geschehen als Sabotage, als Nachlässigkeit oder als Vertuschung zu bezeichnen. Beschrieben ist ein Fehler in einem Werkzeug, und die Unterlage erklärt weder seine Herkunft noch die Testgeschichte dieses Werkzeugs.

Wenn Sehen und Zurücknehmen zugleich verschwinden

Der zweite Teil der Darstellung macht aus dem Vorfall ein Problem der Kontrollarchitektur. Der Betreiber nennt zwei Hindernisse, die gleichzeitig auftraten:

"All of this happened very fast. And as our engineers worked to figure out what was happening and why, they faced two large obstacles: first, it was not possible to access our data centers through our normal means because their networks were down, and second, the total loss of DNS broke many of the internal tools we'd normally use to investigate and resolve outages like this."

Genau gelesen sind das nicht zwei Vorfälle, die zusammenfielen. Es ist ein Ereignis mit zwei aneinandergekoppelten Folgen: Das Produktionsnetz verschwand, und mit ihm verschwand ein großer Teil der internen Fähigkeit, zu erkennen, was gerade geschah. Eine Erkennung, die von dem System abhängt, das ausgefallen ist, ist keine unabhängige Erkennung; sie ist ein Komfort, der funktioniert, solange man ihn nicht braucht.

Die Reaktion zeigt, wie weit diese Abhängigkeit reichte. Der Betreiber griff auf körperliche Anwesenheit zurück:

"Our primary and out-of-band network access was down, so we sent engineers onsite to the data centers to have them debug the issue and restart the systems."

Der Out-of-Band-Zugang existiert gerade deshalb, weil er den Ausfall der Hauptebene überleben soll. Diesmal lagen beide danieder. Die Wiederherstellung lief weder über eine Fernkonsole noch über eine Notfallkonsole, sondern darüber, dass Menschen in die Standorte fuhren und Systeme neu starteten. Das ist ein legitimer Weg, und es ist zugleich der Beleg dafür, dass die letzte Verteidigungslinie des Fernzugangs keine Verteidigungslinie mehr war.

Was sich von außen datieren lässt

Die unabhängige Bestätigung in diesem Text liegt auf der Ebene der Beobachtung, nicht der Ursache. Eine dritte Partei veröffentlichte aus ihrer eigenen Netzposition eine Analyse des Ausfalls mit Uhrzeiten in UTC:

"But 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."

"It stopped being available at around 15:50 UTC and returned at 21:20 UTC."

"At around 21:00 UTC we saw renewed BGP activity from Facebook's network which peaked at 21:17 UTC."

"as of 21:28 UTC Facebook appears to be reconnected to the global Internet and DNS working again."

Diese Abfolge leistet drei Dinge und ein viertes nicht. Sie datiert den Rückzug der Routen, die die Namenspräfixe des Betreibers transportierten; sie dokumentiert ein Zeitfenster, in dem eine Hauptdomain nicht auflösbar war; sie hält die Wiederaufnahme der Routing-Aktivität und die Rückkehr des Dienstes fest. Den internen Kontrollweg sieht sie nicht, sie kann nicht bestätigen, warum die Prüf-Software versagte, und sie sagt nichts über spätere Reparaturen.

Diese Außenbeobachtung als Beleg für interne Erkennungsfähigkeit zu lesen, wäre ein Lesefehler: Der Beobachter von außen sah gerade den Teil, den der Betreiber selbst nicht mehr sehen konnte.

Reparatur: Wie weit der Bestand reicht

Die Darstellung endet mit einer Zusage:

"From here on out, our job is to strengthen our testing, drills, and overall resilience to make sure events like this happen as rarely as possible."

Dieser Satz hat einen festen Platz, und er kann nur auf der untersten Stufe einer überprüfbaren Leiter stehen: öffentliche Zusage, datierte Umsetzung, tatsächlich geübte Kontrolle, unabhängige Beobachtung oder Bestätigung. Der geprüfte Bestand — der veröffentlichte Beitrag des Betreibers, die Analyse des unabhängigen Beobachters und eine gezielte Suche nach späteren Unterlagen zu Korrekturmaßnahmen — hat kein Material ergeben, das den Fall eine Stufe höher setzt.

Meta erklärte, Tests, Übungen und die allgemeine Widerstandsfähigkeit verstärken zu wollen; keine datierte Unterlage aus diesem Bestand zeigt den Fehler der Prüf-Software als behoben, die Abhängigkeit des Notzugangs vom ausgefallenen Netz als beseitigt oder eine spätere Übung als von außen beobachtet. In diesem Material erscheint keine nach dem Vorfall eingerichtete Kontrolle als geprüft. Diese Lücke belegt nicht, dass nichts repariert wurde; sie belegt, was das geprüfte Material enthält. Schließen ließe sie sich durch eine datierte Umsetzungsunterlage, das Ergebnis einer geübten Kontrolle oder eine Übung mit einem Beobachter von außen.

Wer wofür einsteht

Die Zurechnung, die dieser Text vertritt, trennt vier Ebenen. Der Befehl ist der unmittelbare Auslöser, und ein Auslöser ist keine Schuld. Die Prüf-Software ist die vorbeugende Kontrolle, die versagt hat. Das Zusammenspiel von Backbone-Verlust, DNS-Verlust, Verlust der Diagnosewerkzeuge und Verlust beider Fernzugangswege ist das Versagen von Eindämmung und Wiederherstellung. Und die Verantwortung auf Betreiberebene liegt beim Kontrollstapel und bei der Widerstandsfähigkeit der Architektur, die in Betrieb war.

Der geprüfte Bestand benennt keine Personen, zeigt keine früheren Warnungen, zeigt keinen Verfahrensverstoß und enthält kein regulatorisches Instrument, keine Gerichtsakte und keine förmliche Untersuchung dieses Vorfalls.

Was dieser Text hinzufügt

Die aufgefundene frühere Berichterstattung über denselben Betreiber behandelt anderes: die Steuerung von Plattformdaten und Entwicklerrechten nach dem Cambridge-Analytica-Vorgang, die Mechanik der Order-Zuordnung beim Börsengang 2012, das Porträt eines Infrastruktur-Ingenieurs, der unter dieser Größenordnung arbeitet, und kurze Meldungen zu späteren, getrennten Dienstausfällen. Keiner dieser Texte untersucht das Kontrollversagen vom 4. Oktober 2021, das gleichzeitige Wegfallen von Produktion und Diagnose, die Notwendigkeit physischer Wiederherstellung oder die Frage nach der Dauerhaftigkeit der Reparatur. Dieser Text fügt die Kontrollkette hinzu und die Beweisgrenze, die sie umgibt — nicht eine Nacherzählung der Störung. Der Betreiber hat einen eigenen Eintrag im BTW-Verzeichnis.