Facebooks selbstheilender Konfigurationsprüfer verwandelte einen fehlerhaften Wert in einen 2,5-stündigen Ausfall

Im September 2010 war Facebook etwa zweieinhalb Stunden lang nicht erreichbar. Das Engineering-Team des Unternehmens bezeichnete dies in einem seltenen öffentlichen Postmortem, das am selben Tag vom Director of Software Engineering Robert Johnson veröffentlicht wurde, als den schlimmsten Ausfall, den die Seite in über vier Jahren erlitten hatte. Jeder Besucher stieß auf jeder Seite auf Fehler, bis die Seite wieder verfügbar war.

Die Ursache war ein automatisiertes System, das Konfigurationswerte gesund halten sollte: Es verglich zwischengespeicherte Werte mit einem persistenten Speicher und ersetzte alles, was es als ungültig einstufte. An jenem Tag hinterließ eine Änderung einen fehlerhaften Wert im persistenten Speicher selbst. Jeder Client sah den „ungültigen“ Wert und versuchte, ihn zu reparieren, und da die Reparatur eine Abfrage an einen Datenbankcluster bedeutete, wurde der Cluster mit Hunderttausenden Abfragen pro Sekunde bombardiert.

Die Fehlerbehandlung verschlimmerte die Lage. Wenn die Abfrage eines Clients fehlschlug, deutete er den Fehlschlag als „Wert weiterhin ungültig“ und löschte den entsprechenden Cache-Schlüssel – was eine weitere Reparaturabfrage erzeugte. Selbst nachdem der ursprüngliche fehlerhafte Wert korrigiert worden war, nährte sich die Schleife weiter selbst. Der einzige Ausweg bestand darin, den gesamten Datenverkehr zum Datenbankcluster zu stoppen, was bedeutete, die Seite vollständig abzuschalten, die Datenbanken sich erholen zu lassen und die Nutzer dann langsam wieder hereinzulassen.

Die gesamte Seite war etwa 2,5 Stunden lang nicht erreichbar – die eigenen Ingenieure von Facebook nannten es den schlimmsten Ausfall seit mehr als vier Jahren

Der Prüfer ging davon aus, dass der persistente Speicher stets korrekt sei; als dieser den fehlerhaften Wert enthielt, erhielt jeder Client dieselbe vergiftete Reparaturanweisung.

Die Fehlerbehandlung setzte „Datenbank überlastet“ mit „ungültiger Wert“ gleich, sodass jeder Fehlschlag zusätzliche Last erzeugte – eine verstärkende Rückkopplungsschleife.

Das Löschen von Cache-Schlüsseln bei Fehlern beseitigte die einzige Schicht, die den Wiederholungssturm hätte abfangen können.

Es gab keinen Circuit Breaker zwischen den Clients und dem Cluster, sodass der einzige verbleibende Hebel eine vollständige Abschaltung der Seite war.

Selbstheilender Code, der jeden Fehler als „los, reparieren“ behandelt, verstärkt Fehler, statt sie abzufangen. Begrenzen Sie Wiederholungsversuche pro Client, dämpfen Sie Rückkopplungsschleifen und halten Sie einen Wiederherstellungshebel bereit, der nicht in einer vollständigen Abschaltung besteht.

Facebook schaltete das selbstkorrigierende Konfigurationssystem noch am selben Tag ab und erklärte, es werde um Muster herum neu gestaltet, die vorübergehende Spitzen und Rückkopplungsschleifen tolerieren. Der Dienst wurde noch am selben Tag vollständig wiederhergestellt, und das Unternehmen, damals das größte soziale Netzwerk der Welt, veröffentlichte die technischen Details innerhalb von Stunden. Der Vorfall wird noch immer als Lehrbuchbeispiel für eine Fehlerbehandlung zitiert, die einen kleinen Fehler in einen sich selbst erhaltenden Sturm verwandelt.