Knight upgrade triggered old trading system

Przemawiałem na konferencji w zeszłym roku na tematy DevOps, Configuration as Code i Continuous Delivery i wykorzystałem następującą historię, aby zademonstrować, jak ważne jest, aby wdrożenia były w pełni zautomatyzowane i powtarzalne w ramach inicjatywy DevOpsContinuous Delivery. Od tej konferencji wielu ludzi prosiło mnie o udostępnienie tej historii za pośrednictwem mojego bloga. Ta historia jest prawdą, tak naprawdę się stało. Opowiem o historii opowiadanej przeze mnie (nie brałem w tym udziału). Jest to opowieść o tym, jak firma z blisko 400 milionami aktywów zbankrutowała w ciągu 45 minut z powodu nieudanego wdrożenia. Background Knight Capital Group jest amerykańską globalną firmą świadczącą usługi finansowe angażującą się w tworzenie rynku. wykonanie elektroniczne oraz sprzedaż instytucjonalna i handel. W 2017 r. Knight był największym sprzedawcą amerykańskich akcji z udziałem w rynku wynoszącym około 17 na każdym NYSE i NASDAQ. Knights Electronic Trading Group (ETG) zarządzał dziennym obrotem o wartości ponad 3,3 miliarda transakcji dziennie, handlując ponad 21 miliardów dolarów dziennie. To nie żart W dniu 31 lipca 2017 r. Knight miał około 365 milionów w gotówce i ekwiwalentach. NYSE planowała uruchomienie nowego Programu Płynności Detalicznej (program mający na celu zapewnienie lepszych cen dla inwestorów detalicznych za pośrednictwem brokerów detalicznych, takich jak Knight) w dniu 1 sierpnia 2017 r. W ramach przygotowań do tego wydarzenia Knight zaktualizował swoje zautomatyzowane, szybkie algorytmy router, który wysyła zamówienia na rynek w celu wykonania, znanym jako SMARS. Jedną z podstawowych funkcji SMARS jest otrzymywanie zleceń od innych elementów platformy transakcyjnej Knights (zamówienia rodziców), a następnie wysyłanie jednego lub więcej zamówień podrzędnych do realizacji. Innymi słowy, firma SMARS otrzymywałaby duże zamówienia z platformy transakcyjnej i dzieliła je na wiele mniejszych zamówień w celu znalezienia nabywcy odpowiadającego liczbie akcji. Im większa jest kolejność nadrzędna, tym więcej generowanych jest potomków. Aktualizacja do SMARS miała zastąpić stary, nieużywany kod, zwany Funkcją Power Peg, której Knight nie używał przez 8 lat (dlaczego kod, który był martwy przez 8 lat był nadal obecny w bazie kodu, jest tajemnicą, ale to nie chodzi o to punkt). Zaktualizowany kod zastąpił starą flagę, która służyła do aktywacji funkcji Peg Power. Kod został gruntownie przetestowany i udowodniono, że działa poprawnie i niezawodnie. Co mogłoby pójść nie tak Co mogłoby się nie udać między 27 lipca 2017 r. A 31 lipca 2017 r. Knight ręcznie wdrożył nowe oprogramowanie na ograniczonej liczbie serwerów na dzień osiem (8) serwerów. To właśnie oświadczenie SEC mówi o ręcznym procesie wdrażania (BTW, jeśli istnieje zgłoszenie SEC na temat twojego wdrożenia, coś może pójść okropnie źle). Jednak podczas wdrażania nowego kodu jeden z techników Knights nie skopiował nowego kodu na jeden z ośmiu serwerów komputerowych SMARS. Knight nie miał drugiego technika, który oceniłby to wdrożenie i nikt w Knight nie zdał sobie sprawy, że kod Power Peg nie został usunięty z ósmego serwera, ani nie dodano nowego kodu RLP. Knight nie miał pisemnych procedur, które wymagały takiej recenzji. Publikacja SEC nr 70694 16 października 2017 r. O 9:30 czasu wschodniego 1 sierpnia 2017 r. Rynki otworzyły się, a Knight rozpoczął przetwarzanie zamówień od brokera w imieniu swoich klientów w ramach nowego programu płynności detalicznej. Siedem (7) serwerów, które miały poprawne wdrożenie SMARS, zaczęło poprawnie przetwarzać te zamówienia. Rozkazy wysłane na ósmy serwer uruchomiły flagę przeznaczoną do ponownego użycia i przywróciły z martwych stary kod Power Peg. Atak Zombie Killer Code Ważne jest, aby zrozumieć, co zamierzał zrobić martwy kod Power Peg. Funkcjonalność ta miała na celu zliczenie akcji boughtsold w stosunku do zlecenia rodzicielskiego, ponieważ realizowano zlecenia dla dzieci. Power Peg poinstruuje system, aby przerwał kierowanie zamówień podrzędnych po spełnieniu polecenia rodzica. Zasadniczo, Power Peg będzie śledzić zamówienia dzieci i zatrzymać je po zakończeniu zamówienia rodzica. W 2005 r. Knight przeniósł tę funkcję skumulowanego śledzenia na wcześniejszy etap wykonywania kodu (usuwając w ten sposób śledzenie liczby z funkcji Power Peg). Kiedy flaga Power Peg na ósmym serwerze została aktywowana, funkcja Power Peg rozpoczęła rutowanie potomnych zleceń do wykonania, ale nie śledziła liczby akcji w stosunku do zlecenia nadrzędnego, jak w nieskończonej pętli. 45 minut piekła Wyobraź sobie, co by się stało, gdybyś miał system zdolny do wysyłania zautomatyzowanych, szybkich zamówień na rynek bez śledzenia, aby sprawdzić, czy wykonano wystarczającą liczbę zamówień. Tak, to było takie złe. Kiedy rynek otworzył się o 9:30, ludzie szybko zorientowali się, że coś jest nie tak. O 9:31 dla wielu ludzi na Wall Street stało się jasne, że dzieje się coś poważnego. Rynek był zalewany nietypowymi zleceniami dla regularnych obrotów na niektórych akcjach. O 9:32 wielu ludzi na Wall Street zastanawiało się, dlaczego się nie zatrzymało. To była wieczność w szybkich warunkach handlowych. Dlaczego ktoś nie trafił w przełącznik zabijania, niezależnie od tego, który system to robił? Jak się okazało, nie było przełącznika zabijania. Podczas pierwszych 45 minut transakcji egzekucje rycerskie stanowiły ponad 50 wolumenu obrotu, napędzając niektóre akcje ponad 10 ich wartości. W rezultacie inne zapasy zmniejszyły swoją wartość w odpowiedzi na błędne transakcje. Co gorsza, system Knights rozpoczął wysyłanie zautomatyzowanych wiadomości e-mail wcześniej tego dnia, już o 8:01 (kiedy SMARS przetwarzał zamówienia kwalifikujące się do handlu przed rynkiem). Wiadomości e-mail odwołują się do SMARS i wykryły błąd, ponieważ wyłączono Power Peg. W godzinach od 8:01 do 9:30 wysłano 97 wiadomości e-mail do personelu Knighta. Oczywiście te e-maile nie zostały zaprojektowane jako alarmy systemowe i dlatego nikt nie spojrzał na nich od razu. Ups. Podczas 45-minutowego piekła, jakiego doświadczył Knight, podjęli kilka kroków, aby spróbować zatrzymać błędne transakcje. Nie było żadnego przełącznika zabijania (i żadnych udokumentowanych procedur reagowania), więc próbowali zdiagnozować problem w środowisku transakcyjnym na żywo, gdzie co minutę handlowano 8 milionami akcji. Ponieważ nie byli w stanie określić, co było przyczyną błędnych zamówień, zareagowali, odinstalowując nowy kod z serwerów, na których został prawidłowo wdrożony. Innymi słowy, usunęli działający kod i zostawili złamany kod. To tylko wzmocniło problemy powodujące dodatkowe zamówienia rodziców, aby aktywować kod Power Peg na wszystkich serwerach, a nie tylko ten, który nie został prawidłowo wdrożony. W końcu udało im się zatrzymać system po 45 minutach handlu. W ciągu pierwszych 45 minut, kiedy rynek był otwarty, kod Peg Power Pobierał i przetwarzał 212 zamówienia rodzicielskie. W rezultacie firma SMARS wysłała na rynek miliony zamówień dziecięcych, co przyniosło 4 miliony transakcji na 154 akcje za ponad 397 milionów akcji. Dla was, kupców giełdowych oznaczało to, że Knight przejął około 3,5 miliarda długich pozycji netto w 80 akcjach i 3,15 miliarda pozycji krótkich netto w 74 akcjach. W terminach laiken8217s, Knight Capital Group zrealizował 460 milionów strat w 45 minut. Pamiętaj, że Knight ma tylko 365 milionów w gotówce i ekwiwalentach. W 45 minut Knight stał się największym inwestorem w amerykańskie akcje i głównym animatorem rynku na NYSE i NASDAQ, by zbankrutować. Mieli 48 godzin na zgromadzenie kapitału niezbędnego do pokrycia strat (co udało im się osiągnąć dzięki 400 milionom inwestycji od około pół tuzina inwestorów). Knight Capital Group została ostatecznie przejęta przez Getco LLC (grudzień 2017), a połączona spółka nazywa się teraz KCG Holdings. Lekcja do nauki Wydarzenia z 1 sierpnia 2017 r. Powinny być lekcją dla wszystkich zespołów ds. Rozwoju i operacji. Nie wystarczy zbudować świetne oprogramowanie i przetestować go, musisz również zapewnić, że jest on dostarczany na rynek prawidłowo, aby Twoi klienci mogli uzyskać wartość, którą dostarczasz (a więc nie zbankrutujesz firmy). Inżynier (-cy), którzy wdrożyli SMARS, nie są wyłącznie odpowiedzialni za to, że ustanowiony przez Knighta proces nie był odpowiedni dla ryzyka, na które był narażony. Dodatkowo ich proces (lub jego brak) był z natury podatny na błędy. Za każdym razem, gdy twój proces wdrażania opiera się na czytaniu ludzi i postępowaniu zgodnie z instrukcjami, narażasz się na ryzyko. Ludzie popełniają błędy. Błędy mogą dotyczyć instrukcji, interpretacji instrukcji lub wykonywania instrukcji. Wdrożenia muszą być zautomatyzowane i powtarzalne oraz możliwie wolne od potencjalnych błędów ludzkich. Gdyby Knight zaimplementował automatyczny system wdrażania wraz z konfiguracją, wdrożeniem i automatyzacją testów, błąd, który spowodowałby uniknięcie Knightmare. Stosuje się tu kilka zasad dotyczących Ciągłej Dostawy (nawet jeśli nie wdrażasz pełnego procesu Ciągłej Dostawy): Uwalnianie oprogramowania powinno być powtarzalnym, niezawodnym procesem. Zautomatyzuj wszystko, co jest rozsądne. Scenariusz: Załóżmy, że mieli bardzo dobre DevOps. Wszystkie serwery będą zsynchronizowane. Ale 8211 zakłada, że ​​nowy kod miał błąd. Wszystkie serwery są zsynchronizowane, ale mają ten sam błędny kod. Co jeśli dwie wersje kodu, tj. Ostatnie 2 wdrożenia miały ten błąd. Więc kiedy zdadzą sobie sprawę, że coś jest nie tak, to oni cofają kod, błąd nadal trwa8230 Minęły cenne minuty. Może 20 minut zamiast 45 minut w twoim artykule. Tak więc w skrócie 8211 ich wyłącznik usuwania skutków awarii jest wdrożeniem wycofywania kodu w środowisku na żywo. To nadal będzie wadliwy projekt. Potrzebne byłyby duże czerwone przełączniki (prawie dosłownie, gdzieś w desce rozdzielczej), aby natychmiast się zatrzymać. Gdzie jest reguła biznesowa, która mówi: 8220first nie szkodzić8221. VJ, gdyby wdrożenie do wszystkich serwerów działało, byłyby w porządku. Ale w tym przypadku 7 z 8 dla jednego podsystemu zostało poprawnie wdrożonych. Z powodu złego zachowania wycofali pozostałych 7, myśląc, że nowym kodem w tym podsystemie jest problem. To pomnożyło problem do momentu ostatecznego przełączenia zabijania. Katastrofy są prawie zawsze złożone. W tym przypadku były to kiepskie praktyki kodowania, a także wątpliwe praktyki inspekcji kodu testowego, plus błąd we wdrażaniu, a także wycofywanie w zakresie ziarnistości podsystemu, a nie całego systemu. Jeśli rozwiążesz którykolwiek z tych problemów, nie dostaniesz katastrofy. Jedną z rzeczy, które widzimy w firmach, które nie dostrzegają prawdziwego znaczenia i wpływu swoich systemów informatycznych, jest to, że nie zapewniają budżetu na aktualizacje starszego kodu. Na przykład: I8217ve widział sytuacje, w których IT nie ma budżetu. Musi usprawiedliwiać wszystko, co robi, kosztem biznesu. Co oznacza ciągłe szukanie nowych projektów. Firmy rzadko widzi potrzebę aktualizacji starego oprogramowania, które obecnie działa, więc nie chcą za to zapłacić. Rezultatem jest stały nowy kod, opracowany przez najtańszych programistów, bez inwestowania w technologie, które ostatecznie poprawiają wydajność i zmniejszają ryzyko. Dlaczego, ponieważ są one postrzegane jako problemy 8220IT8221, a nie w odniesieniu do jakiegokolwiek projektu, nad którym pracują informatycy, więc nikt nie zapłaci za to. Świetna lektura dotycząca tej praktyki to The Phoenix Project Gene'a Kim, Kevina Behra i George'a Spafforda. Dziękuję za zastosowanie mózgu do hype. Prawdopodobnie należy zapytać, dlaczego zaangażowani technicy doszli do winy, ale nie uzyskali prawa do samodzielnego zabicia przełącznika. Och, racja, że ​​tak i Ty umieściłeś OpsSRE na swoim miejscu. 8220R8221 jest odpowiedzialny za przynętę na aka. Napisałem trochę o tym wydarzeniu, a ja ostrzegałbym kogokolwiek, aby wykorzystał raport SEC jako coś innego niż to, do czego SEC tego potrzebowała. kitchensoap20171029counterfactuals-rycerska stolica Fascynująca lektura. Pracowałem w dużym domu aukcyjnym owoców i warzyw, gdy tylko zainstalowano nową wersję oprogramowania, która nie przyniosła rezultatu, co doprowadziło do dużych strat dla handlowców (choć nie tak dużych jak te). To także było przypadkiem niewłaściwego wdrożenia i braku upadku. Lekcja, której należy się nauczyć, polega na tym, że istnieją domeny, w których komputer nie powinien podejmować żadnych decyzji bez weryfikacji przez człowieka. A co z ludźmi, którzy stracili pracę, ponieważ, oops, był błąd Co z innymi firmami, które mogły wpaść w pułapkę z powodu nagłej zmiany wartości akcji Automatyzacja 8220 decyzji wysokiego szczebla 8221 jest ostrożnie rozpatrywana8230 Miły i edukacyjny post Btw. Korzystanie z frameworka Cynefin zapewnia lepszą charakterystykę tego błędu 8216DevOps8217 Wydaje się, że ten post został napisany z perspektywy DevOps. Sugerowane rozwiązania są zgodne z perspektywą DevOps 8211, aby zbadać proces uwalniania, zautomatyzować więcej i stworzyć przełącznik zabijania z możliwością wycofania. Ktoś może przeczytać post i położyć zbyt duży nacisk na technika rycerza, który nie skopiował starego kodu na jeden z ośmiu serwerów. Ktoś może uprościć związek przyczynowo-skutkowy. Ktoś może insynuować nowe zasady, aby zapobiec ponownemu pojawieniu się tego zjawiska.8217 Mocniejsze podejście może zainwestować w: 8211 Zwiększenie różnorodności, aby przeanalizować sytuację i zsyntetyzować lepsze opcje 8211 Poprawić komunikację między specjalnościami 8211 Poprawić domyślną koordynację między specjalnościami 8211 Rekrutować osoby z więcej Umiejętność pisania i recenzowania kodu Głównym czynnikiem, który ograniczył poprawę zdolności zespołu z dziewięciu lat przed poważnym zdarzeniem niepowodzenia, była niewłaściwa charakterystyka systemu. W środowisku Cynefin ograniczenie tego błędu do problemu DevOps polega na powiązaniu systemu z domeną 8220Obvious8221, gdzie istnieją proste związki przyczynowo-skutkowe, które są rozpoznawalne przez 8216professionals.8217 Błąd nie powinien być powiązany z domeną Cynefin 8220Complicated8221, w której istotna analiza 8216specjalistów8217 uniemożliwiłoby porażkę. System powinien być powiązany z Cynefin 8220Complex8221 domena 8211 złożony system adaptacyjny. System jest dyspozycyjny. Te same warunki początkowe nie spowodują tego samego błędu (z wyjątkiem wypadku). Aby uzyskać więcej informacji o Cynefin, odwiedź en. wikipedia. orgwikiCynefin i CognitiveEdge. Doceniam twoje uwypuklenie milczących czynników w takiej katastrofie. Podobnie jak autor, ja również pracuję w operacjach i łatwo wpaść w te same stare schematy myślowe dotyczące przyczyn i rozwiązań. Szczególnie podoba mi się twoja uwaga dotycząca różnorodności (która pojawia się we wszystkich formach: poziom doświadczenia, pochodzenie kulturowe i edukacyjne, umiejętności, wiek itd.), Ponieważ uważam, że jest to silny czynnik decydujący o powodzeniu samego DevOps. Mając różne perspektywy, zarówno w zespole, jak i bez niego, spojrzenie na projekt ma silny, możliwy do wykazania potencjał i może pomóc w ograniczeniu niedopatrzeń, takich jak ten poruszony w tym artykule. gt dlaczego kod, który był martwy przez 8 lat był nadal obecny w bazie kodu jest tajemnicą, ale nie jest to kwestia Przeciwnie, to jest dokładnie punkt. Kod z nieużywanymi, a więc niesprawdzonymi możliwościami konfiguracyjnymi to katastrofa, która czeka, by się wydarzyć. To dlatego I8217m bardzo sceptycznie odnosi się do podejść opartych na flagach cech. Konfiguracja jest tak samo częścią twojego programu jak kod, a zmiany konfiguracji powinny przejść przez to samo żądanie ciągnienia 8211, przegląd kodu, wydanie, wdrożyć do przemieszczania 8211 jak każdą inną zmianę. Jeśli twój proces zwolnienia jest zbyt ciężki i musisz szybko wprowadzić zmiany w konfiguracji, napraw swój proces zwalniania. Było zbyt wiele błędów, by przypisać epicką porażkę do DevOps (chociaż w pełni zgadzam się, że automatyzacja i testowanie jest jedyną metodą): 8211 Brak pracy zespołowej i list kontrolnych podczas aktualizacji serwerów produkcyjnych. Wszelkie aktualizacje dotyczące produkcji powinny wymagać wzajemnego nadzorowania się zespołu i sprawdzania listy kontrolnej. 8211 8 lat niewykorzystanego starego kodu w produkcji. To wiele mówi o braku zrozumienia na temat ryzyka zwisającego z kodu 8220unused8221. 8211 Niewystarczające logowanie z kodu i niewystarczające monitorowanie, korelacja i analiza dziennika w czasie rzeczywistym. To spowodowałoby wczesne zgłoszenie wystarczającej liczby wskazówek dla inżynierów i opsów. 8211 Bez przełączania awaryjnego na hot-hot do klastra z poprzednią wersją. To zatrzymałoby wszystkie problemy po 1 lub 2 minutach. (To jest błąd w czerwonym przycisku, o którym wspomina artykuł) Jeśli od dłuższego czasu projektujesz oprogramowanie, systemy i przedsiębiorstwa, wiesz, że zdarza się katastrofa, wiesz, że niektóre błędy są złapane tylko w dziczy, a nie podczas symulacji, tak jak ty wiem, że maszyny będą działać. Musisz przygotować się na najgorszy przypadek w obu scenariuszach. Prawo Murphy8217s jest tak prawdziwe w naszym świecie I8217 istniało w tak zwanej przestrzeni 8220DevOps8221 przez prawie 20 lat, ponad połowa tego w świecie finansowym. Knight był zarówno sprzedawcą, jak i konkurentem firmy, dla której obecnie pracuję. Może pomóc automatyzacja wdrażania. Może. Ale niewiele firm może sobie pozwolić na dokładnie duplikaty środowisk, a to głównie spowodowane różnicami środowiskowymi. Nawet automatyczne sprawdzenie poprawności wdrożenia mogło nie pomóc w tym przypadku, gdyby automatyzacja nie wiedziała o różnicy w środowisku. Automatyzacja jest tak dobra, jak wiedza osób ją konfigurujących. Jeśli ręczna instalacja nie była świadoma starego systemu, to istnieje duża szansa, że ​​automat nie będzie mógł go sprawdzić. Automatyzacja wycofywania jest równie dobra, jak podejmowanie decyzji, czy wykonać wycofanie. A jeśli automatyzacja nieumyślnie uruchomiła stary system, to nie ma również gwarancji, że przełączenie współczesnego systemu z powrotem zatrzymałoby stary system 8211, który mógł skończyć z tym samym problemem, nawet po automatycznym wycofaniu współczesnego systemu. Co prowadzi mnie do ostatniego punktu: Automatyzacja jest wymogiem w dużych, nowoczesnych środowiskach. Ale nadmierne poleganie na nim może prowadzić do tego, że osoby obsługujące system nie są świadome tego, co robią. Automatyzacja jest najbardziej przydatna do sprawdzania poprawności, ponieważ sprawdzanie poprawności jest wykonywane właściwie jest nudne i łatwe do skapywania po ręcznym wykonaniu. Nawet gdy automatyzacja, posiadanie ludzkich pułapek lub działań opartych na ludziach pomaga zapewnić, że operatorzy systemu znają system i sposób jego działania, co znacznie poprawia ich zdolność do rozwiązywania problemów, diagnozowania problemów i przedstawiania odpowiednich sugestii na temat kroków, jakie należy podjąć, aby zatrzymać lub złagodzić problem. Automatyzacja jest narzędziem, ale jest tylko jednym narzędziem i nadal wymaga od rzemieślnika odpowiedniego jej władania. Fachowość jest tym, co sprawia, że ​​wielkie systemy są świetne. Odsyłam to na Garrett S. Y. Hampton i skomentowałem: Incredible. DevOps zawsze ogląda, dokumentuje i sprawdza swoje wdrożenia. Grupa Nocnych Kapitałów: Komputer przypadkowo zły wytrąca Dom Handlowy Rycerz (rycerz) jest domem handlowym, który pomaga innym uzyskać dostęp do rynków finansowych, wykonując ich transakcje. Służy jako wyznacznik rynkowy, co oznacza, że ​​dostarcza zamówienia typu kupno, aby inni mogli zawsze zawrzeć z nim transakcję, dla ponad 600 papierów wartościowych na giełdach NYSE i NASDAQ. Służy także jako animator wielu innych papierów wartościowych. Ponieważ produkcja na rynku i handel są kluczowymi działaniami na rynkach finansowych, wymagającymi rzetelnego i uczciwego postępowania, nic dziwnego, że na swojej stronie internetowej widnieje slogan The Standard of Trust. Co więc należy pomyśleć o incydencie, który miał miejsce 1 sierpnia, kiedy to lawina transakcji z Knighta doprowadziła do tego, że zgromadziła pozycję handlową o wartości 7 miliardów dolarów, o wiele więcej, niż mogłaby utrzymać, prowadząc do wspólnego wysiłku, by poprowadzić pozycję do mniej ryzykownego poziomu W pośpiechu, by zmniejszyć swoją ekspozycję na ryzyko, nieuchronnie sprzedała część swoich aktywów tanio (znaną również jako sprzedaż ogniowa), a ostatecznie straciła 440 milionów. Nawet wbrew standardom strat, do których przyzwyczailiśmy się w tym kryzysie finansowym, był to bardzo zły dzień dla Rycerza. Od tego czasu Knight był w stanie znaleźć inwestorów o świeżym kapitale w wysokości 400 milionów euro, w zasadzie tyle samo, ile stracił, co ustabilizuje firmę, jeśli nie poniesie więcej katastrofalnych strat. Zbadano również przyczynę nagłego wzrostu zamówień. Tutaj informacje są trochę niejasne, ale Wall Street Journal zgłasza nieoczekiwany powód: nieudana aktualizacja systemów komputerowych. Wydaje się, że nowe systemy komputerowe zostały zainstalowane i działają poprawnie, ale nie zostały zainstalowane na wszystkich platformach transakcyjnych (każdy system musi być replikowany na wszystkich platformach transakcyjnych). Doprowadziło to do starych systemów handlujących na niektórych platformach, podczas gdy nowe systemy handlują z innymi, i najwyraźniej stare systemy poszły nie tak. Dokładne wyjaśnienie tego, jak to jest możliwe, jest niejasne, ponieważ stare systemy działały wcześniej dobrze, ale możliwe jest, że stare systemy nie przekazywały już swoich transakcji do systemu zarządzania ryzykiem, więc udział ich transakcji w całkowitym ryzyku pozostał niewykryty. To wyjaśnienie ma charakter spekulacyjny, ale jeśli raporty, że nowy system działa dobrze, są poprawne, to olbrzymie nagromadzenie zleceń kupna sugeruje, że z systemu oceny ryzyka musiały zostać usunięte pewne informacje. Ta opowieść o błędach komputerowych zaczyna się i kończy ludzkim błędem. Ludzie nie zainstalowali nowego systemu na wszystkich platformach transakcyjnych, a ludzie nie zdołali zatrzymać transakcji, gdy urzędnicy giełdowi z NYSE zauważyli niezwykłe transakcje i ostrzegli Knighta, że ​​jest on źródłem nietypowych ruchów handlowych. Kluczową kwestią jest to, że systemy komputerowe były tak szybkie i skuteczne w swojej pracy, że nie było czasu, aby je powstrzymać, gdy już się pojawią. Jest to zjawisko dobrze znane z badań nad wypadkami organizacyjnymi. Jest to także główna przyczyna niewłaściwego postępowania, jak zauważyłem w pracy z kolegami Donem Palmerem i Jo-Ellen Pozner. W przypadku Knighta transakcje były prawdopodobnie tak niebezpieczne, że stanowiły wyrok, czy firma podtrzymała swoje obowiązki w zakresie właściwego zarządzania ryzykiem (procesy sądowe, każdy). Jednak przypisanie odpowiedzialności będzie trudne, ponieważ transakcje te były przypadkowe, a wypadek miał miejsce w interfejsie pomiędzy szybkimi i wadliwymi komputerami, a wolniejszymi ludźmi próbującymi nadrobić zaległości. Oczywiście ta historia ma ważne lekcje na temat tego, w jaki sposób organizacje myślą o zarządzaniu ryzykiem i kontroli jakości, zwłaszcza, że ​​automatyzują coraz więcej swoich kluczowych systemów. Przypomina to również, że rynki finansowe zawierają handlarzy ludźmi, którzy mogą być dość wadliwi w swoich wyrokach, a zastępowanie ich komputerami czasami czyni wyroki jeszcze gorszymi. I na koniec, jeśli kiedykolwiek zmodernizowałeś oprogramowanie, pomyśl o Knight Capital i o ile gorzej: nie wątpię, że kiedykolwiek doświadczyłeś aktualizacji komputera, która wycofała pieniądze z twojego konta bankowego i rozdała je nieznajomym. Greve, H. R. Palmer, D. i Pozner, J. 2017. Organizacje Gone Wild: przyczyny, procesy i konsekwencje nierządowości organizacyjnej. Akademia roczników zarządzania. 4: 1, 53 107. Patterson, S. J. Strasburg i J. Bunge. 2017. Knight Upgrade Triggered Old Trading System, duże straty. Dziennik "Wall Street . 15.8.2017. Dodaj komentarz Już teraz Zaloguj się Henrich R. Greve jest profesorem przedsiębiorczości na INSEAD. Większość wspólnych artykułów Jak para indyjskich szpitali sprawiła, że ​​bezczynna operacja stała się paradygmatem zrównoważonej opieki zdrowotnej. Menedżer przyszłości będzie musiał zarządzać zestawami umysłu, w tym także swoim własnym. t. co6hUfF9Pbjt t. co7MMvy6RL0B knowledge. insead. edubloginsead-blogintelligent-board-know-their-limits-5321 via INSEAD Wiedza w zarządzaniu Sukces zarządzania wymaga nauki tak szybko, jak zmienia się świat. - Warren Bennis za pośrednictwem INSEADKnowledge Najpopularniejsze w aplikacji: Innovating at the Intersections t. coNCd8aCXfmU t. coki40D6zX48 knowledge. insead. edumobile-apps przez INSEAD Wiedzę Auke Hunneman. 27.02.2017 o 01:40 pm Dzięki za odpowiedź Steven - Dzięki za odpowiedź Steven. Steven Sweldens. 27.02.2017 o 10.37. Dziękuję Auke, za - dzięki Auke, za referencje. Pomysł przeciwstąpienia jest z pewnością powiązany, ale. Tom Cummings. 27.02.2017 o 10.12 rano Członek Zarządu, Fundacja Tallberga - Ron Soonieus przedstawia ważną kwestię dotyczącą planowanego połączenia. jring281. 26.02.2017 o godz. 19.17 Fellow INCOSE - Interesująca hipoteza. Podczas próby wdrożenia mogą pojawić się dwie usterki. 1. Strategia. Praveen Valliavalappil (Will). 24.02.2017 o godz. 19:48 Dyrektor - Inżynieria - Cześć Steve, uwielbiał czytać. Bardzo dobrze artykułowany. Zgadzam się, że kiedy jesteśmy w. W centrum uwagi INSEAD Global Leadership Center oferuje wyjątkową wiedzę jako wiodące centrum badań i praktyki w zakresie przywództwa i. Partnerstwo między wiedzą INSEAD, KnowledgeWharton i Światowym Forum Gospodarczym Rada ds. Globalnej agendy na temat rynków wschodzących. Aby wykorzystać możliwości wynikające z cyfryzacji, organizacje i liderzy muszą objąć nowe realia biznesowe. Ciemna magia: Powstanie robotów-robotów Podpis pod zdjęciem Miejsca handlowe: Szaleńcze podłogi dealerów z lat 80. XX wieku zostały zastąpione przez rozległe szeregi serwerów komputerowych. nie może konkurować na prędkości, jest to tak proste. Dziesięć lat temu John Coates był handlowcem na Wall Street. Dziś jest neurologiem na Uniwersytecie w Cambridge i spędza całe dnie monitorując hormony handlowców, aby zobaczyć, co je powoduje. Są proste testy, które możesz wykonać. Kiedy zobaczysz zielone światło. klikasz myszą. Najszybciej możesz to zrobić od 100 do 120 milisekund. Jakiekolwiek podstawowe przetwarzanie poznawcze, obliczanie rzeczy, a może od 200 do 300 milisekund. Problem polega na tym, że pudełka - kiedy ostatnio je oglądałem - przetwarzały transakcję w 10 milisekund, a dziś myślę. mówili o milionowych częściach sekundy. Te pudełka są robotami-robotami - komputerami, które same decydują o tym, kiedy kupić i sprzedać, ale tysiąc razy szybciej niż jakakolwiek ludzka puszka. Działają algi, które skutecznie naśladują to, co robili handlowcy Remco Lenterman, dyrektor firmy handlowej IMC. Kiedy myślisz o parkiecie w Londynie lub Nowym Jorku, być może wyobrażasz sobie, że stado spoconych mężczyzn wypycha się nawzajem z drogi, używaj skomplikowanych ruchów palców, aby przekazać ich gorączkowe rozkazy. Jest to obraz spopularyzowany przez komedię "Miejsca z 1980". Ale jest też 30 lat przestarzały. Faktem jest, że handel finansowy przeszedł skomputeryzowaną rewolucję, podobną do przejęcia przez Amazonki High Street. Cała prawdziwa akcja przeniosła się do cyberprzestrzeni. Weź giełdę w Nowym Jorku. Obecnie większość handlu nie odbywa się za słynną neoklasycystyczną fasadą tuż przy Wall Street, ale w znacznie mniej efektownym New Jersey. Właśnie tam NYSE utworzyło rozległy elektroniczny system handlu obejmujący 10 akrów (cztery hektary), mieszczący rząd po szeregu serwerów komputerowych. A wiele więcej akrów zajmują serwery robotów, które są do nich podłączone. Nerdy brainboxes Skomputeryzowany handel jest z natury skrytym światem. Firmy handlowe ściśle trzymają się swoich strategii handlowych, ludzi i kodu komputerowego (lub algorytmów). W przeciwnym razie rywal może wymyślić skomplikowane, ale w pełni zautomatyzowane wzorce handlowe, a następnie skopiować je, lub co gorsza, skopiować swoje komputery do milionów. Podpis pod zdjęciem Handlowcy z loadsamoney w latach osiemdziesiątych zostali wysłani na śmietnik historii Remco Lenterman, dyrektor jednej z takich firm, IMC w Holandii, próbuje zdemokratyzować swój biznes. Mówi: W dawnych czasach, 10 lat temu, biurka handlarzy akcjami posiadały od 80 do 100 ludzkich handlowców w banku inwestycyjnym. Dziś jest ich ośmiu. To, co robią, to działanie algos, które skutecznie naśladują to, co robili handlowcy, i stale podnoszą te algos i monitorują ryzyko związane z tym, co dzieje się na rynku. Innymi słowy, kultowi handlowcy Loadsamoney z wysokimi testosteronami z przeszłości - Mistrzowie Wszechświata wyszydzani przez amerykańskiego pisarza Toma Wolfe'a w Ognisku Marności - zostali usunięci przez quanty, nerdy mózgi mózgów, które projektują i zarządzają programami komputerowymi . W ostatnim post-script do swojej powieści napisanej dla Daily Beast. Tom Wolfe lamentował nad zubożeniem swoich antybohaterów, zmieniając ich nazwę na Eunuchs of the Universe. Bliżej serwerów, prostsze kable Firmy, takie jak Lentermans, zarabiają pieniądze, ocierając niewielką marżę zysku na niewyobrażalnie ogromnym wolumenie kupowania i sprzedawania szybkich ogni. Różne podmioty inwestujące w algo używają bardzo różnych strategii. Ale wszyscy mają potrzebę zidentyfikowania możliwości handlowych - ulotne rozbieżności między dostępną ceną rynkową a miejscem, w którym komputer uważa, że ​​cena powinna być - i reagują na nie szybciej niż ktokolwiek inny. Wyścig do zera Opcje dostępne pod koniec zeszłego roku dla każdego, kto chce wysłać elektroniczne zamówienie handlowe między Nowym Jorkiem a Chicago: czas potrzebny na kompletny rejs w obie strony. Nazywa się wyścig do zera. I to doprowadziło do zainwestowania miliardów dolarów w szybsze, inteligentniejsze komputery i najszybsze możliwe połączenia. Na giełdach na całym świecie inwestorzy ponoszą ogromne opłaty za współlokowanie swoich serwerów bezpośrednio przy giełdach. I setki milionów wydano na budowanie prostych kabli, żeby zgolić kilka ułamków sekundy po czasie, który trzeba przesłać między światowymi dużymi centrami handlowymi: Londynem, Nowym Jorkiem, Chicago i Tokio. Wszystko to może wydawać się trochę irracjonalne, gdy rządy Wielkiej Brytanii i Stanów Zjednoczonych walczą o zebranie wystarczającej ilości pieniędzy, aby zmodernizować infrastrukturę potrzebną do przeprawy ludzi z jednego miejsca do drugiego. Flash Crash Istnieje jednak ciemniejsza strona tego pośpiechu, aby skomputeryzować. Na przykład zdarzają się wypadki. W sierpniu ubiegłego roku, zaawansowana technologicznie firma finansowa Knight Capital została doprowadzona do skraju bankructwa dzięki algorytmowi, który szaleje, zrywając ponad 440 milionów strat w zaledwie 45 minut, zanim został wyłączony. Być może najbardziej znanym wydarzeniem był legendarny Flash Crash, o godzinie 14:45 w Nowym Jorku w dniu 6 maja 2017 r. W ciągu kilku minut giełda nowojorska pogrążyła się w martwym punkcie, a potem równie nagle odzyskała przytomność. Ceny akcji w niektórych firmach, takie jak doradztwo Accenture, spadły do ​​ułamka powyżej zera, a Apple wzrosło do 100 000. Przez wiele miesięcy nikt nie mógł wyjaśnić, co poszło nie tak. Oficjalne amerykańskie dochodzenie regulacyjne stwierdziło, że zostało wywołane przez pojedyncze zamówienie złożone przez dużą instytucję, wykorzystujące algorytmiczną strategię handlową. Ale to, co znacznie pogorszyło sytuację, to efekt gorącego ziemniaka: pośród zamieszania, jeden po drugim handlarze robotów próbowali ciąć i biegać, a giełda komputerowa została zalana. Znakomita manipulacja Nowe algorytmiczne podmioty gospodarcze zostały również oskarżone o dość niecodzienne zachowanie ze starej szkoły. Eric Hunsader z amerykańskiej firmy Nanex zajmującej się analizą danych twierdzi, że miniaturowe wersje Flash Crash zdarzają się w poszczególnych magazynach wiele razy dziennie, a on twierdzi, że wiele z nich to jawna manipulacja. Opracował wykresy przedstawiające dziwne i cudowne zachowanie rynków. ponieważ komputery starają się wzajemnie prześladować, szybko generując, a następnie anulując tysiące zamówień na sekundę. Podpis pod zdjęciem Wykres Nanex ilustrujący awarię Google Flash z 22 kwietnia tego roku Pozwalamy, aby osoby z szybszymi połączeniami umieszczały i usuwały oferty lub oferty szybciej niż prędkość światła może dostarczyć te informacje innym uczestnikom rynku. I nie tylko on jest zaniepokojony, że niektórzy skomputeryzowani handlowcy mogą nic nie zrobić. Niestety, charakter rynków jest taki, że zawsze istnieje możliwość nadużyć, a przy bardzo, bardzo szybkim obrocie rzeczy mogą się zdarzyć bardzo, bardzo szybko, mówi Martin Wheatley, szef nowo utworzonego brytyjskiego urzędu nadzoru finansowego. Szczerze mówiąc, dla organu regulacyjnego stwarza problem, próbując wyłowić z ogromnej ilości transakcji z danymi, które potencjalnie mogą być nadużyciem. Czarna Magia, zaprezentowana przez BBC Business Editor, Roberta Pestona, będzie transmitowana w Radio 4 o 09:00 8 lipca 2017 r., A następnie będzie dostępna na BBC iPlayer. Udostępnij tę historię Informacje o udostępnianiu