Knightmare: Eine mahnende DevOps-Geschichte (2014)

• Ein Artikel über die warnende Geschichte des global bedeutenden Finanzdienstleistungsunternehmens Knight Capital Group im Jahr 2012, ein Fall, in dem das Unternehmen durch ein fehlgeschlagenes Software-Deployment innerhalb von 45 Minuten bankrottging.
• 2012 war Knight Capital Group der größte Händler von US-Aktien, mit einem durchschnittlichen täglichen Handelsvolumen von mehr als 3,3 Milliarden Transaktionen und über 21 Milliarden US-Dollar Handelswert pro Tag.
• Das Unternehmen aktualisierte SMARS, einen automatisierten Hochgeschwindigkeits-Algorithmus-Router, während es sich auf den Start des neuen Retail Liquidity Program der NYSE vorbereitete.
• Dieses Update sollte alten, ungenutzten Code namens "Power Peg" ersetzen, den Knight seit 8 Jahren nicht mehr verwendet hatte.
• Der neue Code wurde manuell auf 8 Server ausgerollt, doch durch einen Fehler eines Technikers wurde der neue Code auf einen Server nicht kopiert, wodurch der alte Power-Peg-Code aktiviert wurde.
• Weil die Power-Peg-Funktion begann, Routen zur Ausführung von Child Orders zu senden, ohne die Anzahl der Aktien für die Parent Order zu verfolgen, entstand eine Endlosschleife von Orders.
• Als der Markt öffnete, überschwemmte Knights System den Markt mit Orders; einige Aktien stiegen dadurch um mehr als 10 % ihres Werts, andere fielen als Reaktion auf die fehlerhaften Trades.
• Das System von Knight verschickte 97 automatische E-Mails, die auf SMARS verwiesen und den Fehler als "Power Peg disabled" identifizierten, doch sie waren nicht als Systemalarme konzipiert und wurden nicht sofort geprüft.
• In den ersten 45 Minuten des Handels verarbeitete der Power-Peg-Code 212 Parent Orders, führte 4 Millionen Trades in 154 Aktien aus und bewegte mehr als 397 Millionen Aktien.
• Knight Capital Group erlitt in 45 Minuten einen Verlust von 460 Millionen US-Dollar, was das Unternehmen in den Bankrott trieb. Das nötige Kapital zur Deckung der Verluste beschaffte es durch eine Investition von 400 Millionen US-Dollar von einem halben Dutzend Investoren.
• Der Artikel betont, wie wichtig es ist, Deployments vollständig zu automatisieren und wiederholbar zu machen, um derart große Ausfälle zu vermeiden; dies sei Teil einer DevOps-/Continuous-Delivery-Strategie.
• Der Autor schlägt vor, dass Software-Releases ein wiederholbarer und verlässlicher Prozess sein sollten und so weit wie möglich automatisiert werden müssten, um das Risiko menschlicher Fehler zu verringern.

[GN⁺]

Hacker-News-Kommentare

• Automatisierte Deployments hätten das Problem möglicherweise nicht verhindert und es durch inkompatiblen Code sogar verschärfen können.
• Automatisierte Handelssysteme sollten einen eingebauten Kill Switch haben, der regelmäßig getestet wird, um seine Funktionsfähigkeit sicherzustellen.
• Ein Continuous-Deployment-System hätte diesen Bug möglicherweise nicht abgefangen, obwohl es sich um einen Logikfehler handelte, der zu einem katastrophalen Ausfall führte.
• Der Ausdruck „Knight Capitalen“ ist im quantitativen Finanzwesen als Bezeichnung dafür bekannt, bei kritischen Systemen Abkürzungen zu nehmen und dann mit den Folgen konfrontiert zu werden.
• Hochfrequenzhandel ist ein extremes Beispiel dafür, wie schnell etwas schieflaufen kann.
• Bei Systemen, die große Verkaufsvolumina verarbeiten, sind manuelle Prozesse, Rollback-Schritte und Feature Flags wichtig, um Risiken zu mindern.
• Der Vorfall bei Knight Capital war das Ergebnis davon, dass ein automatisches SCRAM-System ignoriert wurde, das alle Transaktionen stoppen oder per manueller Intervention warnen sollte.
• Dass sich acht Jahre lang toter Code in der Codebasis befand, deutet auf ein Risiko hin und zeigt einen Mangel an aktiver Wartung.
• Wenn Konfiguration und Binärdateien gleichzeitig ausgerollt worden wären, hätte sich diese Art von Problem verhindern lassen.
• Die Wiederverwendung alter Flags war ein schwerwiegender Fehler und unterstreicht, wie wichtig saubere Praktiken bei Deployments sind.