Основатель Web-payment.ru
35,9
рейтинг
23 октября 2013 в 19:06

Разработка → Как 45 минут терять по $172 222 в секунду перевод

Это, пожалуй, самый болезненный отчет об ошибке, который я когда-либо читал. Он красочно описывает шаги, которые привели к потере 465 миллионов долларов компанией Knight Capital в связи с ошибкой программного обеспечения, проявившейся в прошлом году и обанкротившей компанию.

В этом отчете есть все характеристики технического долга в огромной, лишенной поддержки и запущенной базе кода (ошибка произошла из-за исполнения кода, который не использовали почти 9 лет) и ужасная и грустная история взаимодействия между разработчиками ПО и ИТ-профессионалами.

Основные моменты:
Для обеспечения участия своих клиентов в Программе ликвидности (ПЛ) на Нью-Йоркской фондовой бирже, запуск которой планировался 1 августа 2012 года, Knight внес ряд изменений в свои системы и программный код, связанный с процессом обработки заказов. Эти изменения включали в себя разработку и развертывание нового программного кода в SMARS. SMARS представляет собой автоматизированный, высокоскоростной, алгоритмический маршрутизатор, который отправляет заказы на рынок. Одна из основных функций SMARS — это получение заказов от других компонентов торговой платформы Knight («родительских» заказов), и, по мере необходимости на основе имеющейся ликвидности, отправка одного или нескольких представительских (или «дочерних») заказов внешним службам на исполнение.

13. При развертывании новый ПЛ код в SMARS должен был заменить неиспользуемый код в соответствующей части маршрутизатора. Этот неиспользуемый код ранее был нужен для функции Power Peg, которую компания не применяла уже долгие годы. Несмотря на это, она оставалась рабочей и вызываемой во время развертывания ПЛ. Новый ПЛ код использовал флаг, который ранее был привязан к Power Peg. Knight хотела удалить код Power Peg, чтобы при активации этого флага использовалась новая функциональность ПЛ, а не Power Peg.

14. Ранее при использовании Power Peg суммирующая функция вычисляла количество акций в выполняемых дочерних заказах и сигнализировала о необходимости прекращения размещения дочерних заказов после того, как родительский заказ был выполнен. В 2003 году Knight прекратили использовать Power Peg. В 2005 Knight изменили код Power Peg, переместив функцию отслеживания выполнения родительского заказа на более раннюю стадию последовательности кода SMARS. Повторного тестирования кода Power Peg после изменения Knight не выполнили и в том, что процедура по-прежнему работает корректно, не убедились.

15. Начиная с 27 июля 2012, компания Knight развернула новый ПЛ код в SMARS, разместив его на ограниченном числе серверов. Во время развертывания нового кода один из техников не скопировал новый код на один из восьми серверов SMARS. В Knight не было второго техника, который бы проводил проверку развертывания, и никто не понял, что код Power Peg не был удален с восьмого сервера и новый ПЛ код не был добавлен. В Knight не было никаких письменных процедур, которые требовали бы такой проверки.

16. 1 августа Knight получала заказы от брокеров-дилеров, чьи клиенты могли участвовать в ПЛ. Семь серверов обрабатывали заказы правильно. Но заказы, отправленные на 8 сервер с установленным флагом запуска, запустили дефектный код Power Peg, который всё ещё присутствовал на этом сервере. В результате сервер воспринял заказы как родительские и начал отправлять дочерние заказы в трейдинговые центры. Вследствие того, что функция проверки выполнения родительского заказа была перемещена на другую стадию процесса, сервер продолжал размещать дочерние заказы безостановочно — не обращая внимания на то, что родительский заказ уже выполнен. Хотя некоторая часть системы обработки заказов определяла, что родительский заказ выполнен, в SMARS эта информация не попадала.

19. 1 августа Knight также получала заказы, которые относились к ПЛ, но предназначались для торговли до открытия рынка. 6 серверов SMARS обрабатывали эти заказы и, начиная примерно с 8:01 утра, внутренние системы генерировали автоматические сообщения (под названием «отказ BNET»), которые ссылались на SMARS и описывали ошибку как «Power Peg отключен». Система Knight отправила 97 таких сообщений до 9:30 утра, когда открылся рынок. Сообщения подобного типа не расценивались системой, как опасные, а персонал вообще не читал их.

