Knight Capital: 45 минути, един необновен сървър и над 460 милиона долара

На 1 август 2012 г. Knight Capital загуби над 460 милиона долара за около 45 минути. Според регулатора всичко започна с промяна в софтуера, която беше инсталирана на седем от осем сървъра. Осмият остана със стар код, който вече не се използваше, и този код се събуди, щом борсата отвори. Следва верига от контроли, които не бяха там, където трябваше.

Случаят е широко документиран в публични регистри: Комисията по ценните книжа и борсите на САЩ (SEC, регулаторът на пазарите в тази страна) го разследва и публикува констатациите си в заповед от 18 страници [1]. Почти всичко по-долу идва оттам. Една важна уговорка: Knight прие споразумението със SEC без да признава и без да отрича тези констатации [1, раздел II].

Тази статия е за онзи, който ръководи компания или ИТ звено. Тя обхваща четири неща:

1. Какво се случи, час по час.
2. Защо не беше лош късмет, а верига от малки решения.
3. Какво научава един ръководител, на езика на бизнеса.
4. Какво да попитате на следващия си комитет и откъде да започнете още тази седмица.

Едно уточнение, преди да започнем: Hábil не е участвала в този случай. Разказваме го с онова, което SEC и самата Knight са съобщили публично.

Първо, кой беше Knight

Knight Capital беше една от най-големите фирми на Уолстрийт по изпълнение на нареждания за акции. Според SEC през 2011 и 2012 г. нейната дейност представляваше, общо взето, около 10 % от всички акции, търгувани на листваните пазари в Съединените щати [1]. Когато дребен инвеститор купуваше акции чрез своя брокер, често нареждането минаваше през Knight.

За целта тя използваше система, наречена SMARS: автоматичен високоскоростен маршрутизатор на нареждания. Работата ѝ е лесна за обяснение. Получава нареждане за покупка или продажба («родителското» нареждане) и според наличното на пазара изпраща едно или повече производни нареждания («дъщерните») към различни места за търговия (борси и други пазари, на които се купуват и продават акции), за да го изпълни [1, пар. 12]. Логично е, когато родителското нареждане вече е изпълнено, системата да спре да праща дъщерни.

Тази последна мисъл е важната. Запомнете я.

Хронологията, час по час

2003 г.: функция, която никой не изключва

Knight спира да използва една функция на SMARS, наречена «Power Peg». Спира да я използва, но не я изтрива. Кодът остава в системата, налице и готов да бъде задействан [1, пар. 13–14].

В този код имаше ключова част: брояч, който сумираше колко от акциите на родителското нареждане вече са изпълнени. Този брояч беше спирачката. Казваше на системата: «готово е, спри да изпращаш».

2005 г.: промяна, която никой не тества отново

Две години по-късно екипът премества този брояч на друго място в SMARS, за да го ползва в друга функция. Никой не тества отново Power Peg, за да види дали все още работи без него [1, пар. 14]. Защо да го прави, щом никой вече не го използва?

От този ден Power Peg е кола без спирачки, паркирана в гаража. Никой не я кара. Никой не я проверява. Ключовете са на таблото.

Юли 2012 г.: осем сървъра, седем копия

Нюйоркската фондова борса (NYSE) ще пусне програма за нарежданията на дребните инвеститори, Retail Liquidity Program, която стартира на 1 август [1, пар. 12]. Knight иска клиентите ѝ да участват от първия ден, затова пише нов код за SMARS.

Две технически решения подготвят капана:

• Новият код замества стария Power Peg в тази част на системата.
• За да се включи, използва повторно същия флаг (превключвател във всяко нареждане), който години по-рано включваше Power Peg [1, пар. 13]. Идеята беше Power Peg да бъде изтрит, така че този флаг да може да включва само новото.

От 27 юли един техник инсталира новия код на етапи, сървър по сървър, в последователни дни. SMARS работи на осем сървъра. На един от тях новият код не се копира [1, пар. 15].

Никой не забелязва. Според SEC Knight не изисквала втори техник да прегледа инсталацията и нямала писмени процедури, които да го изискват [1, пар. 15 и 26]. Осмият сървър остава с Power Peg вътре и без новия код.

