- PagerDuty /
- Der Blog /
- Zuverlässigkeit /
- Verlieren Sie nicht 460 Millionen Dollar durch einen Softwarefehler
Der Blog
Verlieren Sie nicht 460 Millionen Dollar durch einen Softwarefehler
Der Hochfrequenzhandel macht 50 % des US-Wertpapierhandels aus. Da jede Millisekunde Tausende von Wertpapieren im Wert von mehreren Millionen Dollar gehandelt werden, sind robuste und zuverlässige Computersysteme erforderlich, um den Handel zu automatisieren. Diese automatisierten Mikrotransaktionen können enorme Gewinne einbringen. Aber es können schwerwiegende Folgen auftreten, wenn ein Problem auftritt, und diese werden noch verschärft, wenn es nicht behoben wird.
Am 1. August 2012 verlor Knight Capital nach 45 Handelsminuten 460 Millionen Dollar. Knight erhielt 97 E-Mails von seinen Systemen, die sie über das Problem informierten, aber sie reagierten zu spät. Die SEC-Post-Mortem-Dokument veröffentlicht am 16. Oktober 2013 geht näher auf die Ereignisse ein, die zu dem Softwarefehler geführt haben, aber der folgende Punkt fasst den mangelhaften DevOps-Prozess bei der Implementierung eines neuen Codes zusammen:
15. Ab dem 27. Juli 2012 setzte Knight den neuen RLP-Code in SMARS schrittweise ein, indem er ihn an aufeinanderfolgenden Tagen auf einer begrenzten Anzahl von Servern in SMARS platzierte. Während der Bereitstellung des neuen Codes kopierte jedoch einer von Knights Technikern den neuen Code nicht auf einen der acht SMARS-Computerserver. Knight ließ diese Bereitstellung nicht von einem zweiten Techniker überprüfen, und niemandem bei Knight fiel auf, dass der Power Peg-Code nicht vom achten Server entfernt und der neue RLP-Code nicht hinzugefügt worden war. Knight hatte keine schriftlichen Verfahren, die eine solche Überprüfung erforderten. (Seite 6)
Softwarefehler können in jeder Branche zu enormen Verlusten führen. Wenn Sie eine E-Commerce-Website betreiben oder Anzeigen auf Ihrer Seite haben, verlieren Sie mit jeder Sekunde, in der Ihre Seite nicht erreichbar ist, Geld. Auch die Kundenbindung wird beeinträchtigt. Frust führt dazu, dass Kunden sich an konkurrierende Unternehmen wenden. Langsame Reaktionszeiten haben finanzielle Folgen und Folgen für den Ruf. Wenn Probleme auftreten, handeln Sie schnell.
3 Schritte zum schnellen IT-Vorfallmanagement
Fehler können in jeder Entwicklungsphase auftreten und sind die Folge menschlicher Fehler. Um sie zu beheben, ist menschliches Eingreifen erforderlich. Basierend auf den 3 größten Fehlern von Knight Capital implementieren Sie die folgenden Best Practices, um Ihre IT-Vorfälle zu minimieren.
1. Schwellenwerte festlegen.
B. Knight verfügte nicht über angemessene Kontrollen, die verhindern sollten, dass Aufträge für Aktien erteilt wurden, die insgesamt die voreingestellten Kapitalschwellen für das Unternehmen überschritten, wie dies in Regel 15c3-5(c)(1)(i) vorgeschrieben ist. Insbesondere versäumte Knight es, Konten mit unternehmensweiten Kapitalschwellen zu verknüpfen, und Knight verließ sich auf Finanzrisikokontrollen, die nicht in der Lage waren, die Auftragserteilung zu verhindern (Seite 4).
Knight Capital machte einen großen Fehler, indem sie keine Grenzen auf Grundlage ihrer finanziellen Leistungsfähigkeit festlegten. Hätten sie finanzielle Schwellenwerte festgelegt, wie z. B. eine Grenze von 75 % des Kapitals, hätten sie einen Teil ihres 450-Millionen-Dollar-Verlusts verhindern können. Computersysteme werden immer komplexer und es gibt viele Komponenten, die kaputt gehen können, wenn Grenzen überschritten werden. Website-Vorfälle können auftreten, weil es Probleme mit der DNS-Leistung oder der CPU-Auslastung gibt. Legen Sie daher Schwellenwerte dafür fest. Anstatt zu warten, bis die CPU-Auslastung 100 % erreicht, legen Sie Ihren Schwellenwert auf 70 % fest, um einen katastrophalen Ausfall zu vermeiden. Schwellenwerte dienen als Signal für bevorstehende große Vorfälle und können ein Gefühl der Dringlichkeit erzeugen, Probleme zu lösen. Legen Sie proaktive Schwellenwerte fest, um einen Absturz zu verhindern.
2. Erstellen Sie einen Personalprozess.
19. Am 1. August erhielt Knight auch Aufträge, die für das RLP infrage kamen, aber für den vorbörslichen Handel bestimmt waren. SMARS verarbeitete diese Aufträge und ab etwa 8:01 Uhr ET generierte ein internes System bei Knight automatisierte E-Mail-Nachrichten (sogenannte „BNET-Ablehnungen“), die auf SMARS verwiesen und einen Fehler mit der Beschreibung „Power Peg deaktiviert“ identifizierten. Knights System schickte 97 dieser E-Mail-Nachrichten an eine Gruppe von Knight-Mitarbeitern vor der Markteröffnung um 9:30 Uhr. Knight hatte diese Art von Nachrichten nicht als Systemwarnungen konzipiert und die Mitarbeiter von Knight überprüften sie im Allgemeinen nicht, wenn sie eingingen. Diese Nachrichten wurden jedoch in Echtzeit gesendet, waren auf den Fehler bei der Codebereitstellung zurückzuführen und boten Knight die Möglichkeit, das Codierungsproblem vor der Markteröffnung zu identifizieren und zu beheben. Auf diese Benachrichtigungen wurde vor der Markteröffnung nicht reagiert und sie wurden nicht verwendet, um das Problem nach der Markteröffnung zu diagnostizieren. (Seite 6)
27. Am 1. August verfügte Knight über keine Aufsichtsverfahren zur Reaktion auf Vorfälle. Genauer gesagt verfügte Knight über keine Aufsichtsverfahren, um sein zuständiges Personal bei der Entwicklung bedeutender Probleme anzuleiten. Am 1. August verließ sich Knight in erster Linie auf sein Technologieteam, um das SMARS-Problem in einer Live-Handelsumgebung zu identifizieren und zu beheben. Das System von Knight verschickte weiterhin Millionen von untergeordneten Aufträgen, während sein Personal versuchte, die Ursache des Problems zu ermitteln. In einem seiner Versuche, das Problem zu beheben, deinstallierte Knight den neuen RLP-Code von den sieben Servern, auf denen er korrekt bereitgestellt worden war. Diese Aktion verschlimmerte das Problem und führte dazu, dass zusätzliche eingehende übergeordnete Aufträge den auf diesen Servern vorhandenen Power Peg-Code aktivierten, ähnlich wie es bereits auf dem achten Server geschehen war. (Seite 8)
Die Systeme von Knight Capital haben 97 E-Mails gesendet, um sie vor einem Problem zu warnen. Diese E-Mails wurden weder zur Vorbeugung noch zur Diagnose des Problems verwendet. Was nützt eine Warnung, wenn niemand da ist, der sie hört? Wenn Schwellenwerte überschritten werden, müssen die richtigen Personen sofort kontaktiert werden, um den Vorfall zu beheben. Da Computersysteme rund um die Uhr an 365 Tagen im Jahr laufen, werden Teams gebildet, die auf Probleme reagieren, wann immer sie auftreten. Unabhängig davon, ob ein Netzwerkbetriebszentrum (NOC) oder ein Bereitschaftsdienst-Rotationsplan implementiert ist, müssen die richtigen Personen kontaktiert werden, wo auch immer sie sich befinden. Wenn Sie Bereitschaft haben, sind Sie für alle eingehenden Vorfälle verantwortlich und müssen schnell handeln, um schwerwiegende Probleme zu beheben. Indem Sie Personen mit einem Vorfall in Verbindung bringen, entsteht ein Gefühl der Verantwortung und Rechenschaftspflicht.
3. Lernen Sie aus früheren Vorfällen.
33. Mehrere frühere Ereignisse boten Knight die Gelegenheit, die Angemessenheit seiner Kontrollen in ihrer Gesamtheit zu überprüfen. Beispielsweise verwendete Knight im Oktober 2011 Testdaten, um einen Notfallwiederherstellungstest am Wochenende durchzuführen. Nach Abschluss des Tests verwendete Knights LMM-Desk fälschlicherweise weiterhin die Testdaten, um automatisierte Kurse zu generieren, als der Handel an jenem Montagmorgen begann. Knight erlitt infolge dieses Ereignisses einen Verlust von fast 7,5 Millionen US-Dollar. Knight reagierte auf das Ereignis, indem es den Betrieb des Systems auf die Marktzeiten beschränkte, die Kontrolle so änderte, dass dieses System nach Erhalt einer Ausführung keine Kurse mehr bereitstellte, und einen Punkt zu einer Notfallwiederherstellungs-Checkliste hinzufügte, der eine Überprüfung der Testdaten erforderte. Knight prüfte nicht umfassend, ob es über ausreichende Kontrollen verfügte, um die Eingabe fehlerhafter Aufträge zu verhindern, unabhängig davon, welches spezifische System die Aufträge sendete oder was der konkrete Grund für den Fehler dieses Systems war. Knight verfügte auch nicht über einen Mechanismus, um zu testen, ob seine Systeme auf veralteten Daten basierten. (Seite 10)
Der Vorfall im August 2012 war nicht der erste, den Knight erlebte. Nach einem Verlust von 7,5 Millionen Dollar durch einen Vorfall im Oktober 2011 hatte Knight nicht genügend Kontrollen eingeführt, um künftige fehlerhafte Auftragseingänge zu verhindern. Sie hätten den Verlust von 7,5 Millionen Dollar als kleine Lektion nutzen sollen – im Vergleich zu ihrem Verlust von 450 Millionen Dollar im darauffolgenden Jahr – und die Angemessenheit ihrer Kontrollen neu bewerten sollen. Nachdem ein Vorfall gelöst wurde, müssen Sie analysieren, was passiert ist, und Ihren Vorfallmanagementprozess wiederholen. Konsistente und genaue Messungen können helfen, Trends aufzudecken. Diese Trends werden dann in die Festlegung von Schwellenwerten und die Verfeinerung des Personalprozesses für Vorfälle einfließen und letztendlich das Vorfallmanagement effizienter machen.
Lassen Sie Probleme nicht schwelen; beheben Sie sie sofort. Vorfälle sind kostspielig – Kunden werden verärgert, der Ruf wird geschädigt und Geld geht verloren. Im Fall von Knight Capital gingen Hunderte Millionen verloren. Die drei oben genannten Best Practices sind ein zyklischer, nie endender Prozess, aber es lohnt sich.