Comments 94
Можно бросать этотим постом в работодателя когда он отказывается нанимать тестировщика :)
Я вообще искренне радуюсь таким событиям. Может меньше буду со временем слышать позорных отмазок «у нас нет на это времени».
Тот самый случай, когда «скупой платит дважды». Не стоит экономить на спичках.
Думаете тестировщик отловил бы неправильный деплой?
Не знаю, как все, но я перед развертыванием на боевые сервера чего-либо провожу тестирование самого развертывания и проверяю корректность развертывания на боевых серверах в том числе.
В идеале — с пошаговым расписыванием процедуры и выполнением всех шагов
В идеале — с пошаговым расписыванием процедуры и выполнением всех шагов
У нас в компании тестеровщик еще бы и баг этот исправил. Не все же тестировщики обычные обезьяны, которым показали как и в какие кнопки тыкать.
При чем здесь тестировщики? Новую версию софта наверняка протестировали на UAT перед тем как выкатывать на продакшин. Беда случилась из-за того, что забыли выкатить на один из боевых серверов.
Серверов не тысяча, не сто, даже не пятьдесят. Их всего 8 штук. Как можно было пропустить? Может это хитрый план такой, и техник срубил немного денег.
После установки новой версии проводится смоук, чтобы убедиться что все встало нормально. На этой стадии и было бы выявлено что на один из серверов забыли накатить новую версию.
Как вы представляете «смоук» на живой трейдинговой системе с алгоритмическим трейдингом? Там роботы торгуют с настоящими котировками.
биржи не круглосуточно же работают
Когда биржи не работают, котировок нет, поэтому используют эмуляторы. И хорошо, если эти эмуляторы повторяют, например, поведение рынка за вчерашний день. Т.е. оптимально им было бы выкатиться через пару часов после закрытия биржи, повесить табличку «мы скоро вернемся», выключить клиентов, прогнать тесты на эмуляторе за вчерашний день, переключив при этом их роботов в paper trading. Учитывая, что у них даже апдейты продакшна шли вручную, таких апдейт-скриптов у них точно нет. Реально в трейдинге нужно очень много тестов (юниты, интеграция end-to-end) и совсем немного квалифицированных «живых» тестировщиков. Армия обезьянок, к сожалению, вообще никак не поможет. И повальный DevOps, без этого рано или поздно вот такая хрень обязательно произойдет.
Насколько я понял они обновляли не весь зоопарк машин, а только часть ответственную за определенную работу(обработка заказов). И для нее сэмулировать данные попроще будет. Вот для этого и надо было бы провести тестирование, а не для всей трейдинговой системы. Юниты, интеграция end-to-end должны проводиться на тестовом енве, но никак не на продакшене. На проде максимум небольшой не ломающий ничего смоук, чтобы проверить что все встало нормально.
Не тестировщика, а архитектора системы качества и управления техническими рисками. Разница в зарплате где-то на порядок. Тем не менее для подобной конторы это действительно экономия на спичках.
UFO just landed and posted this here
По-русски «child process» — это не «детский», а «дочерний» процесс.
И кстати, callable — не «вызываемая», а «вызывабельная», то есть доступная для вызова. Код Power Peg НЕ вызывался в ходе нормальной процедуры.
Новый ПЛ код использовал флаг, который ранее был привязан к Power Peg. — не просто «был привязан». Установка этого флага активировала вызов Power Peg. Смысл понятен: они решили заменить процедуру, но вызывать её установкой того же флага, что и раньше. По замуслу код Power Peg следовало удалить, и теперь установка флага вызывала бы уже новый код.
Поскольку Power Peg с 2003 года не использовалась, с 2003 года флаг не ставился.
Новый ПЛ код использовал флаг, который ранее был привязан к Power Peg. — не просто «был привязан». Установка этого флага активировала вызов Power Peg. Смысл понятен: они решили заменить процедуру, но вызывать её установкой того же флага, что и раньше. По замуслу код Power Peg следовало удалить, и теперь установка флага вызывала бы уже новый код.
Поскольку Power Peg с 2003 года не использовалась, с 2003 года флаг не ставился.
Эмм, «вызывабельная»? Такого слова нет (аж редактор красным подчеркнул), а потому режет слух. Даже «вызываемая» не портит смысл. Если уж так хочется передать сей тонкий момент, предлагаю использовать словосочетание «потенциально вызываемая».
Конечно, нет такого слова. Я использовал кавычки, чтобы показать, что его нет, что я его сконструировал, чтобы передать смысл. Но, голова моя садовая, не сообразил, что кавычки у меня уже заняты и никто не догадается, что здесь они значат совсем иное. Mea culpa.
То есть по сути вашего комментария — согласен полностью и признаю свою ошибку. Потенциально вызываемая — лучше, чем доступная для вызова. И что угодно лучше вызывабельной.
То есть по сути вашего комментария — согласен полностью и признаю свою ошибку. Потенциально вызываемая — лучше, чем доступная для вызова. И что угодно лучше вызывабельной.
Только после вашего комментария понял, что автор хотел сказать.
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 не выполнили и в том, что процедура по-прежнему работает корректно, не убедились.
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 не выполнили и в том, что процедура по-прежнему работает корректно, не убедились.
И 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 эта информация не попадала.
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 эта информация не попадала.
Я правильно понял? Один техник по неосторожности обанкротил компанию которая ежедневно торговала акциями на 21 млрд. $ ??? С 1418 сотрудниками?
Компания обанкротилась из-за кривых бизнес-процессов, халатного отношения к надежности и отсутствия сценариев поведения в критических ситуациях подобных описанной выше. Банкротство такой компании — дело времени.
Да, ну или на него всех собак повесили.
UFO just landed and posted this here
На самом деле таких «техников» (которые выполняют ответственную работу) — подавляющее большинство.
Грубо говоря — неправильная верстка сайта существенно влияет на доходы компании. Значит верстальщик и дизайнер оказываются в положении «техника».
Уборщица, которая своим пылесосом случайно вырывает «важную вилку» из «важной розетки» — растиражированный синематографом пример.
Не станем мы же к каждой уборщице приставлять «тестера»?
Вопрос не в том, «может ли данный сотрудник обанкротить компанию?», а скорее «с какой вероятностью данный сотрудник в результате ошибки или преднамеренно может принести ущерб компании и в каком размере?». Исходя из этого и строится иерархия и назначаются оклады.
Грубо говоря — неправильная верстка сайта существенно влияет на доходы компании. Значит верстальщик и дизайнер оказываются в положении «техника».
Уборщица, которая своим пылесосом случайно вырывает «важную вилку» из «важной розетки» — растиражированный синематографом пример.
Не станем мы же к каждой уборщице приставлять «тестера»?
Вопрос не в том, «может ли данный сотрудник обанкротить компанию?», а скорее «с какой вероятностью данный сотрудник в результате ошибки или преднамеренно может принести ущерб компании и в каком размере?». Исходя из этого и строится иерархия и назначаются оклады.
Ну конечно, это именно техник не той полярностью датчик прикрутил к ракете.
Имея опыт работы в нескольких не самыл мелких компаниях подобного рода, могу сказать что подобная безалаберность в порядке вещей.
Релизы на продакшин выкативаются вручную (буквально копируются файлики один за другим). Причем зачастую не специально обученными техниками, а самими разработчиками.
Нет пре-продакшина, содержащего идентичную копию продакшина, для репетиции выката-отката и предварительной верификации.
Нет процедур двойного (уже молчу про тройной) контроля процесса выката на продакшин.
нет процедур emergency response
итд
И это при том что цена ошибки в буквальном смысле миллиарды.
Либо мне просто не повезло, либо это бич индустрии.
Релизы на продакшин выкативаются вручную (буквально копируются файлики один за другим). Причем зачастую не специально обученными техниками, а самими разработчиками.
Нет пре-продакшина, содержащего идентичную копию продакшина, для репетиции выката-отката и предварительной верификации.
Нет процедур двойного (уже молчу про тройной) контроля процесса выката на продакшин.
нет процедур emergency response
итд
И это при том что цена ошибки в буквальном смысле миллиарды.
Либо мне просто не повезло, либо это бич индустрии.
примено в каких отраслях работают эти компании? примерно какие системы описаны?
В трейдинге. Знаю примеры систем для NYSE и Forex. Называть конкретные компании и софт не буду. Скажу лишь, что он известный.
Те, в которых работал я, в equity trading, repo trading
UFO just landed and posted this here
Небольшая подборка ошибок в ПО и проектировании из книги Стива Макконнелла «Профессиональная разработка программного обеспечения»:
Космический зонд «Маринер-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.
что-то мужик с парковкой в этом списке вообще ни о чем
Ну к багам последний пункт ("… превысила бюджет...") вряд ли подходит.
Как и "… отложен полёт корабля на 2 дня...", это кстати наоборот, правильный подход — никаких авось или деплоя с багом, ищем проблему до победного.
Остальные же эпичны, да.
Как и "… отложен полёт корабля на 2 дня...", это кстати наоборот, правильный подход — никаких авось или деплоя с багом, ищем проблему до победного.
Остальные же эпичны, да.
Стив Макконнелл приводит этот пункт, как пример ошибочного проектирования, что тоже важно. Примеры хорошего проектирования:
Телекоммуникационной компании понадобилось изменить около 3 тысяч строк в базовом ПО объемом примерно в 1000000 строк. Изменения были внесены столь тщательно, что через год работы не обнаружилось ни одной ошибки. Время, которое потребовалось для внесения изменений, включая анализ требований, планирование, реализацию и тестирование, составило 9 часов.
Группа разработчиков ПО для ВВС США взялась реализовать некий проект за год с бюджетом $2000000, хотя другие вполне достойные разработчики предлагали срок до 2 лет при бюджете до $100000000. Когда же эта группа сдала ПО на месяц раньше срока, менеджер проекта заявил, что успех достигнут за счет методик, известных уже несколько лет, но редко применяемых на практике.
Авиастроительная компания разрабатывает ПО для клиентов по фиксированной цене, при этом только 3% ее проектов превышают сметную стоимость; 97% из 100 укладываются в бюджет.
Организация, твердо следующая политике достижения исключительного качества ПО, в течение 9 лет добивалась ежегодного снижения на 39% количества дефектов, обнаруживаемых после выпуска версий; итоговое снижение составило 99%.
менеджер проекта заявил, что успех достигнут за счет методик, известных уже несколько лет, но редко применяемых на практике.
Страшно подумать, что же это за методики
Если мне не изменяет память, то это те же методики по которым строили пирамиды.
рабский труд?)
Пирамиды не строились рабским трудом, более того, ЕМНИП, рабам вообще было запрещено их строить — их считали недостойными такой великой работы. И да, практически все строители были волонтёрами — в наше время звучит глупо, но вот такая вот тогда была преданность фараону…
Насколько я читал, это было не совсем добровольно — что-то типа современного призыва на военную службу. Но да, строили рядовые граждане.
Но рабы им тоже помогали — делали всю самую тяжелую и гразную работу, но не относящуюся напрямую к постановке камень на камень. Соответственно, граждане содержались в хороших бараках и условиях, а рабы — спали в канавах.
Но рабы им тоже помогали — делали всю самую тяжелую и гразную работу, но не относящуюся напрямую к постановке камень на камень. Соответственно, граждане содержались в хороших бараках и условиях, а рабы — спали в канавах.
Бросали туда боль и страдания пока все не заработает?
> Время, которое потребовалось для внесения изменений, включая анализ требований, планирование, реализацию и тестирование, составило 9 часов.
3 тысячи строк из миллиона за 9 часов (это 9 часов групповой работы или 9 человеко-часов?)
включая анализ требований, планирование, реализацию и тестирование?
включая наверное то, что программисты до этого в этот миллион строк кода не лазили и не знали заранее что конкретно придется изменять?
не верю!
либо это синтетический пример, где просто заменили имплементацию интерфейса другой готовой и оттестированной имплементацией
либо это «охотничья байка»
3 тысячи строк из миллиона за 9 часов (это 9 часов групповой работы или 9 человеко-часов?)
включая анализ требований, планирование, реализацию и тестирование?
включая наверное то, что программисты до этого в этот миллион строк кода не лазили и не знали заранее что конкретно придется изменять?
не верю!
либо это синтетический пример, где просто заменили имплементацию интерфейса другой готовой и оттестированной имплементацией
либо это «охотничья байка»
а что тут удивительного? миллион строк всего. в ядре, допустим, 3 тысячи. Логику ядра переписали полностью, оставив те же самые вызовы. При этом если это ядро было модульным, могли раскидать его на over9000 разработчиков. Ну это грубо говоря. Тут скорее всего 9 часов — это время обезьяньей работы по написанию кода, а время подробного проектирования (вплоть до названий методов и сигнатуры) не учтено.
find . -type f -exec sed -i 's#MySQL AB#Oracle Corporation#g' {} \;rm -rf tests/
Вы как-то уникально разряды выделяете!
Еще случай с Therac хрестоматийный:
«Из-за состояния гонки между управляющей программой и обработчиком клавиатуры иногда случалось, что в режиме рентгеновской терапии диск оказывался в положении «Электронная терапия», и пациент напрямую облучался пучком электронов в 25 МэВ, что вело к переоблучению. При этом датчики выводили «Нулевая доза», поэтому оператор мог повторить процедуру, усугубляя ситуацию. В результате погибли как минимум четыре пациента.»
ru.wikipedia.org/wiki/Race_condition#.D0.A1.D0.BB.D1.83.D1.87.D0.B0.D0.B9_.D1.81_Therac-25
«Из-за состояния гонки между управляющей программой и обработчиком клавиатуры иногда случалось, что в режиме рентгеновской терапии диск оказывался в положении «Электронная терапия», и пациент напрямую облучался пучком электронов в 25 МэВ, что вело к переоблучению. При этом датчики выводили «Нулевая доза», поэтому оператор мог повторить процедуру, усугубляя ситуацию. В результате погибли как минимум четыре пациента.»
ru.wikipedia.org/wiki/Race_condition#.D0.A1.D0.BB.D1.83.D1.87.D0.B0.D0.B9_.D1.81_Therac-25
del
Поэтому софт на прод нужно всегда выкатывать скриптом. К моменту когда софт будет ворочать реальным баблом, скрипт уже будет нормально отлажен, а пакет для развертывания — проверен на всяких UAT и Staging. Лучше никогда на серваки никаких «техников» вообще не пускать, тем более что руками какие-то скрипты по кускам там менять.
Так вот что значит фраза «Epic Fail»
Мне больше всего «нравится» бага с округлением в ракете патриот и как забили конвертнуть физические единицы в обитере
Я кстати так и не понял до конца. Те $460 миллионов таки списали с фирмы реально? Или просто откатили и штрафанули fine-ом на $12 мультов?
Спасибо!
Давно хотел узнать, что там произошло, но читать длинные документы на английском было лень.
Давно хотел узнать, что там произошло, но читать длинные документы на английском было лень.
Такие истории с техникой случались и до компьютеризации.
Читал историю, как в небольшом американском городке электрик перепутал полярность нескольких мощных линий постоянного тока. К ним были подключены различные предприятия. В результате все электродвигатели на них начали вращаться в обратную сторону (-: Конвейеры поехали назад, на швейной фабрике нитки стали разматываться в обратную сторону…
Читал историю, как в небольшом американском городке электрик перепутал полярность нескольких мощных линий постоянного тока. К ним были подключены различные предприятия. В результате все электродвигатели на них начали вращаться в обратную сторону (-: Конвейеры поехали назад, на швейной фабрике нитки стали разматываться в обратную сторону…
интересно где применяются мощные силовые линии постоянного тока?
Ну сам журнал, где я читал заметку, был годов 70-х, а произошел случай еще раньше. Раньше ведь в США было много потребителей постоянного тока.
Сомнительно, ведь для мощных коллекторных двигателей полярность питания не важна — при переполюсовке изменится направление магнитного потока как якоря, так и обмоток возбуждения, и вращающий момент будет направлен в ту же сторону, что и раньше.
Интересно, что менеджмент не учился на своих ошибках:
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 лямов менеджмент ничему не научили.
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 лямов менеджмент ничему не научили.
Как будто у вас на работе все сделано не через одно место? И даже вот после таких ситуаций, в голове у начальства ничего не щёлкает.
Сделай сейчас и вчера выложи на продакшн — стандартная же тема.
Сделай сейчас и вчера выложи на продакшн — стандартная же тема.
а всё потому что нужно грамотно чистить код и выставлять алерты при накате обновления.
Вот, кстати, еще статья про этот случай (без таких подробностей)
habrahabr.ru/post/149019/
habrahabr.ru/post/149019/
Sign up to leave a comment.
Как 45 минут терять по $172 222 в секунду