1066 sind mehr als 200 Jahre seit dem Beginn der Invasion der Wikinger in England vergangen. König Harold sammelte eine Abteilung von Rittern und marschierte zum Derwent River, um einen entscheidenden Kampf mit den Truppen seines Namensvetters - des norwegischen Königs Harald - zu führen. Die Büchsenmacher arbeiteten einen Monat lang daran, genügend Rüstungen der neuen Generation zu schmieden, um den Ritter vor einem Treffer durch eine skandinavische Axt zu schützen. Und wie viele Experimente und Versuche in Turnieren waren zuvor gewesen! Aber die Erwartung hätte sich rechtfertigen müssen - leichte, aber zuverlässige Ausrüstung, die es auch zu Fuß ohne große Verluste ermöglichte, den Wikingerhund zu zerstreuen. Und schließlich trafen sie sich an der Stamford Bridge. Die Hauptabteilung der Ritter, angeführt von einem Kommandanten in glänzender Rüstung, stieß mitten auf einer Brücke mit Feinden zusammen. Ja, der Stahl der podgorny Meister hält den Schlag!
Langsam aber sicher bewegen sich die Wikinger zu einer Round-Robin-Verteidigung. Der Sieg scheint nahe zu sein. Und schließlich finden sich auf dem Schlachtfeld der Ritterkommandant und der norwegische Jarl.
Die zweihändige Jarl-Axt ist bereits gebrochen und er ist gezwungen, sich mit einem gewöhnlichen Sachsen zu verteidigen, der nicht mit einem Ritter und einem halben Schwert zu vergleichen ist. Eine Welle mit einem Dolch - für die Rüstung des Kommandanten ist es wie ein Taschenmesser, aber es geht durch die Rüstung und ... es scheint, dass Magie ins Spiel gekommen ist - die Rüstung benachbarter Ritter ist verstreut! Eine weitere Welle, wieder am Ziel, und jetzt bei den Rittern auf der linken Seite leuchtet die Rüstung plötzlich glühend heiß. Der dritte Schlag - die Ritter schwimmen vor ihren Augen, sie stolpern, fallen und erheben sich nie wieder.
"*** ** **** ****!" Rief Petrovich und wachte am Montag um 5 Uhr morgens in kaltem Schweiß auf. Alles lief völlig schief: Um elf Uhr abends stieg er in Wikipedia ein, um nach Materialien für den Bericht des Kindes über die Natur der Tundra zu suchen, aber zum Zeitpunkt der Nacht befand er sich irgendwie in der Beschreibung der Invasion der Wikinger in England. Und am Wochenende haben sie die nächste Veröffentlichung in den Kampf gezogen, die heute beginnen soll. Wie immer haben wir es lange getestet und gründlich durchlaufen, es millionenfach durch kontinuierliche Integrationssysteme gefahren, ob alles reibungslos läuft ...
Zum Glück für einige, aber leider für die Opfer, gibt es immer die Möglichkeit, aus den Fehlern anderer zu lernen, etwas zu Hause zu verbessern und einen zusätzlichen Teil des Vertrauens zu gewinnen. Mit diesem übersetzten Artikel möchten wir noch einmal genauer auf einen der Fälle in "unserer" Branche eingehen.
Letztes Jahr sprach ich auf der Konferenz über DevOps, Konfiguration als Code und kontinuierliche Bereitstellung. Anhand der folgenden Geschichte habe ich erklärt, wie wichtig es ist, im Rahmen der DevOps / Continuous Delivery-Initiative vollständig automatisierte und reproduzierbare Bereitstellungen zu erstellen. Nach der Konferenz baten mich mehrere Leute, eine Geschichte in einem Blog zu teilen. Dies ist eine absolut wahre Geschichte. Dies ist eine Nacherzählung von dem, was ich gelesen habe, ich selbst habe nicht daran teilgenommen.
Die Geschichte, wie ein Unternehmen mit einem Vermögen von fast 400 Millionen US-Dollar aufgrund eines erfolglosen Einsatzes innerhalb von 45 Minuten bankrott ging.
Ein kleiner Hintergrund
Knight Capital Group („Knight“ bedeutet auf Englisch „Knight“) ist ein amerikanisches globales Finanzunternehmen, das sich mit Market Making, elektronischer Ausführung, institutionellem Verkauf und Handel befasst. 2012 war Knight der größte US-Aktienhändler mit einem Marktanteil von rund 17% an der NYSE und der NASDAQ. Die Electronic Trading Group (ETG) von Knight verwaltete ein durchschnittliches tägliches Handelsvolumen von über 3,3 Milliarden Transaktionen pro Tag und handelte über 21 Milliarden US-Dollar ... pro Tag. Das ist kein Scherz!
Zum 31. Juli 2012 verfügte Knight über liquide Mittel in Höhe von ca. 365 Mio. USD.
Am 1. August 2012 plante die NYSE die Einführung eines neuen Liquiditätsprogramms für Privatanleger, des Retail Liquidity Program (ein Programm zur Verbesserung der Preisgestaltung für Privatanleger durch Einzelhandelsmakler wie Knight). In Vorbereitung auf dieses Ereignis hat Knight den automatisierten algorithmischen Hochgeschwindigkeits-Router SMARS aktualisiert, der Anwendungen zur Ausführung auf den Markt sendet. Eine der Hauptfunktionen von SMARS besteht darin, Anwendungen von anderen Komponenten der Knights-Handelsplattform ("übergeordnete" Anwendungen) zu empfangen und anschließend eine oder mehrere "untergeordnete" Anwendungen zur Ausführung zu senden. Mit anderen Worten, SMARS erhält große Aufträge von der Handelsplattform und teilt sie in mehrere kleine auf, um einen Käufer / Verkäufer für Aktien zu finden. Je größer die übergeordnete Anwendung ist, desto mehr untergeordnete Anwendungen werden erstellt.
Das SMARS-Update sollte den alten, nicht verwendeten Code namens „Power Peg“ ersetzen - diese Funktionalität hatte Knight seit 8 Jahren nicht mehr verwendet (warum der Code, der so lange tot war, noch in der Codebasis war, ist ein Rätsel, aber das ist nicht die Hauptsache). Der aktualisierte Code hat das alte Flag neu zugewiesen, mit dem die Power Peg-Funktionalität aktiviert wurde. Der Code wurde gründlich getestet, funktionierte korrekt und war zuverlässig. Was hätte schief gehen können?
Was hätte schief gehen können? Und wirklich!
Zwischen dem 27. Juli 2012 und dem 31. Juli 2012 stellte Knight neue Software manuell auf einer begrenzten Anzahl von Servern pro Tag bereit - insgesamt acht (8) Server. Das
SEC-Dokument sagt Folgendes über die manuelle Bereitstellung aus (SEC ist die Securities and Exchanges Comission, die amerikanische Börsenaufsichtsbehörde).
„Während der Bereitstellung des neuen Codes hat einer der Knight-Mitarbeiter den neuen Code nicht auf einen der acht SMARS-Server kopiert. Knight führte keine zweite technische Überprüfung dieser Bereitstellung durch, sodass der Power Peg-Code nicht vom achten Server gelöscht und der neue RLP-Code nicht hinzugefügt wurde. Das Unternehmen verfügte nicht über Verfahren, die eine erneute Prüfung erforderten. “ Release Nr. 70694, 16. Oktober 2013
Am 1. August 2012 um 9:30 Uhr EST öffneten sich die Märkte und Knight begann, Anfragen von Broker-Dealern im Namen seiner Kunden im neuen Retail Liquidity Program zu bearbeiten. Sieben (7) Server, die ordnungsgemäß bereitgestellt wurden, begannen, Anwendungen ordnungsgemäß zu verarbeiten. Und diese Anwendungen, die auf den achten Server gingen, haben wahrscheinlich das geänderte Flag aktiviert und Power Peg wiederbelebt.
Zombie Attack: Killer Code
Hier müssen Sie erklären, warum der "tote" Power Peg-Code benötigt wurde. Diese Funktion diente zum Zählen von Aktien, die auf Wunsch eines Elternteils gekauft / verkauft wurden, wenn die Bestellungen des Kindes abgeschlossen sind. Nachdem die übergeordnete Anwendung ausgeführt wurde, verbietet Power Peg die Einreichung von untergeordneten Anwendungen. Im Prinzip verfolgt Power Peg untergeordnete Bestellungen und stoppt deren Ausführung nach der Verarbeitung der übergeordneten Anwendung. Im Jahr 2005 hat Knight diese kumulative Nachverfolgungsfunktion auf eine frühere Phase der Codeausführung zurückgesetzt (wodurch die Mengenverfolgung aus Power Peg entfernt wurde).
Als das Power Peg-Flag auf dem achten Server aktiviert wurde, begann Power Peg, untergeordnete Befehle zur Ausführung weiterzuleiten, korrelierte sie jedoch nicht mit der Anzahl der Freigaben in der übergeordneten Reihenfolge - es entstand eine Art geschlossener Regelkreis
Infernal 45 Minuten
Stellen Sie sich vor: Sie haben ein System, mit dem automatische Hochgeschwindigkeitsanwendungen ohne Nachverfolgung auf den Markt gebracht werden können und das feststellen kann, ob genügend Anwendungen abgeschlossen wurden. Ja, alles ist so schlimm geworden.
Als der Markt um 9:30 Uhr öffnete, stellten die Leute schnell fest, dass etwas nicht stimmte. Um 9:31 Uhr hatten viele an der Wall Street bemerkt, dass etwas Ernstes geschah. Der Markt war mit Geboten überflutet, deren Handelsvolumen für bestimmte Aktien im Vergleich zur normalen Situation ungewöhnlich war. Um 9:32 Uhr an der Wall Street fragten sie sich, warum diese Schande nicht aufhört. Fast für immer im Hochgeschwindigkeitshandel. Warum hat jemand auf dem System, das es getan hat, nicht auf die Schaltfläche "Töten" geklickt? Wie sich herausstellte, gab es keinen Schalter. Während der ersten 45 Handelsminuten betrug die Ausführung von Transaktionen von Knight mehr als 50% des Handelsvolumens, wodurch bestimmte Aktien um mehr als 10% ihres Wertes erhöht wurden. Infolgedessen fielen andere Aktien aufgrund fehlerhafter Transaktionen an Wert.
Und um die Sache noch schlimmer zu machen, begann das Knight-System bereits vor diesen Ereignissen mit dem Versenden automatisierter E-Mails - bereits um 8:01 Uhr (als SMARS Aufträge verarbeitete, die für den Handel vor dem Inverkehrbringen geeignet waren). In Nachrichten verwies das System auf SMARS und zeigte den Fehler "Power Peg ist nicht verfügbar" an. Zwischen 8:01 Uhr und 9:30 Uhr wurden 97 Briefe an Knight-Mitarbeiter gesendet. Natürlich sahen diese Buchstaben nicht wie Systemwarnungen aus, also sah sie niemand sofort an. Autsch.
Für höllische 45 Minuten versuchte Knight, die fehlerhafte Transaktion zu stoppen. Es war nicht möglich, das System auszuschalten (da es keine dokumentierten Verfahren gab, um auf eine solche Situation zu reagieren). Daher versuchten sie, das Problem unter Live-Handelsbedingungen zu lösen, und blieben auf dem Markt, auf dem jede Minute 8 Millionen Aktien verkauft wurden. Da die Mitarbeiter des Unternehmens nicht feststellen konnten, woher die fehlerhaften Anwendungen stammten, entfernten sie den neuen Code von den Servern, auf denen er ordnungsgemäß bereitgestellt wurde. Mit anderen Worten, sie haben den Arbeitscode gelöscht und sind kaputt geblieben. Dies verschärfte nur die Probleme, die dazu führten, dass zusätzliche elterliche Anforderungen den Power Peg-Code auf allen Servern aktivierten, und nicht nur dort, wo der Code ursprünglich falsch bereitgestellt wurde. Am Ende gelang es mir, das System zu stoppen - nach 45 Minuten Handel.
Während des Handels erhielt und verarbeitete der Power Peg-Code 212 Anfragen von Eltern. Infolgedessen schickte SMARS Millionen von Tochterunternehmen auf den Markt und schloss 4 Millionen Transaktionen in 154 Transaktionen mit mehr als 397 Millionen Aktien ab. Für Börsenkenner bedeutete dies, dass Knight Aktien von 80 verschiedenen Unternehmen für 3,5 Milliarden US-Dollar kaufte und Aktien von 74 Unternehmen für 3,15 Milliarden US-Dollar verkaufte. Aus Sicht von Laien verlor die Knight Capital Group innerhalb von 45 Minuten 460 Millionen US-Dollar. Aber Knight verfügt nur über 365 Millionen US-Dollar an liquiden Mitteln. In 45 Minuten hat sich Knight vom größten Händler amerikanischer Aktien und einem großen Market Maker an der NYSE und der NASDAQ in den Bankrott verwandelt. Sie hatten 48 Stunden Zeit, um den zur Deckung der Verluste erforderlichen Betrag einzutreiben (was sie dank einer Investition von etwa einem halben Dutzend Investoren in Höhe von 400 Millionen US-Dollar tun konnten). Letztendlich wurde die Knight Capital Group von Getco LLC (im Dezember 2012) übernommen, und jetzt heißt das kombinierte Unternehmen KCG Holdings.
Welche Schlussfolgerungen müssen Sie ziehen?
Die Ereignisse vom 1. August 2012 sollten eine Lektion für alle Entwicklungsteams und Projektteams sein. Es reicht nicht aus, großartige Software zu erstellen und zu testen. Sie müssen auch sicherstellen, dass es korrekt auf den Markt gebracht wird, damit Ihre Kunden genau den Wert erhalten, den Sie bereitstellen (und dass Sie Ihr Unternehmen nicht bankrott machen). Die Ingenieure, die SMARS eingesetzt haben, sind nicht nur dafür verantwortlich, dass das bei Knight angewandte Verfahren keine Risiken berücksichtigt hat. Das Verfahren (oder seine Abwesenheit) war offensichtlich fehlerhaft. Jedes Mal, wenn der Bereitstellungsprozess davon abhängt, wie Benutzer Anweisungen lesen und befolgen, setzen Sie sich selbst einem Risiko aus. Menschen machen Fehler. Fehler können in den Anweisungen, in der Interpretation der Anweisungen oder in ihrer Implementierung liegen.
Das Layout sollte automatisiert, reproduzierbar und so frei wie möglich von menschlichen Fehlern sein. Wenn Knight ein automatisiertes Bereitstellungssystem implementiert hätte - eine Reihe von Konfigurationen, automatischen Bereitstellungen und Tests -, hätte der Fehler, der zum Albtraum eines Ritters wurde, vermieden werden können.
Hier sind einige Prinzipien der kontinuierlichen Lieferung (auch wenn Sie nicht den vollständigen Prozess der kontinuierlichen Lieferung implementieren):
- Die Softwareversion sollte ein wiederholbarer und zuverlässiger Prozess sein.
- Automatisieren Sie alles, was Sie können.