Сряда, 1 август, 8:01 ч. сутринта (нюйоркско време): 97 имейла, които никой не чете

До отварянето на пазара остава почти час и половина. Пристигат нареждания от новата програма, определени да се изпълнят преди откриването. Към 8:01 ч. една вътрешна система на Knight започва да праща автоматични имейли до група служители. В тях се споменава SMARS и се сочи грешка: «Power Peg disabled», Power Peg е изключен [1, пар. 19].

Преди 9:30 ч. пристигат 97 такива имейла. Никой не действа по тях. Не става дума за небрежност на един човек: тези съобщения не са проектирани като предупреждения и служителите, общо взето, не ги преглеждали при получаването им [1, пар. 19]. SEC го казва така: това били съобщения в реално време, причинени от неуспешната инсталация, и давали една възможност да се намери и поправи проблемът преди откриването [1, пар. 19].

Системата предупреди. Предупреждението стигна до пощенска кутия, която никой не гледаше.

9:30 ч.: пазарът отваря

Звънецът удря. Седем сървъра обработват правилно нарежданията от новата програма. Осмият — не.

Всяко нареждане с повторно използвания флаг, което стигне до този сървър, събужда Power Peg. А Power Peg вече няма своя брояч: не знае кога родителското нареждане е изпълнено. Затова праща дъщерни нареждания без прекъсване, едно след друго, с пълна скорост, за всяко нареждане, което получи [1, пар. 16].

Най-смущаващото: друга част от системата на Knight знаеше, че нарежданията вече са изпълнени. Но тази информация не стигаше до SMARS [1, пар. 16].

Спомнете си мисълта, която ви помолих да запомните. Данните, които биха послужили за спирачка, съществуваха на друго място в системата, а не там, откъдето се изпращаше.

Следващите минути: търсене на сляпо

От откриването насам старши служители на Knight виждат в своя инструмент за наблюдение как в една вътрешна сметка — «Сметка 33» — се трупа огромна позиция [1, пар. 24–25]: купени или продадени акции, които остават за сметка на Knight, с целия им риск. Виждат симптома. Не виждат причината.

SEC описва защо им отнема толкова време да разберат какво става:

• Инструментът за наблюдение зависеше изцяло от това дали човек го гледа: не генерираше автоматични предупреждения за експозицията на фирмата, тоест парите, които тя излагаше на риск [1, пар. 25].
• Не показваше лимитите: който го гледаше, трябваше да знае наизуст лимита на всяка сметка, за да забележи, че е надвишен [1, пар. 25].
• При обема от онази сутрин изоставаше и отчетите му излизаха неточни [1, пар. 25].
• Сметка 33 имаше лимит от 2 милиона долара, но не беше свързана с автоматични контроли върху общата експозиция на Knight; а инструментът за наблюдение също не спираше сам изпращането на нареждания [1, пар. 23–25].
• И нямаше процедури, които да насочват персонала при сериозен инцидент; SEC заключава, че техническият екип се нуждае от ясно указание кога да се изключи система, която се проваля [1, пар. 27 и 42].

Междувременно Knight остава свързана с пазара. Техническият ѝ екип се опитва да намери проблема на живо, докато системата изпраща милиони нареждания [1, пар. 10 и 27].

Лекарството, което влошава всичко

При един от опитите екипът прави онова, което мнозина от нас биха направили: връща предишното състояние. Деинсталира новия код от седемте сървъра, където е бил инсталиран правилно [1, пар. 27].

Но на тези седем сървъра под новия код Power Peg си стоеше. Щом се махне новото, флагът отново включва старото. Сега са осем сървъра, които изпращат нареждания без спирачка [1, пар. 27].

Връщането назад, което трябваше да е мрежата за сигурност, се оказа последният тласък, защото никой не знаеше със сигурност какво има отдолу.

Около 45 минути по-късно

Когато Knight най-после спира да изпраща нареждания, сметката на SEC е следната [1, пар. 1 и 17]:

