Blog

Verlieren Sie nicht 460 Millionen Dollar durch einen Softwarefehler

von Vivian Au 7. November 2013 | 7 Minuten Lesezeit

software bug Hochfrequenzhandel macht 50 % des US-amerikanischen Wertpapierhandels aus. Da jede Millisekunde Tausende von Wertpapieren im Wert von Millionen von Dollar gehandelt werden, sind robuste und zuverlässige Computersysteme für die Automatisierung dieser Transaktionen unerlässlich. Diese automatisierten Mikrotransaktionen können enorme Gewinne abwerfen. Treten jedoch Probleme auf, können schwerwiegende Folgen entstehen, die sich bei Nichtbehebung der Probleme noch verschärfen.

Am 1. August 2012 verlor Knight Capital nach 45 Minuten Handel 460 Millionen Dollar. Knight erhielt 97 E-Mails von seinen Systemen, die sie über das Problem informierten, reagierte aber zu spät. SEC-Bericht zur Todesanalyse Der am 16. Oktober 2013 veröffentlichte Bericht geht detaillierter auf die Ereignisse ein, die zu dem Softwarefehler führten, aber der folgende Punkt fasst den mangelhaften DevOps-Prozess bei der Implementierung eines neuen Codes zusammen:

15. Ab dem 27. Juli 2012 führte Knight den neuen RLP-Code in SMARS schrittweise ein, indem er ihn an aufeinanderfolgenden Tagen auf einer begrenzten Anzahl von Servern in SMARS installierte. Während der Bereitstellung des neuen Codes kopierte jedoch einer der Techniker von Knight den neuen Code nicht auf einen der acht SMARS-Computerserver. Knight ließ diese Bereitstellung nicht von einem zweiten Techniker überprüfen, und niemand bei Knight bemerkte, dass der Power-Peg-Code weder vom achten Server entfernt noch der neue RLP-Code hinzugefügt worden war. Knight verfügte über keine schriftlichen Verfahren, die eine solche Überprüfung vorschrieben. (Seite 6)

Softwarefehler können in jeder Branche zu enormen Verlusten führen. Wenn Sie einen Onlineshop betreiben oder Werbung auf Ihrer Seite schalten, verlieren Sie jede Sekunde Geld, in der Ihre Seite nicht erreichbar ist. Auch die Kundenbindung leidet. Unzufriedene Kunden wechseln zur Konkurrenz. Lange Reaktionszeiten haben finanzielle und reputationsschädigende Folgen. Handeln Sie daher umgehend, wenn Probleme auftreten.

3 Schritte für ein schnelles IT-Vorfallsmanagement

Fehler können in jeder Entwicklungsphase entstehen und sind die Folge menschlichen Versagens. Auch zu ihrer Behebung ist menschliches Eingreifen erforderlich. Basierend auf den drei größten Fehlern von Knight Capital sollten Sie die folgenden Best Practices implementieren, um Ihre IT-Vorfälle zu minimieren.

1. Schwellenwerte festlegen.

B. Knight verfügte nicht über angemessene Kontrollmechanismen, um zu verhindern, dass Aufträge für Aktien erteilt wurden, deren Gesamtkapital die vorab festgelegten Schwellenwerte für das Unternehmen überschritten, wie in Regel 15c3-5(c)(1)(i) vorgeschrieben. Insbesondere versäumte Knight es, Konten mit unternehmensweiten Kapitalschwellenwerten zu verknüpfen, und Knight verließ sich auf Finanzrisikokontrollen, die nicht in der Lage waren, die Erteilung von Aufträgen zu verhindern (Seite 4).

Knight Capital beging einen schweren Fehler, indem das Unternehmen keine Limits an seine finanzielle Leistungsfähigkeit anpasste. Hätte es finanzielle Schwellenwerte, beispielsweise ein Limit von 75 % des Kapitals, festgelegt, hätte es einen Teil seines Verlusts von 450 Millionen US-Dollar verhindern können. Computersysteme werden immer komplexer, und viele Komponenten können ausfallen, wenn Limits überschritten werden. Website-Ausfälle können durch Probleme mit der DNS-Performance oder der CPU-Auslastung verursacht werden. Daher sollten Sie hierfür Schwellenwerte festlegen. Anstatt zu warten, bis die CPU-Auslastung 100 % erreicht, setzen Sie Ihren Schwellenwert auf 70 %, um einen katastrophalen Ausfall zu vermeiden. Schwellenwerte signalisieren drohende schwerwiegende Vorfälle und schaffen ein Gefühl der Dringlichkeit, Probleme zu beheben. Setzen Sie proaktive Schwellenwerte, um ein Überschreiten der kritischen Grenze zu verhindern.

2. Einen Personalprozess erstellen.

19. Am 1. August erhielt Knight auch Aufträge, die für das RLP-Programm geeignet waren, aber für den vorbörslichen Handel bestimmt waren. SMARS verarbeitete diese Aufträge, und ab ca. 8:01 Uhr ET generierte ein internes System bei Knight automatisch E-Mails (sogenannte „BNET-Ablehnungen“), die SMARS erwähnten und einen Fehler mit der Beschreibung „Power Peg deaktiviert“ meldeten. Das System von Knight versandte 97 dieser E-Mails an eine Gruppe von Knight-Mitarbeitern vor Börsenbeginn um 9:30 Uhr. Knight hatte diese Art von Nachrichten nicht als Systemwarnungen vorgesehen, und die Mitarbeiter von Knight prüften sie in der Regel nicht direkt nach Erhalt. Da diese Nachrichten jedoch in Echtzeit versendet wurden, durch den Fehler bei der Codebereitstellung verursacht wurden, bot sich Knight die Möglichkeit, das Codierungsproblem vor Börsenbeginn zu identifizieren und zu beheben. Diese Benachrichtigungen wurden vor Börsenbeginn nicht bearbeitet und auch nach Börsenbeginn nicht zur Diagnose des Problems herangezogen. (Seite 6)

