Катастрофические последствия программных ошибок
Время на прочтение
9 мин
Количество просмотров 44K
Практика не устает доказывать, что в любом ПО самая главная уязвимость — человеческий фактор. И неважно, появился ли баг из-за нехватки квалифицированности специалиста, выжил после долгих часов дебага в поисках ошибки, или считался хитро замаскировавшейся фичей. Среди некоторых разработчиков даже укрепилось мнение, что баги в принципе существуют всегда и везде. Но если ошибки абстрактны и сложно воспроизводимы в реальных условиях, то проблема не является критичной.
В идеальной ситуации баги исправляют все и сразу. Но в жизни всегда есть куча задач, отодвигающих полный и бесповоротный багфикс (новый функционал, срочные хотфиксы, расставленные приоритеты при исправлении багов). Это значит, что в первую очередь находятся и исправляются очевидные и явные проблемы. Остальные тихо ждут своего часа, превращаясь в бомбы замедленного действия. Иногда ошибки приводят не только к неприятностям в жизни рядового разработчика, но и вызывают настоящие катастрофы. Сегодня у нас подборка и объяснение самых кошмарных багов в истории разработки ПО.
Облучение и радиация
Знаменитый случай гибели нескольких человек, получивших смертельную дозу облучения во время сеансов радиационной терапии с применением медицинского ускорителя Therac-25. Ускорители подобного типа используют электроны для создания лучей высокой энергии, высокоточно уничтожающих опухоли. Но некоторые пациенты получили дозы не в несколько сотен рад, как предписывало лечение, а в 20 000 рад; доза в 1000 рад для человека считается несовместимой с жизнью, причем смерть может наступить сразу после облучения.
Всего один программист создал все ПО, используемое в аппаратах Therac — а это 20 тысяч инструкций, написанных на ассемблере. И при этом во всех Therac встречался один тот же пакет библиотек, содержащий ошибки.
Ускоритель Therac-25, ставший третьим в серии успешных аппаратов лучевой терапии, мог работать с рентгеновскими лучами до 25 МэВ. Несколько лет в середине 80-х аппараты Therac-25 работали безупречно, однако со временем начали накапливаться инциденты, повлекшие за собой тяжелые последствия: от ампутации конечностей до гибели пациентов.
Первое время баги просто не замечали, а все неполадки связывали с аппаратными сбоями. Программное обеспечение, безукоризненно проработавшее тысячи часов, воспринималось идеальным и безопасным. Никаких действий для предотвращения последствий возможных ошибок не предпринималось. Кроме того, выдаваемые оператору сообщения о критических с точки зрения безопасности ситуациях выглядели как рутинные. Производитель устройств расследовал каждый инцидент, но при этом не мог воспроизвести сбой. Потребовалось несколько лет исследований сторонних экспертов, привлеченных во время суда после череды смертей, чтобы сделать вывод о наличии большой плеяды именно программных ошибок.
Так при определенной последовательности ввода команд с клавиатуры происходил некорректный вызов процедур, влекущих за собой облучение любого произвольного участка тела пациента. Отсутствие на устройстве аппаратного блокиратора критических и продолжительных доз излучения усугубляло проблему.
Одна и та же переменная в ПО Therac-25, применялась как для анализа введенных чисел, так и для определения положения поворотного круга, отвечающего за направление излучателя. Поэтому при быстром вводе команд аппарат мог принять число дозы излучения за координаты места, куда нужно направить луч — например, прямо в мозг.
Иногда Therac-25 при расчете излучения делил на ноль и соответствующим образом увеличивал величины облучения до максимально возможных. Установка булевской переменной в значение «true» производилась командой «x=x+1» из-за чего с вероятностью 1/256 при нажатии кнопки «Set» программа могла пропустить информацию о некорректном положении излучателя.
Во внутренней документации производителя было обнаружено, что одно и то же сообщение об ошибке выдавалось как в случае ненадлежащей (малой) дозы облучения, так и для большой дозировки — отличить по сообщению об ошибке одно от другого было невозможно.
Если вы разработчик или (что еще лучше) тестировщик, этот случай стоит изучить досконально — есть хорошая статья в wiki, с нее можно начать, а затем ознакомьтесь с большой статьей девятнадцатилетней давности «Мифы о безопасном ПО: уроки знаменитых катастроф». История вобрала в себя большинство классических проблем тестирования.
Как ни печально, но проблемы Therac-25 не остались уникальными. В 2000 году серию аварий вызвал другой софт, точно так же просчитывающий нужную дозу облучения для пациентов, проходящих курс лучевой терапии.
Программное обеспечение Multidata позволяло медицинскому работнику рисовать на экране компьютера порядок размещения металлических блоков, предназначенных для защиты здоровых тканей от радиации. Но софт разрешал использовать только четыре защитных блока, в то время как врачи, в целях повышения безопасности, хотели использовать все пять.
Врачи воспользовались «лайфхаком». Оказалось, что в программе не предусмотрена защита от ввода некорректных данных — можно было нарисовать все пять блоков как один большой блок с отверстием в середине. В медицинском центре онкологии Панамы не понимали, что софт Multidata устанавливал разные показатели конфигурации в зависимости от того, как размещено отверстие: от направления его размещения рассчитывалась правильная доза облучения.
Из-за неверно введенных данных умерли восемь пациентов, в то время как еще 20 получили передозировку, повлекшую серьезные проблемы со здоровьем.
Блэкаут
Маленькая ошибка в программном обеспечении системы мониторинга работы оборудования General Electric Energy привела к тому, что 55 миллионов человек остались без электричества. На Восточном побережье США оказались обесточены жилые дома, школы, больницы, аэропорты.
14 августа 2003 года в 0:15 ночи оператор энергетической системы в Индиане с помощью инструмента мониторинга работы оборудования заметил небольшую проблему. Проблема вызвала раздражающий сигнал об ошибке, который оператор выключил. Оператору удалось за несколько минут решить все трудности, но он забыл перезапустить мониторинг — аварийный сигнал остался в выключенном положении.
Отключение сигнала не стало основной причиной блэкаута. Но когда через несколько часов из-за контакта с деревом вырубились провисшие линии электропередачи в Огайо — об этом никто не узнал. Проблема приняла лавинообразный характер, перегруженные линии передачи и электростанции начали вырубаться в Онтарио, Нью-Йорке, Нью-Джерси, Мичигане и далее.
Ни один из операторов не заметил каскад ошибок, которые медленно убивали энергосистему, из-за единственного выключенного сигнала тревоги — никаких дублирующих систем на этот случай не предполагалось.
Mars Climate Orbiter
В 1998 году NASA потеряло спутник «Mars Climate Orbiter» стоимостью $ 125 млн из-за того, что субподрядчик, работавший над инженерными задачами, не перевел английские единицы измерения (фунты) в метрическую систему. В результате ошибки спутник после 286-дневного путешествия на большой скорости вошел в марсианскую атмосферу, где из-за возникших перегрузок его системы связи вышли из строя. Аппарат оказался на сто километров ниже планируемой орбиты и на 25 км ниже высоты, на которой еще можно было исправить ситуацию. В результате спутник разбился. Такая же участь постигла космический аппарат Mars Polar Lander.
Mariner 1
В 1962 году космический корабль «Mariner 1» был уничтожен с земли после старта из-за отклонения от курса. Авария возникла на ракете из-за программного обеспечения, в котором разработчик пропустил всего один символ. В результате корабль стоимостью 18 миллионов долларов (в деньгах тех лет) получал неверные управляющие сигналы.
При работе над системой управления ракетой программист переводил рукописные математические формулы в компьютерный код. Символ «верхнего тире» (индекса), он воспринял за обычное тире (или знак минус). Функция сглаживания стала отражать нормальные вариации скорости ракеты как критические и недопустимые.
Однако даже допущенная ошибка могла не привести к критическому сбою, но как назло антенна ракеты потеряла связь с наводящей системой на Земле, и управление взял на себя бортовой компьютер.
Запуск баллистических ракет
26 сентября 1983 года спутник эшелона «Око» системы предупреждения о ракетном нападении СССР ошибочно сообщил о запуске пяти баллистических ракет с территории США. Спутник находился на высокой эллиптической орбите, наблюдая за районами базирования ракет под таким углом, чтобы они находились на краю видимого диска Земли. Это позволяло обнаружить факт запуска на фоне темного космического пространства по инфракрасному излучению работающего ракетного двигателя. Кроме того, выбранное расположение спутника снижало вероятность засветок датчиков отраженным от облаков или снега солнечным светом.
После безупречного года работы внезапно выяснилось, что в один день при определенном положении спутника и Солнца свет отражается от облаков, расположенных на больших высотах, оставляя то самое инфракрасное излучение, которое компьютеры восприняли как след от ракет. Заступивший на боевое дежурство подполковник Станислав Петров усомнился в показаниях системы. Подозрение вызвало сообщение о пяти замеченных целях — в случае реального военного конфликта США одновременно произвели бы сотни пусков. Подполковник Петров решил, что это ложное срабатывание системы, и тем самым, вероятно, предотвратил Третью мировую войну.
Подобная ошибка, едва не повлекшая за собой глобальный ядерный конфликт, произошла и по другую сторону океана. 9 ноября 1979 года из-за сбоя компьютера воздушно-космической обороны Северной Америки была получена информация о начале ракетной атаки против США — в количестве 2200 запусков. В то же время спутники раннего предупреждения и радары показали, что никакой информации о советской атаке не поступало — только благодаря перепроверке данных, сделанной за 10 минут, не был отдан приказ о взаимном гарантированном уничтожении.
Причиной всему оказалась самая опасная уязвимость — человеческий фактор. Оператор компьютера, находящегося на боевом дежурстве, загрузил в него пленку с учебной программой, имитировавшей ситуацию массированной ракетной атаки.
За несколько первых лет работы Национального центра управления Объединенного командования аэрокосмической обороны США и Канады было зафиксировано 3703 ложных сигнала тревоги, большая часть из которых появилась из-за атмосферных явлений. Однако случались и компьютерные ошибки. Так один из «боевых» компьютеров 3 июня 1980 года показал постоянно меняющиеся цифры количества ракет, запущенных Советским Союзом. Проблема возникла из-за аппаратного сбоя в микросхеме.
Обновление софта и деление на 0
В 1997 американский ракетный крейсер «Йорктаун» (CG-48), на котором были установлены 27 компьютеров (Pentium-Pro на 200 МГц), решил поделить на ноль и полностью вышел из строя.
Компьютеры работали на Windows NT — и работали они ровно так, как вы и ожидаете, узнав название оси. В то время ВМФ США старался максимально широко использовать коммерческое ПО с целью снижения стоимости военной техники. Компьютеры же позволяли автоматизировать управление кораблем без участия человека.
На компьютеры «Йорктауна» поставили новую программу, управляющую двигателями. Один из операторов, занимавшийся калибровкой клапанов топливной системы, записал в одну из ячеек расчетной таблицы нулевое значение. 21 сентября 1997 года программа запустила операцию деления на этот самый ноль, началась цепная реакция, и ошибка быстро перекинулась на другие компьютеры локальной сети. В результате отказала вся компьютерная система «Йорктауна». Потребовалось почти три часа, чтобы подключить аварийную систему управления.
Схожая проблема с нулем возникла при испытании истребителя в Израиле. Безупречно работавший самолет на автопилоте пролетел над равнинной частью, над горной частью, над долиной реки Иордан и приблизился к Мертвому морю. В этот момент произошел сбой, автопилот выключился, и пилоты посадили истребитель на ручном управлении.
После долгих разбирательств удалось выяснить, что программы автопилота при вычислении параметров управления производили деление на значение текущей высоты истребителя над уровнем океана. Соответственно, у Мертвого моря, лежащего ниже уровня океана, высота становилась нулевой, провоцируя ошибку.
В мире найдется немало историй, когда обновление софта, совершаемое с самыми благими целями, могло повести за собой множество проблем. В 2008 году атомная электростанция в штате Джорджия (США) мощностью 1,759 МВт в экстренном режиме приостановила работу на 48 часов.
Инженер компании, занимающейся технологическим обслуживанием станции, установил обновление на главный компьютер сети АЭС. Компьютер использовался для слежения за химическими данными и диагностики одной из основных систем электростанции. После установки обновлений компьютер штатно перезагрузился, стерев из памяти данные управляющих систем. Система безопасности станции восприняла потерю части данных как выброс радиоактивных веществ в системы охлаждения реактора. В результате автоматика подала сигнал тревоги и остановила все процессы на станции.
Инцидент с F-22
Двенадцать F-22 Raptor (истребитель пятого поколения, состоящий на вооружении США), стоимостью $ 140 млн за штуку, отправились в первый международный вылет в Окинаву. Все шло замечательно, пока эскадрилья не пересекла линию перемены даты, на западной стороне которой дата сдвинута на один день вперед относительно восточной. После пересечения условной линии все 12 истребителей одновременно выдали сообщение об ошибке, эквивалентной синему экрану смерти.
Самолеты потеряли доступы к данным о количестве топлива, датчикам скорости и высоты, частично нарушилась связь. В течение нескольких часов самые современные истребители Америки летели через океан совершенно беспомощными. В конце концов их удалось посадить только благодаря мастерству пилотов.
Так в чем же была ошибка? Проектировщики из Lockheed Martin даже не рассматривали вопрос о возможности пересечения линии перемены дат — им просто не пришло в голову, что где-то понадобится либо прибавлять, либо вычитать одни сутки.
Другие истории
В этой бескрайней теме есть еще несколько интересных историй. О них сложилось либо неправильное мнение, либо уже были подробные статьи на ГТ и Хабре.
Взрыв на советской газотранспортной системе в 1982 году из-за программных ошибок, заложенных ЦРУ. Эксперты категорически отрицают не только взрыв на газопроводе «Уренгой-Сургут-Челябинск» в 1982 году, но и вообще возможность возникновения такого взрыва.
Алгоритмическая ошибка привела к аварии самолета А-330 — в результате инцидента 119 пассажиров и членов экипажа получили ранения, из них 12 тяжелые.
Ракета-носитель Ariane 5 превратилась в «конфетти» 4 июня 1996 года — ошибка произошла в компоненте ПО, предназначенном для выполнения «регулировки» инерциальной платформы. Потеряно 500 млн долларов (стоимость ракеты с грузом).
Toyota: из-за корявой электроники и софта 89 человек погибли с 2000 по 2010 годы.
Источники:
habrahabr.ru/company/mailru/blog/227743
www.wikiwand.com/en/Therac-25
www.baselinemag.com/c/a/Projects-Processes/We-Did-Nothing-Wrong en.wikipedia.org/wiki/Northeast_blackout_of_2003
lps.co.nz/historical-project-failures-mars-climate-orbiter www.jpl.nasa.gov/missions/mariner-1
inosmi.ru/inrussia/20071229/238739.html
https://www.revolvy.com/main/index.php?s=USS%20Yorktown%20(CG-48)
www.defenseindustrydaily.com/f22-squadron-shot-down-by-the-international-date-line-03087
Как бы упорно мы не полагались на машины, они далеки от идеала. Как минимум, потому что сделаны человеком.
Пока программы не станут умнее людей, нам придётся следить за их состоянием постоянно. Особенно когда говорим об отвественном деле.
Истории ниже покажут, как сильно наши жизни зависят от правильно собранного алгоритма, и что бывает, если контроль качества на производстве возьмёт выходной.
Начнём со странных вещей, коснувшихся относительно скромного числа людей, а закончим настоящими финансовыми катастрофами. Они стоили не один десяток бессонных ночей тем, кому пришлось срочно вычитывать хрупкий код и буквально спасать человечество.
1. Система заживо похоронила 8 500 пациентов больницы в Мичигане
В 2003 году Медцентр Св. Марии Милосердия в городе Гранд-Рапидс обновил свою программу для учёта больных до новой версии. Из-за неверного толкования данных переменные «выписан» и «скончался» перепутались.
Потому всем, кто уже прошёл лечение начали приходить уведомления о смерти по почте и в разных отчётах вроде анализа крови.
Проблема не стала бы масштабной, но из-за высокой автоматизации сообщения направились и пациентам, и в страховые службы. Когда последние видели, что человек «умирал», то переставали компенсировать последующее лечение. Сюда входило больше 2 000 пенсионеров и инвалидов.
Поскольку ошибку нашли через два месяца после поломки, примерно столько же потребовалось, чтобы восстановить информацию в сопутствующих службах и компенсировать ущерб.
2. Обновление ПО лишило 60 тысяч человек междугородных звонков
В январе 1990 года американский оператор связи AT&T улучшал свою программу по контролю переключателей между вышками. Из-за ошибки в коде одна из них во время звонка начала отправлять сигналы быстрее, чем другая могла их обработать.
Данные начали наслаиваться друг на друга, и проблема быстро распространилась по другим точкам. На обратном конце люди слышали только шум. Так продолжалось 9 часов.
Проблему решили откатом ПО до предыдущей версии, однако проблема не перестала быть актуальной.
Ситуация повторилась как минимум один раз в 1998 году, но тогда были затронуты только сервисные уведомления по SMS.
3. 5% всех магазинов России сломалось из‑за новой онлайн‑кассы
20 декабря 2017 года техника по контролю данных обновлялась, чтобы продавцы начали напрямую передавать информацию о транзакциях налоговой службе. Одно из таких улучшений заблокировало каждый двадцатый магазин страны.
Сбои начались в салонах сети DNS во Владивостоке, где люди просыпаются раньше Москвы. Система не давала отправлять расчёты в Федеральную налоговую службу (ФНС), а из-за этого кассиры не имели права реализовывать товар.
Пока проблема добралась до столицы, откуда начал решаться вопрос, по всей России встали некоторые точки Магнита, Пятёрочки с Перекрёстком, Эльдорадо и аптек Ригла.
ФНС пришлось быстро реагировать и разрешать магазинам работать в офлайн режиме. Тем разрешили вносить данные после того, как система восстановится.
Полностью же проблему устраняли в течение нескольких дней патчами и принудительными перезагрузками.
Теоретический ущерб, по мнению Ассоциации компаний интернет-торговли, мог дойти до 2,5 млрд рублей. Реальный оказался чуть ниже благодаря быстрой оптимизации процессов со стороны ФНС.
4. Машине дали проектировать стадион в Коннектикуте. Тот рухнул
С 1972 года город Хартфорд старался расширить свою инфраструктуру и вкладывался в крупные проекты. Одним из них стал Hartford Civic Center – комплекс торговых, развлекательных и спортивных площадок.
Структуру стадиона проектировали через программу, что вместе с оптимизированным расходом материалов сэкономило городу около $500 тысяч.
Комплекс полностью функционировал и даже был «домом» для местной хоккейной группы New England Whalers с 1975 года.
Однако утром 18 января 1978-го стадион обвалился. Игр в тот день не проходило: здание было пустым и никто не пострадал.
СМИ растиражировали новость, где причиной указывали тяжесть снега. Но расследование показало, что на самом деле проблема была комплексной, а корнем оказалось наивное доверие программе.
Четыре несущие колонны с момента возведения были плохо продуманы в размере и креплении. Стадион начал постепенно «складываться» ещё во время строительства, а группы по контролю качества распределялись между разными подрядчиками и плохо согласовали данные.
Восстановление стоило городу $90 млн. В последствии на месте комплекса возвели арену XL Center, которая до сих пор исполняет роль главной спортивной площадки Хартфорда.
5. Intel выпустила процессор с ошибкой и устроила международный скандал
В 1994 году CPU под брендом Pentium был флагманом компании, и в нём пряталась микроскопическая проблема, которая касалась крошечной части людей: когда пользователь делил одно число на другое, результат был неверным. Выглядела ошибка так:
Программисты неправильно настроили одну из веток операций, вшитых в процессор. Она искала корневые данные и находила не те.
При этом основной ущерб пришёлся не на пользователей, а на компанию.
Из-за того, что Intel уже тогда уверенно чувствовала себя на рынке, а чипы были новые, даже федеральные СМИ многих стран подхватили новость и нанесли катастрофический ущерб имиджу и доходу компании.
В итоге за 1994 год замена всех повреждённых процессоров сократила выручку компании вдвое от запланированной – на $475 млн.
6. 6 миллионов автомобилей могут не раскрыть воздушные подушки
В январе 2020 года выяснилось, что датчики в некоторых моделях компаний Toyota и Honda слишком чувствительны к электрическому шуму.
Есть вероятность того, что в момент столкновения система не подаст сигнал системе безопасности. Та не сможет удержать ремни натянутыми, а подушки не наполнятся воздухом.
Проблема может быть глобальнее, поскольку компьютер из автомобилей Toyota разрабатывался сторонней организацией ZF-TRW. А она поставляла свои наработки как минимум шести компаниям в одних США, которые продали 12,3 млн машин.
Но пока только японские производители решили чинить датчики. И то, многие всё ещё ждут уведомления от своих диллеров.
7. MySpace уничтожил 50 миллионов песен пользователей
В 2016 году компания делала миграцию данных, которая началась еще в 2013 году. Уже тогда некоторые материалы и аккаунты стали недоступны части пользователей.
А в ходе переноса своей огромной библиотеки музыки, фотографий и видео возникла ошибка на сервере, которая их безвозвратно удалила.
Поскольку точной причины руководство не раскрыло, по поводу источника проблемы ходят разные слухи. Например, есть предположение, что хранить такой объём старых данных невыгодно и руководству было дешевле его «случайно» удалить.
Так или иначе, мир потерял один из крупнейших пластов интернет-культуры с 2003 по 2015 годы.
8. 144 тысячи родителей-одиночек не получили государственных выплат
В апреле 2003 года британская компания по поддержке малообеспеченных и неполноценных семей Child Support Agency внедрила систему по фильтрации заявлений. Она стоила £300 млн.
Спустя полгода обнаружилось, что обрабатывалась меньше, чем двадцатая часть просьб, и многие дети остались без материальной помощи.
Скандал длился как минимум до 2006 года, пока программа продолжала съедать 70% выделяемых на проект денег и затраты к 2010 году не составили £1,1 млрд.
В итоге в 2012 году агенство закрыли и вместо него запустили новую организацию Child Maintenance Group.
9. Уязвимость в защите 500 тысяч крупнейших сайтов давала доступ к вашей RAM
В апреле 2014 года специалисты по информационной безопасности обнаружили в библиотеке OpenSSL, на которой держится самый распространённый протокол HTTPS, критическую дыру в безопасности.
Её назвали Heartbleed по аналогии с процессом Heartbeat, взятым за основу этой ошибки.
С помощью уязвимости можно было узнать, что находится в оперативной памяти компьютера жертвы.
И, хотя максимальный объём украденной информации не мог превышать 64 Кб за один запрос, этого хватало на доступ к паролям и конфиденциальным сообщениям.
Ошибка затронула 17% всех защищенных сайтов. В том числе Google, Facebook, Instagram, Twitter и даже Minecraft.
Опасность закрывалась простым патчем, поэтому многие компании отреагировали быстро.
Однако по масштабу с этой проблемой сопоставима только одна, и вы наверняка о ней хоть раз слышали.
10. Мир потратил $300 млрд, чтобы в 2000 году компьютеры продолжили работать
Фото Эмори Кристоф / Emory Kristof
До 1999 года системы программировали так, что одни отмечали даты форматом из 8 цифр (ЧЧ.ММ.ГГГГ), а другие оставляли 6.
Это могло привести к тому, что переход в новое тысячелетие вызвал бы ошибки в программах по всей планете.
Дата формата ЧЧ.ММ.ГГ могла заменить 2000 на 1900 год, поскольку оба числа кончаются на «ОО». Таким образом ошибка бы переписала и стёрла данные, нарушила работу алгоритмов и спровоцировала коллапс онлайн-систем.
Большинство времени и ресурсов компаний ушло не на исправление последствий, а на то, чтобы проверить каждый компьютер в компании.
Поскольку программное обеспечение не переживало таких прыжков в исчислении времени раньше, ситуацию обсуждали по всему миру.
Вокруг Проблемы 2000 года (или Y2K) было много разговоров, в том числе о целесообразности паники. Их подогревало то, что страны восприняли вопрос серьезно и прописывали инициативы на государственном уровне.
Например, Россия создала официальный документ Национальный план действий по решению “Проблемы 2000” в Российской Федерации.
Табло на последней строке «обнулилось» и показывает 1900 вместо 2000
Ближайшая похожая ошибка настигнет не оптимизированные 32-битные системы в январе 2038 года, однако программисты уже готовятся к переходу.
64-х битных систем ситуация коснётся через 292 миллиарда лет, так что тут можно расслабиться.
Куда реальнее и скорее грозит Проблема 10 000 года своим переходом на значения из пяти цифр. Кажется, что не стоит о ней беспокоиться – пока вопрос ведь скорее теоретический.
Правда, всегда есть вероятность того, что крупицы существующего кода из вашего смартфона доживут до той эпохи.
Может, призадуматься и стоит.
(30 голосов, общий рейтинг: 4.77 из 5)
🤓 Хочешь больше? Подпишись на наш Telegram.
iPhones.ru
В последнем случае – миллиардов.
- Подборки,
- Это интересно
Павел
@Tinelray
У меня 4 новых года: обычный, свой, WWDC и сентябрьская презентация Apple. Последний — самый ожидаемый, и ни капли за это не стыдно.
Современное программное обеспечение (сокращенно ПО) позволяет сделать жизнь миллионов людей проще, однако сбои в крупных системах могут иметь катастрофические последствия. Нередко ошибки при работе компьютеров приводили к серьезным разрушениям и смерти людей.
Ниже будут перечислены наиболее масштабные инциденты, произошедшие из-за ошибок программного обеспечения.
1 Ошибка в космическом агентстве
В июне 1996 года специалисты Европейского космического агентства осуществляли запуск ракеты Ariane 5.
Ошибка в программном обеспечении для модуля управления привела к старту процесса самоуничтожения – через 37 секунд полета ракета взорвалась.
2 Акции упали, деньги пропали
В прошлом году крупный сбой в программном обеспечении чуть не обанкротил корпорацию Knight Capital.
Фирма менее чем за час потеряла полмиллиарда долларов – система начала несанкционированно покупать и продавать большое количество акций. В итоге за два дня акции упали в цене на 75%.
3 Сбой в медицинском оборудовании
Сбои случались и в медицинском оборудовании. В 1980-годы несколько пациентов погибли после получения слишком большой дозы облучения рентгеновским аппаратом Therac-25 (лучевая терапия).
Эксперты предположили, что масштабный сбой произошел из-за обычной ошибки в коде, которая привела к выполнению одной операции многократно.
4 Жаркое лето для Амазона
Летом 2013 года произошло отключение серверов американской компании Amazon (самая известная компания в мире по продаже различных товаров и услуг через Интернет). Это привело к потере файлов пользователей, хранившихся в сетевом хранилище.
Авария, первоначально вызванная грозой, неожиданно усугубилась ошибками в используемом программном обеспечении. Это быстро привело к каскадному сбою.
5 О связи электричества и программного обеспечения
Массовое отключение электричества в 2003 году в северо-восточной части США произошло из-за локальной аварии, которая не была зафиксирована программным обеспечением General Electric Energy.
Отсутствие реакции на локальный сбой привело к каскадному отключению электроэнергии.
6 Авиакомпании и программное обеспечение
Маленький сын спрашивает у папы-программиста:
— Папа, почему солнце всходит на востоке?
— Вот работает, сынок, и не трогай!
В 2014 году из-за ошибки в программе была заблокирована работа всех самолетов авиакомпании American Airlines.
Сбой возник в системе бронирования билетов – проводилась работа по объединению программных платформ нескольких компаний.
К сожалению, не всегда программисты могут точно просчитать последствия тех или иных действий, заложенных ими в программное обеспечение.
Поэтому с программистами надо обращаться аккуратно. С одной стороны, их надо сильно мотивировать на создание безошибочного кода. С другой стороны, нужны методы контроля и проверки программного обеспечения, которые могли бы исключить подобные ошибки в будущем. Тем более, что эти ошибки могут приводить не только к многомиллиардным убыткам, но и к человеческим жертвам.
Крупные и ответственные корпорации создают такие технологии программирования, в которых обязательно соблюдались бы все этапы создания программ. Включая контроль безошибочности написанного кода. Устраивают конкурсы среди хакеров, лучших из них приглашают на высокооплачиваемую работу.
Но даже это не всегда спасает, как видно из приведенных выше вопиющих фактов программных сбоев. Программы обрабатывают множество данных, и не всегда, к сожалению, удается проверить работоспособность программ на всех возможных вариантах и комбинациях этих данных, поступающих на обработку. Это и может привести к непоправимым сбоям.
Будем внимательны к программному обеспечению, к программистам и друг к другу!
P.S. Это интересно:
Не влезай, умрет!
Стив Джобс: он просто взял и изменил мир
Без мифов и легенд о выборе профессии программиста: часть 1
Самый богатый ботаник в мире
Что такое шпионские программы Spyware?
Получайте актуальные статьи по компьютерной грамотности прямо на ваш почтовый ящик.
Уже более 3.000 подписчиков
.
Важно: необходимо подтвердить свою подписку! В своей почте откройте письмо для активации и кликните по указанной там ссылке. Если письма нет, проверьте папку Спам.
В истории программирования не всегда все было легко и безоблачно. Ведь любому программисту, вне зависимости от опыта и технического бэкграунда, трудно уберечься от ошибок и порой даже небольшого количества плохого кода хватало, чтобы вызвать серьезную проблему. «Библиотека программиста» немного полистала ИТ-летописи и нашла для вас 10 самых худших ошибок в истории кодинга. Поехали!
1. Ошибка 2000 года
Более двух десятилетий назад, в канун нового 2000 года, весь развитый мир охватила паника из-за проблемы способной привести к сбоям в работе компьютеров, падению самолетов, прекращению работы медицинского оборудования и разрушению глобальной финансовой системы.
Суть проблемы заключалась в том, что большинство устаревших информационных систем, созданных еще в 70-х и 80-х, использовали только две цифры для исчисления года. Это значит, что часы внутри микропроцессоров различного аппаратного ПО регистрировали 1999 год как «99», основываясь на ошибочном предположении разработчиков прошлого, что мы всегда будем жить в 20-м веке и цифра «19» в обозначении года никогда не изменится.
Тогда все полагали, что в 2000 году у всех нас наверняка будут реактивные ранцы, еда в форме таблеток, футуристическая серебристая униформа и человечество к этому времени откажется от старых компьютерных систем середины века. Но чуда не случилось!
И в канун всеми любимого праздника мир охватила полномасштабная паника. Кто-то усердно работал над внедрением обходных путей, выделяя на эти цели колоссальные средства. Другие же вообще не чинили, не исправляли и не обновляли свои системы. Кто из них был прав, сейчас сказать сложно, но когда наступил рубеж тысячелетий, глобальной катастрофы не произошло. Однако у всей этой шумихи, все же был положительный эффект. До общественности наконец начало доходить, как много жизненно важных систем зависит от компьютеров и микропроцессоров и как важно следить за их ПО и своевременно его обслуживать.
2. Терак-25
Плохой код на самом деле может убить. Такая катастрофа произошла с аппаратом лучевой терапии Therac-25, произведенным компанией Atomic Energy of Canada, ставшего причиной гибели не менее шести пациентов. Расследование выявило недоработку системы, вызвавшую передозировку радиацией. Связано это было с трудностью проведения автоматизированных тестов такого специфического программного обеспечения. И поэтому машина, призванная помочь людям, стала машиной для убийств из научной фантастики. Этот случай заставил разработчиков ПО медицинской отрасли крайне ответственно подходить к тестированию такого оборудования.
3. Сеть AT&T выходит из строя
15 января 1990 года около 50 процентов мобильной сети AT&T вышло из строя. За девять часов простоя более 75 миллионов звонков остались без ответа. И хотя в первоначальных отчетах следствия по этому делу значилось хакерская атака, на самом деле, виновником сего происшествия стало стандартное обновление ПО. Ошибка всего в одной строке кода стоила компании огромных денег. Все организации, целиком зависящие от наличия и качества связи, выставили AT&T иски с внушительными суммами. К примеру, крупнейший авиаперевозчик American Airlines, понес колоссальные финансовые убытки из-за того, что получил наполовину меньше звонков своих клиентов из-за сбоя. Авария 1990 года до сих пор служит прекрасным примером важности тестирования программного обеспечения и служит напоминанием о неразрывной связи между технологиями и экономической деятельностью большинства компаний.
4. Досрочное освобождение заключенных
В 2005 году в США штате Мичиган произошел сбой тюремной программы, отвечающей за расчет срока наказания заключенных, в результате чего более 20 заключенных досрочно вышли на свободу. Программа ошибочно посчитала смягчающий коэффициент и снизила срок пребывания отбывающих наказание людей в несколько раз. Ошибку в коде заметили не сразу, а лишь по прошествии некоторого времени. И поэтому меру пресечения счастливчикам никто не пересчитывал. Среди них, к слову, не было матерых гангстеров и маньяков. В основном это были мелкие правонарушители, отбывавшие срок за неуплату алиментов, махинации с налогами и незаконное хранение психотропов.
Произошедшее показывает, что в погоне за автоматизацией процессов и сокращением количества ручных операций программисты зачастую забывают о грамотной настройке разработанной системы и ее тестировании. А мы с вами в очередной раз убеждаемся, что даже незначительная ошибка может привести к серьезным последствиям.
5. Взрыв Ariane 5
Случай произошел 4 июня 1996 года при первом запуске Ariane 5 — одной из самых надежных беспилотных ракетных установок, целью которой было изучение взаимодействия между солнечным ветром и магнитосферой Земли. Через 37 секунд после старта ракета, вылетевшая с космодрома, находящегося на берегах Французской Гвианы, развернулась на 90 градусов и всего через несколько секунд превратилась в огромный огненный шар.
Специальная группа прочесала место происшествия, собирая обломки, чтобы попытаться выяснить, что произошло. Через некоторое время техническая комиссия установила, что авария была вызвана программным сбоем.
Отказ системы произошел из-за полной потери информации о точности наведения ракеты и ориентации ее в пространстве, поступающей в центральный процессор. Потеря — следствие ошибки проектировщиков ПО и вызвана она была некорректным преобразованием 64-битного числа с плавающей запятой в 16-битное целое число.
К слову, целочисленное переполнение является широко распространенной ошибкой в компьютерном программировании.
6. Ошибка Paypal
Что бы вы сделали, если бы PayPal случайно зачислил на ваш счет 92 квадриллиона долларов? Крису Рейнольдсу, 56-летнему американцу, продающему автозапчасти на eBay, не пришлось долго об этом думать. Ведь он даже не успел ощутить себя первым в мире квадриллионером и самым богатым человеком в мире, так как ошибка была устранена в течение нескольких минут. Поэтому, прежде чем мужчина начал мечтать о новом кадиллаке и золотой карте члена королевского яхт-клуба, сумма на его счету вернулась к привычному балансу. Конечно, стоило бы потребовать с компании хотя бы часть этой суммы за моральный ущерб, но, видимо, шок от увиденного не позволил ему сделать это.
7. Калькулятор Windows
Эта ошибка, существующая в большинстве версий Windows (кроме Windows 10), которую вы сможете проверить самостоятельно.
Для этого нужно:
- Открыть калькулятор Windows и ввести 4.
- Извлечь из этого числа квадратный корень и получите 2.
- Вычесть из него 2 и вместо нулевого результата в разных версиях Windows вы увидите разные результаты.
Причиной ошибки является недоработка, вызванная некорректным обращением калькулятора с операциями sqrt. В итоге результаты сохраняются как числа с плавающей запятой, а не целые числа, вызывая ошибку точности при дальнейших вычислениях, которую вы можете видеть.
Microsoft признала эту ошибку в приложении калькулятора и исправила ее в Windows 10.
8. Проблема 2038 года
Ошибка 2038 будет вызвана использованием 32-разрядных процессоров в 32-разрядных системах. Проще говоря, 19 января 2038 года наступит в 03:14:07. Компьютеры, которые все еще используют 32-разрядные системы для управления датой и временем, не смогут справиться с этим изменением. Как и в случае с ошибкой 2000 года, компьютеры не смогут отличить 2038 год от 1970 года.
Однако волноваться не стоит: почти все современные процессоры в настольных ПК имеют 64-битные системы с 64-битным программным обеспечением и в 2038 году само существование 32-битных систем будет под вопросом.
9. Видео Gangnam Style «сломало» YouTube
Счетчик YouTube ранее использовал 32-битное целое число для определения максимального количества просмотров видеоролика, и равно оно было 2 147 483 647.
Однако корейская поп-группа PSY, выложившая на сервис свой клип с зажигательной песней Gangnam Style благополучно его сломала, превысив допустимую планку.
«Когда мы его делали, никогда не думали, что какое-нибудь видео посмотрят столько раз, но это было до Gangman Style», — написал на своей странице в сети один из разработчиков портала.
Клип PSY опубликовали 15 июля 2012 года и к концу мая 2014 года он стал единственным видеороликом, которой просмотрели больше 2 млрд раз.
В настоящее время YouTube использует 64-битное целое число для счетчика видео, что означает, что максимальное количество просмотров видео составляет 9,22 квинтиллиона.
10. Синий экран смерти
BSOD или «Синий экран смерти» — жаргонное название фатальной системной ошибки Windows, показывающей системный сбой, при котором операционка достигала состояния, в котором она больше не могла надежно работать. Как правило, вызывалась она в Windows 95-98 после неожиданного завершения важного процесса или общего сбоя оборудования. Старожилы наверняка помнят этот баг, который довольно часто возникал на заре становления ИТ-культуры.
16 марта 2000 года Microsoft выпустила обновление для системы безопасности, устраняющее эту неполадку, однако и сейчас на форумах изредка можно встретить сообщение от пользователей об этой проблеме.
***
Людям свойственно совершать ошибки. Однако, будьте внимательны — всегда нужно помнить, что даже одна плохо написанная строчка кода может привести к печальным последствиям. Удачи!
Материалы по теме
- ⚠️ 10 самых распространенных ошибок, ежедневно допускаемых каждым программистом
- ⚠️ Как не нужно учить TypeScript: 5 распространенных ошибок
- 😢 Дорогостоящие ошибки: почему нам пришлось отказаться от Firebase
Катастрофические последствия программных ошибок +24
Информационная безопасность, Программирование, Блог компании Mail.Ru Group, История IT
Рекомендация: подборка платных и бесплатных курсов Python — https://katalog-kursov.ru/
Практика не устает доказывать, что в любом ПО самая главная уязвимость — человеческий фактор. И неважно, появился ли баг из-за нехватки квалифицированности специалиста, выжил после долгих часов дебага в поисках ошибки, или считался хитро замаскировавшейся фичей. Среди некоторых разработчиков даже укрепилось мнение, что баги в принципе существуют всегда и везде. Но если ошибки абстрактны и сложно воспроизводимы в реальных условиях, то проблема не является критичной.
В идеальной ситуации баги исправляют все и сразу. Но в жизни всегда есть куча задач, отодвигающих полный и бесповоротный багфикс (новый функционал, срочные хотфиксы, расставленные приоритеты при исправлении багов). Это значит, что в первую очередь находятся и исправляются очевидные и явные проблемы. Остальные тихо ждут своего часа, превращаясь в бомбы замедленного действия. Иногда ошибки приводят не только к неприятностям в жизни рядового разработчика, но и вызывают настоящие катастрофы. Сегодня у нас подборка и объяснение самых кошмарных багов в истории разработки ПО.
Облучение и радиация
Знаменитый случай гибели нескольких человек, получивших смертельную дозу облучения во время сеансов радиационной терапии с применением медицинского ускорителя Therac-25. Ускорители подобного типа используют электроны для создания лучей высокой энергии, высокоточно уничтожающих опухоли. Но некоторые пациенты получили дозы не в несколько сотен рад, как предписывало лечение, а в 20 000 рад; доза в 1000 рад для человека считается несовместимой с жизнью, причем смерть может наступить сразу после облучения.
Всего один программист создал все ПО, используемое в аппаратах Therac — а это 20 тысяч инструкций, написанных на ассемблере. И при этом во всех Therac встречался один тот же пакет библиотек, содержащий ошибки.
Ускоритель Therac-25, ставший третьим в серии успешных аппаратов лучевой терапии, мог работать с рентгеновскими лучами до 25 МэВ. Несколько лет в середине 80-х аппараты Therac-25 работали безупречно, однако со временем начали накапливаться инциденты, повлекшие за собой тяжелые последствия: от ампутации конечностей до гибели пациентов.
Первое время баги просто не замечали, а все неполадки связывали с аппаратными сбоями. Программное обеспечение, безукоризненно проработавшее тысячи часов, воспринималось идеальным и безопасным. Никаких действий для предотвращения последствий возможных ошибок не предпринималось. Кроме того, выдаваемые оператору сообщения о критических с точки зрения безопасности ситуациях выглядели как рутинные. Производитель устройств расследовал каждый инцидент, но при этом не мог воспроизвести сбой. Потребовалось несколько лет исследований сторонних экспертов, привлеченных во время суда после череды смертей, чтобы сделать вывод о наличии большой плеяды именно программных ошибок.
Так при определенной последовательности ввода команд с клавиатуры происходил некорректный вызов процедур, влекущих за собой облучение любого произвольного участка тела пациента. Отсутствие на устройстве аппаратного блокиратора критических и продолжительных доз излучения усугубляло проблему.
Одна и та же переменная в ПО Therac-25, применялась как для анализа введенных чисел, так и для определения положения поворотного круга, отвечающего за направление излучателя. Поэтому при быстром вводе команд аппарат мог принять число дозы излучения за координаты места, куда нужно направить луч — например, прямо в мозг.
Иногда Therac-25 при расчете излучения делил на ноль и соответствующим образом увеличивал величины облучения до максимально возможных. Установка булевской переменной в значение «true» производилась командой «x=x+1» из-за чего с вероятностью 1/256 при нажатии кнопки «Set» программа могла пропустить информацию о некорректном положении излучателя.
Во внутренней документации производителя было обнаружено, что одно и то же сообщение об ошибке выдавалось как в случае ненадлежащей (малой) дозы облучения, так и для большой дозировки — отличить по сообщению об ошибке одно от другого было невозможно.
Если вы разработчик или (что еще лучше) тестировщик, этот случай стоит изучить досконально — есть хорошая статья в wiki, с нее можно начать, а затем ознакомьтесь с большой статьей девятнадцатилетней давности «Мифы о безопасном ПО: уроки знаменитых катастроф». История вобрала в себя большинство классических проблем тестирования.
Как ни печально, но проблемы Therac-25 не остались уникальными. В 2000 году серию аварий вызвал другой софт, точно так же просчитывающий нужную дозу облучения для пациентов, проходящих курс лучевой терапии.
Программное обеспечение Multidata позволяло медицинскому работнику рисовать на экране компьютера порядок размещения металлических блоков, предназначенных для защиты здоровых тканей от радиации. Но софт разрешал использовать только четыре защитных блока, в то время как врачи, в целях повышения безопасности, хотели использовать все пять.
Врачи воспользовались «лайфхаком». Оказалось, что в программе не предусмотрена защита от ввода некорректных данных — можно было нарисовать все пять блоков как один большой блок с отверстием в середине. В медицинском центре онкологии Панамы не понимали, что софт Multidata устанавливал разные показатели конфигурации в зависимости от того, как размещено отверстие: от направления его размещения рассчитывалась правильная доза облучения.
Из-за неверно введенных данных умерли восемь пациентов, в то время как еще 20 получили передозировку, повлекшую серьезные проблемы со здоровьем.
Блэкаут
Маленькая ошибка в программном обеспечении системы мониторинга работы оборудования General Electric Energy привела к тому, что 55 миллионов человек остались без электричества. На Восточном побережье США оказались обесточены жилые дома, школы, больницы, аэропорты.
14 августа 2003 года в 0:15 ночи оператор энергетической системы в Индиане с помощью инструмента мониторинга работы оборудования заметил небольшую проблему. Проблема вызвала раздражающий сигнал об ошибке, который оператор выключил. Оператору удалось за несколько минут решить все трудности, но он забыл перезапустить мониторинг — аварийный сигнал остался в выключенном положении.
Отключение сигнала не стало основной причиной блэкаута. Но когда через несколько часов из-за контакта с деревом вырубились провисшие линии электропередачи в Огайо — об этом никто не узнал. Проблема приняла лавинообразный характер, перегруженные линии передачи и электростанции начали вырубаться в Онтарио, Нью-Йорке, Нью-Джерси, Мичигане и далее.
Ни один из операторов не заметил каскад ошибок, которые медленно убивали энергосистему, из-за единственного выключенного сигнала тревоги — никаких дублирующих систем на этот случай не предполагалось.
Mars Climate Orbiter
В 1998 году NASA потеряло спутник «Mars Climate Orbiter» стоимостью $ 125 млн из-за того, что субподрядчик, работавший над инженерными задачами, не перевел английские единицы измерения (фунты) в метрическую систему. В результате ошибки спутник после 286-дневного путешествия на большой скорости вошел в марсианскую атмосферу, где из-за возникших перегрузок его системы связи вышли из строя. Аппарат оказался на сто километров ниже планируемой орбиты и на 25 км ниже высоты, на которой еще можно было исправить ситуацию. В результате спутник разбился. Такая же участь постигла космический аппарат Mars Polar Lander.
Mariner 1
В 1962 году космический корабль «Mariner 1» был уничтожен с земли после старта из-за отклонения от курса. Авария возникла на ракете из-за программного обеспечения, в котором разработчик пропустил всего один символ. В результате корабль стоимостью 18 миллионов долларов (в деньгах тех лет) получал неверные управляющие сигналы.
При работе над системой управления ракетой программист переводил рукописные математические формулы в компьютерный код. Символ «верхнего тире» (индекса), он воспринял за обычное тире (или знак минус). Функция сглаживания стала отражать нормальные вариации скорости ракеты как критические и недопустимые.
Однако даже допущенная ошибка могла не привести к критическому сбою, но как назло антенна ракеты потеряла связь с наводящей системой на Земле, и управление взял на себя бортовой компьютер.
Запуск баллистических ракет
26 сентября 1983 года спутник эшелона «Око» системы предупреждения о ракетном нападении СССР ошибочно сообщил о запуске пяти баллистических ракет с территории США. Спутник находился на высокой эллиптической орбите, наблюдая за районами базирования ракет под таким углом, чтобы они находились на краю видимого диска Земли. Это позволяло обнаружить факт запуска на фоне темного космического пространства по инфракрасному излучению работающего ракетного двигателя. Кроме того, выбранное расположение спутника снижало вероятность засветок датчиков отраженным от облаков или снега солнечным светом.
После безупречного года работы внезапно выяснилось, что в один день при определенном положении спутника и Солнца свет отражается от облаков, расположенных на больших высотах, оставляя то самое инфракрасное излучение, которое компьютеры восприняли как след от ракет. Заступивший на боевое дежурство подполковник Станислав Петров усомнился в показаниях системы. Подозрение вызвало сообщение о пяти замеченных целях — в случае реального военного конфликта США одновременно произвели бы сотни пусков. Подполковник Петров решил, что это ложное срабатывание системы, и тем самым, вероятно, предотвратил Третью мировую войну.
Подобная ошибка, едва не повлекшая за собой глобальный ядерный конфликт, произошла и по другую сторону океана. 9 ноября 1979 года из-за сбоя компьютера воздушно-космической обороны Северной Америки была получена информация о начале ракетной атаки против США — в количестве 2200 запусков. В то же время спутники раннего предупреждения и радары показали, что никакой информации о советской атаке не поступало — только благодаря перепроверке данных, сделанной за 10 минут, не был отдан приказ о взаимном гарантированном уничтожении.
Причиной всему оказалась самая опасная уязвимость — человеческий фактор. Оператор компьютера, находящегося на боевом дежурстве, загрузил в него пленку с учебной программой, имитировавшей ситуацию массированной ракетной атаки.
За несколько первых лет работы Национального центра управления Объединенного командования аэрокосмической обороны США и Канады было зафиксировано 3703 ложных сигнала тревоги, большая часть из которых появилась из-за атмосферных явлений. Однако случались и компьютерные ошибки. Так один из «боевых» компьютеров 3 июня 1980 года показал постоянно меняющиеся цифры количества ракет, запущенных Советским Союзом. Проблема возникла из-за аппаратного сбоя в микросхеме.
Обновление софта и деление на 0
В 1997 американский ракетный крейсер «Йорктаун» (CG-48), на котором были установлены 27 компьютеров (Pentium-Pro на 200 МГц), решил поделить на ноль и полностью вышел из строя.
Компьютеры работали на Windows NT — и работали они ровно так, как вы и ожидаете, узнав название оси. В то время ВМФ США старался максимально широко использовать коммерческое ПО с целью снижения стоимости военной техники. Компьютеры же позволяли автоматизировать управление кораблем без участия человека.
На компьютеры «Йорктауна» поставили новую программу, управляющую двигателями. Один из операторов, занимавшийся калибровкой клапанов топливной системы, записал в одну из ячеек расчетной таблицы нулевое значение. 21 сентября 1997 года программа запустила операцию деления на этот самый ноль, началась цепная реакция, и ошибка быстро перекинулась на другие компьютеры локальной сети. В результате отказала вся компьютерная система «Йорктауна». Потребовалось почти три часа, чтобы подключить аварийную систему управления.
Схожая проблема с нулем возникла при испытании истребителя в Израиле. Безупречно работавший самолет на автопилоте пролетел над равнинной частью, над горной частью, над долиной реки Иордан и приблизился к Мертвому морю. В этот момент произошел сбой, автопилот выключился, и пилоты посадили истребитель на ручном управлении.
После долгих разбирательств удалось выяснить, что программы автопилота при вычислении параметров управления производили деление на значение текущей высоты истребителя над уровнем океана. Соответственно, у Мертвого моря, лежащего ниже уровня океана, высота становилась нулевой, провоцируя ошибку.
В мире найдется немало историй, когда обновление софта, совершаемое с самыми благими целями, могло повести за собой множество проблем. В 2008 году атомная электростанция в штате Джорджия (США) мощностью 1,759 МВт в экстренном режиме приостановила работу на 48 часов.
Инженер компании, занимающейся технологическим обслуживанием станции, установил обновление на главный компьютер сети АЭС. Компьютер использовался для слежения за химическими данными и диагностики одной из основных систем электростанции. После установки обновлений компьютер штатно перезагрузился, стерев из памяти данные управляющих систем. Система безопасности станции восприняла потерю части данных как выброс радиоактивных веществ в системы охлаждения реактора. В результате автоматика подала сигнал тревоги и остановила все процессы на станции.
Инцидент с F-22
Двенадцать F-22 Raptor (истребитель пятого поколения, состоящий на вооружении США), стоимостью $ 140 млн за штуку, отправились в первый международный вылет в Окинаву. Все шло замечательно, пока эскадрилья не пересекла линию перемены даты, на западной стороне которой дата сдвинута на один день вперед относительно восточной. После пересечения условной линии все 12 истребителей одновременно выдали сообщение об ошибке, эквивалентной синему экрану смерти.
Самолеты потеряли доступы к данным о количестве топлива, датчикам скорости и высоты, частично нарушилась связь. В течение нескольких часов самые современные истребители Америки летели через океан совершенно беспомощными. В конце концов их удалось посадить только благодаря мастерству пилотов.
Так в чем же была ошибка? Проектировщики из Lockheed Martin даже не рассматривали вопрос о возможности пересечения линии перемены дат — им просто не пришло в голову, что где-то понадобится либо прибавлять, либо вычитать одни сутки.
Другие истории
В этой бескрайней теме есть еще несколько интересных историй. О них сложилось либо неправильное мнение, либо уже были подробные статьи на ГТ и Хабре.
Взрыв на советской газотранспортной системе в 1982 году из-за программных ошибок, заложенных ЦРУ. Эксперты категорически отрицают не только взрыв на газопроводе «Уренгой-Сургут-Челябинск» в 1982 году, но и вообще возможность возникновения такого взрыва.
Алгоритмическая ошибка привела к аварии самолета А-330 — в результате инцидента 119 пассажиров и членов экипажа получили ранения, из них 12 тяжелые.
Ракета-носитель Ariane 5 превратилась в «конфетти» 4 июня 1996 года — ошибка произошла в компоненте ПО, предназначенном для выполнения «регулировки» инерциальной платформы. Потеряно 500 млн долларов (стоимость ракеты с грузом).
Toyota: из-за корявой электроники и софта 89 человек погибли с 2000 по 2010 годы.
Источники:
habrahabr.ru/company/mailru/blog/227743
www.wikiwand.com/en/Therac-25
www.baselinemag.com/c/a/Projects-Processes/We-Did-Nothing-Wrong en.wikipedia.org/wiki/Northeast_blackout_of_2003
lps.co.nz/historical-project-failures-mars-climate-orbiter www.jpl.nasa.gov/missions/mariner-1
inosmi.ru/inrussia/20071229/238739.html
https://www.revolvy.com/main/index.php?s=USS%20Yorktown%20(CG-48)
www.defenseindustrydaily.com/f22-squadron-shot-down-by-the-international-date-line-03087
Подборка из 20 неопровержимых фактов, когда программирование или дизайн, привели к гибели людей.
Первая жертва беспилотного автомобиля
1. Элаи Херцберг попала в историю, как первый человек который погиб под колесами беспилотного автомобиля. Весной 2018 года в темное время суток, машина Uber засекла преграду, в начале подумав что мусор, потом что животное, и только за пару метров поняв что это человек.
К сожалению машина не успела затормозить, что привело к смерти человека. Тестирование проходило на модифицированном Volvo XC90, у которой была отключена система экстренного торможения, чтоб не мешать ПО Uber управлять машиной. Не может быть два короля в одном королевстве. Задача тормозить в экстренных случаях была положена на плечи водителя, который страховал автопилот. Он же в это время смотрел сериал на Netflix.
Аппарат Therac-25
2. Аппарат Therac-25 стал самым резонансным случаем в истории программирования для медицинских девайсов. В силу ошибки race condition, при быстром переключении режимов работы девайсов между магнитным и рентгеновским заслонка для рентгеновских лучей не успевала установиться.
Из-за этого у 10 пациентов диагностировали лучевую болезнь, что привело к смерти, или ампутации зараженных частей тела.
Часовые пояса и ПВО Patriot
3. 25 февраля 1991 года установка ПВО Patriot не смогла перехватить ракету пущенную со стороны сил Саддама Хусейна которая попала в барак солдат США, и что привело к 28 смертям.
Расследование показало, что 24 битные процессоры перехватчика при переводе времени совершают ошибку. в 0.013 секунды каждый час. Patriot не перегружали более 100 часов, что привело к ошибкам вычисления положения ракеты на 600 метров. Вот уж где перезагрузка бы спасла жизни.
Антон Ельчин и электронный ручник
4. В 2016 году, актер Антон Ельчин был раздавлен собственной машиной при въезде домой. Антон многим запомнился как актер игравший навигатора Чехова в полнометражках Start Trek.
Причиной смерти послужил не интуитивный дизайн ручки передач представленный Jeep в новых моделях машин. В отличии от стандартных ручек передач, где положение ручки показывает режим работы двигателя, у новых ручек — местоположение выбиралось скорее как рычажок в меню. Антон вместо паркинга, выбрал нейтральное положение, от чего машина скатилась и задавила не внимательного хозяина.
Распределения маршрутов скорой помощи
5. В 1992 году ошибки системы распределения маршрутов в Лондонской скорой помощи привели к смерти 30-45 человек ( разброс большой, потому что не ясно, смогла бы скорая спасти человека ). Все произошло, когда в Лондоне решили заменить людей операторов на компьютерную систему.
В результате система была введена в эксплуатацию без нагрузочного тестирования и с 81! известным багом. Добавьте к этому еще и то, что интегратор решил сэкономить, и купил дешевое оборудование, которое сломалось через пару часов после активного пользования системой. Хаос был настолько безумным, что бывали случаи, когда человек не дождавшись скорой умирал, его увозили в морг, и только тогда приезжала скорая.
АЭС в Пенсильвании
6. 1979 год, Пенсильвания чуть не стала местом еще одного Чернобыля, и стала самым большим прецедентом в истории атомной энергетики в США. Внешний дизайн датчиков системы был настолько плохо продуман, и был расположен по кругу комнаты, что смена которая следила за состоянием не заметила всех показателей, который указывали на то, что есть утечка, и значение температуры реактора приблизилось к критическому значению. Ситуацию спасла следующая смена, которая выходила на вахту, и начинала считывать показания датчиков. Чтоб считать показатели, надо было пройти по круглой комнате, и отдельно смотреть на каждый показатель во многих разных местах. Утечку нашли, реактор отключили, но еще 14 лет проводили очистные работы на территории. Это стало поводом огромных анти-атомных митингов, и очень поменяло общественное мнение про «мирный атом»
Неудачный дизайн приборной панели
7. 1992 год, самолет под управлением опытной команды потерпел крушение возле Страсбурга. 87 из 92 человек погибли. Анализ черного ящика показал, что опытные пилоты перепутали настройки авто-пилота: угол и скорость снижения. Дизайнер приборной панели очень стремился сэкономить место, и расположил эти два индикатора друг возле друга. При том, что даже не смотря на то, что единицы измерения совершенно разные ( пилоты хотели задать 3.3 градуса спуска а задали 3300 фунтов в минуту) Но для экономии места, оба показателя показывались как 3.3. Кому в голову прийдет показывать 3300 как 33?
Станислав Петров спас мир сделав НИЧЕГО
8. Станислав Петров, в 1983 году спас мир сделав НИЧЕГО. Станислав Петров во время разгара холодной войны между США и СССР служил в штабе анти-ракетной обороны. Так как две страны обладали атомным оружием, между ними была заключена доктрина полного уничтожения, что значило, что только одна ракеты полетит со стороны одной страны в другую — другая может ответить как хочет. Грубо говоря — начало третьей мировой.
Станислав Петров в 1983 году как раз наблюдал за системой раннего обнаружения ракетного удара. И как же он удивился, когда увидел на экране 5 ракет, которые летели со стороны США в сторону СССР. По всем правилам Петров должен был отдать указания полномасштабного ракетного удара по США. Но, как она дальше сказал: «У него была чуйка». Он решил что нападать на СССР всего лишь 5 ракетами — не логично, и решил подождать.
Внезапно ракеты пропали, он сделал рапорт. Расследование определило, что эти 5 ракет — edge case того, как лучи солнца падают на спутник на орбите Молния. Таким образом, Петров, не сделав ничего подарил нам с вами мир, в котором мы живем. Хотя злые языки говорят что он был в стельку пьян в этом время, что не отменяет того, что даже пьяным ты можешь спасти миллиарды.
Дизайн медецинской системы
9. Пациентка Jenny (имя заменено в репортах) погибла от обезвоживания после химиотерапии. Причина оказалась до ужаса идиотской: дизайн медицинской системы был настолько плох, что опытные медсестры просто не заметили пункта который говорил что для этого пациента необходимо вводить дополнительные элементы сразу после операции.
Неудачный дизайн упаковки
10. Шестеро велосипедистов сошли с дистанции гонки в Осло в 2014-ом году. Обнаружилось, что велосипедисты упились жидкостью для мытья пола, решив что это энергетик. Дизайн упаковки — тоже дизайн.
Программная ошибка автопилота
11. 1994 год, борта авиакомпании China Arilines потерпел крушение, унеся жизни более чем 250 человек. При приземлении второй пилот случайно включит автопилот, который начал вносить коррективы в действия пилотов. При снижении пилоты заметили это, и смогли выключить автопилот, но к сожалений рассинхронизация действий людей и авто-пилота привело к крушению. При расследовании так же была найдена ошибка, патч для которой уже был написан, и борт который потерпел крушение был запланирован на апдейт системы сразу после окончания рейса, который к сожалению так и не закончился удачно.
Потеря 460 миллионов долларов за 45 минут
12. Knight Capital в свое время перепутали деплои, и вместо тестового енва, задеплоили новую версию на продакшен. Тратя, как система думала, виртуальные доллары — Knight потеряли 460 миллионов долларов за 45 минут. Скидывались на спасение Knight всем селом.
Ошибка софта по контролю топлива в двигателях
13. 2015й год грузовой самолет испанских военно воздушных сил потерпел крушение около Севильи. Airbus после этого случая отозвали все самолеты A400, на проверку, потому как авария были причинена ошибкой ПО, что унесло жизни 4х человек. Причина заключалась в новой версии софта по контролю топлива в двигателях. Система топливо подавала, но очень медленно, от чего 3 их 4х двигателей отключились.
Метрическая и имперская системы
14. 1998 год, один из спутников Nasa отправленный на Марс, достигнув орбиты красной планеты взорвался. Проблема — ошибка в двух модулях ПО спутника: один ждал данные в метрической системе, а другой отдавал в имперской:) Не додебажили на 327 лямов.
Системная ошибка F-14
15. Один из самолетов F-14 разбился в следствии того, что в системе случилась системная ошибка, но программист не обернул ее в catch, что привело к полному отключению бортового компьютера. Пилот катапультировался, но самолет конечно же не спасли.
Взрыв газа в СССР
16. Случай кибервойны, или взрыв который было видно из космоса. В 1982 ЦРУ внедрило шпиона в Канадскую фирму по разработка софта для газопроводных систем, потому как знали что этот софт будет использован СССР. И они использовали. Программист-шпион написал такие методы, что в 1982м году газопроводная труба взорвалась так сильно, что взрыв можно было наблюдать из космоса. К счастью никто, кроме оленей не пострадал.
Не та версия ПО
17. Ариана 5, разработкой которой стоила около 8! миллиардов долларов, должна была вывести на орбиту несколько спутников и другого оборудования. Полет ракеты завершился через 4 секунды после взлета. Она упала. Причиной послужило то, что один из модулей системы попытался сконвертировать 64 битное число в 16-битное. Оно оказалось больше, чем влазило в память, и модель завалился! Но ведь есть дублирующий модуль, которому было передано управление. На котором была та же версия ПО. Которая попытался сделать то же самое.
Ошибка системы «Свой — Чужой»
18. 1982й год, миноносец морских сил Великобритании, был поражен ракетой выпущенной с самолета принадлежавшего Аргентине. Противоракетная система не сработала, погибло 28 человек. Во время постройки, произошел взрыв, и погибло два строителя. Поврежденная часть корабля была заменена на часть с идентичного аргентинского корабля. Когда система обнаружила ракету, она провела проверку на свой-чужой. А так как часть корабля была аргентинская, ракета была определена как своя После чего противоракетная оборона не сработала, потому как ожидало что ракета пролетит. Но нет.
Ошибки в системе управления двигателями
19. 1994 год, вертолет модели Chinook разбился, даже не смотря на управление очень опытным пилотом, что привело к гибели 29 человек. Расследование очень долго пыталось скинуть всю вину на пилота, но в результате были найдены ошибки в системе управления двигателями, а так же проблемы работы датчика высоты с одновременно включенным радио вертолета. А мне не верили что в Samsung компанс со спотифай не работает:)
Смены часового пояса и самолет F-18
20. Новейший на то время самолет F-18 превращался в тыкву, когда перескал зону смены часового пояса меняющий день ( к примеру полет с Гаваев в Японию ). Система не расчитывала что может попасть в прошлое, потому 127 миллонный самолет мог упасть в любой момент. Благо помогал ресет
Автор текста: ©Я есть XSLT
Изображения: — интернет
published on
caprizulka.ru according to the materials
chert-poberi.ru
Как бы упорно мы не полагались на машины, они далеки от идеала. Как минимум, потому что сделаны человеком.
Пока программы не станут умнее людей, нам придётся следить за их состоянием постоянно. Особенно когда говорим об отвественном деле.
Истории ниже покажут, как сильно наши жизни зависят от правильно собранного алгоритма, и что бывает, если контроль качества на производстве возьмёт выходной.
Начнём со странных вещей, коснувшихся относительно скромного числа людей, а закончим настоящими финансовыми катастрофами. Они стоили не один десяток бессонных ночей тем, кому пришлось срочно вычитывать хрупкий код и буквально спасать человечество.
1. Система заживо похоронила 8 500 пациентов больницы в Мичигане
В 2003 году Медцентр Св. Марии Милосердия в городе Гранд-Рапидс обновил свою программу для учёта больных до новой версии. Из-за неверного толкования данных переменные «выписан» и «скончался» перепутались.
Потому всем, кто уже прошёл лечение начали приходить уведомления о смерти по почте и в разных отчётах вроде анализа крови.
Проблема не стала бы масштабной, но из-за высокой автоматизации сообщения направились и пациентам, и в страховые службы. Когда последние видели, что человек «умирал», то переставали компенсировать последующее лечение. Сюда входило больше 2 000 пенсионеров и инвалидов.
Поскольку ошибку нашли через два месяца после поломки, примерно столько же потребовалось, чтобы восстановить информацию в сопутствующих службах и компенсировать ущерб.
2. Обновление ПО лишило 60 тысяч человек междугородных звонков
В январе 1990 года американский оператор связи AT&T улучшал свою программу по контролю переключателей между вышками. Из-за ошибки в коде одна из них во время звонка начала отправлять сигналы быстрее, чем другая могла их обработать.
Данные начали наслаиваться друг на друга, и проблема быстро распространилась по другим точкам. На обратном конце люди слышали только шум. Так продолжалось 9 часов.
Проблему решили откатом ПО до предыдущей версии, однако проблема не перестала быть актуальной.
Ситуация повторилась как минимум один раз в 1998 году, но тогда были затронуты только сервисные уведомления по SMS.
3. 5% всех магазинов России сломалось из‑за новой онлайн‑кассы
20 декабря 2017 года техника по контролю данных обновлялась, чтобы продавцы начали напрямую передавать информацию о транзакциях налоговой службе. Одно из таких улучшений заблокировало каждый двадцатый магазин страны.
Сбои начались в салонах сети DNS во Владивостоке, где люди просыпаются раньше Москвы. Система не давала отправлять расчёты в Федеральную налоговую службу (ФНС), а из-за этого кассиры не имели права реализовывать товар.
Пока проблема добралась до столицы, откуда начал решаться вопрос, по всей России встали некоторые точки Магнита, Пятёрочки с Перекрёстком, Эльдорадо и аптек Ригла.
ФНС пришлось быстро реагировать и разрешать магазинам работать в офлайн режиме. Тем разрешили вносить данные после того, как система восстановится.
Полностью же проблему устраняли в течение нескольких дней патчами и принудительными перезагрузками.
Теоретический ущерб, по мнению Ассоциации компаний интернет-торговли, мог дойти до 2,5 млрд рублей. Реальный оказался чуть ниже благодаря быстрой оптимизации процессов со стороны ФНС.
4. Машине дали проектировать стадион в Коннектикуте. Тот рухнул
С 1972 года город Хартфорд старался расширить свою инфраструктуру и вкладывался в крупные проекты. Одним из них стал Hartford Civic Center – комплекс торговых, развлекательных и спортивных площадок.
Структуру стадиона проектировали через программу, что вместе с оптимизированным расходом материалов сэкономило городу около $500 тысяч.
Комплекс полностью функционировал и даже был «домом» для местной хоккейной группы New England Whalers с 1975 года.
Однако утром 18 января 1978-го стадион обвалился. Игр в тот день не проходило: здание было пустым и никто не пострадал.
СМИ растиражировали новость, где причиной указывали тяжесть снега. Но расследование показало, что на самом деле проблема была комплексной, а корнем оказалось наивное доверие программе.
Четыре несущие колонны с момента возведения были плохо продуманы в размере и креплении. Стадион начал постепенно «складываться» ещё во время строительства, а группы по контролю качества распределялись между разными подрядчиками и плохо согласовали данные.
Восстановление стоило городу $90 млн. В последствии на месте комплекса возвели арену XL Center, которая до сих пор исполняет роль главной спортивной площадки Хартфорда.
5. Intel выпустила процессор с ошибкой и устроила международный скандал
В 1994 году CPU под брендом Pentium был флагманом компании, и в нём пряталась микроскопическая проблема, которая касалась крошечной части людей: когда пользователь делил одно число на другое, результат был неверным. Выглядела ошибка так:
Программисты неправильно настроили одну из веток операций, вшитых в процессор. Она искала корневые данные и находила не те.
При этом основной ущерб пришёлся не на пользователей, а на компанию.
Из-за того, что Intel уже тогда уверенно чувствовала себя на рынке, а чипы были новые, даже федеральные СМИ многих стран подхватили новость и нанесли катастрофический ущерб имиджу и доходу компании.
В итоге за 1994 год замена всех повреждённых процессоров сократила выручку компании вдвое от запланированной – на $475 млн.
6. 6 миллионов автомобилей могут не раскрыть воздушные подушки
В январе 2020 года выяснилось, что датчики в некоторых моделях компаний Toyota и Honda слишком чувствительны к электрическому шуму.
Есть вероятность того, что в момент столкновения система не подаст сигнал системе безопасности. Та не сможет удержать ремни натянутыми, а подушки не наполнятся воздухом.
Проблема может быть глобальнее, поскольку компьютер из автомобилей Toyota разрабатывался сторонней организацией ZF-TRW. А она поставляла свои наработки как минимум шести компаниям в одних США, которые продали 12,3 млн машин.
Но пока только японские производители решили чинить датчики. И то, многие всё ещё ждут уведомления от своих диллеров.
7. MySpace уничтожил 50 миллионов песен пользователей
В 2016 году компания делала миграцию данных, которая началась еще в 2013 году. Уже тогда некоторые материалы и аккаунты стали недоступны части пользователей.
А в ходе переноса своей огромной библиотеки музыки, фотографий и видео возникла ошибка на сервере, которая их безвозвратно удалила.
Поскольку точной причины руководство не раскрыло, по поводу источника проблемы ходят разные слухи. Например, есть предположение, что хранить такой объём старых данных невыгодно и руководству было дешевле его «случайно» удалить.
Так или иначе, мир потерял один из крупнейших пластов интернет-культуры с 2003 по 2015 годы.
8. 144 тысячи родителей-одиночек не получили государственных выплат
В апреле 2003 года британская компания по поддержке малообеспеченных и неполноценных семей Child Support Agency внедрила систему по фильтрации заявлений. Она стоила £300 млн.
Спустя полгода обнаружилось, что обрабатывалась меньше, чем двадцатая часть просьб, и многие дети остались без материальной помощи.
Скандал длился как минимум до 2006 года, пока программа продолжала съедать 70% выделяемых на проект денег и затраты к 2010 году не составили £1,1 млрд.
В итоге в 2012 году агенство закрыли и вместо него запустили новую организацию Child Maintenance Group.
9. Уязвимость в защите 500 тысяч крупнейших сайтов давала доступ к вашей RAM
В апреле 2014 года специалисты по информационной безопасности обнаружили в библиотеке OpenSSL, на которой держится самый распространённый протокол HTTPS, критическую дыру в безопасности.
Её назвали Heartbleed по аналогии с процессом Heartbeat, взятым за основу этой ошибки.
С помощью уязвимости можно было узнать, что находится в оперативной памяти компьютера жертвы.
И, хотя максимальный объём украденной информации не мог превышать 64 Кб за один запрос, этого хватало на доступ к паролям и конфиденциальным сообщениям.
Ошибка затронула 17% всех защищенных сайтов. В том числе Google, Facebook, Instagram, Twitter и даже Minecraft.
Опасность закрывалась простым патчем, поэтому многие компании отреагировали быстро.
Однако по масштабу с этой проблемой сопоставима только одна, и вы наверняка о ней хоть раз слышали.
10. Мир потратил $300 млрд, чтобы в 2000 году компьютеры продолжили работать
Фото Эмори Кристоф / Emory Kristof
До 1999 года системы программировали так, что одни отмечали даты форматом из 8 цифр (ЧЧ.ММ.ГГГГ), а другие оставляли 6.
Это могло привести к тому, что переход в новое тысячелетие вызвал бы ошибки в программах по всей планете.
Дата формата ЧЧ.ММ.ГГ могла заменить 2000 на 1900 год, поскольку оба числа кончаются на «ОО». Таким образом ошибка бы переписала и стёрла данные, нарушила работу алгоритмов и спровоцировала коллапс онлайн-систем.
Большинство времени и ресурсов компаний ушло не на исправление последствий, а на то, чтобы проверить каждый компьютер в компании.
Поскольку программное обеспечение не переживало таких прыжков в исчислении времени раньше, ситуацию обсуждали по всему миру.
Вокруг Проблемы 2000 года (или Y2K) было много разговоров, в том числе о целесообразности паники. Их подогревало то, что страны восприняли вопрос серьезно и прописывали инициативы на государственном уровне.
Например, Россия создала официальный документ Национальный план действий по решению “Проблемы 2000” в Российской Федерации.
Табло на последней строке «обнулилось» и показывает 1900 вместо 2000
Ближайшая похожая ошибка настигнет не оптимизированные 32-битные системы в январе 2038 года, однако программисты уже готовятся к переходу.
64-х битных систем ситуация коснётся через 292 миллиарда лет, так что тут можно расслабиться.
Куда реальнее и скорее грозит Проблема 10 000 года своим переходом на значения из пяти цифр. Кажется, что не стоит о ней беспокоиться – пока вопрос ведь скорее теоретический.
Правда, всегда есть вероятность того, что крупицы существующего кода из вашего смартфона доживут до той эпохи.
Может, призадуматься и стоит.
(30 голосов, общий рейтинг: 4.77 из 5)
🤓 Хочешь больше? Подпишись на наш Telegram.
iPhones.ru
В последнем случае – миллиардов.
- Подборки,
- Это интересно
Павел
@Tinelray
У меня 4 новых года: обычный, свой, WWDC и сентябрьская презентация Apple. Последний — самый ожидаемый, и ни капли за это не стыдно.
Катастрофические последствия программных ошибок
Время на прочтение
9 мин
Количество просмотров 44K
Практика не устает доказывать, что в любом ПО самая главная уязвимость — человеческий фактор. И неважно, появился ли баг из-за нехватки квалифицированности специалиста, выжил после долгих часов дебага в поисках ошибки, или считался хитро замаскировавшейся фичей. Среди некоторых разработчиков даже укрепилось мнение, что баги в принципе существуют всегда и везде. Но если ошибки абстрактны и сложно воспроизводимы в реальных условиях, то проблема не является критичной.
В идеальной ситуации баги исправляют все и сразу. Но в жизни всегда есть куча задач, отодвигающих полный и бесповоротный багфикс (новый функционал, срочные хотфиксы, расставленные приоритеты при исправлении багов). Это значит, что в первую очередь находятся и исправляются очевидные и явные проблемы. Остальные тихо ждут своего часа, превращаясь в бомбы замедленного действия. Иногда ошибки приводят не только к неприятностям в жизни рядового разработчика, но и вызывают настоящие катастрофы. Сегодня у нас подборка и объяснение самых кошмарных багов в истории разработки ПО.
Облучение и радиация
Знаменитый случай гибели нескольких человек, получивших смертельную дозу облучения во время сеансов радиационной терапии с применением медицинского ускорителя Therac-25. Ускорители подобного типа используют электроны для создания лучей высокой энергии, высокоточно уничтожающих опухоли. Но некоторые пациенты получили дозы не в несколько сотен рад, как предписывало лечение, а в 20 000 рад; доза в 1000 рад для человека считается несовместимой с жизнью, причем смерть может наступить сразу после облучения.
Всего один программист создал все ПО, используемое в аппаратах Therac — а это 20 тысяч инструкций, написанных на ассемблере. И при этом во всех Therac встречался один тот же пакет библиотек, содержащий ошибки.
Ускоритель Therac-25, ставший третьим в серии успешных аппаратов лучевой терапии, мог работать с рентгеновскими лучами до 25 МэВ. Несколько лет в середине 80-х аппараты Therac-25 работали безупречно, однако со временем начали накапливаться инциденты, повлекшие за собой тяжелые последствия: от ампутации конечностей до гибели пациентов.
Первое время баги просто не замечали, а все неполадки связывали с аппаратными сбоями. Программное обеспечение, безукоризненно проработавшее тысячи часов, воспринималось идеальным и безопасным. Никаких действий для предотвращения последствий возможных ошибок не предпринималось. Кроме того, выдаваемые оператору сообщения о критических с точки зрения безопасности ситуациях выглядели как рутинные. Производитель устройств расследовал каждый инцидент, но при этом не мог воспроизвести сбой. Потребовалось несколько лет исследований сторонних экспертов, привлеченных во время суда после череды смертей, чтобы сделать вывод о наличии большой плеяды именно программных ошибок.
Так при определенной последовательности ввода команд с клавиатуры происходил некорректный вызов процедур, влекущих за собой облучение любого произвольного участка тела пациента. Отсутствие на устройстве аппаратного блокиратора критических и продолжительных доз излучения усугубляло проблему.
Одна и та же переменная в ПО Therac-25, применялась как для анализа введенных чисел, так и для определения положения поворотного круга, отвечающего за направление излучателя. Поэтому при быстром вводе команд аппарат мог принять число дозы излучения за координаты места, куда нужно направить луч — например, прямо в мозг.
Иногда Therac-25 при расчете излучения делил на ноль и соответствующим образом увеличивал величины облучения до максимально возможных. Установка булевской переменной в значение «true» производилась командой «x=x+1» из-за чего с вероятностью 1/256 при нажатии кнопки «Set» программа могла пропустить информацию о некорректном положении излучателя.
Во внутренней документации производителя было обнаружено, что одно и то же сообщение об ошибке выдавалось как в случае ненадлежащей (малой) дозы облучения, так и для большой дозировки — отличить по сообщению об ошибке одно от другого было невозможно.
Если вы разработчик или (что еще лучше) тестировщик, этот случай стоит изучить досконально — есть хорошая статья в wiki, с нее можно начать, а затем ознакомьтесь с большой статьей девятнадцатилетней давности «Мифы о безопасном ПО: уроки знаменитых катастроф». История вобрала в себя большинство классических проблем тестирования.
Как ни печально, но проблемы Therac-25 не остались уникальными. В 2000 году серию аварий вызвал другой софт, точно так же просчитывающий нужную дозу облучения для пациентов, проходящих курс лучевой терапии.
Программное обеспечение Multidata позволяло медицинскому работнику рисовать на экране компьютера порядок размещения металлических блоков, предназначенных для защиты здоровых тканей от радиации. Но софт разрешал использовать только четыре защитных блока, в то время как врачи, в целях повышения безопасности, хотели использовать все пять.
Врачи воспользовались «лайфхаком». Оказалось, что в программе не предусмотрена защита от ввода некорректных данных — можно было нарисовать все пять блоков как один большой блок с отверстием в середине. В медицинском центре онкологии Панамы не понимали, что софт Multidata устанавливал разные показатели конфигурации в зависимости от того, как размещено отверстие: от направления его размещения рассчитывалась правильная доза облучения.
Из-за неверно введенных данных умерли восемь пациентов, в то время как еще 20 получили передозировку, повлекшую серьезные проблемы со здоровьем.
Блэкаут
Маленькая ошибка в программном обеспечении системы мониторинга работы оборудования General Electric Energy привела к тому, что 55 миллионов человек остались без электричества. На Восточном побережье США оказались обесточены жилые дома, школы, больницы, аэропорты.
14 августа 2003 года в 0:15 ночи оператор энергетической системы в Индиане с помощью инструмента мониторинга работы оборудования заметил небольшую проблему. Проблема вызвала раздражающий сигнал об ошибке, который оператор выключил. Оператору удалось за несколько минут решить все трудности, но он забыл перезапустить мониторинг — аварийный сигнал остался в выключенном положении.
Отключение сигнала не стало основной причиной блэкаута. Но когда через несколько часов из-за контакта с деревом вырубились провисшие линии электропередачи в Огайо — об этом никто не узнал. Проблема приняла лавинообразный характер, перегруженные линии передачи и электростанции начали вырубаться в Онтарио, Нью-Йорке, Нью-Джерси, Мичигане и далее.
Ни один из операторов не заметил каскад ошибок, которые медленно убивали энергосистему, из-за единственного выключенного сигнала тревоги — никаких дублирующих систем на этот случай не предполагалось.
Mars Climate Orbiter
В 1998 году NASA потеряло спутник «Mars Climate Orbiter» стоимостью $ 125 млн из-за того, что субподрядчик, работавший над инженерными задачами, не перевел английские единицы измерения (фунты) в метрическую систему. В результате ошибки спутник после 286-дневного путешествия на большой скорости вошел в марсианскую атмосферу, где из-за возникших перегрузок его системы связи вышли из строя. Аппарат оказался на сто километров ниже планируемой орбиты и на 25 км ниже высоты, на которой еще можно было исправить ситуацию. В результате спутник разбился. Такая же участь постигла космический аппарат Mars Polar Lander.
Mariner 1
В 1962 году космический корабль «Mariner 1» был уничтожен с земли после старта из-за отклонения от курса. Авария возникла на ракете из-за программного обеспечения, в котором разработчик пропустил всего один символ. В результате корабль стоимостью 18 миллионов долларов (в деньгах тех лет) получал неверные управляющие сигналы.
При работе над системой управления ракетой программист переводил рукописные математические формулы в компьютерный код. Символ «верхнего тире» (индекса), он воспринял за обычное тире (или знак минус). Функция сглаживания стала отражать нормальные вариации скорости ракеты как критические и недопустимые.
Однако даже допущенная ошибка могла не привести к критическому сбою, но как назло антенна ракеты потеряла связь с наводящей системой на Земле, и управление взял на себя бортовой компьютер.
Запуск баллистических ракет
26 сентября 1983 года спутник эшелона «Око» системы предупреждения о ракетном нападении СССР ошибочно сообщил о запуске пяти баллистических ракет с территории США. Спутник находился на высокой эллиптической орбите, наблюдая за районами базирования ракет под таким углом, чтобы они находились на краю видимого диска Земли. Это позволяло обнаружить факт запуска на фоне темного космического пространства по инфракрасному излучению работающего ракетного двигателя. Кроме того, выбранное расположение спутника снижало вероятность засветок датчиков отраженным от облаков или снега солнечным светом.
После безупречного года работы внезапно выяснилось, что в один день при определенном положении спутника и Солнца свет отражается от облаков, расположенных на больших высотах, оставляя то самое инфракрасное излучение, которое компьютеры восприняли как след от ракет. Заступивший на боевое дежурство подполковник Станислав Петров усомнился в показаниях системы. Подозрение вызвало сообщение о пяти замеченных целях — в случае реального военного конфликта США одновременно произвели бы сотни пусков. Подполковник Петров решил, что это ложное срабатывание системы, и тем самым, вероятно, предотвратил Третью мировую войну.
Подобная ошибка, едва не повлекшая за собой глобальный ядерный конфликт, произошла и по другую сторону океана. 9 ноября 1979 года из-за сбоя компьютера воздушно-космической обороны Северной Америки была получена информация о начале ракетной атаки против США — в количестве 2200 запусков. В то же время спутники раннего предупреждения и радары показали, что никакой информации о советской атаке не поступало — только благодаря перепроверке данных, сделанной за 10 минут, не был отдан приказ о взаимном гарантированном уничтожении.
Причиной всему оказалась самая опасная уязвимость — человеческий фактор. Оператор компьютера, находящегося на боевом дежурстве, загрузил в него пленку с учебной программой, имитировавшей ситуацию массированной ракетной атаки.
За несколько первых лет работы Национального центра управления Объединенного командования аэрокосмической обороны США и Канады было зафиксировано 3703 ложных сигнала тревоги, большая часть из которых появилась из-за атмосферных явлений. Однако случались и компьютерные ошибки. Так один из «боевых» компьютеров 3 июня 1980 года показал постоянно меняющиеся цифры количества ракет, запущенных Советским Союзом. Проблема возникла из-за аппаратного сбоя в микросхеме.
Обновление софта и деление на 0
В 1997 американский ракетный крейсер «Йорктаун» (CG-48), на котором были установлены 27 компьютеров (Pentium-Pro на 200 МГц), решил поделить на ноль и полностью вышел из строя.
Компьютеры работали на Windows NT — и работали они ровно так, как вы и ожидаете, узнав название оси. В то время ВМФ США старался максимально широко использовать коммерческое ПО с целью снижения стоимости военной техники. Компьютеры же позволяли автоматизировать управление кораблем без участия человека.
На компьютеры «Йорктауна» поставили новую программу, управляющую двигателями. Один из операторов, занимавшийся калибровкой клапанов топливной системы, записал в одну из ячеек расчетной таблицы нулевое значение. 21 сентября 1997 года программа запустила операцию деления на этот самый ноль, началась цепная реакция, и ошибка быстро перекинулась на другие компьютеры локальной сети. В результате отказала вся компьютерная система «Йорктауна». Потребовалось почти три часа, чтобы подключить аварийную систему управления.
Схожая проблема с нулем возникла при испытании истребителя в Израиле. Безупречно работавший самолет на автопилоте пролетел над равнинной частью, над горной частью, над долиной реки Иордан и приблизился к Мертвому морю. В этот момент произошел сбой, автопилот выключился, и пилоты посадили истребитель на ручном управлении.
После долгих разбирательств удалось выяснить, что программы автопилота при вычислении параметров управления производили деление на значение текущей высоты истребителя над уровнем океана. Соответственно, у Мертвого моря, лежащего ниже уровня океана, высота становилась нулевой, провоцируя ошибку.
В мире найдется немало историй, когда обновление софта, совершаемое с самыми благими целями, могло повести за собой множество проблем. В 2008 году атомная электростанция в штате Джорджия (США) мощностью 1,759 МВт в экстренном режиме приостановила работу на 48 часов.
Инженер компании, занимающейся технологическим обслуживанием станции, установил обновление на главный компьютер сети АЭС. Компьютер использовался для слежения за химическими данными и диагностики одной из основных систем электростанции. После установки обновлений компьютер штатно перезагрузился, стерев из памяти данные управляющих систем. Система безопасности станции восприняла потерю части данных как выброс радиоактивных веществ в системы охлаждения реактора. В результате автоматика подала сигнал тревоги и остановила все процессы на станции.
Инцидент с F-22
Двенадцать F-22 Raptor (истребитель пятого поколения, состоящий на вооружении США), стоимостью $ 140 млн за штуку, отправились в первый международный вылет в Окинаву. Все шло замечательно, пока эскадрилья не пересекла линию перемены даты, на западной стороне которой дата сдвинута на один день вперед относительно восточной. После пересечения условной линии все 12 истребителей одновременно выдали сообщение об ошибке, эквивалентной синему экрану смерти.
Самолеты потеряли доступы к данным о количестве топлива, датчикам скорости и высоты, частично нарушилась связь. В течение нескольких часов самые современные истребители Америки летели через океан совершенно беспомощными. В конце концов их удалось посадить только благодаря мастерству пилотов.
Так в чем же была ошибка? Проектировщики из Lockheed Martin даже не рассматривали вопрос о возможности пересечения линии перемены дат — им просто не пришло в голову, что где-то понадобится либо прибавлять, либо вычитать одни сутки.
Другие истории
В этой бескрайней теме есть еще несколько интересных историй. О них сложилось либо неправильное мнение, либо уже были подробные статьи на ГТ и Хабре.
Взрыв на советской газотранспортной системе в 1982 году из-за программных ошибок, заложенных ЦРУ. Эксперты категорически отрицают не только взрыв на газопроводе «Уренгой-Сургут-Челябинск» в 1982 году, но и вообще возможность возникновения такого взрыва.
Алгоритмическая ошибка привела к аварии самолета А-330 — в результате инцидента 119 пассажиров и членов экипажа получили ранения, из них 12 тяжелые.
Ракета-носитель Ariane 5 превратилась в «конфетти» 4 июня 1996 года — ошибка произошла в компоненте ПО, предназначенном для выполнения «регулировки» инерциальной платформы. Потеряно 500 млн долларов (стоимость ракеты с грузом).
Toyota: из-за корявой электроники и софта 89 человек погибли с 2000 по 2010 годы.
Источники:
habrahabr.ru/company/mailru/blog/227743
www.wikiwand.com/en/Therac-25
www.baselinemag.com/c/a/Projects-Processes/We-Did-Nothing-Wrong en.wikipedia.org/wiki/Northeast_blackout_of_2003
lps.co.nz/historical-project-failures-mars-climate-orbiter www.jpl.nasa.gov/missions/mariner-1
inosmi.ru/inrussia/20071229/238739.html
https://www.revolvy.com/main/index.php?s=USS%20Yorktown%20(CG-48)
www.defenseindustrydaily.com/f22-squadron-shot-down-by-the-international-date-line-03087
Как бы упорно мы не полагались на машины, они далеки от идеала. Как минимум, потому что сделаны человеком.
Пока программы не станут умнее людей, нам придётся следить за их состоянием постоянно. Особенно когда говорим об отвественном деле.
Истории ниже покажут, как сильно наши жизни зависят от правильно собранного алгоритма, и что бывает, если контроль качества на производстве возьмёт выходной.
Начнём со странных вещей, коснувшихся относительно скромного числа людей, а закончим настоящими финансовыми катастрофами. Они стоили не один десяток бессонных ночей тем, кому пришлось срочно вычитывать хрупкий код и буквально спасать человечество.
1. Система заживо похоронила 8 500 пациентов больницы в Мичигане
В 2003 году Медцентр Св. Марии Милосердия в городе Гранд-Рапидс обновил свою программу для учёта больных до новой версии. Из-за неверного толкования данных переменные «выписан» и «скончался» перепутались.
Потому всем, кто уже прошёл лечение начали приходить уведомления о смерти по почте и в разных отчётах вроде анализа крови.
Проблема не стала бы масштабной, но из-за высокой автоматизации сообщения направились и пациентам, и в страховые службы. Когда последние видели, что человек «умирал», то переставали компенсировать последующее лечение. Сюда входило больше 2 000 пенсионеров и инвалидов.
Поскольку ошибку нашли через два месяца после поломки, примерно столько же потребовалось, чтобы восстановить информацию в сопутствующих службах и компенсировать ущерб.
2. Обновление ПО лишило 60 тысяч человек междугородных звонков
В январе 1990 года американский оператор связи AT&T улучшал свою программу по контролю переключателей между вышками. Из-за ошибки в коде одна из них во время звонка начала отправлять сигналы быстрее, чем другая могла их обработать.
Данные начали наслаиваться друг на друга, и проблема быстро распространилась по другим точкам. На обратном конце люди слышали только шум. Так продолжалось 9 часов.
Проблему решили откатом ПО до предыдущей версии, однако проблема не перестала быть актуальной.
Ситуация повторилась как минимум один раз в 1998 году, но тогда были затронуты только сервисные уведомления по SMS.
3. 5% всех магазинов России сломалось из‑за новой онлайн‑кассы
20 декабря 2017 года техника по контролю данных обновлялась, чтобы продавцы начали напрямую передавать информацию о транзакциях налоговой службе. Одно из таких улучшений заблокировало каждый двадцатый магазин страны.
Сбои начались в салонах сети DNS во Владивостоке, где люди просыпаются раньше Москвы. Система не давала отправлять расчёты в Федеральную налоговую службу (ФНС), а из-за этого кассиры не имели права реализовывать товар.
Пока проблема добралась до столицы, откуда начал решаться вопрос, по всей России встали некоторые точки Магнита, Пятёрочки с Перекрёстком, Эльдорадо и аптек Ригла.
ФНС пришлось быстро реагировать и разрешать магазинам работать в офлайн режиме. Тем разрешили вносить данные после того, как система восстановится.
Полностью же проблему устраняли в течение нескольких дней патчами и принудительными перезагрузками.
Теоретический ущерб, по мнению Ассоциации компаний интернет-торговли, мог дойти до 2,5 млрд рублей. Реальный оказался чуть ниже благодаря быстрой оптимизации процессов со стороны ФНС.
4. Машине дали проектировать стадион в Коннектикуте. Тот рухнул
С 1972 года город Хартфорд старался расширить свою инфраструктуру и вкладывался в крупные проекты. Одним из них стал Hartford Civic Center – комплекс торговых, развлекательных и спортивных площадок.
Структуру стадиона проектировали через программу, что вместе с оптимизированным расходом материалов сэкономило городу около $500 тысяч.
Комплекс полностью функционировал и даже был «домом» для местной хоккейной группы New England Whalers с 1975 года.
Однако утром 18 января 1978-го стадион обвалился. Игр в тот день не проходило: здание было пустым и никто не пострадал.
СМИ растиражировали новость, где причиной указывали тяжесть снега. Но расследование показало, что на самом деле проблема была комплексной, а корнем оказалось наивное доверие программе.
Четыре несущие колонны с момента возведения были плохо продуманы в размере и креплении. Стадион начал постепенно «складываться» ещё во время строительства, а группы по контролю качества распределялись между разными подрядчиками и плохо согласовали данные.
Восстановление стоило городу $90 млн. В последствии на месте комплекса возвели арену XL Center, которая до сих пор исполняет роль главной спортивной площадки Хартфорда.
5. Intel выпустила процессор с ошибкой и устроила международный скандал
В 1994 году CPU под брендом Pentium был флагманом компании, и в нём пряталась микроскопическая проблема, которая касалась крошечной части людей: когда пользователь делил одно число на другое, результат был неверным. Выглядела ошибка так:
Программисты неправильно настроили одну из веток операций, вшитых в процессор. Она искала корневые данные и находила не те.
При этом основной ущерб пришёлся не на пользователей, а на компанию.
Из-за того, что Intel уже тогда уверенно чувствовала себя на рынке, а чипы были новые, даже федеральные СМИ многих стран подхватили новость и нанесли катастрофический ущерб имиджу и доходу компании.
В итоге за 1994 год замена всех повреждённых процессоров сократила выручку компании вдвое от запланированной – на $475 млн.
6. 6 миллионов автомобилей могут не раскрыть воздушные подушки
В январе 2020 года выяснилось, что датчики в некоторых моделях компаний Toyota и Honda слишком чувствительны к электрическому шуму.
Есть вероятность того, что в момент столкновения система не подаст сигнал системе безопасности. Та не сможет удержать ремни натянутыми, а подушки не наполнятся воздухом.
Проблема может быть глобальнее, поскольку компьютер из автомобилей Toyota разрабатывался сторонней организацией ZF-TRW. А она поставляла свои наработки как минимум шести компаниям в одних США, которые продали 12,3 млн машин.
Но пока только японские производители решили чинить датчики. И то, многие всё ещё ждут уведомления от своих диллеров.
7. MySpace уничтожил 50 миллионов песен пользователей
В 2016 году компания делала миграцию данных, которая началась еще в 2013 году. Уже тогда некоторые материалы и аккаунты стали недоступны части пользователей.
А в ходе переноса своей огромной библиотеки музыки, фотографий и видео возникла ошибка на сервере, которая их безвозвратно удалила.
Поскольку точной причины руководство не раскрыло, по поводу источника проблемы ходят разные слухи. Например, есть предположение, что хранить такой объём старых данных невыгодно и руководству было дешевле его «случайно» удалить.
Так или иначе, мир потерял один из крупнейших пластов интернет-культуры с 2003 по 2015 годы.
8. 144 тысячи родителей-одиночек не получили государственных выплат
В апреле 2003 года британская компания по поддержке малообеспеченных и неполноценных семей Child Support Agency внедрила систему по фильтрации заявлений. Она стоила £300 млн.
Спустя полгода обнаружилось, что обрабатывалась меньше, чем двадцатая часть просьб, и многие дети остались без материальной помощи.
Скандал длился как минимум до 2006 года, пока программа продолжала съедать 70% выделяемых на проект денег и затраты к 2010 году не составили £1,1 млрд.
В итоге в 2012 году агенство закрыли и вместо него запустили новую организацию Child Maintenance Group.
9. Уязвимость в защите 500 тысяч крупнейших сайтов давала доступ к вашей RAM
В апреле 2014 года специалисты по информационной безопасности обнаружили в библиотеке OpenSSL, на которой держится самый распространённый протокол HTTPS, критическую дыру в безопасности.
Её назвали Heartbleed по аналогии с процессом Heartbeat, взятым за основу этой ошибки.
С помощью уязвимости можно было узнать, что находится в оперативной памяти компьютера жертвы.
И, хотя максимальный объём украденной информации не мог превышать 64 Кб за один запрос, этого хватало на доступ к паролям и конфиденциальным сообщениям.
Ошибка затронула 17% всех защищенных сайтов. В том числе Google, Facebook, Instagram, Twitter и даже Minecraft.
Опасность закрывалась простым патчем, поэтому многие компании отреагировали быстро.
Однако по масштабу с этой проблемой сопоставима только одна, и вы наверняка о ней хоть раз слышали.
10. Мир потратил $300 млрд, чтобы в 2000 году компьютеры продолжили работать
Фото Эмори Кристоф / Emory Kristof
До 1999 года системы программировали так, что одни отмечали даты форматом из 8 цифр (ЧЧ.ММ.ГГГГ), а другие оставляли 6.
Это могло привести к тому, что переход в новое тысячелетие вызвал бы ошибки в программах по всей планете.
Дата формата ЧЧ.ММ.ГГ могла заменить 2000 на 1900 год, поскольку оба числа кончаются на «ОО». Таким образом ошибка бы переписала и стёрла данные, нарушила работу алгоритмов и спровоцировала коллапс онлайн-систем.
Большинство времени и ресурсов компаний ушло не на исправление последствий, а на то, чтобы проверить каждый компьютер в компании.
Поскольку программное обеспечение не переживало таких прыжков в исчислении времени раньше, ситуацию обсуждали по всему миру.
Вокруг Проблемы 2000 года (или Y2K) было много разговоров, в том числе о целесообразности паники. Их подогревало то, что страны восприняли вопрос серьезно и прописывали инициативы на государственном уровне.
Например, Россия создала официальный документ Национальный план действий по решению “Проблемы 2000” в Российской Федерации.
Табло на последней строке «обнулилось» и показывает 1900 вместо 2000
Ближайшая похожая ошибка настигнет не оптимизированные 32-битные системы в январе 2038 года, однако программисты уже готовятся к переходу.
64-х битных систем ситуация коснётся через 292 миллиарда лет, так что тут можно расслабиться.
Куда реальнее и скорее грозит Проблема 10 000 года своим переходом на значения из пяти цифр. Кажется, что не стоит о ней беспокоиться – пока вопрос ведь скорее теоретический.
Правда, всегда есть вероятность того, что крупицы существующего кода из вашего смартфона доживут до той эпохи.
Может, призадуматься и стоит.
(30 голосов, общий рейтинг: 4.77 из 5)
🤓 Хочешь больше? Подпишись на наш Telegram.
iPhones.ru
В последнем случае – миллиардов.
- Подборки,
- Это интересно
Павел
@Tinelray
У меня 4 новых года: обычный, свой, WWDC и сентябрьская презентация Apple. Последний — самый ожидаемый, и ни капли за это не стыдно.
Катастрофические последствия программных ошибок +24
Информационная безопасность, Программирование, Блог компании Mail.Ru Group, История IT
Рекомендация: подборка платных и бесплатных курсов Python — https://katalog-kursov.ru/
Практика не устает доказывать, что в любом ПО самая главная уязвимость — человеческий фактор. И неважно, появился ли баг из-за нехватки квалифицированности специалиста, выжил после долгих часов дебага в поисках ошибки, или считался хитро замаскировавшейся фичей. Среди некоторых разработчиков даже укрепилось мнение, что баги в принципе существуют всегда и везде. Но если ошибки абстрактны и сложно воспроизводимы в реальных условиях, то проблема не является критичной.
В идеальной ситуации баги исправляют все и сразу. Но в жизни всегда есть куча задач, отодвигающих полный и бесповоротный багфикс (новый функционал, срочные хотфиксы, расставленные приоритеты при исправлении багов). Это значит, что в первую очередь находятся и исправляются очевидные и явные проблемы. Остальные тихо ждут своего часа, превращаясь в бомбы замедленного действия. Иногда ошибки приводят не только к неприятностям в жизни рядового разработчика, но и вызывают настоящие катастрофы. Сегодня у нас подборка и объяснение самых кошмарных багов в истории разработки ПО.
Облучение и радиация
Знаменитый случай гибели нескольких человек, получивших смертельную дозу облучения во время сеансов радиационной терапии с применением медицинского ускорителя Therac-25. Ускорители подобного типа используют электроны для создания лучей высокой энергии, высокоточно уничтожающих опухоли. Но некоторые пациенты получили дозы не в несколько сотен рад, как предписывало лечение, а в 20 000 рад; доза в 1000 рад для человека считается несовместимой с жизнью, причем смерть может наступить сразу после облучения.
Всего один программист создал все ПО, используемое в аппаратах Therac — а это 20 тысяч инструкций, написанных на ассемблере. И при этом во всех Therac встречался один тот же пакет библиотек, содержащий ошибки.
Ускоритель Therac-25, ставший третьим в серии успешных аппаратов лучевой терапии, мог работать с рентгеновскими лучами до 25 МэВ. Несколько лет в середине 80-х аппараты Therac-25 работали безупречно, однако со временем начали накапливаться инциденты, повлекшие за собой тяжелые последствия: от ампутации конечностей до гибели пациентов.
Первое время баги просто не замечали, а все неполадки связывали с аппаратными сбоями. Программное обеспечение, безукоризненно проработавшее тысячи часов, воспринималось идеальным и безопасным. Никаких действий для предотвращения последствий возможных ошибок не предпринималось. Кроме того, выдаваемые оператору сообщения о критических с точки зрения безопасности ситуациях выглядели как рутинные. Производитель устройств расследовал каждый инцидент, но при этом не мог воспроизвести сбой. Потребовалось несколько лет исследований сторонних экспертов, привлеченных во время суда после череды смертей, чтобы сделать вывод о наличии большой плеяды именно программных ошибок.
Так при определенной последовательности ввода команд с клавиатуры происходил некорректный вызов процедур, влекущих за собой облучение любого произвольного участка тела пациента. Отсутствие на устройстве аппаратного блокиратора критических и продолжительных доз излучения усугубляло проблему.
Одна и та же переменная в ПО Therac-25, применялась как для анализа введенных чисел, так и для определения положения поворотного круга, отвечающего за направление излучателя. Поэтому при быстром вводе команд аппарат мог принять число дозы излучения за координаты места, куда нужно направить луч — например, прямо в мозг.
Иногда Therac-25 при расчете излучения делил на ноль и соответствующим образом увеличивал величины облучения до максимально возможных. Установка булевской переменной в значение «true» производилась командой «x=x+1» из-за чего с вероятностью 1/256 при нажатии кнопки «Set» программа могла пропустить информацию о некорректном положении излучателя.
Во внутренней документации производителя было обнаружено, что одно и то же сообщение об ошибке выдавалось как в случае ненадлежащей (малой) дозы облучения, так и для большой дозировки — отличить по сообщению об ошибке одно от другого было невозможно.
Если вы разработчик или (что еще лучше) тестировщик, этот случай стоит изучить досконально — есть хорошая статья в wiki, с нее можно начать, а затем ознакомьтесь с большой статьей девятнадцатилетней давности «Мифы о безопасном ПО: уроки знаменитых катастроф». История вобрала в себя большинство классических проблем тестирования.
Как ни печально, но проблемы Therac-25 не остались уникальными. В 2000 году серию аварий вызвал другой софт, точно так же просчитывающий нужную дозу облучения для пациентов, проходящих курс лучевой терапии.
Программное обеспечение Multidata позволяло медицинскому работнику рисовать на экране компьютера порядок размещения металлических блоков, предназначенных для защиты здоровых тканей от радиации. Но софт разрешал использовать только четыре защитных блока, в то время как врачи, в целях повышения безопасности, хотели использовать все пять.
Врачи воспользовались «лайфхаком». Оказалось, что в программе не предусмотрена защита от ввода некорректных данных — можно было нарисовать все пять блоков как один большой блок с отверстием в середине. В медицинском центре онкологии Панамы не понимали, что софт Multidata устанавливал разные показатели конфигурации в зависимости от того, как размещено отверстие: от направления его размещения рассчитывалась правильная доза облучения.
Из-за неверно введенных данных умерли восемь пациентов, в то время как еще 20 получили передозировку, повлекшую серьезные проблемы со здоровьем.
Блэкаут
Маленькая ошибка в программном обеспечении системы мониторинга работы оборудования General Electric Energy привела к тому, что 55 миллионов человек остались без электричества. На Восточном побережье США оказались обесточены жилые дома, школы, больницы, аэропорты.
14 августа 2003 года в 0:15 ночи оператор энергетической системы в Индиане с помощью инструмента мониторинга работы оборудования заметил небольшую проблему. Проблема вызвала раздражающий сигнал об ошибке, который оператор выключил. Оператору удалось за несколько минут решить все трудности, но он забыл перезапустить мониторинг — аварийный сигнал остался в выключенном положении.
Отключение сигнала не стало основной причиной блэкаута. Но когда через несколько часов из-за контакта с деревом вырубились провисшие линии электропередачи в Огайо — об этом никто не узнал. Проблема приняла лавинообразный характер, перегруженные линии передачи и электростанции начали вырубаться в Онтарио, Нью-Йорке, Нью-Джерси, Мичигане и далее.
Ни один из операторов не заметил каскад ошибок, которые медленно убивали энергосистему, из-за единственного выключенного сигнала тревоги — никаких дублирующих систем на этот случай не предполагалось.
Mars Climate Orbiter
В 1998 году NASA потеряло спутник «Mars Climate Orbiter» стоимостью $ 125 млн из-за того, что субподрядчик, работавший над инженерными задачами, не перевел английские единицы измерения (фунты) в метрическую систему. В результате ошибки спутник после 286-дневного путешествия на большой скорости вошел в марсианскую атмосферу, где из-за возникших перегрузок его системы связи вышли из строя. Аппарат оказался на сто километров ниже планируемой орбиты и на 25 км ниже высоты, на которой еще можно было исправить ситуацию. В результате спутник разбился. Такая же участь постигла космический аппарат Mars Polar Lander.
Mariner 1
В 1962 году космический корабль «Mariner 1» был уничтожен с земли после старта из-за отклонения от курса. Авария возникла на ракете из-за программного обеспечения, в котором разработчик пропустил всего один символ. В результате корабль стоимостью 18 миллионов долларов (в деньгах тех лет) получал неверные управляющие сигналы.
При работе над системой управления ракетой программист переводил рукописные математические формулы в компьютерный код. Символ «верхнего тире» (индекса), он воспринял за обычное тире (или знак минус). Функция сглаживания стала отражать нормальные вариации скорости ракеты как критические и недопустимые.
Однако даже допущенная ошибка могла не привести к критическому сбою, но как назло антенна ракеты потеряла связь с наводящей системой на Земле, и управление взял на себя бортовой компьютер.
Запуск баллистических ракет
26 сентября 1983 года спутник эшелона «Око» системы предупреждения о ракетном нападении СССР ошибочно сообщил о запуске пяти баллистических ракет с территории США. Спутник находился на высокой эллиптической орбите, наблюдая за районами базирования ракет под таким углом, чтобы они находились на краю видимого диска Земли. Это позволяло обнаружить факт запуска на фоне темного космического пространства по инфракрасному излучению работающего ракетного двигателя. Кроме того, выбранное расположение спутника снижало вероятность засветок датчиков отраженным от облаков или снега солнечным светом.
После безупречного года работы внезапно выяснилось, что в один день при определенном положении спутника и Солнца свет отражается от облаков, расположенных на больших высотах, оставляя то самое инфракрасное излучение, которое компьютеры восприняли как след от ракет. Заступивший на боевое дежурство подполковник Станислав Петров усомнился в показаниях системы. Подозрение вызвало сообщение о пяти замеченных целях — в случае реального военного конфликта США одновременно произвели бы сотни пусков. Подполковник Петров решил, что это ложное срабатывание системы, и тем самым, вероятно, предотвратил Третью мировую войну.
Подобная ошибка, едва не повлекшая за собой глобальный ядерный конфликт, произошла и по другую сторону океана. 9 ноября 1979 года из-за сбоя компьютера воздушно-космической обороны Северной Америки была получена информация о начале ракетной атаки против США — в количестве 2200 запусков. В то же время спутники раннего предупреждения и радары показали, что никакой информации о советской атаке не поступало — только благодаря перепроверке данных, сделанной за 10 минут, не был отдан приказ о взаимном гарантированном уничтожении.
Причиной всему оказалась самая опасная уязвимость — человеческий фактор. Оператор компьютера, находящегося на боевом дежурстве, загрузил в него пленку с учебной программой, имитировавшей ситуацию массированной ракетной атаки.
За несколько первых лет работы Национального центра управления Объединенного командования аэрокосмической обороны США и Канады было зафиксировано 3703 ложных сигнала тревоги, большая часть из которых появилась из-за атмосферных явлений. Однако случались и компьютерные ошибки. Так один из «боевых» компьютеров 3 июня 1980 года показал постоянно меняющиеся цифры количества ракет, запущенных Советским Союзом. Проблема возникла из-за аппаратного сбоя в микросхеме.
Обновление софта и деление на 0
В 1997 американский ракетный крейсер «Йорктаун» (CG-48), на котором были установлены 27 компьютеров (Pentium-Pro на 200 МГц), решил поделить на ноль и полностью вышел из строя.
Компьютеры работали на Windows NT — и работали они ровно так, как вы и ожидаете, узнав название оси. В то время ВМФ США старался максимально широко использовать коммерческое ПО с целью снижения стоимости военной техники. Компьютеры же позволяли автоматизировать управление кораблем без участия человека.
На компьютеры «Йорктауна» поставили новую программу, управляющую двигателями. Один из операторов, занимавшийся калибровкой клапанов топливной системы, записал в одну из ячеек расчетной таблицы нулевое значение. 21 сентября 1997 года программа запустила операцию деления на этот самый ноль, началась цепная реакция, и ошибка быстро перекинулась на другие компьютеры локальной сети. В результате отказала вся компьютерная система «Йорктауна». Потребовалось почти три часа, чтобы подключить аварийную систему управления.
Схожая проблема с нулем возникла при испытании истребителя в Израиле. Безупречно работавший самолет на автопилоте пролетел над равнинной частью, над горной частью, над долиной реки Иордан и приблизился к Мертвому морю. В этот момент произошел сбой, автопилот выключился, и пилоты посадили истребитель на ручном управлении.
После долгих разбирательств удалось выяснить, что программы автопилота при вычислении параметров управления производили деление на значение текущей высоты истребителя над уровнем океана. Соответственно, у Мертвого моря, лежащего ниже уровня океана, высота становилась нулевой, провоцируя ошибку.
В мире найдется немало историй, когда обновление софта, совершаемое с самыми благими целями, могло повести за собой множество проблем. В 2008 году атомная электростанция в штате Джорджия (США) мощностью 1,759 МВт в экстренном режиме приостановила работу на 48 часов.
Инженер компании, занимающейся технологическим обслуживанием станции, установил обновление на главный компьютер сети АЭС. Компьютер использовался для слежения за химическими данными и диагностики одной из основных систем электростанции. После установки обновлений компьютер штатно перезагрузился, стерев из памяти данные управляющих систем. Система безопасности станции восприняла потерю части данных как выброс радиоактивных веществ в системы охлаждения реактора. В результате автоматика подала сигнал тревоги и остановила все процессы на станции.
Инцидент с F-22
Двенадцать F-22 Raptor (истребитель пятого поколения, состоящий на вооружении США), стоимостью $ 140 млн за штуку, отправились в первый международный вылет в Окинаву. Все шло замечательно, пока эскадрилья не пересекла линию перемены даты, на западной стороне которой дата сдвинута на один день вперед относительно восточной. После пересечения условной линии все 12 истребителей одновременно выдали сообщение об ошибке, эквивалентной синему экрану смерти.
Самолеты потеряли доступы к данным о количестве топлива, датчикам скорости и высоты, частично нарушилась связь. В течение нескольких часов самые современные истребители Америки летели через океан совершенно беспомощными. В конце концов их удалось посадить только благодаря мастерству пилотов.
Так в чем же была ошибка? Проектировщики из Lockheed Martin даже не рассматривали вопрос о возможности пересечения линии перемены дат — им просто не пришло в голову, что где-то понадобится либо прибавлять, либо вычитать одни сутки.
Другие истории
В этой бескрайней теме есть еще несколько интересных историй. О них сложилось либо неправильное мнение, либо уже были подробные статьи на ГТ и Хабре.
Взрыв на советской газотранспортной системе в 1982 году из-за программных ошибок, заложенных ЦРУ. Эксперты категорически отрицают не только взрыв на газопроводе «Уренгой-Сургут-Челябинск» в 1982 году, но и вообще возможность возникновения такого взрыва.
Алгоритмическая ошибка привела к аварии самолета А-330 — в результате инцидента 119 пассажиров и членов экипажа получили ранения, из них 12 тяжелые.
Ракета-носитель Ariane 5 превратилась в «конфетти» 4 июня 1996 года — ошибка произошла в компоненте ПО, предназначенном для выполнения «регулировки» инерциальной платформы. Потеряно 500 млн долларов (стоимость ракеты с грузом).
Toyota: из-за корявой электроники и софта 89 человек погибли с 2000 по 2010 годы.
Источники:
habrahabr.ru/company/mailru/blog/227743
www.wikiwand.com/en/Therac-25
www.baselinemag.com/c/a/Projects-Processes/We-Did-Nothing-Wrong en.wikipedia.org/wiki/Northeast_blackout_of_2003
lps.co.nz/historical-project-failures-mars-climate-orbiter www.jpl.nasa.gov/missions/mariner-1
inosmi.ru/inrussia/20071229/238739.html
https://www.revolvy.com/main/index.php?s=USS%20Yorktown%20(CG-48)
www.defenseindustrydaily.com/f22-squadron-shot-down-by-the-international-date-line-03087
Как бы упорно мы не полагались на машины, они далеки от идеала. Как минимум, потому что сделаны человеком.
Пока программы не станут умнее людей, нам придётся следить за их состоянием постоянно. Особенно когда говорим об отвественном деле.
Истории ниже покажут, как сильно наши жизни зависят от правильно собранного алгоритма, и что бывает, если контроль качества на производстве возьмёт выходной.
Начнём со странных вещей, коснувшихся относительно скромного числа людей, а закончим настоящими финансовыми катастрофами. Они стоили не один десяток бессонных ночей тем, кому пришлось срочно вычитывать хрупкий код и буквально спасать человечество.
1. Система заживо похоронила 8 500 пациентов больницы в Мичигане
В 2003 году Медцентр Св. Марии Милосердия в городе Гранд-Рапидс обновил свою программу для учёта больных до новой версии. Из-за неверного толкования данных переменные «выписан» и «скончался» перепутались.
Потому всем, кто уже прошёл лечение начали приходить уведомления о смерти по почте и в разных отчётах вроде анализа крови.
Проблема не стала бы масштабной, но из-за высокой автоматизации сообщения направились и пациентам, и в страховые службы. Когда последние видели, что человек «умирал», то переставали компенсировать последующее лечение. Сюда входило больше 2 000 пенсионеров и инвалидов.
Поскольку ошибку нашли через два месяца после поломки, примерно столько же потребовалось, чтобы восстановить информацию в сопутствующих службах и компенсировать ущерб.
2. Обновление ПО лишило 60 тысяч человек междугородных звонков
В январе 1990 года американский оператор связи AT&T улучшал свою программу по контролю переключателей между вышками. Из-за ошибки в коде одна из них во время звонка начала отправлять сигналы быстрее, чем другая могла их обработать.
Данные начали наслаиваться друг на друга, и проблема быстро распространилась по другим точкам. На обратном конце люди слышали только шум. Так продолжалось 9 часов.
Проблему решили откатом ПО до предыдущей версии, однако проблема не перестала быть актуальной.
Ситуация повторилась как минимум один раз в 1998 году, но тогда были затронуты только сервисные уведомления по SMS.
3. 5% всех магазинов России сломалось из‑за новой онлайн‑кассы
20 декабря 2017 года техника по контролю данных обновлялась, чтобы продавцы начали напрямую передавать информацию о транзакциях налоговой службе. Одно из таких улучшений заблокировало каждый двадцатый магазин страны.
Сбои начались в салонах сети DNS во Владивостоке, где люди просыпаются раньше Москвы. Система не давала отправлять расчёты в Федеральную налоговую службу (ФНС), а из-за этого кассиры не имели права реализовывать товар.
Пока проблема добралась до столицы, откуда начал решаться вопрос, по всей России встали некоторые точки Магнита, Пятёрочки с Перекрёстком, Эльдорадо и аптек Ригла.
ФНС пришлось быстро реагировать и разрешать магазинам работать в офлайн режиме. Тем разрешили вносить данные после того, как система восстановится.
Полностью же проблему устраняли в течение нескольких дней патчами и принудительными перезагрузками.
Теоретический ущерб, по мнению Ассоциации компаний интернет-торговли, мог дойти до 2,5 млрд рублей. Реальный оказался чуть ниже благодаря быстрой оптимизации процессов со стороны ФНС.
4. Машине дали проектировать стадион в Коннектикуте. Тот рухнул
С 1972 года город Хартфорд старался расширить свою инфраструктуру и вкладывался в крупные проекты. Одним из них стал Hartford Civic Center – комплекс торговых, развлекательных и спортивных площадок.
Структуру стадиона проектировали через программу, что вместе с оптимизированным расходом материалов сэкономило городу около $500 тысяч.
Комплекс полностью функционировал и даже был «домом» для местной хоккейной группы New England Whalers с 1975 года.
Однако утром 18 января 1978-го стадион обвалился. Игр в тот день не проходило: здание было пустым и никто не пострадал.
СМИ растиражировали новость, где причиной указывали тяжесть снега. Но расследование показало, что на самом деле проблема была комплексной, а корнем оказалось наивное доверие программе.
Четыре несущие колонны с момента возведения были плохо продуманы в размере и креплении. Стадион начал постепенно «складываться» ещё во время строительства, а группы по контролю качества распределялись между разными подрядчиками и плохо согласовали данные.
Восстановление стоило городу $90 млн. В последствии на месте комплекса возвели арену XL Center, которая до сих пор исполняет роль главной спортивной площадки Хартфорда.
5. Intel выпустила процессор с ошибкой и устроила международный скандал
В 1994 году CPU под брендом Pentium был флагманом компании, и в нём пряталась микроскопическая проблема, которая касалась крошечной части людей: когда пользователь делил одно число на другое, результат был неверным. Выглядела ошибка так:
Программисты неправильно настроили одну из веток операций, вшитых в процессор. Она искала корневые данные и находила не те.
При этом основной ущерб пришёлся не на пользователей, а на компанию.
Из-за того, что Intel уже тогда уверенно чувствовала себя на рынке, а чипы были новые, даже федеральные СМИ многих стран подхватили новость и нанесли катастрофический ущерб имиджу и доходу компании.
В итоге за 1994 год замена всех повреждённых процессоров сократила выручку компании вдвое от запланированной – на $475 млн.
6. 6 миллионов автомобилей могут не раскрыть воздушные подушки
В январе 2020 года выяснилось, что датчики в некоторых моделях компаний Toyota и Honda слишком чувствительны к электрическому шуму.
Есть вероятность того, что в момент столкновения система не подаст сигнал системе безопасности. Та не сможет удержать ремни натянутыми, а подушки не наполнятся воздухом.
Проблема может быть глобальнее, поскольку компьютер из автомобилей Toyota разрабатывался сторонней организацией ZF-TRW. А она поставляла свои наработки как минимум шести компаниям в одних США, которые продали 12,3 млн машин.
Но пока только японские производители решили чинить датчики. И то, многие всё ещё ждут уведомления от своих диллеров.
7. MySpace уничтожил 50 миллионов песен пользователей
В 2016 году компания делала миграцию данных, которая началась еще в 2013 году. Уже тогда некоторые материалы и аккаунты стали недоступны части пользователей.
А в ходе переноса своей огромной библиотеки музыки, фотографий и видео возникла ошибка на сервере, которая их безвозвратно удалила.
Поскольку точной причины руководство не раскрыло, по поводу источника проблемы ходят разные слухи. Например, есть предположение, что хранить такой объём старых данных невыгодно и руководству было дешевле его «случайно» удалить.
Так или иначе, мир потерял один из крупнейших пластов интернет-культуры с 2003 по 2015 годы.
8. 144 тысячи родителей-одиночек не получили государственных выплат
В апреле 2003 года британская компания по поддержке малообеспеченных и неполноценных семей Child Support Agency внедрила систему по фильтрации заявлений. Она стоила £300 млн.
Спустя полгода обнаружилось, что обрабатывалась меньше, чем двадцатая часть просьб, и многие дети остались без материальной помощи.
Скандал длился как минимум до 2006 года, пока программа продолжала съедать 70% выделяемых на проект денег и затраты к 2010 году не составили £1,1 млрд.
В итоге в 2012 году агенство закрыли и вместо него запустили новую организацию Child Maintenance Group.
9. Уязвимость в защите 500 тысяч крупнейших сайтов давала доступ к вашей RAM
В апреле 2014 года специалисты по информационной безопасности обнаружили в библиотеке OpenSSL, на которой держится самый распространённый протокол HTTPS, критическую дыру в безопасности.
Её назвали Heartbleed по аналогии с процессом Heartbeat, взятым за основу этой ошибки.
С помощью уязвимости можно было узнать, что находится в оперативной памяти компьютера жертвы.
И, хотя максимальный объём украденной информации не мог превышать 64 Кб за один запрос, этого хватало на доступ к паролям и конфиденциальным сообщениям.
Ошибка затронула 17% всех защищенных сайтов. В том числе Google, Facebook, Instagram, Twitter и даже Minecraft.
Опасность закрывалась простым патчем, поэтому многие компании отреагировали быстро.
Однако по масштабу с этой проблемой сопоставима только одна, и вы наверняка о ней хоть раз слышали.
10. Мир потратил $300 млрд, чтобы в 2000 году компьютеры продолжили работать
Фото Эмори Кристоф / Emory Kristof
До 1999 года системы программировали так, что одни отмечали даты форматом из 8 цифр (ЧЧ.ММ.ГГГГ), а другие оставляли 6.
Это могло привести к тому, что переход в новое тысячелетие вызвал бы ошибки в программах по всей планете.
Дата формата ЧЧ.ММ.ГГ могла заменить 2000 на 1900 год, поскольку оба числа кончаются на «ОО». Таким образом ошибка бы переписала и стёрла данные, нарушила работу алгоритмов и спровоцировала коллапс онлайн-систем.
Большинство времени и ресурсов компаний ушло не на исправление последствий, а на то, чтобы проверить каждый компьютер в компании.
Поскольку программное обеспечение не переживало таких прыжков в исчислении времени раньше, ситуацию обсуждали по всему миру.
Вокруг Проблемы 2000 года (или Y2K) было много разговоров, в том числе о целесообразности паники. Их подогревало то, что страны восприняли вопрос серьезно и прописывали инициативы на государственном уровне.
Например, Россия создала официальный документ Национальный план действий по решению “Проблемы 2000” в Российской Федерации.
Табло на последней строке «обнулилось» и показывает 1900 вместо 2000
Ближайшая похожая ошибка настигнет не оптимизированные 32-битные системы в январе 2038 года, однако программисты уже готовятся к переходу.
64-х битных систем ситуация коснётся через 292 миллиарда лет, так что тут можно расслабиться.
Куда реальнее и скорее грозит Проблема 10 000 года своим переходом на значения из пяти цифр. Кажется, что не стоит о ней беспокоиться – пока вопрос ведь скорее теоретический.
Правда, всегда есть вероятность того, что крупицы существующего кода из вашего смартфона доживут до той эпохи.
Может, призадуматься и стоит.
(30 голосов, общий рейтинг: 4.77 из 5)
🤓 Хочешь больше? Подпишись на наш Telegram.
iPhones.ru
В последнем случае – миллиардов.
- Подборки,
- Это интересно
Павел
@Tinelray
У меня 4 новых года: обычный, свой, WWDC и сентябрьская презентация Apple. Последний — самый ожидаемый, и ни капли за это не стыдно.
Современное программное обеспечение (сокращенно ПО) позволяет сделать жизнь миллионов людей проще, однако сбои в крупных системах могут иметь катастрофические последствия. Нередко ошибки при работе компьютеров приводили к серьезным разрушениям и смерти людей.
Ниже будут перечислены наиболее масштабные инциденты, произошедшие из-за ошибок программного обеспечения.
1 Ошибка в космическом агентстве
В июне 1996 года специалисты Европейского космического агентства осуществляли запуск ракеты Ariane 5.
Ошибка в программном обеспечении для модуля управления привела к старту процесса самоуничтожения – через 37 секунд полета ракета взорвалась.
2 Акции упали, деньги пропали
В прошлом году крупный сбой в программном обеспечении чуть не обанкротил корпорацию Knight Capital.
Фирма менее чем за час потеряла полмиллиарда долларов – система начала несанкционированно покупать и продавать большое количество акций. В итоге за два дня акции упали в цене на 75%.
3 Сбой в медицинском оборудовании
Сбои случались и в медицинском оборудовании. В 1980-годы несколько пациентов погибли после получения слишком большой дозы облучения рентгеновским аппаратом Therac-25 (лучевая терапия).
Эксперты предположили, что масштабный сбой произошел из-за обычной ошибки в коде, которая привела к выполнению одной операции многократно.
4 Жаркое лето для Амазона
Летом 2013 года произошло отключение серверов американской компании Amazon (самая известная компания в мире по продаже различных товаров и услуг через Интернет). Это привело к потере файлов пользователей, хранившихся в сетевом хранилище.
Авария, первоначально вызванная грозой, неожиданно усугубилась ошибками в используемом программном обеспечении. Это быстро привело к каскадному сбою.
5 О связи электричества и программного обеспечения
Массовое отключение электричества в 2003 году в северо-восточной части США произошло из-за локальной аварии, которая не была зафиксирована программным обеспечением General Electric Energy.
Отсутствие реакции на локальный сбой привело к каскадному отключению электроэнергии.
6 Авиакомпании и программное обеспечение
Маленький сын спрашивает у папы-программиста:
— Папа, почему солнце всходит на востоке?
— Вот работает, сынок, и не трогай!
В 2014 году из-за ошибки в программе была заблокирована работа всех самолетов авиакомпании American Airlines.
Сбой возник в системе бронирования билетов – проводилась работа по объединению программных платформ нескольких компаний.
К сожалению, не всегда программисты могут точно просчитать последствия тех или иных действий, заложенных ими в программное обеспечение.
Поэтому с программистами надо обращаться аккуратно. С одной стороны, их надо сильно мотивировать на создание безошибочного кода. С другой стороны, нужны методы контроля и проверки программного обеспечения, которые могли бы исключить подобные ошибки в будущем. Тем более, что эти ошибки могут приводить не только к многомиллиардным убыткам, но и к человеческим жертвам.
Крупные и ответственные корпорации создают такие технологии программирования, в которых обязательно соблюдались бы все этапы создания программ. Включая контроль безошибочности написанного кода. Устраивают конкурсы среди хакеров, лучших из них приглашают на высокооплачиваемую работу.
Но даже это не всегда спасает, как видно из приведенных выше вопиющих фактов программных сбоев. Программы обрабатывают множество данных, и не всегда, к сожалению, удается проверить работоспособность программ на всех возможных вариантах и комбинациях этих данных, поступающих на обработку. Это и может привести к непоправимым сбоям.
Будем внимательны к программному обеспечению, к программистам и друг к другу!
P.S. Это интересно:
Не влезай, умрет!
Стив Джобс: он просто взял и изменил мир
Без мифов и легенд о выборе профессии программиста: часть 1
Самый богатый ботаник в мире
Что такое шпионские программы Spyware?
Получайте актуальные статьи по компьютерной грамотности прямо на ваш почтовый ящик.
Уже более 3.000 подписчиков
.
Важно: необходимо подтвердить свою подписку! В своей почте откройте письмо для активации и кликните по указанной там ссылке. Если письма нет, проверьте папку Спам.
В истории программирования не всегда все было легко и безоблачно. Ведь любому программисту, вне зависимости от опыта и технического бэкграунда, трудно уберечься от ошибок и порой даже небольшого количества плохого кода хватало, чтобы вызвать серьезную проблему. «Библиотека программиста» немного полистала ИТ-летописи и нашла для вас 10 самых худших ошибок в истории кодинга. Поехали!
1. Ошибка 2000 года
Более двух десятилетий назад, в канун нового 2000 года, весь развитый мир охватила паника из-за проблемы способной привести к сбоям в работе компьютеров, падению самолетов, прекращению работы медицинского оборудования и разрушению глобальной финансовой системы.
Суть проблемы заключалась в том, что большинство устаревших информационных систем, созданных еще в 70-х и 80-х, использовали только две цифры для исчисления года. Это значит, что часы внутри микропроцессоров различного аппаратного ПО регистрировали 1999 год как «99», основываясь на ошибочном предположении разработчиков прошлого, что мы всегда будем жить в 20-м веке и цифра «19» в обозначении года никогда не изменится.
Тогда все полагали, что в 2000 году у всех нас наверняка будут реактивные ранцы, еда в форме таблеток, футуристическая серебристая униформа и человечество к этому времени откажется от старых компьютерных систем середины века. Но чуда не случилось!
И в канун всеми любимого праздника мир охватила полномасштабная паника. Кто-то усердно работал над внедрением обходных путей, выделяя на эти цели колоссальные средства. Другие же вообще не чинили, не исправляли и не обновляли свои системы. Кто из них был прав, сейчас сказать сложно, но когда наступил рубеж тысячелетий, глобальной катастрофы не произошло. Однако у всей этой шумихи, все же был положительный эффект. До общественности наконец начало доходить, как много жизненно важных систем зависит от компьютеров и микропроцессоров и как важно следить за их ПО и своевременно его обслуживать.
2. Терак-25
Плохой код на самом деле может убить. Такая катастрофа произошла с аппаратом лучевой терапии Therac-25, произведенным компанией Atomic Energy of Canada, ставшего причиной гибели не менее шести пациентов. Расследование выявило недоработку системы, вызвавшую передозировку радиацией. Связано это было с трудностью проведения автоматизированных тестов такого специфического программного обеспечения. И поэтому машина, призванная помочь людям, стала машиной для убийств из научной фантастики. Этот случай заставил разработчиков ПО медицинской отрасли крайне ответственно подходить к тестированию такого оборудования.
3. Сеть AT&T выходит из строя
15 января 1990 года около 50 процентов мобильной сети AT&T вышло из строя. За девять часов простоя более 75 миллионов звонков остались без ответа. И хотя в первоначальных отчетах следствия по этому делу значилось хакерская атака, на самом деле, виновником сего происшествия стало стандартное обновление ПО. Ошибка всего в одной строке кода стоила компании огромных денег. Все организации, целиком зависящие от наличия и качества связи, выставили AT&T иски с внушительными суммами. К примеру, крупнейший авиаперевозчик American Airlines, понес колоссальные финансовые убытки из-за того, что получил наполовину меньше звонков своих клиентов из-за сбоя. Авария 1990 года до сих пор служит прекрасным примером важности тестирования программного обеспечения и служит напоминанием о неразрывной связи между технологиями и экономической деятельностью большинства компаний.
4. Досрочное освобождение заключенных
В 2005 году в США штате Мичиган произошел сбой тюремной программы, отвечающей за расчет срока наказания заключенных, в результате чего более 20 заключенных досрочно вышли на свободу. Программа ошибочно посчитала смягчающий коэффициент и снизила срок пребывания отбывающих наказание людей в несколько раз. Ошибку в коде заметили не сразу, а лишь по прошествии некоторого времени. И поэтому меру пресечения счастливчикам никто не пересчитывал. Среди них, к слову, не было матерых гангстеров и маньяков. В основном это были мелкие правонарушители, отбывавшие срок за неуплату алиментов, махинации с налогами и незаконное хранение психотропов.
Произошедшее показывает, что в погоне за автоматизацией процессов и сокращением количества ручных операций программисты зачастую забывают о грамотной настройке разработанной системы и ее тестировании. А мы с вами в очередной раз убеждаемся, что даже незначительная ошибка может привести к серьезным последствиям.
5. Взрыв Ariane 5
Случай произошел 4 июня 1996 года при первом запуске Ariane 5 — одной из самых надежных беспилотных ракетных установок, целью которой было изучение взаимодействия между солнечным ветром и магнитосферой Земли. Через 37 секунд после старта ракета, вылетевшая с космодрома, находящегося на берегах Французской Гвианы, развернулась на 90 градусов и всего через несколько секунд превратилась в огромный огненный шар.
Специальная группа прочесала место происшествия, собирая обломки, чтобы попытаться выяснить, что произошло. Через некоторое время техническая комиссия установила, что авария была вызвана программным сбоем.
Отказ системы произошел из-за полной потери информации о точности наведения ракеты и ориентации ее в пространстве, поступающей в центральный процессор. Потеря — следствие ошибки проектировщиков ПО и вызвана она была некорректным преобразованием 64-битного числа с плавающей запятой в 16-битное целое число.
К слову, целочисленное переполнение является широко распространенной ошибкой в компьютерном программировании.
6. Ошибка Paypal
Что бы вы сделали, если бы PayPal случайно зачислил на ваш счет 92 квадриллиона долларов? Крису Рейнольдсу, 56-летнему американцу, продающему автозапчасти на eBay, не пришлось долго об этом думать. Ведь он даже не успел ощутить себя первым в мире квадриллионером и самым богатым человеком в мире, так как ошибка была устранена в течение нескольких минут. Поэтому, прежде чем мужчина начал мечтать о новом кадиллаке и золотой карте члена королевского яхт-клуба, сумма на его счету вернулась к привычному балансу. Конечно, стоило бы потребовать с компании хотя бы часть этой суммы за моральный ущерб, но, видимо, шок от увиденного не позволил ему сделать это.
7. Калькулятор Windows
Эта ошибка, существующая в большинстве версий Windows (кроме Windows 10), которую вы сможете проверить самостоятельно.
Для этого нужно:
- Открыть калькулятор Windows и ввести 4.
- Извлечь из этого числа квадратный корень и получите 2.
- Вычесть из него 2 и вместо нулевого результата в разных версиях Windows вы увидите разные результаты.
Причиной ошибки является недоработка, вызванная некорректным обращением калькулятора с операциями sqrt. В итоге результаты сохраняются как числа с плавающей запятой, а не целые числа, вызывая ошибку точности при дальнейших вычислениях, которую вы можете видеть.
Microsoft признала эту ошибку в приложении калькулятора и исправила ее в Windows 10.
8. Проблема 2038 года
Ошибка 2038 будет вызвана использованием 32-разрядных процессоров в 32-разрядных системах. Проще говоря, 19 января 2038 года наступит в 03:14:07. Компьютеры, которые все еще используют 32-разрядные системы для управления датой и временем, не смогут справиться с этим изменением. Как и в случае с ошибкой 2000 года, компьютеры не смогут отличить 2038 год от 1970 года.
Однако волноваться не стоит: почти все современные процессоры в настольных ПК имеют 64-битные системы с 64-битным программным обеспечением и в 2038 году само существование 32-битных систем будет под вопросом.
9. Видео Gangnam Style «сломало» YouTube
Счетчик YouTube ранее использовал 32-битное целое число для определения максимального количества просмотров видеоролика, и равно оно было 2 147 483 647.
Однако корейская поп-группа PSY, выложившая на сервис свой клип с зажигательной песней Gangnam Style благополучно его сломала, превысив допустимую планку.
«Когда мы его делали, никогда не думали, что какое-нибудь видео посмотрят столько раз, но это было до Gangman Style», — написал на своей странице в сети один из разработчиков портала.
Клип PSY опубликовали 15 июля 2012 года и к концу мая 2014 года он стал единственным видеороликом, которой просмотрели больше 2 млрд раз.
В настоящее время YouTube использует 64-битное целое число для счетчика видео, что означает, что максимальное количество просмотров видео составляет 9,22 квинтиллиона.
10. Синий экран смерти
BSOD или «Синий экран смерти» — жаргонное название фатальной системной ошибки Windows, показывающей системный сбой, при котором операционка достигала состояния, в котором она больше не могла надежно работать. Как правило, вызывалась она в Windows 95-98 после неожиданного завершения важного процесса или общего сбоя оборудования. Старожилы наверняка помнят этот баг, который довольно часто возникал на заре становления ИТ-культуры.
16 марта 2000 года Microsoft выпустила обновление для системы безопасности, устраняющее эту неполадку, однако и сейчас на форумах изредка можно встретить сообщение от пользователей об этой проблеме.
***
Людям свойственно совершать ошибки. Однако, будьте внимательны — всегда нужно помнить, что даже одна плохо написанная строчка кода может привести к печальным последствиям. Удачи!
Материалы по теме
- ⚠️ 10 самых распространенных ошибок, ежедневно допускаемых каждым программистом
- ⚠️ Как не нужно учить TypeScript: 5 распространенных ошибок
- 😢 Дорогостоящие ошибки: почему нам пришлось отказаться от Firebase
Катастрофические последствия программных ошибок +24
Информационная безопасность, Программирование, Блог компании Mail.Ru Group, История IT
Рекомендация: подборка платных и бесплатных курсов Python — https://katalog-kursov.ru/
Практика не устает доказывать, что в любом ПО самая главная уязвимость — человеческий фактор. И неважно, появился ли баг из-за нехватки квалифицированности специалиста, выжил после долгих часов дебага в поисках ошибки, или считался хитро замаскировавшейся фичей. Среди некоторых разработчиков даже укрепилось мнение, что баги в принципе существуют всегда и везде. Но если ошибки абстрактны и сложно воспроизводимы в реальных условиях, то проблема не является критичной.
В идеальной ситуации баги исправляют все и сразу. Но в жизни всегда есть куча задач, отодвигающих полный и бесповоротный багфикс (новый функционал, срочные хотфиксы, расставленные приоритеты при исправлении багов). Это значит, что в первую очередь находятся и исправляются очевидные и явные проблемы. Остальные тихо ждут своего часа, превращаясь в бомбы замедленного действия. Иногда ошибки приводят не только к неприятностям в жизни рядового разработчика, но и вызывают настоящие катастрофы. Сегодня у нас подборка и объяснение самых кошмарных багов в истории разработки ПО.
Облучение и радиация
Знаменитый случай гибели нескольких человек, получивших смертельную дозу облучения во время сеансов радиационной терапии с применением медицинского ускорителя Therac-25. Ускорители подобного типа используют электроны для создания лучей высокой энергии, высокоточно уничтожающих опухоли. Но некоторые пациенты получили дозы не в несколько сотен рад, как предписывало лечение, а в 20 000 рад; доза в 1000 рад для человека считается несовместимой с жизнью, причем смерть может наступить сразу после облучения.
Всего один программист создал все ПО, используемое в аппаратах Therac — а это 20 тысяч инструкций, написанных на ассемблере. И при этом во всех Therac встречался один тот же пакет библиотек, содержащий ошибки.
Ускоритель Therac-25, ставший третьим в серии успешных аппаратов лучевой терапии, мог работать с рентгеновскими лучами до 25 МэВ. Несколько лет в середине 80-х аппараты Therac-25 работали безупречно, однако со временем начали накапливаться инциденты, повлекшие за собой тяжелые последствия: от ампутации конечностей до гибели пациентов.
Первое время баги просто не замечали, а все неполадки связывали с аппаратными сбоями. Программное обеспечение, безукоризненно проработавшее тысячи часов, воспринималось идеальным и безопасным. Никаких действий для предотвращения последствий возможных ошибок не предпринималось. Кроме того, выдаваемые оператору сообщения о критических с точки зрения безопасности ситуациях выглядели как рутинные. Производитель устройств расследовал каждый инцидент, но при этом не мог воспроизвести сбой. Потребовалось несколько лет исследований сторонних экспертов, привлеченных во время суда после череды смертей, чтобы сделать вывод о наличии большой плеяды именно программных ошибок.
Так при определенной последовательности ввода команд с клавиатуры происходил некорректный вызов процедур, влекущих за собой облучение любого произвольного участка тела пациента. Отсутствие на устройстве аппаратного блокиратора критических и продолжительных доз излучения усугубляло проблему.
Одна и та же переменная в ПО Therac-25, применялась как для анализа введенных чисел, так и для определения положения поворотного круга, отвечающего за направление излучателя. Поэтому при быстром вводе команд аппарат мог принять число дозы излучения за координаты места, куда нужно направить луч — например, прямо в мозг.
Иногда Therac-25 при расчете излучения делил на ноль и соответствующим образом увеличивал величины облучения до максимально возможных. Установка булевской переменной в значение «true» производилась командой «x=x+1» из-за чего с вероятностью 1/256 при нажатии кнопки «Set» программа могла пропустить информацию о некорректном положении излучателя.
Во внутренней документации производителя было обнаружено, что одно и то же сообщение об ошибке выдавалось как в случае ненадлежащей (малой) дозы облучения, так и для большой дозировки — отличить по сообщению об ошибке одно от другого было невозможно.
Если вы разработчик или (что еще лучше) тестировщик, этот случай стоит изучить досконально — есть хорошая статья в wiki, с нее можно начать, а затем ознакомьтесь с большой статьей девятнадцатилетней давности «Мифы о безопасном ПО: уроки знаменитых катастроф». История вобрала в себя большинство классических проблем тестирования.
Как ни печально, но проблемы Therac-25 не остались уникальными. В 2000 году серию аварий вызвал другой софт, точно так же просчитывающий нужную дозу облучения для пациентов, проходящих курс лучевой терапии.
Программное обеспечение Multidata позволяло медицинскому работнику рисовать на экране компьютера порядок размещения металлических блоков, предназначенных для защиты здоровых тканей от радиации. Но софт разрешал использовать только четыре защитных блока, в то время как врачи, в целях повышения безопасности, хотели использовать все пять.
Врачи воспользовались «лайфхаком». Оказалось, что в программе не предусмотрена защита от ввода некорректных данных — можно было нарисовать все пять блоков как один большой блок с отверстием в середине. В медицинском центре онкологии Панамы не понимали, что софт Multidata устанавливал разные показатели конфигурации в зависимости от того, как размещено отверстие: от направления его размещения рассчитывалась правильная доза облучения.
Из-за неверно введенных данных умерли восемь пациентов, в то время как еще 20 получили передозировку, повлекшую серьезные проблемы со здоровьем.
Блэкаут
Маленькая ошибка в программном обеспечении системы мониторинга работы оборудования General Electric Energy привела к тому, что 55 миллионов человек остались без электричества. На Восточном побережье США оказались обесточены жилые дома, школы, больницы, аэропорты.
14 августа 2003 года в 0:15 ночи оператор энергетической системы в Индиане с помощью инструмента мониторинга работы оборудования заметил небольшую проблему. Проблема вызвала раздражающий сигнал об ошибке, который оператор выключил. Оператору удалось за несколько минут решить все трудности, но он забыл перезапустить мониторинг — аварийный сигнал остался в выключенном положении.
Отключение сигнала не стало основной причиной блэкаута. Но когда через несколько часов из-за контакта с деревом вырубились провисшие линии электропередачи в Огайо — об этом никто не узнал. Проблема приняла лавинообразный характер, перегруженные линии передачи и электростанции начали вырубаться в Онтарио, Нью-Йорке, Нью-Джерси, Мичигане и далее.
Ни один из операторов не заметил каскад ошибок, которые медленно убивали энергосистему, из-за единственного выключенного сигнала тревоги — никаких дублирующих систем на этот случай не предполагалось.
Mars Climate Orbiter
В 1998 году NASA потеряло спутник «Mars Climate Orbiter» стоимостью $ 125 млн из-за того, что субподрядчик, работавший над инженерными задачами, не перевел английские единицы измерения (фунты) в метрическую систему. В результате ошибки спутник после 286-дневного путешествия на большой скорости вошел в марсианскую атмосферу, где из-за возникших перегрузок его системы связи вышли из строя. Аппарат оказался на сто километров ниже планируемой орбиты и на 25 км ниже высоты, на которой еще можно было исправить ситуацию. В результате спутник разбился. Такая же участь постигла космический аппарат Mars Polar Lander.
Mariner 1
В 1962 году космический корабль «Mariner 1» был уничтожен с земли после старта из-за отклонения от курса. Авария возникла на ракете из-за программного обеспечения, в котором разработчик пропустил всего один символ. В результате корабль стоимостью 18 миллионов долларов (в деньгах тех лет) получал неверные управляющие сигналы.
При работе над системой управления ракетой программист переводил рукописные математические формулы в компьютерный код. Символ «верхнего тире» (индекса), он воспринял за обычное тире (или знак минус). Функция сглаживания стала отражать нормальные вариации скорости ракеты как критические и недопустимые.
Однако даже допущенная ошибка могла не привести к критическому сбою, но как назло антенна ракеты потеряла связь с наводящей системой на Земле, и управление взял на себя бортовой компьютер.
Запуск баллистических ракет
26 сентября 1983 года спутник эшелона «Око» системы предупреждения о ракетном нападении СССР ошибочно сообщил о запуске пяти баллистических ракет с территории США. Спутник находился на высокой эллиптической орбите, наблюдая за районами базирования ракет под таким углом, чтобы они находились на краю видимого диска Земли. Это позволяло обнаружить факт запуска на фоне темного космического пространства по инфракрасному излучению работающего ракетного двигателя. Кроме того, выбранное расположение спутника снижало вероятность засветок датчиков отраженным от облаков или снега солнечным светом.
После безупречного года работы внезапно выяснилось, что в один день при определенном положении спутника и Солнца свет отражается от облаков, расположенных на больших высотах, оставляя то самое инфракрасное излучение, которое компьютеры восприняли как след от ракет. Заступивший на боевое дежурство подполковник Станислав Петров усомнился в показаниях системы. Подозрение вызвало сообщение о пяти замеченных целях — в случае реального военного конфликта США одновременно произвели бы сотни пусков. Подполковник Петров решил, что это ложное срабатывание системы, и тем самым, вероятно, предотвратил Третью мировую войну.
Подобная ошибка, едва не повлекшая за собой глобальный ядерный конфликт, произошла и по другую сторону океана. 9 ноября 1979 года из-за сбоя компьютера воздушно-космической обороны Северной Америки была получена информация о начале ракетной атаки против США — в количестве 2200 запусков. В то же время спутники раннего предупреждения и радары показали, что никакой информации о советской атаке не поступало — только благодаря перепроверке данных, сделанной за 10 минут, не был отдан приказ о взаимном гарантированном уничтожении.
Причиной всему оказалась самая опасная уязвимость — человеческий фактор. Оператор компьютера, находящегося на боевом дежурстве, загрузил в него пленку с учебной программой, имитировавшей ситуацию массированной ракетной атаки.
За несколько первых лет работы Национального центра управления Объединенного командования аэрокосмической обороны США и Канады было зафиксировано 3703 ложных сигнала тревоги, большая часть из которых появилась из-за атмосферных явлений. Однако случались и компьютерные ошибки. Так один из «боевых» компьютеров 3 июня 1980 года показал постоянно меняющиеся цифры количества ракет, запущенных Советским Союзом. Проблема возникла из-за аппаратного сбоя в микросхеме.
Обновление софта и деление на 0
В 1997 американский ракетный крейсер «Йорктаун» (CG-48), на котором были установлены 27 компьютеров (Pentium-Pro на 200 МГц), решил поделить на ноль и полностью вышел из строя.
Компьютеры работали на Windows NT — и работали они ровно так, как вы и ожидаете, узнав название оси. В то время ВМФ США старался максимально широко использовать коммерческое ПО с целью снижения стоимости военной техники. Компьютеры же позволяли автоматизировать управление кораблем без участия человека.
На компьютеры «Йорктауна» поставили новую программу, управляющую двигателями. Один из операторов, занимавшийся калибровкой клапанов топливной системы, записал в одну из ячеек расчетной таблицы нулевое значение. 21 сентября 1997 года программа запустила операцию деления на этот самый ноль, началась цепная реакция, и ошибка быстро перекинулась на другие компьютеры локальной сети. В результате отказала вся компьютерная система «Йорктауна». Потребовалось почти три часа, чтобы подключить аварийную систему управления.
Схожая проблема с нулем возникла при испытании истребителя в Израиле. Безупречно работавший самолет на автопилоте пролетел над равнинной частью, над горной частью, над долиной реки Иордан и приблизился к Мертвому морю. В этот момент произошел сбой, автопилот выключился, и пилоты посадили истребитель на ручном управлении.
После долгих разбирательств удалось выяснить, что программы автопилота при вычислении параметров управления производили деление на значение текущей высоты истребителя над уровнем океана. Соответственно, у Мертвого моря, лежащего ниже уровня океана, высота становилась нулевой, провоцируя ошибку.
В мире найдется немало историй, когда обновление софта, совершаемое с самыми благими целями, могло повести за собой множество проблем. В 2008 году атомная электростанция в штате Джорджия (США) мощностью 1,759 МВт в экстренном режиме приостановила работу на 48 часов.
Инженер компании, занимающейся технологическим обслуживанием станции, установил обновление на главный компьютер сети АЭС. Компьютер использовался для слежения за химическими данными и диагностики одной из основных систем электростанции. После установки обновлений компьютер штатно перезагрузился, стерев из памяти данные управляющих систем. Система безопасности станции восприняла потерю части данных как выброс радиоактивных веществ в системы охлаждения реактора. В результате автоматика подала сигнал тревоги и остановила все процессы на станции.
Инцидент с F-22
Двенадцать F-22 Raptor (истребитель пятого поколения, состоящий на вооружении США), стоимостью $ 140 млн за штуку, отправились в первый международный вылет в Окинаву. Все шло замечательно, пока эскадрилья не пересекла линию перемены даты, на западной стороне которой дата сдвинута на один день вперед относительно восточной. После пересечения условной линии все 12 истребителей одновременно выдали сообщение об ошибке, эквивалентной синему экрану смерти.
Самолеты потеряли доступы к данным о количестве топлива, датчикам скорости и высоты, частично нарушилась связь. В течение нескольких часов самые современные истребители Америки летели через океан совершенно беспомощными. В конце концов их удалось посадить только благодаря мастерству пилотов.
Так в чем же была ошибка? Проектировщики из Lockheed Martin даже не рассматривали вопрос о возможности пересечения линии перемены дат — им просто не пришло в голову, что где-то понадобится либо прибавлять, либо вычитать одни сутки.
Другие истории
В этой бескрайней теме есть еще несколько интересных историй. О них сложилось либо неправильное мнение, либо уже были подробные статьи на ГТ и Хабре.
Взрыв на советской газотранспортной системе в 1982 году из-за программных ошибок, заложенных ЦРУ. Эксперты категорически отрицают не только взрыв на газопроводе «Уренгой-Сургут-Челябинск» в 1982 году, но и вообще возможность возникновения такого взрыва.
Алгоритмическая ошибка привела к аварии самолета А-330 — в результате инцидента 119 пассажиров и членов экипажа получили ранения, из них 12 тяжелые.
Ракета-носитель Ariane 5 превратилась в «конфетти» 4 июня 1996 года — ошибка произошла в компоненте ПО, предназначенном для выполнения «регулировки» инерциальной платформы. Потеряно 500 млн долларов (стоимость ракеты с грузом).
Toyota: из-за корявой электроники и софта 89 человек погибли с 2000 по 2010 годы.
Источники:
habrahabr.ru/company/mailru/blog/227743
www.wikiwand.com/en/Therac-25
www.baselinemag.com/c/a/Projects-Processes/We-Did-Nothing-Wrong en.wikipedia.org/wiki/Northeast_blackout_of_2003
lps.co.nz/historical-project-failures-mars-climate-orbiter www.jpl.nasa.gov/missions/mariner-1
inosmi.ru/inrussia/20071229/238739.html
https://www.revolvy.com/main/index.php?s=USS%20Yorktown%20(CG-48)
www.defenseindustrydaily.com/f22-squadron-shot-down-by-the-international-date-line-03087
Подборка из 20 неопровержимых фактов, когда программирование или дизайн, привели к гибели людей.
Первая жертва беспилотного автомобиля
1. Элаи Херцберг попала в историю, как первый человек который погиб под колесами беспилотного автомобиля. Весной 2018 года в темное время суток, машина Uber засекла преграду, в начале подумав что мусор, потом что животное, и только за пару метров поняв что это человек.
К сожалению машина не успела затормозить, что привело к смерти человека. Тестирование проходило на модифицированном Volvo XC90, у которой была отключена система экстренного торможения, чтоб не мешать ПО Uber управлять машиной. Не может быть два короля в одном королевстве. Задача тормозить в экстренных случаях была положена на плечи водителя, который страховал автопилот. Он же в это время смотрел сериал на Netflix.
Аппарат Therac-25
2. Аппарат Therac-25 стал самым резонансным случаем в истории программирования для медицинских девайсов. В силу ошибки race condition, при быстром переключении режимов работы девайсов между магнитным и рентгеновским заслонка для рентгеновских лучей не успевала установиться.
Из-за этого у 10 пациентов диагностировали лучевую болезнь, что привело к смерти, или ампутации зараженных частей тела.
Часовые пояса и ПВО Patriot
3. 25 февраля 1991 года установка ПВО Patriot не смогла перехватить ракету пущенную со стороны сил Саддама Хусейна которая попала в барак солдат США, и что привело к 28 смертям.
Расследование показало, что 24 битные процессоры перехватчика при переводе времени совершают ошибку. в 0.013 секунды каждый час. Patriot не перегружали более 100 часов, что привело к ошибкам вычисления положения ракеты на 600 метров. Вот уж где перезагрузка бы спасла жизни.
Антон Ельчин и электронный ручник
4. В 2016 году, актер Антон Ельчин был раздавлен собственной машиной при въезде домой. Антон многим запомнился как актер игравший навигатора Чехова в полнометражках Start Trek.
Причиной смерти послужил не интуитивный дизайн ручки передач представленный Jeep в новых моделях машин. В отличии от стандартных ручек передач, где положение ручки показывает режим работы двигателя, у новых ручек — местоположение выбиралось скорее как рычажок в меню. Антон вместо паркинга, выбрал нейтральное положение, от чего машина скатилась и задавила не внимательного хозяина.
Распределения маршрутов скорой помощи
5. В 1992 году ошибки системы распределения маршрутов в Лондонской скорой помощи привели к смерти 30-45 человек ( разброс большой, потому что не ясно, смогла бы скорая спасти человека ). Все произошло, когда в Лондоне решили заменить людей операторов на компьютерную систему.
В результате система была введена в эксплуатацию без нагрузочного тестирования и с 81! известным багом. Добавьте к этому еще и то, что интегратор решил сэкономить, и купил дешевое оборудование, которое сломалось через пару часов после активного пользования системой. Хаос был настолько безумным, что бывали случаи, когда человек не дождавшись скорой умирал, его увозили в морг, и только тогда приезжала скорая.
АЭС в Пенсильвании
6. 1979 год, Пенсильвания чуть не стала местом еще одного Чернобыля, и стала самым большим прецедентом в истории атомной энергетики в США. Внешний дизайн датчиков системы был настолько плохо продуман, и был расположен по кругу комнаты, что смена которая следила за состоянием не заметила всех показателей, который указывали на то, что есть утечка, и значение температуры реактора приблизилось к критическому значению. Ситуацию спасла следующая смена, которая выходила на вахту, и начинала считывать показания датчиков. Чтоб считать показатели, надо было пройти по круглой комнате, и отдельно смотреть на каждый показатель во многих разных местах. Утечку нашли, реактор отключили, но еще 14 лет проводили очистные работы на территории. Это стало поводом огромных анти-атомных митингов, и очень поменяло общественное мнение про «мирный атом»
Неудачный дизайн приборной панели
7. 1992 год, самолет под управлением опытной команды потерпел крушение возле Страсбурга. 87 из 92 человек погибли. Анализ черного ящика показал, что опытные пилоты перепутали настройки авто-пилота: угол и скорость снижения. Дизайнер приборной панели очень стремился сэкономить место, и расположил эти два индикатора друг возле друга. При том, что даже не смотря на то, что единицы измерения совершенно разные ( пилоты хотели задать 3.3 градуса спуска а задали 3300 фунтов в минуту) Но для экономии места, оба показателя показывались как 3.3. Кому в голову прийдет показывать 3300 как 33?
Станислав Петров спас мир сделав НИЧЕГО
8. Станислав Петров, в 1983 году спас мир сделав НИЧЕГО. Станислав Петров во время разгара холодной войны между США и СССР служил в штабе анти-ракетной обороны. Так как две страны обладали атомным оружием, между ними была заключена доктрина полного уничтожения, что значило, что только одна ракеты полетит со стороны одной страны в другую — другая может ответить как хочет. Грубо говоря — начало третьей мировой.
Станислав Петров в 1983 году как раз наблюдал за системой раннего обнаружения ракетного удара. И как же он удивился, когда увидел на экране 5 ракет, которые летели со стороны США в сторону СССР. По всем правилам Петров должен был отдать указания полномасштабного ракетного удара по США. Но, как она дальше сказал: «У него была чуйка». Он решил что нападать на СССР всего лишь 5 ракетами — не логично, и решил подождать.
Внезапно ракеты пропали, он сделал рапорт. Расследование определило, что эти 5 ракет — edge case того, как лучи солнца падают на спутник на орбите Молния. Таким образом, Петров, не сделав ничего подарил нам с вами мир, в котором мы живем. Хотя злые языки говорят что он был в стельку пьян в этом время, что не отменяет того, что даже пьяным ты можешь спасти миллиарды.
Дизайн медецинской системы
9. Пациентка Jenny (имя заменено в репортах) погибла от обезвоживания после химиотерапии. Причина оказалась до ужаса идиотской: дизайн медицинской системы был настолько плох, что опытные медсестры просто не заметили пункта который говорил что для этого пациента необходимо вводить дополнительные элементы сразу после операции.
Неудачный дизайн упаковки
10. Шестеро велосипедистов сошли с дистанции гонки в Осло в 2014-ом году. Обнаружилось, что велосипедисты упились жидкостью для мытья пола, решив что это энергетик. Дизайн упаковки — тоже дизайн.
Программная ошибка автопилота
11. 1994 год, борта авиакомпании China Arilines потерпел крушение, унеся жизни более чем 250 человек. При приземлении второй пилот случайно включит автопилот, который начал вносить коррективы в действия пилотов. При снижении пилоты заметили это, и смогли выключить автопилот, но к сожалений рассинхронизация действий людей и авто-пилота привело к крушению. При расследовании так же была найдена ошибка, патч для которой уже был написан, и борт который потерпел крушение был запланирован на апдейт системы сразу после окончания рейса, который к сожалению так и не закончился удачно.
Потеря 460 миллионов долларов за 45 минут
12. Knight Capital в свое время перепутали деплои, и вместо тестового енва, задеплоили новую версию на продакшен. Тратя, как система думала, виртуальные доллары — Knight потеряли 460 миллионов долларов за 45 минут. Скидывались на спасение Knight всем селом.
Ошибка софта по контролю топлива в двигателях
13. 2015й год грузовой самолет испанских военно воздушных сил потерпел крушение около Севильи. Airbus после этого случая отозвали все самолеты A400, на проверку, потому как авария были причинена ошибкой ПО, что унесло жизни 4х человек. Причина заключалась в новой версии софта по контролю топлива в двигателях. Система топливо подавала, но очень медленно, от чего 3 их 4х двигателей отключились.
Метрическая и имперская системы
14. 1998 год, один из спутников Nasa отправленный на Марс, достигнув орбиты красной планеты взорвался. Проблема — ошибка в двух модулях ПО спутника: один ждал данные в метрической системе, а другой отдавал в имперской:) Не додебажили на 327 лямов.
Системная ошибка F-14
15. Один из самолетов F-14 разбился в следствии того, что в системе случилась системная ошибка, но программист не обернул ее в catch, что привело к полному отключению бортового компьютера. Пилот катапультировался, но самолет конечно же не спасли.
Взрыв газа в СССР
16. Случай кибервойны, или взрыв который было видно из космоса. В 1982 ЦРУ внедрило шпиона в Канадскую фирму по разработка софта для газопроводных систем, потому как знали что этот софт будет использован СССР. И они использовали. Программист-шпион написал такие методы, что в 1982м году газопроводная труба взорвалась так сильно, что взрыв можно было наблюдать из космоса. К счастью никто, кроме оленей не пострадал.
Не та версия ПО
17. Ариана 5, разработкой которой стоила около 8! миллиардов долларов, должна была вывести на орбиту несколько спутников и другого оборудования. Полет ракеты завершился через 4 секунды после взлета. Она упала. Причиной послужило то, что один из модулей системы попытался сконвертировать 64 битное число в 16-битное. Оно оказалось больше, чем влазило в память, и модель завалился! Но ведь есть дублирующий модуль, которому было передано управление. На котором была та же версия ПО. Которая попытался сделать то же самое.
Ошибка системы «Свой — Чужой»
18. 1982й год, миноносец морских сил Великобритании, был поражен ракетой выпущенной с самолета принадлежавшего Аргентине. Противоракетная система не сработала, погибло 28 человек. Во время постройки, произошел взрыв, и погибло два строителя. Поврежденная часть корабля была заменена на часть с идентичного аргентинского корабля. Когда система обнаружила ракету, она провела проверку на свой-чужой. А так как часть корабля была аргентинская, ракета была определена как своя После чего противоракетная оборона не сработала, потому как ожидало что ракета пролетит. Но нет.
Ошибки в системе управления двигателями
19. 1994 год, вертолет модели Chinook разбился, даже не смотря на управление очень опытным пилотом, что привело к гибели 29 человек. Расследование очень долго пыталось скинуть всю вину на пилота, но в результате были найдены ошибки в системе управления двигателями, а так же проблемы работы датчика высоты с одновременно включенным радио вертолета. А мне не верили что в Samsung компанс со спотифай не работает:)
Смены часового пояса и самолет F-18
20. Новейший на то время самолет F-18 превращался в тыкву, когда перескал зону смены часового пояса меняющий день ( к примеру полет с Гаваев в Японию ). Система не расчитывала что может попасть в прошлое, потому 127 миллонный самолет мог упасть в любой момент. Благо помогал ресет
Автор текста: ©Я есть XSLT
Изображения: — интернет
published on
caprizulka.ru according to the materials
chert-poberi.ru
#подборки
- 19 июл 2021
-
0
Иногда ошибки в программах стоят миллионов долларов и даже уносят жизни людей. Расскажем о самых дорогих багах в истории IT.
Иллюстрация: Meery Mary для Skillbox Media
Пишет об истории IT, разработке и советской кибернетике. Знает Python, JavaScript и немного C++, но предпочитает писать на русском.
Закон Мёрфи гласит: если что-то может пойти не так, это обязательно произойдёт. Яркий пример — фильм Стэнли Кубрика «2001: Космическая одиссея». По сюжету военные зашили в бортовой компьютер HAL 9000 жёсткую инструкцию, которая должна была скрывать от астронавтов истинные цели экспедиции. В результате искусственный интеллект перебил почти всех членов команды и сорвал операцию.
Но такие сюжеты встречаются не только в кино — в реальности дорогие компьютеры не раз сходили с ума и даже убивали людей. Расскажем о самых громких ошибках в ПО.
Этот баг изрядно потрепал нервы владельцам яблочных смартфонов, хотя всё закончилось хорошо и устройства удалось восстановить.
В 2016 году резвые пользователи reddit.com пронюхали фичу: если в 64-битной версии iOS установить время на 00:00:00 часов 1 января 1970 года, а потом перезагрузить смартфон, он больше не включится. Устройство буквально превращалось в кирпич: пользователь видел только логотип Apple, а повторная перезагрузка не помогала.
Шутка разлетелась по интернету, и даже незнакомые с Reddit пользователи стали экспериментировать. Кто-то разыгрывал знакомых владельцев айфонов и айпадов.
Во «ВКонтакте» и на форумах моментально появились «добрые» розыгрыши:
Скриншот: МДКОпытным путём всё-таки удалось восстановить смартфоны: надо было подождать, пока они полностью разрядятся, или отключить аккумулятор вручную. После этого система запускалась с заводскими настройками.
Причина «окирпичивания» яблочной техники — UNIX-время и некачественное тестирование. Время в iOS отсчитывается от 1 января 1970 года — это условный ноль в UNIX-подобных системах.
В зависимости от часового пояса устройства добавляют смещение — прибавляют или отнимают необходимое количество часов. По одной из версий, когда пользователи из регионов с отрицательным смещением устанавливали злосчастную дату, время «уходило в минус». Например, в Нью-Йорке iPhone показывал бы −4 часа.
В итоге iOS не понимал, что делать с отрицательным временем, а инструкции, которые используют время, выкидывали белый флаг и просто-напросто ломались.
Но этой версии противоречат несколько фактов:
- На баг жаловались и в регионах с положительным смещением времени.
- Проблема вскрылась только на 64-битной версии.
- Неужели разработчики Apple могли не поставить элементарную проверку на отрицательные значения? WTF?!
По другой версии, операционная система «подавилась» слишком большим числом. Главная программа использует переменную времени при настройке окружения и действительно вычитает из неё какие-то константы.
И когда пользователи устанавливают время в ноль, оно не попадает в отрицательный диапазон, а становится равным 18 446 744 073 709 551 616 — это максимальное целое положительное число в 64-битной операционной системе.
В индекс Доу Джонса заложена стоимость акций 30 самых больших американских компаний — например, Apple, Coca-Cola и Intel. Ещё есть индекс S&P 500 — в него входит 505 компаний. По этим показателям оценивают «здоровье» экономики США: индексы «зеленеют» — экономика растёт, «краснеют» — экономика падает.
В октябре 1987 года индекс Доу Джонса упал на 22,6%, а S&P 500 — на 20,5%. Это вызвало эффект лавины на мировом фондовом рынке. Вслед за США обвалились Гонконг (на 46%), Австралия (на 42%), Канада (на 23%) и другие развитые экономики. Событие стало финансовой трагедией, а вину опять повесили на разработчиков.
Эксперты всё ещё спорят об истинных причинах падения, но, по официальной версии, к кризису привела ошибка программного трейдинга. Специальная программа автоматически заключала сделки, чтобы инвесторам не приходилось постоянно следить за котировками и проводить все операции вручную. Машины ориентировались на движение рынка: индексы растут — закупаем, падают — продаём. Алгоритмами пользовались только крупные инвесторы вроде пенсионных фондов и центральных банков, поэтому объёмы программного трейдинга были велики.
Когда рынок немного качнуло, машины одновременно стали продавать акции на миллионы долларов. Но покупать их было некому, а потому программа ещё больше снижала цену. Случилось настоящее восстание машин: за один день американский рынок акций потерял около 500 млрд долларов. Вслед за американцами паника перекинулась и на другие страны — их экономики тоже просели на десятки процентов.
«Чёрный понедельник» ударил по развитым экономикам даже сильнее Великой депрессии. Зато государства и финансовые организации разработали правила для защиты частных инвесторов. Теперь биржи прекращают торги при падении S&P 500 на 7%, 13% и 20%, чтобы дать инвесторам принять взвешенное решение.
P. S. Объяснения рыночных воротил звучат красиво и убедительно, но мы-то с вами знаем, что на самом деле виноваты не разработчики, а рептилоиды с иллюминатами
Хотя финансовые игроки многому научились в 1987 году, история с «взбесившейся» программой повторилась спустя 25 лет.
Knight Capital была одной из крупнейших финансовых компаний в мире — с её помощью на фондовом рынке торговали страховщики, пенсионные фонды и банки. Через компанию проходила каждая шестая ценная бумага с бирж NYSE и NASDAQ. К тому же Knight Capital торговала собственными акциями и неплохо росла из года в год.
В начале 2010-х стала популярной высокочастотная торговля с помощью роботов. Они совершали сотни и тысячи сделок в секунду по заранее составленному алгоритму и помогали неплохо зарабатывать на минимальных скачках цены. Человек просто физически не мог выставлять столько ордеров в такие короткие сроки.
В 2012 году Knight Capital запустила своего робота — и сразу же всё пошло наперекосяк. Из-за ошибки в коде алгоритм за сорок минут умудрился провести более 2 млн сделок — а это недельная норма для рынка. Менеджеры компании смотрели и ничего не могли сделать: у программы просто не было «выключателя».
За сорок минут робот успел потратить полмиллиарда долларов. Правда, из них только 365 млн принадлежало Knight Capital, а остальные деньги были заёмными. Вы удивитесь, но банки и фонды скинулись и спасли компанию от банкротства. Паники на фондовом рынке тоже не случилось — помогли защитные механизмы, которые придумали после «чёрного понедельника».
Первый полёт самой надёжной европейской ракеты Ariane 5 был неудачным. Гордость космической программы взорвалась через 40 секунд после старта из-за ошибки в управляющей программе. Этот баг признан самым дорогим в истории.
В течение 10 лет 10 стран Евросоюза потратили на проект 7 млрд долларов, половину из которых дала Франция. Ракета должна была вывести на геостационарную орбиту спутники для изучения магнитного поля Земли.
4 июня 1996 года миллионы европейцев в прямом эфире наблюдали, как в небе буквально сгорают их налоги. На высоте 4 тысяч метров Ariane 5 отклонился от прямой траектории и самоуничтожился. Оказывается, разработчики скопировали код из управляющей программы предыдущей модели ракеты, которая успешно взлетала больше сотни раз. Только они не учли, что Ariane 4 летел по другой траектории и с другой горизонтальной скоростью.
Скопированный программный модуль неверно прочитал ситуацию и преобразовал 64-битное значение в 16-битное безо всякой проверки. Да, программа перехватила исключение — а вот отреагировала на него неадекватно и отправила на бортовой компьютер сигнал аварийного завершения. При этом с технической точки зрения полёт был абсолютно нормальным.
Евросоюз потерял год исследований и более 500 млн долларов. После аварии страны-участники провели открытое расследование и нашли все «золотые» баги. А спутники быстренько отправили в космос на российском «Союзе». Злополучный код для Ariane переписали на Ada, и ракета успешно стартовала в 1997 году.
Иногда баги приводят к смерти. В Национальном институте рака в Панаме из-за компьютерной ошибки погибли восемь человек и как минимум двадцать получили лучевую болезнь.
Врачи управляли камерой для облучения с помощью специальной программы: устанавливали дозу радиации, длительность терапии и положение четырёх защитных плит, которые укрывали здоровые ткани пациентов. Радиолог попросил добавить пятую плиту для дополнительной защиты, но программа разрешала ставить не больше четырёх. Тогда операторы придумали хитрость: фактически установить две плиты, а программе показать, что она всего лишь одна.
Позже выяснилось, что программа рассчитывала длительность терапии исходя из количества защитных блоков. Она позволяла вводить параметры, но итоговое время устанавливала сама. Поэтому после изменения настроек пациенты облучались в два раза дольше и у всех появились признаки лучевой болезни. Правда, врачи ещё несколько месяцев не обращали внимания на жалобы.
За это время через аппарат прошло 28 человек. Восемь из них скончались почти сразу, а остальные умерли в течение нескольких лет от различных осложнений. Врачей приговорили к тюремным срокам за убийство пациентов и нанесение тяжкого вреда здоровью.
Идеальных программ не бывает, и все сценарии предугадать невозможно. Хакеры каждый день находят уязвимости в приложениях и устройствах, «ломают» небезопасные сайты. Но ошибки можно свести к минимуму, если правильно тестировать приложения и не вносить в них правки или «рацпредложения» по своему усмотрению, без попытки проверить последствия.
Научитесь: Профессия Инженер по тестированию
Узнать больше