[Перевод] Кошмар «Рыцаря»: поучительная история про DevOps
1066 год, с начала вторжения викингов в Англию прошло уже больше 200 лет. Король Гарольд, собрав отряд рыцарей выступил к реке Дервент для решающего сражения с войсками своего тёзки — норвежского конунга Харальда. Целый месяц трудились оружейники, чтобы выковать достаточное количество доспехов нового поколения, способных защитить рыцаря от удара скандинавским топором. А сколько перед этим было экспериментов и испытаний на турнирах! Но ожидание должно было себя оправдать — лёгкая, но надёжная экипировка позволяла даже в пешем строю, без больших потерь, разметать викингский хирд. И, наконец, они встретились у Стамфорд-Бриджа. Главный отряд рыцарей во главе с командиром в блестящих доспехах схлестнулся посреди моста с врагами. Да, держит удар сталь подгорных мастеров!
Медленно, но верно, викинги переходят к круговой обороне. Кажется, победа уже близко. И на поле боя, наконец-то, находят друг друга командир рыцарей и норвежский ярл.
Двуручный топор ярла уже сломан и он вынужден защищаться обычным саксом, не идущим ни в какое сравнение с рыцарским полуторным мечом. Взмах кинжалом — для доспехов командира это как перочинный ножик, но он проходит сквозь доспех и… кажется, в ход пошла магия — рассыпаются доспехи у соседних рыцарей на правом фланге! Ещё взмах, опять в цель, и теперь у рыцарей на левом фланге доспехи вдруг накаляются докрасна. Третий удар — у рыцарей плывёт перед глазами, они спотыкаются, падают, и уже никогда не поднимаются.
»*** ** **** ****!» — вскрикнул Петрович, просыпаясь в 5 утра в понедельник в холодном поту. Всё пошло совсем не так: в 11 вечера он полез в Википедию в поисках материалов для доклада ребёнка о природе тундры, но к часу ночи почему-то оказался на описании вторжения викингов в Англию. А ещё, в выходные ставили на бой очередной релиз, который сегодня должен запуститься. Как всегда, долго и тщательно тестировали, миллион раз прогнали через системы continuous integration, всё ли пойдёт гладко…
К счастью для одних, но к несчастью для пострадавших, всегда есть возможность поучиться на чужих ошибках, чтобы что-то улучшить у себя и получить дополнительную порцию уверенности. Этой переводной статьёй хотим ещё раз, поподробнее, вспомнить один из случаев в «нашей» индустрии.
В прошлом году на конференции я рассказывал про DevOps, конфигурацию как код и непрерывную поставку. На примере истории ниже я объяснял важность создания полностью автоматизированных и воспроизводимых развертываний в рамках инициативы DevOps/непрерывной поставки. После конференции несколько человек попросили меня поделиться историей в блоге. Это абсолютно правдивая история. Это пересказ прочитанного, сам я в этом не участвовал.
Так вот, история о том, как компания с активами почти в $400 миллионов обанкротилась за 45 минут из-за неудачного развертывания.
Knight Capital Group («Knight» по-английски значит «рыцарь») — американская глобальная финансовая компания, занимающаяся маркет-мейкингом, электронным исполнением, институциональными продажами и трейдингом. В 2012 году Knight был крупнейшим трейдером американских акций с долей рынка около 17% на NYSE и NASDAQ. Knight’s Electronic Trading Group (ETG) управляла средним ежедневным объёмом торгов более 3,3 миллиарда сделок в день, торгуя более $21 миллиардами… в день. Это не шутка!
На 31 июля 2012 года у Knight было около $365 миллионов наличности и денежных эквивалентов.
1 августа 2012 года NYSE планировали запустить новую программу ликвидности розничной торговли — Retail Liquidity Program (программа, предназначенная для улучшения ценообразования для розничных инвесторов через розничных брокеров, таких как Knight). При подготовке к этому событию Knight обновили свой автоматизированный, высокоскоростной, алгоритмический маршрутизатор SMARS, который отправляет на рынок заявки для исполнения. Одной из основных функций SMARS является получение заявок от других компонентов торговой платформы Knights («родительских» заявок), с последующей отправкой одной или нескольких «дочерних» заявок на исполнение. Другими словами, SMARS будет получать большие заявки от торговой платформы и разбивать их на несколько маленьких, чтобы найти покупателя/продавца для акций. Чем больше родительская заявка, тем больше дочерних заявок будет создано.
Обновление SMARS должно было заменить старый, неиспользуемый код, называемый «Power Peg» — эту функциональность Knight не использовал в течение 8 лет (почему код, который был мёртв так долго, всё ещё был в кодовой базе — загадка, но это не главное). Обновлённый код переназначил старый флаг, который использовался для активации функциональности Power Peg. Код был тщательно протестирован, работал правильно и был надежным. Что могло пойти не так?
В период с 27 июля 2012 года по 31 июля 2012 года в Knight вручную развернули новое программное обеспечение на ограниченном количестве серверов в день — всего на восьми (8) серверах. Вот что написано в документе SEC по поводу ручного развёртывания (SEC — это Securities and Exchanges Comission, американский регулятор фондового рынка).
«Во время развёртывания нового кода один из сотрудников Knight не скопировал новый код на один из восьми серверов SMARS. Knight не провёл повторное техническое ревью этого развёртывания, поэтому код Power Peg с восьмого сервера не удалили, а новый RLP-код не добавили. У компании не были прописаны процедуры, требующие проводить повторную проверку». Релиз № 70694, 16 октября 2013 года
1 августа 2012 в 9:30 утра по восточному времени открылись рынки, и Knight начал обработку заявок от брокеров-дилеров от имени своих клиентов в новой Retail Liquidity Program. Семь (7) серверов, которые были развёрнуты правильно, начали корректно обрабатывать заявки. А те заявки, что ушли на восьмой сервер, вероятно, активировали изменённый флаг и воскресили Power Peg.
Тут нужно пояснить, для чего был нужен «мертвый» код Power Peg. Эта функциональность предназначалась для подсчёта акций, купленных/проданных по родительской заявке по мере выполнения дочерних заявок. После того, как родительская заявка исполнена, Power Peg запрещает отправлять дочерние заявки. В принципе, Power Peg будет отслеживать дочерние заказы и останавливать их исполнение после завершения обработки родительской заявки. В 2005 году Knight откатил эту кумулятивную функциональность отслеживания на более раннюю стадию исполнения кода (таким образом удалив из Power Peg отслеживание количества).
Когда флаг Power Peg на восьмом сервере был активирован, Power Peg начала маршрутизировать дочерние заказы для выполнения, но не соотносила их с количеством акций в родительской заявке — возникло что-то вроде замкнутого цикла
Представьте: у вас есть система, способная отправлять автоматические высокоскоростные заявки на рынок без какого-либо отслеживания и возможности посмотреть, было ли выполнено достаточно заявок. Да, всё оказалось настолько плохо.
Когда в 9:30 утра рынок открылся, люди быстро поняли, что что-то не так. К 9:31 утра многим на Уолл-Стрит стало очевидно, что происходит нечто серьёзное. Рынок был наводнён заявками с необычным, по сравнению с нормальной ситуацией, объёмом торгов на определенные акции. К 9:32 на Уолл-Стрит удивлялись, почему это безобразие не прекращается. Почти вечность в условиях высокоскоростной торговли. Почему кто-нибудь не нажал кнопку «убить» на той системе, которая это делала? Как оказалось, выключателя не было. В течение первых 45-ти минут торгов исполнения сделок от Knight составляли более 50% объёма торгов, поднимая определённые акции вверх более чем на 10% от их стоимости. В результате другие акции упали в цене из-за ошибочных сделок.
И что ещё хуже, система Knight начала отправлять по электронной почте автоматические сообщения ещё до этих событий — уже в 8:01 утра (когда SMARS обработал заявки, подходящие для пред-рыночной торговли). В сообщениях система ссылалась на SMARS и показывала ошибку «Power Peg недоступен». Между 8:01 и 9:30 утра 97 писем были отправлены сотрудникам Knight. Конечно, эти письма не имели вид системных предупреждений, поэтому их никто сразу не посмотрел. Ой.
В течение адских 45 минут в Knight пытались остановить ошибочные сделки. Не было возможности отключить систему (как и не было задокументированных процедур по реагированию на такую ситуацию), поэтому, пытаясь разобраться с проблемой в условиях живых торгов, они оставались на рынке, где каждую минуту продавалось 8 миллионов акций. Поскольку сотрудники компании не смогли определить, откуда появились ошибочные заявки, они удалили новый код с серверов, где он был развернут правильно. Другими словами, они удалили рабочий код и оставили сломанный. Это только усугубило проблемы, вызывающие дополнительные родительские заявки для активации кода Power Peg на всех серверах, а не только на том, где код изначально был развёрнут неправильно. В конце концов удалось остановить систему — после 45 минут торгов.
Пока велась торговля, код Power Peg получил и обработал 212 родительских заявок. В результате SMARS отправил на рынок миллионы дочерних заявок, выполнил 4 миллиона транзакций по 154 сделкам с более чем 397 миллионами акций. Для знатоков фондового рынка, это означало, что Knight купил акции 80-ти различных компаний на $3,5 млрд и продал акции 74-х компаний на $3,15 млрд. С точки зрения непрофессионалов, Knight Capital Group за 45 минут потеряла $460 миллионов. Но у Knight есть только $365 миллионов наличных и их эквивалентов. За 45 минут Knight превратился из крупнейшего трейдера американских акций и крупного маркет-мейкера на NYSE и NASDAQ в банкрота. У них было 48 часов, чтобы собрать сумму, необходимую для покрытия убытков (что им удалось сделать благодаря инвестициями в размере $400 миллионов от примерно полудюжины инвесторов). В конечном итоге, Knight Capital Group была приобретена Getco LLC (в декабре 2012 года), и теперь объединенная компания называется KCG Holdings.
События 1 августа 2012 года должны стать уроком для всех команд разработки и проектных групп. Недостаточно создать отличное программное обеспечение и протестировать его; ещё вам нужно убедиться, что оно правильно доставлено на рынок, чтобы ваши клиенты получили именно ту ценность, которую вы предоставляете (и чтобы вы не обанкротили свою компанию). Инженер (ы), которые развернули SMARS, не только виноваты в том, что процедура, которой следовали в Knight, не учитывала риски. Процедура (или её отсутствие) была заведомо ошибочной. Каждый раз, когда процесс развёртывания зависит от того, как люди читают и выполняют инструкции, вы подвергаете себя риску. Люди совершают ошибки. Ошибки могут быть в инструкциях, в интерпретации инструкций или в их выполнении.
Раскладка должна быть автоматизированным, воспроизводимым и максимально свободным от возможных человеческих ошибок процессом. Если бы Knight внедрил автоматизированную систему развертывания — комплект из конфигурации, автоматического развёртывания и тестирования, — то ошибки, которая обернулась кошмаром для «Рыцаря», можно было бы избежать.
Вот пара принципов непрерывной поставки (даже если вы не реализуете полный процесс непрерывной поставки):
- Выпуск программного обеспечения должен быть повторяемым и надёжным процессом.
- Автоматизируйте всё, что можете.