• 212 нареждания от дребни инвеститори задействаха всичко.
• SMARS изпрати милиони дъщерни нареждания, с над 4 милиона изпълнения в 154 акции и над 397 милиона ценни книги.
• Knight остана, без да го иска, с нетна дълга позиция от около 3 500 милиона долара в 80 акции и с нетна къса позиция от около 3 150 милиона в 74 акции.

Щетите не останаха само у Knight. В 75 от тези акции нейните сделки бяха над 20 % от обема и допринесоха за ценови движения от над 5 %; в 37 цената се движи с над 10 % и Knight беше повече от половината от обема [1, пар. 18]. Тези изпълнения засегнаха други участници на пазара: някои получиха по-неблагоприятни цени, а други — по-благоприятни от тези, които биха имали без тях.

Следващите дни

• Четвъртък, 2 август. Knight обявява загуба преди данъци от приблизително 440 милиона долара [3]. Същата сутрин, според Associated Press, акцията ѝ губи половината от стойността си в началото на сесията [5].
• Понеделник, 6 август. Група инвеститори се съгласява да вложи в нея 400 милиона долара срещу конвертируеми привилегировани акции (акции със специални права, които могат да се заменят за обикновени акции) [4]. В тримесечния си отчет самата Knight признава, че е имало «съществено съмнение» относно способността ѝ да продължи дейността си [6].
• 1 юли 2013 г. Knight Capital Group и GETCO се обединяват и създават KCG Holdings; Knight престава да бъде самостоятелна компания [1, пар. 11].
• 16 октомври 2013 г. SEC ѝ налага глоба от 12 милиона долара. Това е първото действие на SEC по прилагане на правилото ѝ за достъп до пазара, прието през 2010 г.: правилото, което изисква от фирмите контроли на риска, преди да изпращат нареждания на пазара [1][2]. Окончателната сума на загубата, определена от SEC, е над 460 милиона долара [1, пар. 1 и 10].

Бележка за цифрите: 440-те милиона са оценката, която Knight публикува на следващия ден [3]; над 460-те милиона са това, което SEC установи при приключване на разследването [1]. Тук използваме сумата на SEC.

Не беше лош късмет: беше верига

Изкушаващо е историята да се разкаже като «един техник забрави да копира файл». SEC не я разказва така. Нейната заповед сочи пропуски в контрола, а не в един човек [1, пар. 9 и 40–44]. Всяко от тези звена, поотделно, би прекъснало веригата:

Прочетете отново третия ред. Според регулатора една проста двойна проверка на инсталацията «би могла да установи, че един сървър е бил пропуснат, и да предотврати събитията от 1 август» [1, пар. 41].

И има една подробност, която би трябвало да смути всеки комитет: Knight имаше контроли. Интерфейсът ѝ за клиенти, вътрешната ѝ система за нареждания и системата ѝ за вътрешно изпълнение имаха контроли срещу погрешни нареждания [1, пар. 20]. Проблемът е, че те бяха преди SMARS. На последния участък, който докосваше пазара, нямаше достатъчно такъв контрол [1, пар. 21].

Предупреждението, което дойде година по-рано

През октомври 2011 г. Knight направи в почивните дни тест за възстановяване след бедствие, с тестови данни. В понеделник една от системите ѝ продължи да използва тези тестови данни, за да котира на реалния пазар. Загуби почти 7,5 милиона долара [1, пар. 33].

Knight поправи този проблем: ограничи работното време на системата, промени един контрол и добави стъпка към контролен списък. Онова, което не направи, казва SEC, е да се запита дали има достатъчно контроли срещу погрешни нареждания независимо коя система ги изпраща и защо [1, пар. 33 и 44]. Реагира на случая, не на причината.

Подписът, който казваше друго

През март 2012 г. главният изпълнителен директор на Knight подписа годишното удостоверение, което изисква правилото за достъп до пазара. В текста не пишеше, че контролите отговарят на правилото; пишеше, че Knight има «процеси», за да го спазва. Беше непреднамерена грешка в редакцията, директорът не я забеляза и вярваше, че подписва, че всичко е изрядно [1, пар. 34]. За SEC да се заяви, че съществуват «процеси», не е равносилно на заявление, че контролите и процедурите са разумно проектирани и отговарят на правилото [1, пар. 45].