Дальше еще веселее:

27. 1 августа в Knight не было никаких процедур, касающихся реагирования на инциденты. Иными словами, в компании не было контрольных процедур для руководства персоналом, когда происходили серьезные проблемы. 1 августа Knight пользовался услугами своей команды техников, чтобы выявить и устранить проблемы в SMARS в живой торговой среде. Система Knight продолжала посылать миллионы «дочерних» заказов, пока персонал пытался выявить источник проблемы. Компания даже удалила новый ПЛ код с семи серверов, на которых он был установлен правильно. Это усугубило ситуацию, ведь новые «родительские» заказы активировали код Power Peg, который присутствовал на этих серверах, подобно тому, что уже произошло на восьмом сервере.

Безусловно, стоит прочитать весь документ, в нем большое внимание уделяется новым процедурам проверки, выполняемым людьми, чтобы избежать подобной трагедии. Ошибки разработчиков, безусловно, были связаны с человеческим фактором, но такие последствия стали результатом плохого сценария развертывания и отвратительного мониторинга. Что это за контора, в которой даже не проверяют версию программного обеспечения кластера? Не говоря уже о сценарии развертывания, при котором проверяются коды возврата.

Мы можем только надеяться, что «письменные процедуры проверки» неиспользуемого кода подразумевали собой систематическим тесты, хотя Википедия говорит, что это не так.

И на сладкое: штраф составил еще 12 миллионов долларов, проведенный аудит показал, что система постоянно пыталась осуществить спекулятивные короткие продажи.

