Ritter Upgrade Ausgelöst Alt Trading System

Ich habe auf einer Konferenz im vergangenen Jahr zu den Themen von DevOps, Konfiguration als Code und Continuous Delivery gesprochen und die folgende Geschichte verwendet, um zu zeigen, wie wichtig es ist, Installationen vollständig automatisiert und wiederholbar als Teil einer DevOpsContinuous Delivery Initiative zu machen. Seit dieser Konferenz bin ich von mehreren Leuten gefragt worden, um die Geschichte über meinen Blog zu teilen. Diese Geschichte ist wahr, das ist wirklich passiert. Das ist meine Erzählung von der Geschichte, die auf dem basiert, was ich gelesen habe (ich war nicht daran beteiligt). Dies ist die Geschichte, wie ein Unternehmen mit fast 400 Millionen in Vermögenswerten in 45 Minuten wegen eines gescheiterten Einsatzes in Konkurs ging. Hintergrund Ritter Kapital-Gruppe ist ein amerikanisches globales Finanzdienstleistungsunternehmen, das in der Marktherstellung engagiert. Elektronische Ausführung und institutionelle Verkäufe und Handel. Im Jahr 2012 war Knight der größte Händler in US-Aktien mit Marktanteil von rund 17 auf jeder der NYSE und NASDAQ. Knights Electronic Trading Group (ETG) verwaltete ein durchschnittliches tägliches Handelsvolumen von mehr als 3,3 Milliarden Trades täglich und handelte über 21 Milliarden Dollar täglich. Das ist kein Witz Am 31. Juli 2012 hatte Knight ungefähr 365 Millionen in Bargeld und Äquivalenten. Die NYSE hat am 1. August 2012 ein neues Retail-Liquidity-Programm eingeführt (ein Programm, das den Einzelhandelsanlegern durch Einzelhandelsmakler wie Knight am 1. August 2012 eine verbesserte Preisgestaltung ermöglicht. In Vorbereitung auf diese Veranstaltung hat Knight ihre automatisierte, hochgeschwindigkeitsalgorithmische Software aktualisiert Router, der Aufträge in den Markt für die Ausführung als SMARS bekannt sendet. Eine der Kernfunktionen von SMARS ist es, Aufträge von anderen Komponenten der Knights Trading-Plattform (übergeordnete Aufträge) zu erhalten und dann eine oder mehrere Kinderaufträge zur Ausführung zu senden. Mit anderen Worten, SMARS würde große Aufträge von der Handelsplattform erhalten und sie in mehrere kleinere Aufträge aufteilen, um ein Käufer-Match für das Volumen der Aktien zu finden. Je größer die übergeordnete Reihenfolge, desto mehr Kinderaufträge würden erzeugt. Das Update zu SMARS sollte den alten, unbenutzten Code, der als Power Peg-Funktionalität bezeichnet wird, ersetzen, den Knight in 8 Jahren nicht benutzt hatte (warum der Code, der seit 8 Jahren tot war, in der Codebasis noch vorhanden war, ist ein Rätsel, aber das ist Nicht der Punkt). Der Code, der aktualisiert wurde, hat eine alte Flagge umgestellt, die verwendet wurde, um die Power Peg-Funktionalität zu aktivieren. Der Code wurde sorgfältig geprüft und erwies sich als ordnungsgemäß und zuverlässig. Was könnte falsch gehen Was könnte Möglicherweise falsch gehen In der Tat Zwischen 27. Juli 2012 und 31. Juli 2012 Ritter manuell entfaltete die neue Software auf eine begrenzte Anzahl von Servern pro Tag acht (8) Server in allen. Dies ist, was die SEC-Einreichung über den manuellen Bereitstellungsprozess sagt (BTW, wenn es eine SEC-Anmeldung über Ihre Bereitstellung gibt, kann etwas schrecklich falsch gegangen sein). Während des Einsatzes des neuen Codes hat jedoch einer der Rittertechniker den neuen Code nicht auf einen der acht SMARS-Computer-Server kopiert. Knight hatte keinen zweiten Techniker, der diese Bereitstellung überprüfte und niemand bei Knight erkannte, dass der Power Peg-Code nicht vom achten Server entfernt worden war und der neue RLP-Code nicht hinzugefügt wurde. Ritter hatte keine schriftlichen Verfahren, die eine solche Überprüfung erforderten. SEC Filing Release Nr. 70694 16. Oktober 2013 Um 9:30 Uhr Eastern Time am 1. August 2012 eröffneten die Märkte und Knight begann im Auftrag ihrer Kunden Aufträge von Broker-Händlern für das neue Retail Liquidity Program zu verarbeiten. Die sieben (7) Server, die die korrekte SMARS-Implementierung hatten, begannen, diese Aufträge korrekt zu bearbeiten. Aufträge, die an den achten Server gesendet wurden, lösten die angeblich wiederverfügte Flagge aus und brachten den Toten den alten Power Peg Code zurück. Angriff der Killer-Code Zombies Es ist wichtig zu verstehen, was der tote Power Peg-Code zu tun war. Diese Funktionalität sollte dazu bestimmt sein, die Aktien bürgerlich gegen eine Elternordnung zu zählen, als Kinderaufträge ausgeführt wurden. Power Peg würde das System anweisen, die Befehlsaufträge zu stoppen, sobald die übergeordnete Bestellung erfüllt war. Grundsätzlich würde Power Peg die Kinderaufträge behalten und sie stoppen, sobald die übergeordnete Bestellung abgeschlossen war. Im Jahr 2005 hat Knight diese kumulative Tracking-Funktionalität zu einem früheren Stadium der Codeausführung bewegt und damit die Zählverfolgung von der Power Peg-Funktionalität entfernt. Als das Power Peg-Flag auf dem achten Server aktiviert wurde, fing die Power Peg-Funktionalität an, Kinderaufträge für die Ausführung zu leiten, aber war nicht die Verfolgung der Menge an Aktien gegen die übergeordnete Reihenfolge etwas wie eine endlose Schleife. 45 Minuten der Hölle Stellen Sie sich vor, was passieren würde, wenn Sie ein System hätten, das in der Lage wäre, automatisierte, schnell geschaltete Aufträge in den Markt zu schicken, ohne zu verfolgen, ob genug Aufträge ausgeführt worden sind. Ja, es war so schlimm. Als der Markt um 9:30 Uhr eröffnete, wussten die Leute schnell, dass etwas nicht stimmte. Um 9:31 Uhr war es für viele Leute an der Wall Street offensichtlich, dass etwas Ernstes passierte. Der Markt wurde mit Aufträgen aus dem ordentlichen für reguläre Handelsvolumina auf bestimmte Bestände überschwemmt. Um 9:32 Uhr waren viele Leute an der Wall Street gefragt, warum es nicht aufgehört hatte. Dies war eine Ewigkeit in High-Speed-Trading-Bedingungen. Warum hatte niemand den Kill-Switch auf was auch immer das System getan hat. Wie es sich herausstellt, gab es keinen Kill-Schalter. Während der ersten 45-minütigen Handelsrunden führten Ritterausführungen mehr als 50 des Handelsvolumens aus und trieben bestimmte Bestände über 10 ihres Wertes an. Infolgedessen verringerten sich andere Bestände im Wert auf die fehlerhaften Geschäfte. Um die Dinge noch schlimmer zu machen, begann das Knights-System, bereits früh um 8:01 Uhr (wenn SMARS Aufträge für den Pre-Market-Handel in Anspruch genommen hatte), automatisierte E-Mails zu senden. Die E-Mail-Nachrichten verweisen auf SMARS und haben einen Fehler als Power Peg deaktiviert. Zwischen 8:01 und 9:30 Uhr gab es 97 dieser E-Mails an Ritter Personal. Natürlich waren diese E-Mails nicht als Systemwarnungen konzipiert und deshalb sah sie niemand sofort an. Hoppla. Während der 45-Minuten der Hölle, die Ritter erlebt haben, versuchten sie mehrere Gegenmaßnahmen zu versuchen, die falschen Trades zu stoppen. Es gab keinen Kill-Switch (und keine dokumentierten Verfahren, wie man reagiert), so dass sie versuchten, das Problem in einem Live-Trading-Umfeld zu diagnostizieren, wo 8 Millionen Aktien jede Minute gehandelt wurden. Da sie nicht in der Lage waren zu bestimmen, was die falschen Aufträge verursacht, die sie durch die Deinstallation des neuen Codes von den Servern umgesetzt haben, wurde sie korrekt eingesetzt. Mit anderen Worten, sie haben den Arbeitscode entfernt und den gebrochenen Code verlassen. Dies verstärkte nur die Probleme, die zusätzliche übergeordnete Aufträge verursachten, um den Power Peg-Code auf allen Servern zu aktivieren, nicht nur der, der nicht korrekt eingesetzt wurde. Schließlich konnten sie das System nach 45 Minuten des Handels stoppen. In den ersten 45 Minuten war der Markt offen, der Power Peg Code erhielt und verarbeitete 212 Elternaufträge. Infolgedessen setzte SMARS Millionen von Kinderaufträgen in den Markt, was zu 4 Millionen Transaktionen gegen 154 Aktien für mehr als 397 Millionen Aktien führte. Für Sie Aktienmarkt-Junkies bedeutet dies, dass der Ritter etwa 3,5 Milliarden Netto-Long-Positionen in 80 Aktien und 3,15 Milliarden Netto-Short-Positionen in 74 Aktien angenommen. In Laien8217s Begriffe, Knight Capital Group realisiert einen 460 Millionen Verlust in 45 Minuten. Denken Sie daran, Ritter hat nur 365 Millionen in bar und Äquivalente. In 45-Minuten-Ritter ging von der größten Händler in US-Aktien und ein bedeutender Marktmacher in der NYSE und NASDAQ zu bankrott. Sie hatten 48 Stunden Zeit, um das notwendige Kapital zu erheben, um ihre Verluste zu decken (was sie mit einer Investition von 400 Millionen aus rund einem halben Dutzend Investoren zu tun hatten). Knight Capital Group wurde schließlich von Getco LLC (Dezember 2012) erworben und das fusionierte Unternehmen heißt jetzt KCG Holdings. Eine Lektion zum Lernen Die Ereignisse vom 1. August 2012 sollten eine Lehre für alle Entwicklungs - und Operations-Teams sein. Es ist nicht genug, um große Software zu bauen und zu testen, die Sie auch sicherstellen müssen, dass es geliefert wird, um korrekt zu vermarkten, damit Ihre Kunden den Wert erhalten, den Sie liefern (und damit Sie Ihr Unternehmen nicht bankrottieren). Die Ingenieure, die SMARS eingesetzt haben, sind nicht nur die Schuld daran, dass der Prozess, den Ritter eingerichtet hatte, nicht für das Risiko geeignet war, dem sie ausgesetzt waren. Darüber hinaus war ihr Prozess (oder dessen Fehlen) anfällig für Fehler. Jedes Mal, wenn Ihr Deployment-Prozess auf Menschen Lesung und nachfolgende Anweisungen, die Sie sich ausgesetzt sind, riskieren. Menschen machen Fehler. Die Fehler könnten in der Anweisung, in der Auslegung der Anweisungen oder in der Ausführung der Anweisungen sein. Deployments müssen automatisiert und wiederholbar und frei von möglichen menschlichen Fehlern wie möglich sein. Hatte Knight ein automatisiertes Bereitstellungssystem implementiert, das mit der Konfiguration, dem Einsatz und der Testautomatisierung kompatibel ist, ist der Fehler, der die Knightmare verursacht hätte, vermieden. Ein paar der Prinzipien für Continuous Delivery gelten hier (auch wenn Sie nicht einen vollständigen Continuous Delivery Prozess implementieren): Freigeben von Software sollte ein wiederholbarer, zuverlässiger Prozess sein. Automatisieren Sie so viel wie vernünftig Ein Szenario: Nehmen wir an, sie hatten sehr gute DevOps. Also alle Server würden synchron sein. Aber 8211 davon ausgehen, dass der neue Code einen Bug hatte. Also alle Server sind synchron, haben aber den gleichen Buggy Code. Was, wenn zwei Versionen des Codes, d. h. die letzten 2 Bereitstellungen hatte diesen Fehler. Also, sobald sie merken, dass etwas nicht stimmt, holt sie den Code zurück, der Bug ist immer noch still8230 Kostbare Minuten sind vergangen. Vielleicht 20 Minuten statt der 45 Minuten in deinem Artikel. Also in kurzen 8211 ihre Katastrophe Kill-Switch ist ein Code-Rollback-Einsatz in einer Live-Umgebung. Das wäre noch ein defektes Design. Was sie brauchen würde, wäre ein großer roter Schalter (fast wörtlich, irgendwo im Armaturenbrett), um sofort zu stoppen. Wo ist die Geschäftsregel, die sagt, dass es keinen Schaden gibt. VJ, wenn die Bereitstellung auf alle Server gearbeitet hatte, wäre es ok gewesen Aber in diesem Fall wurden 7 von 8 für ein Subsystem korrekt eingesetzt. Weil das schlechte Verhalten, sie rollten die anderen 7 Denken der neue Code in diesem Subsystem war das Problem. Das vervielfachte das Problem bis zum eventuellen Kill-Schalter. Katastrophen sind fast immer komplex In diesem Fall waren es schlechte Codierungspraktiken, plus fragwürdige Testcode-Inspektionspraktiken sowie ein Fehler bei der Bereitstellung sowie ein Rollback bei der Granularität des Subsystems und nicht für das gesamte System. Wenn du irgendwelche dieser Probleme beheben wirst, bekommst du eine Katastrophe. Eines der Dinge, die ich in Unternehmen gesehen habe, die die wahre Bedeutung und die Auswirkungen ihrer IT-Systeme nicht erkennt, ist, dass sie das Budget für Legacy-Code-Updates bieten. Zum Beispiel: I8217ve gesehen Situationen, in denen IT kein Budget hat. Es muss alles rechtfertigen, was es gegen einen Geschäftsaufwand macht. Das bedeutet immer wieder, um neue Projekte aufzurichten. Business sieht selten die Notwendigkeit, alte Software zu aktualisieren, die gerade arbeitet, also weigern sie sich dafür zu bezahlen. Das Ergebnis ist ein konstanter neuer Code, der von den günstigsten Codern möglich gemacht wird, während er nicht in die Technologien investiert, die letztlich die Leistung verbessern und das Risiko verringern würden. Warum, weil diese als 8220IT Probleme8221 gesehen werden und nicht die Einschätzung von was auch immer Projekt die IT-Leute arbeiten, so wird niemand dafür bezahlen. Ein toller Bericht über diese Praxis ist das Phoenix-Projekt von Gene Kim, Kevin Behr und George Spafford. Vielen Dank für die Anwendung des Gehirns auf den Hype. Wahrscheinlich sollte man fragen, warum die beteiligten Techniker die Schuld annehmen wollten, aber sie wurden nicht berechtigt, den eigenen Sender zu töten. Oh, genau das, warum hast du opsSRE sowieso an Ort und Stelle gesetzt. 8220R8221 ist für verantwortlich, aka Flammenköder. Ich habe ein bisschen über dieses Ereignis geschrieben, und ich würde jeden empfehlen, den SEC-Bericht als alles andere zu verwenden, als für das, was die SEC es brauchte. Kitchensoap20131029counterfactuals-Ritter-Hauptstadt Faszinierende lesen. Ich arbeitete an einem großen Auktionshaus für Obst und Gemüse einmal, wo eine neue Software-Version installiert und gescheitert war, was zu großen Verlusten an die Händler (wenn auch nicht so massiv wie diese). Auch dies war ein Fall von unsachgemäßem Einsatz und kein Rückfall. Die Lektion, die gelernt wird, ist, dass es Domains gibt, in denen Computer keine Entscheidung ohne menschliche Validierung treffen sollte. Was ist mit den Leuten, die ihre Arbeit verloren haben, weil, oops, da war ein Bug Was ist mit den anderen Firmen, die vielleicht in Trubble wegen der plötzlichen Änderung der Aktienwert Automation von 8220high Ebene Entscheidungen8221 ist zu behandeln sorgfältig8230 Nizza und pädagogischen Post Btw. Mit dem Cynefin-Framework bietet eine bessere Charakterisierung dieses 8216DevOps8217 Ausfalls Dieser Beitrag scheint aus einer DevOps-Perspektive geschrieben worden zu sein. Die vorgeschlagenen Lösungen sind im Einklang mit einer DevOps-Perspektive 8211 untersuchen den Release-Prozess, automatisieren mehr und Handwerk ein Kill-Switch mit Rollback-Fähigkeiten. Jemand kann die Post lesen und legte zu viel Wert auf den Rittertechniker, der den alten Code nicht auf einen der acht Server kopierte. Jemand kann eine Ursache - und Wirkungsbeziehung überschreiten. Jemand kann auf neue Regeln hineinstecken, um dies zu veranlassen, jemals wieder aufzutreten.8217 Ein stärkerer Ansatz kann investieren: 8211 Erhöhung der Vielfalt, um die Situation zu analysieren und bessere Möglichkeiten zu synthetisieren 8211 Verbessern Sie die Kommunikation zwischen den Spezialitäten 8211 Verbessern Sie die implizite Koordination zwischen den Spezialitäten 8211 Rekrutieren Sie Personen mit mehr Know-how zu schreiben und zu überprüfen Code Ein wichtiger Faktor, dass die Verbesserung der Fähigkeit des Teams von neun Jahren vor dem erheblichen Fehler Ereignis war falsch charakterisieren das System. In einem Cynefin-Framework verknüpft dieses Fehlen eines DevOps-Problems das System mit der Domäne 8220Obvious8221, wo es einfache Ursachen - und Wirkungsbeziehungen gibt, die von 8216professionals erkannt werden.8217 Der Fehler sollte nicht mit der Cynefin 8220Complicated8221 Domäne verknüpft werden, wo eine signifikante Analyse vorliegt Von 8216spezialisten8217 hätte das versagen verhindert Das System sollte mit der Cynefin 8220Complex8221 Domäne 8211 ein komplexes adaptives System verknüpft werden. Das System ist dispositional. Die gleichen Anfangsbedingungen werden nicht das gleiche Versagen (außer durch Unfall). Für weitere Informationen über Cynefin, besuchen Sie en. wikipedia. orgwikiCynefin und CognitiveEdge. Ich schätze Ihre Hervorhebung der stillschweigenden Faktoren in einer solchen Katastrophe. Wie der Autor arbeite ich auch in Operationen, und es ist leicht, in die gleichen alten Gedankenmuster auf Ursachen und Lösungen zu fallen. Ich freue mich besonders auf die Vielfalt (die in allen Formen kommt: Erfahrungsstufen, kulturelle und pädagogische Hintergründe, Skillsets, Alter usw.), wie ich denke, das ist ein starker Fahrer hinter dem Erfolg von DevOps selbst. Mit einer Vielzahl von Perspektiven, sowohl innerhalb als auch ohne Ihr Team, Blick auf Ihr Projekt hat ein starkes, nachweisbares Potenzial und kann helfen, Eindringlinge wie die, die in diesem Artikel aufgewachsen. Gt Warum Code, der seit 8 Jahren tot war, war noch in der Codebasis vorhanden, ist ein Mysterium, aber das ist nicht der Punkt Im Gegenteil, das ist genau der Punkt. Code mit unbenutzten und daher ungetesteten Konfigurationsmöglichkeiten ist eine Katastrophe, die darauf wartet zu passieren. Dies ist der Grund, warum I8217m sehr skeptisch über Feature-Flag-basierte Ansätze im Allgemeinen. Konfiguration ist so viel ein Teil Ihres Programms wie Code ist, und Konfigurationsänderungen sollten durch den gleichen Lebenszyklus gehen 8211 ziehen Anforderung, Code-Überprüfung, Release, Bereitstellung auf Staging 8211 wie jede andere Änderung. Wenn Ihr Release-Prozess zu schwer ist und Sie müssen schnell konfigurieren Änderungen an der Produktion, beheben Sie Ihre Release-Prozess. Es gab zu viele Fehler, um das epische Versagen nur DevOps zuzuschreiben (obwohl ich voll und ganz zustimme, dass Automatisierung und Test ist der einzige Weg): 8211 Keine Teamarbeit und Checklisten bei einem Update auf Produktionsservern. Jede Aktualisierung auf Produktion sollte ein Team über einander beobachten, und durch eine Checkliste. 8211 8 Jahre unbenutzter alter Code in Produktion. Das erzählt Ihnen viel über den Mangel an Verständnis über die Risiken der baumeln 8220unused8221 Code. 8211 Unzureichende Protokollierung aus dem Code und unzureichende Echtzeit-Protokollüberwachung, Korrelation und Analyse. Das hätte genügend Anhaltspunkte für die Ingenieure und Ops-Leute gegeben. 8211 Kein Hot-Hot-Failover zu einem Cluster mit der vorherigen Version. Das hätte nach 1 oder 2 Minuten alle Probleme aufgegeben. (Das ist der Fehler rote Taste, die der Artikel erwähnt) Wenn Sie auch schon seit langem Software, Systeme und Unternehmen architektonisch kennengelernt haben, wissen Sie, dass manche Bugs nur in der Wildnis gefangen werden und nicht während der Simulationen, genau wie Sie Die Maschinen werden nach unten gehen. Sie müssen sich in beiden Szenarien auf den schlimmsten Fall vorbereiten. Murphy8217s Gesetz ist so wahr in unserer Welt I8217ve gewesen in dem, was jetzt genannt wird der 8220DevOps8221 Raum für fast 20 Jahre, mehr als die Hälfte davon in der Finanzwelt. Ritter war sowohl ein Verkäufer als auch ein Konkurrent des Unternehmens, für das ich zurzeit arbeite. Bereitstellungsautomatisierung könnte geholfen haben. Könnte sein. Aber nur wenige Unternehmen können sich genau doppelte Umgebungen leisten, und dies wurde im Wesentlichen durch Umweltunterschiede verursacht. Auch eine automatisierte Validierung des Einsatzes hätte in diesem Fall nicht geholfen, wenn die Automatisierung nicht über den Umweltunterschied informiert hätte. Automatisierung ist nur so gut wie das Wissen der Leute, die es aufstellen. Wenn eine manuelle Installation nicht auf das alte System aufmerksam geworden wäre, dann gibt es eine gute Chance, dass das automatisierte System es auch nicht gewollt hat. Automatisierung eines Rollbacks ist auch nur so gut wie die Entscheidungsfindung, ob man den Roll-back machen soll. Und wenn die Automatisierung das alte System unbeabsichtigt gestartet hat, gibt es auch keine Garantie dafür, dass das Umschalten des zeitgenössischen Systems zurückgegangen wäre, das alte System 8211 hätten Sie auch nach einem automatisierten Rollback des zeitgenössischen Systems mit demselben Problem enden können. Das bringt mich zu einem letzten Punkt: Automatisierung ist eine Voraussetzung in großen, modernen Umgebungen. Aber über-Vertrauen auf sie kann zu den Leuten führen, die das System betreuen, das nicht bewusst ist, was it8217s tut. Automatisierung ist für die Validierung am nützlichsten, denn die Validierung der Dinge ist korrekt durchgeführt ist langweilig und einfach zu skimp auf, wenn manuell durchgeführt. Auch bei der Automatisierung, mit menschlichen Pausen oder menschlich betriebenen Schritten hilft sicherzustellen, dass diejenigen, die das System betreiben, das System kennen und wie es funktioniert, erheblich verbessert ihre Fähigkeit, Probleme zu beheben, Probleme zu diagnostizieren und geeignete Vorschläge zu machen, welche Schritte zu ergreifen Stoppen oder mildern ein Problem. Automatisierung ist ein Werkzeug, aber es ist nur ein Werkzeug, und es bedarf noch eines Handwerkers, um es entsprechend auszuführen. Kompetenz ist das, was macht und hält große Systeme großartig. Hat diesen Eintrag auf Garrett S. Y. Hampton gerebloggt und kommentiert: Incredible. DevOps immer aufpassen, dokumentieren und überprüfen Sie Ihre DeploymentsKnight Capital Group: Hat ein versehentlich böser Computer klopfen ein Trading House Knight Capital Group (Ritter) ist ein Handelshaus, das anderen hilft, die Finanzmärkte zu erreichen, indem sie ihre Trades ausführen. Es dient als markierter Marktmarker, was bedeutet, dass es Buysell-Aufträge anbietet, so dass andere immer einen Handel gegen sie ausführen können, für mehr als 600 Wertpapiere an den NYSE - und NASDAQ-Börsen. Es dient auch als Market Maker für viele andere Wertpapiere. Weil Markt machen und Handel sind Schlüsselaktivitäten auf den Finanzmärkten, die zuverlässige und ehrliche Handlung, ist es kein Wunder, dass seine Website trägt den Slogan The Standard of Trust. Also, was ist an den Vorfall zu denken, der am 1. August stattfand, wo eine Flut von Trades von Knight dazu führte, dass er eine Handelsposition von 7 Milliarden ansammelte, weit mehr als es sicherstellen konnte, was zu einer konzertierten Anstrengung führte, um die Position zu vertreiben Bis zu einem weniger riskanten Niveau In seiner Eile, um seine Risiko-Exposition zu reduzieren, es unweigerlich verkauft einige seiner Bestände billig (auch bekannt als ein Feuer Verkauf), und am Ende verlieren 440 Millionen. Auch gegen die Standards der Verluste, die wir in dieser Finanzkrise gewöhnt haben, war es ein sehr schlechter Tag für Ritter. Seitdem ist Ritter in der Lage, Investoren mit frischem Kapital von 400 Millionen zu finden, im Wesentlichen die gleiche Menge, die es verloren hat, was die Firma stabilisiert, wenn es keine katastrophalen Verluste erleidet. Es hat auch den Grund für den plötzlichen Anstieg der Kaufaufträge untersucht. Hier ist die Information ein wenig unklar, aber Wall Street Journal berichtet einen unerwarteten Grund: Ein verpfuschtes Update von Computersystemen. Was scheint passiert zu haben, ist, dass die neuen Computersysteme korrekt installiert und bearbeitet wurden, aber sie wurden nicht auf allen Handelsplattformen installiert (jedes System muss über alle Handelsplattformen repliziert werden). Dies führte zu alten Systemen, die auf einigen Plattformen handelten, während neue Systeme auf andere gehandelt wurden, und anscheinend waren es die alten Systeme, die schief gegangen waren. Genau wie dies möglich ist, ist unklar, weil die alten Systeme offensichtlich schon früher gearbeitet haben, aber ein möglicher Grund dafür ist, dass die alten Systeme ihre Trades nicht mehr dem Risikomanagementsystem verliehen haben, so dass der Beitrag ihres Trades zum Gesamtrisiko unentdeckt wurde. Diese Erklärung ist spekulativ, aber wenn die Berichte, die das neue System gut funktionierte, richtig sind, dann deutet der riesige Aufbau von Kaufaufträgen darauf hin, dass es einige Informationen gegeben haben muss, die aus dem Risikobewertungssystem fallen gelassen wurden. Diese Geschichte des Computerfehlers beginnt und endet mit menschlichem Fehler. Die Leute haben es versäumt, das neue System über alle Handelsplattformen hinweg zu installieren, und die Menschen haben es geschafft, den Handel zu stoppen, als die NYSE-Trading-Boden-Beamten die ungewöhnlichen Trades bemerkten und Ritter gewarnt hatten, dass es die Quelle für ungewöhnliche Handelsbewegungen sei. Aber der entscheidende Punkt hier ist, dass die Computersysteme so schnell und effektiv in ihrer Arbeit waren, dass es wenig Zeit gab, sie zu stoppen, sobald sie gegangen sind. Dies ist ein Phänomen, das aus der Forschung über organisatorische Unfälle bekannt ist. Es ist auch eine Hauptursache für Fehlverhalten, wie ich bei der Arbeit mit den Kollegen Don Palmer und Jo-Ellen Pozner bemerkt habe. Im Falle von Ritter waren die Trades wohl so gefährlich, dass es ein Urteil ist, ob die Firma ihre Pflichten für ein ordnungsgemäßes Risikomanagement (Klagen, jedermann) wahrgenommen hat. Allerdings wird die Zuweisung von Verantwortung schwierig sein, weil diese Trades zufällig waren und der Unfall in der Schnittstelle zwischen schnellen und fehlerhaften Computern auftrat, und langsamere Menschen, die versuchen, aufzuholen. Eindeutig hat diese Geschichte wichtige Lehren für die Art und Weise, wie Organisationen über das Management von Risiken und die Qualitätskontrolle nachdenken, zumal sie mehr und mehr ihre Schlüsselsysteme automatisch machen. Es ist auch eine Erinnerung daran, dass die Finanzmärkte menschliche Händler enthalten, die in ihren Urteilen sehr fehlerhaft sein können und sie mit Computern ersetzen, macht manchmal die Urteile noch schlimmer. Und schließlich, wenn du jemals ein Software-Upgrade gehabt hast, geh schlecht, denke an Knight Capital und wie viel schlimmer könnte es sein: Ich bezweifle, dass du jemals ein Computer-Upgrade erlebt hast, das Geld von deinem Bankkonto zurückzog und es an Fremde verteilte. Greve, H. R. Palmer, D. und Pozner, J. 2010. Organisationen Gone Wild: Die Ursachen, Prozesse und Konsequenzen des organisatorischen Fehlverhaltens. Die Akademie der Management-Annalen. 4: 1, 53 107. Patterson, S. J. Strasburg und J. Bunge. 2012. Ritter Upgrade ausgelöst Old Trading System, Big Losses. Wallstreet Journal . 15.8.2012 Kommentar hinzufügen Bereits Mitglied Henrich R. Greve ist Professor für Entrepreneurship bei INSEAD. Die meisten geteilten Artikel Wie ein Paar indische Krankenhäuser haben keine Kosten-Chirurgie ein nachhaltiges Gesundheitswesen Paradigma gemacht. Der Manager der Zukunft muss Mind-Sets verwalten, einschließlich seiner eigenen. T. co6hUfF9Pbjt t. co7MMvy6RL0B knowledge. insead. edubloginsead-blogintelligent-boards-know-its-limits-5321 über INSEADKnowledge Erfolg im Management erfordert das Lernen so schnell wie die Welt sich verändert. - Warren Bennis via INSEADKnowledge Am beliebtesten in der App: Innovationen an den Kreuzungen t. coNCd8aCXfmU t. coki40D6zX48 knowledge. insead. edumobile-apps via INSEADKnowledge Auke Hunneman. 27.02.2017 um 01.40 Uhr Danke für deine Antwort Steven - Danke für deine Antwort Steven. Steven Sweldens. 27.02.2017 um 10.37 Uhr Danke Auke, für die - Danke Auke, für die Referenz. Die Antifragment-Idee ist sicherlich verwandt, aber. Tom Cummings 27.02.2017 um 10.12 Uhr Vorstandsmitglied, Tallberg-Stiftung - Ron Soonieus macht einen wichtigen Punkt, wie die vorgeschlagene Fusion Jring281 26.02.2017 um 07.17 Uhr Fellow INCOSE - Interessante Hypothese Bei dem Versuch, es zu implementieren, können zwei Fehler auftreten. 1. Strategie. Praveen Valliavalappil (Will). 24.02.2017 um 07.48 Uhr Direktor - Ingenieurwesen - Hallo Steve, liebte das Lesen. Sehr gut artikuliert Ich stimme zu, dass, wenn wir in der. Im Fokus Das INSEAD Global Leadership Center bietet ein einzigartiges Know-how als führendes Zentrum für Forschung und Praxis in Führung und. Eine Partnerschaft zwischen INSEAD Knowledge, KnowledgeWharton und dem World Economic Forum Global Agenda Council on Emerging Market. Um die Chancen der Digitalisierung zu nutzen, müssen die Organisationen und Führungskräfte die neuen Geschäftsrealitäten umarmen. Eine dunkle Magie: Der Aufstieg der Roboterhändler Bildunterschrift Handelsplätze: Die hektischen Händlerböden der 1980er Jahre wurden durch riesige Reihen von Computer-Servern ersetzt Kann nicht auf Geschwindigkeit konkurrieren, es ist so einfach wie das. Vor zehn Jahren war John Coates ein Händler in der Wall Street. Heute ist er Neurowissenschaftler an der Universität von Cambridge und verbringt seine Tage mit Hormonen, um zu sehen, was sie tickt. Es gibt einfache Tests, die Sie tun können. Wenn du ein grünes Licht siehst. Du klickst eine Maus. Die schnellste, die Sie tun können, ist 100 bis 120 Millisekunden. Jede grundlegende kognitive Verarbeitung, die Dinge aus, dann vielleicht 200 bis 300 Millisekunden. Das Problem ist, die Boxen - das letzte Mal sah ich - sie verarbeiteten einen Handel in 10 Millisekunden, und heute denke ich. Sprachen über millionstelsekunden Diese Boxen sind die Roboter-Händler - Computer, die ihre eigenen Entscheidungen über wann zu kaufen und zu verkaufen, aber tausendmal schneller als jeder Mensch kann. Sie betreiben Algos, die effektiv nachahmen, was Händler verwendet haben, um Remco Lenterman, Direktor des Handelsunternehmens IMC zu tun. Wenn Sie an einen Handelsboden in London oder New York denken, dann denken Sie vielleicht eine Schar von verschwitzten Männern, die sich gegenseitig aus dem Weg wie sie Verwenden Sie aufwendige Fingerbewegungen, um ihre hektischen Befehle zu vermitteln. Sein ein Bild, das durch die achtziger Jahre Komödie Trading Places popularisiert wird. Aber auch 30 Jahre veraltet. Denn die Tatsache ist, dass der Finanzhandel eine computergesteuerte Revolution verliebt hat, die mit der Amazonen-Übernahme der High Street verwandt ist. Die ganze wirkliche Aktion ist in den Cyberspace umgezogen. Nehmen Sie die New Yorker Börse. In diesen Tagen findet der Handel nicht hinter seiner berühmten neoklassizistischen Fassade direkt an der Wall Street statt, sondern in weit weniger glamourösem New Jersey. Das ist, wo die NYSE hat eine riesige elektronische Handels-Anlage für 10 Hektar (vier Hektar), Gehäuse-Zeile auf Reihe von Computer-Servern eingerichtet. Und viele weitere Hektar werden von den Servern der Roboterhandelsfirmen besetzt, die dazu aufgehört haben. Nerdy brainboxes Computergesteuerter Handel ist eine inhärent geheimnisvolle Welt. Die Handelsfirmen halten ihre Handelsstrategien, Menschen und Computer-Code (oder Algorithmen) fest. Andernfalls könnte ein Konkurrent seine komplexen, aber vollautomatischen Handelsmuster herausfinden und dann kopieren, oder noch schlimmer noch, schlagen ihre Computer in die Übergabe von Millionen. Bildunterschrift Die Loadsamoney-Trader der 1980er Jahre sind dem Mülleimer der Geschichte überlassen worden. Remco Lenterman, ein Direktor einer solchen Firma, IMC in den Niederlanden, versucht, sein Geschäft zu entmystifizieren. Er sagt: In den alten Tagen, vor 10 Jahren, würde ein Schreibtisch von Aktienhändlern zwischen 80 und 100 von menschlichen Händlern an einer Investmentbank haben. Heute sind es vielleicht acht von ihnen übrig. Was sie tun, ist Algos zu betreiben, die effektiv imitieren, was die Händler zu tun pflegten, und sie definieren ständig diese Algos und überwachen das Risiko, was auf dem Markt vor sich geht. Mit anderen Worten, die ikonischen High-Testosteron-Loadsamoney-Trader der Vergangenheit - die Masters of the Universe, die vom amerikanischen Autor Tom Wolfe im Bonfire of the Vanities verspottet wurden - wurden von Quants, den nerdy-Gehirnkisten, die die Computerprogramme entwerfen und ausführen, verdrängt . In einem neueren Post-Skript zu seinem Roman für das Daily Beast geschrieben. Tom Wolfe beklagte die Entmannung seiner Anti-Helden und benannte sie Eunuchen des Universums um. Nähere Server, geradere Kabel Firmen wie Lentermans machen ihr Geld, indem sie eine winzige Gewinnspanne auf ein unvorstellbar großes Volumen von Schnellfeuer kaufen und verkaufen. Verschiedene Algo-Trader verwenden sehr unterschiedliche Strategien. Aber sie alle teilen die Notwendigkeit, Handelschancen zu identifizieren - flüchtige Diskrepanzen zwischen dem verfügbaren Marktpreis und wo der Computer den Preis wahrnimmt - und dann reagieren sie schneller als jeder andere. Race to zero Die Optionen, die Ende letzten Jahres für alle, die einen elektronischen Handelsauftrag zwischen New York und Chicago senden möchten: die Zeit, die für eine komplette Hin - und Rückfahrt benötigt wird, heißt das Rennen auf Null. Und es hat zur Investition von Milliarden von Dollar in schnellere, intelligentere Computer und in den schnellsten Verbindungen geführt. An Börsen über den Planeten zahlen die Händler kräftige Gebühren, um ihre Server direkt neben den Börsen zu lokalisieren. Und Hunderte von Millionen wurden für den Aufbau gerader Kabel ausgegeben, um ein paar Bruchteile einer Sekunde von der Zeit, die es braucht, um Aufträge zwischen den Welten große Handelszentren zu verteilen: London, New York, Chicago und Tokio. All dies kann ein wenig irrational erscheinen, wenn die britischen und US-Regierungen kämpfen, um zusammen genug Geld zu kratzen, um die Infrastruktur zu aktualisieren, die benötigt wird, um Menschen von einem Ort zum anderen zu fähren. Flash Crash Es gibt jedoch eine dunklere Seite zu diesem Rush zu computerisieren. Zum Beispiel können Unfälle passieren. Im vergangenen August wurde die Hightech-Finanzfirma Knight Capital an den Rand des Konkurses durch einen Algorithmus gebracht, der haywire ging und mehr als 440m Verluste in nur 45 Minuten, bevor es ausgeschaltet wurde. Vielleicht war das berühmteste Missgeschick der mittlerweile legendäre Flash Crash, um 2.45 Uhr in New York am 6. Mai 2010. In ein paar Minuten stürzte die New Yorker Börse, und dann genauso wie plötzlich wieder erholt. Aktienkurse in einigen Firmen, wie die Beratung Accenture, fiel auf einen Bruchteil über Null, während Apple auf 100.000 anstieg. Für Monate danach konnte niemand erklären, was schief gegangen war Die offizielle US-Regulierungsuntersuchung sagte, dass es durch einen einzigen Auftrag ausgelöst worden sei, der von einer großen Institution unter Verwendung einer algorithmischen Handelsstrategie platziert wurde. Aber was machte viel schlimmer war ein heißer Kartoffel-Effekt: Inmitten der Verwirrung, eins nach dem anderen die Roboter-Händler versuchten zu schneiden und laufen, und die Börsen Computer wurden überschwemmt. Gerechte Manipulation Die neuen algorithmischen Händler wurden auch von einem ziemlich altschulischen, ruchlosen Verhalten angeklagt. Eric Hunsader, der US-Datenanalyse-Firma Nanex, sagt, dass Miniatur-Versionen des Flash Crashs in einzelnen Beständen mehrmals am Tag passieren, und er behauptet, dass eine Menge davon eine direkte Manipulation ist. Er hat Diagramme erstellt, die das seltsame und wunderbare Verhalten der Märkte darstellen. Als Computer versuchen, sich gegenseitig zu überholen, indem sie schnell und schnell Tausende von Aufträgen auslöschen. Bildunterschrift Ein Nanex-Diagramm, das den Google-Mini-Blitz-Crash vom 22. April dieses Jahres veranschaulicht Wir erlauben den Menschen, schnellere Verbindungen zu platzieren und zu entfernen Angebote oder Gebote schneller als die Geschwindigkeit des Lichts können diese Informationen an die anderen Marktteilnehmer liefern. Und er ist nicht der einzige, der besorgt ist, dass einige computerisierte Händler vielleicht nicht gut sind. Leider ist die Art der Märkte, dass es immer Potenzial für missbräuchliche Aktivitäten gibt, und mit sehr, sehr schnellem Handel, können diese Dinge sehr, sehr schnell passieren, sagt Martin Wheatley, Leiter der britischen neu geschaffenen Financial Conduct Authority. Ehrlich gesagt, für die Regulierungsbehörde, schafft es ein Problem versuchen, aus der riesigen Menge an Daten Trades, die möglicherweise missbräuchlich sein könnte. Eine Dunkelmagie, präsentiert von BBC Business Editor Robert Peston, wird am 8. Juli 2013 auf Radio 4 ausgestrahlt und steht danach auf dem BBC iPlayer zur Verfügung. Teilen Sie diese Geschichte über das Teilen