На едно заседание това звучи като техническа подробност. Тази разлика сама по себе си не обяснява какво се случи на 1 август, но показва надзор, който приемаше за даденост, че контролите са достатъчни, без да го проверява.

Какво научава един ръководител

Вие не управлявате маршрутизатор на акции. Но ако вашата компания събира плащания, издава фактури, одобрява кредити, издава полици или продава онлайн, имате системи, които действат сами и бързо. Тези уроци не са от Уолстрийт; те са за всяка дейност, която не може да спре.

1. Най-скъпият риск не е в новия код: той е в онзи, който никой не помни

Power Peg не беше използван от девет години. Никой не го виждаше като риск, защото «не правеше нищо». В системи с много години зад гърба си често остават изключени функции, повторно използвани флагове и интеграции без ясен собственик. Онова, което не се използва и не се изтрива, е дълг, който се връща с лихви в най-лошия ден.

2. Промяна, която се инсталира на ръка, не е контролирана промяна

Проблемът не беше, че един човек сгреши: хората грешат. Проблемът беше, че нищо не беше проектирано да открие грешката. Ако инсталирането на осем сървъра зависи от това дали някой ще повтори осем пъти едно и също, без да сбърка, рано или късно едно от повторенията ще мине зле. Автоматизираният път за пускане (процесът, който отвежда всяка промяна до сървърите без ръчни стъпки) намалява това отклонение: инсталира едно и също навсякъде и проверява, че е останало еднакво. Не премахва риска, но го прави видим.

3. Предупреждение, което никой не чете, е запис, а не контрол

Тези 97 имейла са сцената, която най-много би трябвало да отнема съня на един ръководител. Системата наистина откри проблема, час и половина по-рано. Но предупреждението не беше проектирано така, че някой да действа по него. Попитайте се колко автоматични известия във вашата дейност стигат днес до споделена пощенска кутия, която никой не преглежда.

4. Спирачката трябва да е там, където е рискът, и трябва да е автоматична

Knight имаше контроли в началото на пътя и наблюдение след събитията. Липсваше ѝ спирачка точно преди парите да излязат и липсваха лимити, които да спират изпращането сами. Лимит, който зависи от това дали някой ще си го спомни, докато гледа бавен екран, не е лимит.

5. Връщането назад също е промяна и също трябва да се репетира

Опитът за връщане към предишната версия влоши всичко, защото никой не знаеше какво има отдолу. Безопасното връщане назад не е «деинсталирай и се моли»: това е процедура, изпробвана предварително, която води до известно състояние.

6. При инцидент първото решение е бизнес решение: изключваме ли?

В продължение на 45 минути техническият екип търси повредата при включена система. SEC посочва, че на Knight е трябвало ясно указание кога да се изключи [1, пар. 42]. Това решение не бива да се импровизира насред пожара, нито да зависи от този, който държи клавиатурата: уговаря се предварително, с име и фамилия и с ясен праг.

7. Поправянето на симптома не е поправяне на причината

Загубата от 7,5 милиона през 2011 г. беше предупреждение. Knight поправи онзи конкретен случай и продължи постарому. Всеки малък инцидент е най-евтината възможност да се открие големият.

Защо това продължава да се случва

Минаха повече от четиринайсет години, а урокът остава валиден по една неудобна причина: нито един от тези контроли не изисква екзотична технология. Двойна проверка, добре насочено предупреждение, автоматичен лимит, процедура за изключване. Те съчетават процес, технология и управление, а истинската им трудност е друга: те се конкурират с бързането. Knight имаше твърда дата — старта на програмата на борсата — и искаше да е готова в този ден [1, пар. 12].

Когато календарът диктува, първото, което се реже, е онова, което «не се вижда»: прегледът, тестът на старото, репетицията на връщането назад. Докато не се види.

Пет въпроса за следващия ви комитет

1. Как достига една промяна до нашите критични системи? По автоматизиран път, който инсталира едно и също навсякъде и го проверява, или защото някой го копира на ръка?
2. Какъв код или изключени функции още стоят в нашите системи и кой ще отговаря, ако някой ги включи неволно?
3. Какви автоматични предупреждения генерират днес нашите системи, до кого стигат и кой е длъжен да действа, когато се появят?
4. Какви лимити на пари, обем или количество спират сами една необичайна операция и на кое точно място по пътя са?
5. Ако утре една система започне да нанася вреда, кой решава да я изключи, при какъв праг и кога за последно репетирахме връщането назад?

