Zusammenfassung

  • Ein Wartungsbefehl, der die Verfügbarkeit der globalen Backbone-Kapazität prüfen sollte, trennte alle Verbindungen im Backbone von Facebook und schnitt die Rechenzentren weltweit vom Netz.
  • Die Instanz, die solche Befehle abfangen sollte, war ein Prüfwerkzeug — und ein Fehler in diesem Werkzeug verhinderte, dass es den Befehl anhielt.
  • Die DNS-Server zogen ihre BGP-Ankündigungen zurück, weil sie ihre Rechenzentren nicht mehr erreichten. Das war entworfenes Verhalten, kein Nebeneffekt, und es trug den Fehler von der internen Verbindung in die weltweite Erreichbarkeit.

Der Befehl kam aus dem Alltag, nicht aus dem Notfall. Er sollte ermitteln, wie viel Kapazität das globale Backbone noch hergibt. Stattdessen nahm er alles weg. „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.“ So steht es in der Schilderung von Engineering at Meta, veröffentlicht am 5. Oktober 2021.

Was dieser Satz nicht sagt, ist ebenso wichtig wie das, was er sagt: Weder Inhalt noch Umfang des Befehls noch der Weg seiner Freigabe sind in einem lesbaren internen Dokument nachvollziehbar. Wer ihn formuliert hat, welche Parameter er trug, wer ihn genehmigte — nichts davon liegt in dem Material vor, das ich geprüft habe. Der Befund bleibt deshalb bei dem, was der Betreiber selbst einräumt: Der Befehl sollte messen und hat abgeschaltet.

Interessanter als der Befehl ist die Instanz, die ihn hätte aufhalten sollen. Facebook beschreibt sie als Schicht, die genau für diese Klasse von Eingriffen gebaut war. Sie hat nicht funktioniert, und der Grund lag nicht in einer Ausnahme, die niemand vorhersehen konnte, sondern im Prüfwerkzeug selbst. „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.“

Das ist der Kern des Falls. Ein Betrieb stellt eine Kontrolle vor eine gefährliche Handlung und nennt das Prävention. Diese Kontrolle ist aber ihrerseits ein Programm, das laufen, lesen, entscheiden und eingreifen muss — und jedes dieser Elemente kann ausfallen. Ein fehlerhafter Prüfer ist keine Prüfung; er ist ein weiteres System, das niemandem mehr etwas beweist. Es gibt in dem vorliegenden Material keinen lesbaren Fehlerbericht und keinen Testnachweis für dieses Werkzeug. Die stärkste Spur bleibt der Satz des Betreibers, dass ein Bug es am Stoppen hinderte.

Dann griff die zweite Kontrolle, und sie tat genau, wofür sie gebaut war. Die autoritativen DNS-Server von Facebook sind so eingestellt, dass sie ihre eigenen BGP-Ankündigungen zurücknehmen, sobald sie ihre Rechenzentren nicht mehr erreichen können — das Signal für eine ungesunde Verbindung. „To ensure reliable operation, our DNS servers disable those BGP advertisements if they themselves can not speak to our data centers, since this is an indication of an unhealthy network connection.

In the recent outage the entire backbone was removed from operation, making these locations declare themselves unhealthy and withdraw those BGP advertisements.“

Weil das gesamte Backbone fehlte, erklärte sich jeder dieser Standorte gleichzeitig für ungesund und zog sich zurück. Der Fehler wanderte damit aus dem Inneren des Netzes nach außen: Was intern nicht mehr erreichbar war, war nun auch für den Rest des Internets nicht mehr auflösbar. Das ist kein Versagen der Sicherung. Es ist die Sicherung bei der Arbeit, unter einer Bedingung, die der Ausfall selbst erzeugt hat. Wer eine Schutzvorrichtung baut, deren Auslöser der Schaden ist, gegen den sie schützt, bekommt im Ernstfall keine Bremse, sondern eine Verstärkung.

Wie lange das dauerte, lässt sich nicht aus dem Betreiberbericht ablesen, sondern nur aus der Messung von außen. Cloudflare beobachtete, dass der Name facebook.com auf dem Resolver 1.1.1.1 gegen 15:50 UTC nicht mehr auflösbar war und gegen 21:20 UTC wieder verfügbar wurde. Zwischen 15:58 UTC und 21:00 UTC gab es keine Ankündigungen der DNS-Präfixe über BGP, gegen 21:17 UTC erreichte die erneute BGP-Aktivität ihren Höhepunkt. „At around 21:00 UTC we saw renewed BGP activity from Facebook's network which peaked at 21:17 UTC. ... This chart shows the availability of the DNS name 'facebook.com' on Cloudflare's DNS resolver 1.1.1.1. It stopped being available at around 15:50 UTC and returned at 21:20 UTC.“ Cloudflare beziffert die Störung auf etwa fünfeinhalb bis sechs Stunden. Das ist die Einordnung von Cloudflare, nicht eine Dauerangabe von Meta.

Warum es so lange dauerte, ist der unangenehmste Teil der Geschichte. Der Weg zurück führte nicht über eine Konsole. „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. But this took time, because these facilities are designed with high levels of physical and system security in mind. They're hard to get into, and once you're inside, the hardware and routers are designed to be difficult to modify even when you have physical access to them.“

Beide Fernwege waren weg: der reguläre und der außerbandige. Was blieb, war der Körper vor dem Gerät, in einem Gebäude, das genau gegen den übereilten physischen Eingriff gebaut ist. Diese Härtung ist kein Fehler — sie ist der Sinn eines Rechenzentrums. Nur trifft sie im Ernstfall dieselbe Organisation, die den Notfall beheben muss, und sie tut es ohne Ausnahme und ohne Beschleunigung. Der Notausgang war zu, weil das Gebäude ihn zu Recht verschlossen hielt.

Damit steht die Frage, die dieser Fall offenlegt: Wer prüft den Prüfer? Ein Prüfwerkzeug ist nur dann eine Kontrolle, wenn sein eigenes Verhalten getestet und sein eigenes Versagen sichtbar wird. Für beides findet sich in dem Material, das ich geprüft habe, kein Beleg — nicht in den beiden Dokumenten vom 5. Oktober 2021, nicht in einer ergänzenden technischen Aufzeichnung. Ich habe die Schilderung des Betreibers und die externe Messung von Cloudflare gelesen; einen Wiederherstellungsplan, einen Umsetzungsstand oder einen Nachweis über die Dauerhaftigkeit der Reparatur enthalten sie nicht.

Das ist eine Grenze des geprüften Materials, keine Aussage darüber, dass es solche Nachweise nicht gibt.

Der Ausfall selbst ist gut dokumentiert. Die Frage, die er aufwirft, ist es nicht. Ein Unternehmen, das seine gefährlichsten Eingriffe von einem Programm abfangen lässt, sollte als Erstes wissen, wie man dieses Programm testet, wenn es selbst falsch liegt.