Перевод: David Wilson
Виталий Цигулев @cigulev
карма
66,7
рейтинг 35,9
Основатель Web-payment.ru
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (94)

  • +58
    Можно бросать этотим постом в работодателя когда он отказывается нанимать тестировщика :)
    • +32
      Я вообще искренне радуюсь таким событиям. Может меньше буду со временем слышать позорных отмазок «у нас нет на это времени».
    • +8
      Тот самый случай, когда «скупой платит дважды». Не стоит экономить на спичках.
      • +10
        Тот самый случай, когда в мире работает карма. Так этим брокерам и прочим экономическим паразитам, качающим деньги «из воздуха», и надо.
    • +17
      Думаете тестировщик отловил бы неправильный деплой?
      • +1
        Не знаю, как все, но я перед развертыванием на боевые сервера чего-либо провожу тестирование самого развертывания и проверяю корректность развертывания на боевых серверах в том числе.
        В идеале — с пошаговым расписыванием процедуры и выполнением всех шагов
      • 0
        У нас в компании тестеровщик еще бы и баг этот исправил. Не все же тестировщики обычные обезьяны, которым показали как и в какие кнопки тыкать.
    • +12
      При чем здесь тестировщики? Новую версию софта наверняка протестировали на UAT перед тем как выкатывать на продакшин. Беда случилась из-за того, что забыли выкатить на один из боевых серверов.
      • +3
        Серверов не тысяча, не сто, даже не пятьдесят. Их всего 8 штук. Как можно было пропустить? Может это хитрый план такой, и техник срубил немного денег.
        • +3
          Я знаю случаи, когда сервера всего 2 и 2-й забывали обновить.
      • 0
        После установки новой версии проводится смоук, чтобы убедиться что все встало нормально. На этой стадии и было бы выявлено что на один из серверов забыли накатить новую версию.
        • +2
          Как вы представляете «смоук» на живой трейдинговой системе с алгоритмическим трейдингом? Там роботы торгуют с настоящими котировками.
          • 0
            биржи не круглосуточно же работают
            • 0
              Когда биржи не работают, котировок нет, поэтому используют эмуляторы. И хорошо, если эти эмуляторы повторяют, например, поведение рынка за вчерашний день. Т.е. оптимально им было бы выкатиться через пару часов после закрытия биржи, повесить табличку «мы скоро вернемся», выключить клиентов, прогнать тесты на эмуляторе за вчерашний день, переключив при этом их роботов в paper trading. Учитывая, что у них даже апдейты продакшна шли вручную, таких апдейт-скриптов у них точно нет. Реально в трейдинге нужно очень много тестов (юниты, интеграция end-to-end) и совсем немного квалифицированных «живых» тестировщиков. Армия обезьянок, к сожалению, вообще никак не поможет. И повальный DevOps, без этого рано или поздно вот такая хрень обязательно произойдет.
              • 0
                Насколько я понял они обновляли не весь зоопарк машин, а только часть ответственную за определенную работу(обработка заказов). И для нее сэмулировать данные попроще будет. Вот для этого и надо было бы провести тестирование, а не для всей трейдинговой системы. Юниты, интеграция end-to-end должны проводиться на тестовом енве, но никак не на продакшене. На проде максимум небольшой не ломающий ничего смоук, чтобы проверить что все встало нормально.
                • 0
                  На продакшене смоук тестов не проводят, тем более на системах, которые роутят ордера. Нужно было проверить корректное развертывание и номер версии.
                  • 0
                    что подразумевается под корректным развертыванием? за это вроде как и отвечает смоук.
                    • 0
                      У нас для пред-продакшен систем проверяется: корректный номер версии, отсутствие алармов, отсутствие ошибок в логах, параметры системы. Для продакшена думаю что-то подобное, там все делают операторы.
    • +1
      Не тестировщика, а архитектора системы качества и управления техническими рисками. Разница в зарплате где-то на порядок. Тем не менее для подобной конторы это действительно экономия на спичках.
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Даже самый пупер инженер может иногда ошибиться: человеческий фактор.

        Непосредственная причина в отсутствии отработанного авто-деплоя, а первопричина — в отсутствии желания технического контроля над собственным бизнесом.
  • +39
    По-русски «child process» — это не «детский», а «дочерний» процесс.
    • +24
      И кстати, callable — не «вызываемая», а «вызывабельная», то есть доступная для вызова. Код Power Peg НЕ вызывался в ходе нормальной процедуры.

      Новый ПЛ код использовал флаг, который ранее был привязан к Power Peg. — не просто «был привязан». Установка этого флага активировала вызов Power Peg. Смысл понятен: они решили заменить процедуру, но вызывать её установкой того же флага, что и раньше. По замуслу код Power Peg следовало удалить, и теперь установка флага вызывала бы уже новый код.

      Поскольку Power Peg с 2003 года не использовалась, с 2003 года флаг не ставился.
      • –3
        Эмм, «вызывабельная»? Такого слова нет (аж редактор красным подчеркнул), а потому режет слух. Даже «вызываемая» не портит смысл. Если уж так хочется передать сей тонкий момент, предлагаю использовать словосочетание «потенциально вызываемая».
        • +20
          Конечно, нет такого слова. Я использовал кавычки, чтобы показать, что его нет, что я его сконструировал, чтобы передать смысл. Но, голова моя садовая, не сообразил, что кавычки у меня уже заняты и никто не догадается, что здесь они значат совсем иное. Mea culpa.

          То есть по сути вашего комментария — согласен полностью и признаю свою ошибку. Потенциально вызываемая — лучше, чем доступная для вызова. И что угодно лучше вызывабельной.
    • +14
      Только после вашего комментария понял, что автор хотел сказать.
  • +6
    14 переведу заново.

    When Knight used the Power Peg code previously, as child orders were executed, a cumulative quantity function counted the number of shares of the parent order that had been executed. This feature instructed the code to stop routing child orders after the parent order had been filled completely. In 2003, Knight ceased using the Power Peg functionality. In 2005, Knight moved the tracking of cumulative shares function in the Power Peg code to an earlier point
    in the SMARS code sequence. Knight did not retest the Power Peg code after moving the cumulative quantity function to determine whether Power Peg would still function correctly if called.


    Ранее при использовании Power Peg суммирующая функция вычисляла количество акций в выполняемых дочерних заказах и сигнализировала о необходимости прекращения размещения дочерних заказов после того, как родительский заказ был выполнен. В 2003 году Knight прекратили использовать Power Peg. В 2005 Knight изменили код Power Peg, переместив функцию отслеживания выполнения родительского заказа на более раннюю стадию последовательности кода SMARS. Повторного тестирования кода Power Peg после изменения Knight не выполнили и в том, что процедура по-прежнему работает корректно, не убедились.
    • +2
      Спасибо, исправил
  • +2
    И 16 тоже. Потому что это самый жЫр и есть:

    On August 1, Knight received orders from broker-dealers whose customers were eligible to participate in the RLP. The seven servers that received the new code processed these orders correctly. However, orders sent with the repurposed flag to the eighth server triggered the defective Power Peg code still present on that server. As a result, this server began sending child orders to certain trading centers for execution. Because the cumulative quantity function had been moved, this server continuously sent child orders, in rapid sequence, for each incoming parent order without regard to the number of share executions Knight had already received from trading centers. Although one part of Knight’s order handling system recognized that the parent orders had been filled, this information was not communicated to SMARS.

    1 августа Knight получили заказы от брокеров-дилеров, клиенты которых имели право участвовать в Программе Ликвидности. Семь серверов обрабатывали заказы правильно. Но заказы, отправленные на 8 сервер с установленным флагом запуска, запустили дефектный код Power Peg, который всё ещё присутствовал на этом сервере. В результате сервер [воспринял заказы как родительские и] начал отправлять дочерние заказы в трейдинговые центры. Вследствие того, что функция проверки выполнения родительского заказа была перемещена на другую стадию процесса, сервер продолжал размещать дочерние заказы безостановочно — не обращая внимания на то, что родительский заказ уже выполнен. Хотя некоторая часть системы обработки заказов определяла, что родительский заказ выполнен, в SMARS эта информация не попадала.
  • +15
    Я правильно понял? Один техник по неосторожности обанкротил компанию которая ежедневно торговала акциями на 21 млрд. $ ??? С 1418 сотрудниками?
    • +35
      Компания обанкротилась из-за кривых бизнес-процессов, халатного отношения к надежности и отсутствия сценариев поведения в критических ситуациях подобных описанной выше. Банкротство такой компании — дело времени.
      • +5
        Да, ладно. Так можно практически о любой компании сказать. Здесь просто специфика биржевой торговли повлияла на банкротство.
    • +4
      Да, ну или на него всех собак повесили.
    • НЛО прилетело и опубликовало эту надпись здесь
      • –3
        На самом деле таких «техников» (которые выполняют ответственную работу) — подавляющее большинство.
        Грубо говоря — неправильная верстка сайта существенно влияет на доходы компании. Значит верстальщик и дизайнер оказываются в положении «техника».
        Уборщица, которая своим пылесосом случайно вырывает «важную вилку» из «важной розетки» — растиражированный синематографом пример.
        Не станем мы же к каждой уборщице приставлять «тестера»?
        Вопрос не в том, «может ли данный сотрудник обанкротить компанию?», а скорее «с какой вероятностью данный сотрудник в результате ошибки или преднамеренно может принести ущерб компании и в каком размере?». Исходя из этого и строится иерархия и назначаются оклады.
        • +6
          Если у вас железяку за миллион баксов можно просто выткнуть из розетки, у неё нет UPS'а, нет дублирования и около неё ведёт уборку человек, не знающий об особенностях безопасности уборки там — виноват не этот человек, отнюдь, а тот, кто допустил всё это.
      • +7
        • +1
          Показалось сначала, что она в шапке-ушанке :)
    • 0
      Ну конечно, это именно техник не той полярностью датчик прикрутил к ракете.
  • +16
    Имея опыт работы в нескольких не самыл мелких компаниях подобного рода, могу сказать что подобная безалаберность в порядке вещей.

    Релизы на продакшин выкативаются вручную (буквально копируются файлики один за другим). Причем зачастую не специально обученными техниками, а самими разработчиками.
    Нет пре-продакшина, содержащего идентичную копию продакшина, для репетиции выката-отката и предварительной верификации.
    Нет процедур двойного (уже молчу про тройной) контроля процесса выката на продакшин.
    нет процедур emergency response
    итд

    И это при том что цена ошибки в буквальном смысле миллиарды.

    Либо мне просто не повезло, либо это бич индустрии.
    • 0
      примено в каких отраслях работают эти компании? примерно какие системы описаны?
      • +1
        В трейдинге. Знаю примеры систем для NYSE и Forex. Называть конкретные компании и софт не буду. Скажу лишь, что он известный.
        • 0
          Угу, спасибо.
          • +1
            Тоже могу подтвердить, после почти 10 лет в банках — не везде и не всегда есть нормальная процедура деплоймента, адекватное тестирование, и использование транзакций.
            • +1
              банковские транзакции реализованы без транзакций? да ладно :))
              • +2
                Это было мое первое потрясение от той системы в которой я с самого начала работал. Совершенно четко не было транзакций. Большая OTC торговая площадка.
      • 0
        Те, в которых работал я, в equity trading, repo trading
    • 0
      О да! Я Вам поставил плюс. Я вот поработал в 2-ух инвестбанках в Нью-Йорке. Это точно так, как вы говорите — безолаберность и неграмотность в порядке вещей. Причем, на митингах, где хоть как-то можно было бы начать обсуждение проблем, начальство рапортует о том, как все прекрасно и о том, как у нас нет проблем. Как будто разработчики совсем имбицилы и не видят, что происходит.
  • +18
    Небольшая подборка ошибок в ПО и проектировании из книги Стива Макконнелла «Профессиональная разработка программного обеспечения»:
    Космический зонд «Маринер-1» был потерян на пути к Венере из-за ошибки в программировании управления навигацией.

    Самолет, выполнявший рейс № 655 иранских авиалиний, был сбит системой «Эгида» (щит Зевса) американского авианосца «Винсенн» в 1988 г. Погибло 290 человек. Поначалу ошибку записали на счет оператора, но позднее некоторые специалисты посчитали причиной происшествия плохой дизайн пользовательского интерфейса системы «Эгида».

    Ракета «Ариан-5» взорвалась при первом пуске из-за ошибки в ПО.

    Бомбардировщик «Б-2» также не взлетел с первого раза из-за проблем с ПО.

    В Лондоне автоматизированная система отправки бригад скорой помощи по вызовам была введена в действие раньше, чем была готова, и полностью рухнула, что вызвало задержки до 11 часов. Новая система отправки бригад стала причиной 20 смертных случаев.

    Цутому Шимомура оставил свой автомобиль на парковке аэропорта в Сан-Диего 29 февраля 1992 г. Когда он вернулся через 6 дней, счет за стоянку составил более 3 тысяч долларов. ПО парковки не распознало дату 29 февраля как правильную.

    В январе 1990 г. из-за ошибки ПО за 9 часов было блокировано примерно пять миллионов телефонных звонков.

    Первый полет корабля многоразового использования был отложен на два дня из-за трудноуловимой ошибки программиста.

    Неполадки в системе обработки багажа привели к задержке открытия международного аэропорта в Денвере более чем на год. Потери оцениваются в $1100 000 в день.

    Управляемые компьютером паромы в г. Сиэттл (штат Вашингтон) около полутора десятка раз врезались в доки, нанеся ущерб на сумму свыше $7 000 000. Власти штата рекомендовали выделить более $3000000 на перевод паромов обратно на ручное управление.

    Налоговая служба США провалила программу модернизации ПО стоимостью $8000 000000, что обошлось в $50000 000 000 несобранных доходов в год.

    Улучшенная АСУ Федерального управления авиации (FAA) превысила выделенный бюджет примерно на $3000 000 000.
    • +14
      что-то мужик с парковкой в этом списке вообще ни о чем
      • +3
        В 92 году это приличная сумма была, как 15 тысяч сегодня.
      • +13
        Это ему Митник поди подосрал.
    • +9
      Ну к багам последний пункт ("… превысила бюджет...") вряд ли подходит.
      Как и "… отложен полёт корабля на 2 дня...", это кстати наоборот, правильный подход — никаких авось или деплоя с багом, ищем проблему до победного.

      Остальные же эпичны, да.
      • +9
        Стив Макконнелл приводит этот пункт, как пример ошибочного проектирования, что тоже важно. Примеры хорошего проектирования:
        Телекоммуникационной компании понадобилось изменить около 3 тысяч строк в базовом ПО объемом примерно в 1000000 строк. Изменения были внесены столь тщательно, что через год работы не обнаружилось ни одной ошибки. Время, которое потребовалось для внесения изменений, включая анализ требований, планирование, реализацию и тестирование, составило 9 часов.

        Группа разработчиков ПО для ВВС США взялась реализовать некий проект за год с бюджетом $2000000, хотя другие вполне достойные разработчики предлагали срок до 2 лет при бюджете до $100000000. Когда же эта группа сдала ПО на месяц раньше срока, менеджер проекта заявил, что успех достигнут за счет методик, известных уже несколько лет, но редко применяемых на практике.

        Авиастроительная компания разрабатывает ПО для клиентов по фиксированной цене, при этом только 3% ее проектов превышают сметную стоимость; 97% из 100 укладываются в бюджет.

        Организация, твердо следующая политике достижения исключительного качества ПО, в течение 9 лет добивалась ежегодного снижения на 39% количества дефектов, обнаруживаемых после выпуска версий; итоговое снижение составило 99%.
        • +7
          менеджер проекта заявил, что успех достигнут за счет методик, известных уже несколько лет, но редко применяемых на практике.

          Страшно подумать, что же это за методики
          • +6
            Если мне не изменяет память, то это те же методики по которым строили пирамиды.
            • +5
              рабский труд?)
              • +6
                Пирамиды не строились рабским трудом, более того, ЕМНИП, рабам вообще было запрещено их строить — их считали недостойными такой великой работы. И да, практически все строители были волонтёрами — в наше время звучит глупо, но вот такая вот тогда была преданность фараону…
                • 0
                  Насколько я читал, это было не совсем добровольно — что-то типа современного призыва на военную службу. Но да, строили рядовые граждане.

                  Но рабы им тоже помогали — делали всю самую тяжелую и гразную работу, но не относящуюся напрямую к постановке камень на камень. Соответственно, граждане содержались в хороших бараках и условиях, а рабы — спали в канавах.
            • 0
              Бросали туда боль и страдания пока все не заработает?
        • +4
          > Время, которое потребовалось для внесения изменений, включая анализ требований, планирование, реализацию и тестирование, составило 9 часов.

          3 тысячи строк из миллиона за 9 часов (это 9 часов групповой работы или 9 человеко-часов?)
          включая анализ требований, планирование, реализацию и тестирование?
          включая наверное то, что программисты до этого в этот миллион строк кода не лазили и не знали заранее что конкретно придется изменять?

          не верю!
          либо это синтетический пример, где просто заменили имплементацию интерфейса другой готовой и оттестированной имплементацией
          либо это «охотничья байка»
          • 0
            а что тут удивительного? миллион строк всего. в ядре, допустим, 3 тысячи. Логику ядра переписали полностью, оставив те же самые вызовы. При этом если это ядро было модульным, могли раскидать его на over9000 разработчиков. Ну это грубо говоря. Тут скорее всего 9 часов — это время обезьяньей работы по написанию кода, а время подробного проектирования (вплоть до названий методов и сигнатуры) не учтено.
          • +1
            find . -type f -exec sed -i 's#MySQL AB#Oracle Corporation#g' {} \;
            rm -rf tests/
    • +16
      Вы как-то уникально разряды выделяете!
    • +4
      Еще случай с Therac хрестоматийный:

      «Из-за состояния гонки между управляющей программой и обработчиком клавиатуры иногда случалось, что в режиме рентгеновской терапии диск оказывался в положении «Электронная терапия», и пациент напрямую облучался пучком электронов в 25 МэВ, что вело к переоблучению. При этом датчики выводили «Нулевая доза», поэтому оператор мог повторить процедуру, усугубляя ситуацию. В результате погибли как минимум четыре пациента.»

      ru.wikipedia.org/wiki/Race_condition#.D0.A1.D0.BB.D1.83.D1.87.D0.B0.D0.B9_.D1.81_Therac-25
      • 0
        Что такое «состояние гонки между управляющей программой и обработчиком клавиатуры»?
        • +1
          Это ирония?
          • 0
            Отнюдь. Мне даже пространное описание по ссылке не очень как-то помогло в понимании.
            • 0
              Там же даже пример кода приведён.
              • 0
                Тьфу ты, статья про состояние гонки а не про Therac-25. А я только с этого абзаца и до конца дочитал. Мой косяк, невнимателен.
  • 0
    del
  • +1
    Поэтому софт на прод нужно всегда выкатывать скриптом. К моменту когда софт будет ворочать реальным баблом, скрипт уже будет нормально отлажен, а пакет для развертывания — проверен на всяких UAT и Staging. Лучше никогда на серваки никаких «техников» вообще не пускать, тем более что руками какие-то скрипты по кускам там менять.
    • 0
      Скрипты тоже могут не сработать на всех серверах. Занимаюсь развертыванием несколько лет, в любом случае нужны пробники.
      • +2
        а точнее, регламенты и мониторинг.
      • +2
        Пардон, скрипт «свалится» и всем заинтересованным придет письмо счастья
  • +4
    Так вот что значит фраза «Epic Fail»
  • 0
    Мне больше всего «нравится» бага с округлением в ракете патриот и как забили конвертнуть физические единицы в обитере
  • +1
    Я кстати так и не понял до конца. Те $460 миллионов таки списали с фирмы реально? Или просто откатили и штрафанули fine-ом на $12 мультов?
    • 0
      Списали
      • 0
        Всмысле списали? Knight Capital что-то купило на них или куда эти деньги вообще делись?
        • +1
          Это потери от закрытия позиций
    • +2
      Ну, как бы сказать… Торги на бирже идут в реальном времени, а кто согласится вернуть полученные деньги на фразу «у нас была ошибка в программе, верните деньги!»?
      • +1
      • 0
        Торги идут в рельном времени, но сделки закрываются после закрытия торгов. Откатить «ошибочную» сделку нельзя ни при каких условиях, таковы правила. Иначе все, кто понес убытки будут придумывать отмазки чтобы откатить плохие сделки.
  • +1
    Спасибо!
    Давно хотел узнать, что там произошло, но читать длинные документы на английском было лень.
  • 0
    Такие истории с техникой случались и до компьютеризации.
    Читал историю, как в небольшом американском городке электрик перепутал полярность нескольких мощных линий постоянного тока. К ним были подключены различные предприятия. В результате все электродвигатели на них начали вращаться в обратную сторону (-: Конвейеры поехали назад, на швейной фабрике нитки стали разматываться в обратную сторону…
    • 0
      интересно где применяются мощные силовые линии постоянного тока?
    • 0
      Сомнительно, ведь для мощных коллекторных двигателей полярность питания не важна — при переполюсовке изменится направление магнитного потока как якоря, так и обмоток возбуждения, и вращающий момент будет направлен в ту же сторону, что и раньше.
  • 0
    Интересно, что менеджмент не учился на своих ошибках:
    35.Several previous events presented an opportunity for Knight to review the adequacy of its controls in their entirety. For example, in October 2011, Knight used test data to perform a weekend disaster recovery test. After the test concluded,
    Knight’s LMM desk mistakenly continued to use the test data to generate automated quotes when trading began that Monday morning. Knight experienced a nearly $7.5 million loss as a result of this event. Knight responded to the event by
    limiting the operation of the system to market hours, changing the control so that this system would stop providing quotes after receiving an execution, and adding an item to a
    disaster recovery checklist that required a check of the test data. Knight did not broadly consider whether it had sufficient controls to prevent the entry of erroneous orders, regardless of
    the specific system that sent the orders or the particular reason for that system’s error. Knight also did not have a mechanism to test whether their systems were relying on stale data.

    В кратце говориться о том, что они выкатили в продакшен приложение, которое брало котировки не от биржи, а от тестового сервера. Убытки в 7.5 лямов менеджмент ничему не научили.
  • 0
    Как будто у вас на работе все сделано не через одно место? И даже вот после таких ситуаций, в голове у начальства ничего не щёлкает.

    Сделай сейчас и вчера выложи на продакшн — стандартная же тема.
  • 0
    а всё потому что нужно грамотно чистить код и выставлять алерты при накате обновления.
  • 0
    Вот, кстати, еще статья про этот случай (без таких подробностей)
    habrahabr.ru/post/149019/

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.