Ако някой отговор е «не знам» или «зависи кой е на смяна», превърнете го в риск с отговорник и срок. За всеки от тях поискайте пет неща: засегнатата система, нейния отговорник, доказателствата, които съществуват днес, въздействието при отказ и следващия контрол, който е необходим. С това вашият комитет може да подреди приоритетите за първата система и да реши следващата стъпка.

Откъде да започнете тази седмица

Изберете една система, която събира, плаща или движи пари. Помолете този, който я пуска, да ви разкаже стъпка по стъпка как е излязла последната промяна: кой я е инсталирал, на колко сървъра, как е проверено, че е останала еднаква навсякъде и какво би станало, ако се беше провалила. Ако отговорът съдържа «обикновено» или «той знае процедурата», вече знаете откъде да започнете.

Какво прави Hábil

Hábil е мексиканска инженерна консултантска компания, основана през 2006 г., която изгражда системи за дейности, които не могат да спрат. Един от проблемите, които решаваме, е точно този от тази история: пускането на промяна да спре да плаши.

Проектираме и внедряваме автоматизирани пътища за пускане в облака, на вашите сървъри или и на двете места: всяка промяна излиза по един и същ път, с тестове и преглед за сигурност, преди да стигне до клиентите ви, със среди за тестване и за работа, които си приличат, с уговорено връщане към предишно състояние и с проследимост кой какво е одобрил. Започваме от инструментите, които екипът ви вече използва, и от системата, която ви боли най-много, при работеща дейност. Вижте страницата Пускане в експлоатация бързо и без изненади и, ако искате техническите подробности, статията CI/CD DevSecOps във вашата собствена инфраструктура.

Ако искате да сверите тези пет въпроса с конкретна система, нека започнем оттам. Поискайте първия си разговор, безплатно. Преглеждаме как пускате днес една от приоритетните си системи, а вие си тръгвате с първа карта на рисковете си и със следващото си решение. Пишете ни по WhatsApp.

Често задавани въпроси

Фалира ли Knight Capital?

Не съвсем. Оцеля благодарение на инжекция от 400 милиона долара от група инвеститори, договорена пет дни по-късно [4], но загуби независимостта си: през юли 2013 г. се обедини с GETCO и създаде KCG Holdings [1, пар. 11].

Вина ли беше на техника, който не копира кода?

SEC не го поставя така. Заповедта ѝ сочи, че Knight не е имала писмени процедури, нито втори преглед за инсталиране на код в тази система, нито контроли, които да не допускат активиране на неизползван код [1, пар. 9-D, 15 и 26]. Човешката грешка е предвидима; липсваше система, която да я открие.

Защо се говори за 440 милиона, а също и за 460?

440-те милиона са загубата преди данъци, която Knight оцени на 2 август 2012 г. [3]. SEC, при приключване на разследването си през октомври 2013 г., установи загуба от над 460 милиона [1].

Само за финансовите компании ли е това?

Не. Всяка компания със системи, които действат сами (събиране на плащания, фактуриране, плащания, наличности, онлайн поръчки), има същата уязвимост: зле инсталирана промяна, забравен код и предупреждения, на които никой не обръща внимание. Променя се скоростта, с която грешката се превръща в пари.

Премахва ли автоматизирането на пусканията риска?

Не го премахва; намалява го и го прави видим. Автоматизираният път инсталира едно и също навсякъде, проверява резултата и оставя следа, но все пак са нужни тестове, автоматични лимити, предупреждения, по които някой действа, и репетирано връщане назад.

Откъде започва една компания, която днес пуска на ръка?

От една-единствена система, онази, която движи най-много пари или боли най-много, като първо се измери как се пуска днес. Оттам се автоматизира на етапи, без да се спира дейността.

Цифрите и фактите по случая идват от публични документи, консултирани на 20 октомври 2026 г. Цитатите са преведени от английски.