27. Am 1. August verfügte Knight über keine Aufsichtsverfahren für die Reaktion auf Vorfälle. Insbesondere fehlten Knights Aufsichtsverfahren, um die zuständigen Mitarbeiter bei Auftreten schwerwiegender Probleme anzuleiten. Am 1. August verließ sich Knight hauptsächlich auf sein IT-Team, um das SMARS-Problem im laufenden Handel zu identifizieren und zu beheben. Das System von Knight sendete weiterhin Millionen von untergeordneten Aufträgen, während die Mitarbeiter versuchten, die Fehlerursache zu ermitteln. In einem Lösungsversuch deinstallierte Knight den neuen RLP-Code von den sieben Servern, auf denen er korrekt installiert war. Diese Maßnahme verschärfte das Problem, da zusätzliche eingehende übergeordnete Aufträge den auf diesen Servern vorhandenen Power-Peg-Code aktivierten, ähnlich wie bereits auf dem achten Server geschehen. (Seite 8)

Die Systeme von Knight Capital versendeten 97 E-Mails, um vor einem Problem zu warnen. Diese E-Mails dienten weder der Prävention noch der Diagnose des Problems. Was nützt eine Warnung, wenn niemand da ist, der sie empfängt? Sobald Schwellenwerte überschritten werden, müssen die zuständigen Personen umgehend kontaktiert werden, um den Vorfall zu beheben. Da Computersysteme rund um die Uhr laufen, werden Teams gebildet, die auf auftretende Probleme reagieren. Ob ein Netzwerkbetriebszentrum (NOC) oder ein Bereitschaftsdienstplan implementiert ist – die richtigen Ansprechpartner müssen unabhängig von ihrem Standort erreichbar sein. Wer Bereitschaftsdienst hat, ist für alle eingehenden Vorfälle verantwortlich und muss schnell handeln, um kritische Probleme zu lösen. Die Zuordnung von Personen zu einem Vorfall schafft Verantwortungsbewusstsein und Rechenschaftspflicht.

3. Aus früheren Vorfällen lernen.

33. Mehrere vorangegangene Ereignisse boten Knight die Gelegenheit, die Angemessenheit seiner Kontrollmechanismen umfassend zu überprüfen. Beispielsweise führte Knight im Oktober 2011 einen Notfallwiederherstellungstest am Wochenende mit Testdaten durch. Nach Abschluss des Tests nutzte der LMM-Handelstisch von Knight irrtümlicherweise weiterhin die Testdaten, um am darauffolgenden Montagmorgen automatisierte Kurse zu generieren. Knight erlitt dadurch einen Verlust von fast 7,5 Millionen US-Dollar. Knight reagierte darauf, indem der Systembetrieb auf die Marktzeiten beschränkt, die Kontrollmaßnahme so geändert wurde, dass das System nach der Auftragserteilung keine Kurse mehr lieferte, und ein Punkt in die Checkliste für die Notfallwiederherstellung aufgenommen wurde, der die Überprüfung der Testdaten vorschrieb. Knight prüfte nicht umfassend, ob ausreichende Kontrollmechanismen vorhanden waren, um die Eingabe fehlerhafter Aufträge zu verhindern, unabhängig vom jeweiligen System, das die Aufträge gesendet hatte, oder der Ursache des Systemfehlers. Knight verfügte auch über keinen Mechanismus, um zu testen, ob seine Systeme auf veraltete Daten zurückgriffen. (Seite 10)

Der Vorfall bei Knight im August 2012 war nicht der erste. Nach einem Verlust von 7,5 Millionen US-Dollar durch einen Vorfall im Oktober 2011 hatte Knight nicht genügend Kontrollmechanismen implementiert, um zukünftige fehlerhafte Auftragserfassungen zu verhindern. Sie hätten den Verlust von 7,5 Millionen US-Dollar – im Vergleich zu ihrem Verlust von 450 Millionen US-Dollar im Folgejahr – als kleine Lektion nutzen und die Angemessenheit ihrer Kontrollmechanismen erneut überprüfen sollen. Nach jedem Vorfall ist es notwendig, die Geschehnisse zu analysieren und den Vorfallmanagementprozess zu optimieren. Konsistente und präzise Messungen helfen, Trends aufzudecken. Diese Trends fließen dann in die Festlegung von Schwellenwerten und die Verfeinerung der internen Prozesse bei Vorfällen ein und tragen letztendlich zu einem effizienteren Vorfallmanagement bei.

Lassen Sie Probleme nicht ungelöst; beheben Sie sie sofort. Vorfälle sind kostspielig – Kunden sind verärgert, der Ruf wird geschädigt und Geld geht verloren. Im Fall von Knight Capital belief sich der Verlust auf Hunderte von Millionen. Die drei oben genannten Best Practices sind ein fortlaufender, nie endender Prozess, aber er lohnt sich.