Последствия ошибки в программе
Обновлено: 02.07.2024
Когда-то я заинтересовался вопросом ответственности в IT. К финансовым потерям мы уже привыкли. Не проданный продукт, ошибка в расчете и недовольный клиент — это те последствия, о которых мы в курсе. Но что, если наши ошибки приведут к непоправимым последствиям. Я несколько раз читал лекции на тему ошибок в программировании, которые привели к человеческим жертвам.
1. Элаи Херцберг попала в историю как первый человек, который погиб под колесами беспилотного автомобиля. Весной 2018 года в темное время суток машина Uber засекла преграду. В начале она подумала, что это мусор, потом — что животное, и только за пару метров поняла, что это человек.
К сожалению, машина не успела затормозить, что привело к смерти человека. Тестирование проходило на модифицированной Volvo XC90, у которой была отключена система экстренного торможения, чтобы не мешать ПО Uber управлять машиной. Не может быть два короля в одном королевстве. Задача тормозить в экстренных случаях была возложена на плечи водителя, который страховал автопилот. Он же в это время смотрел Netflix.
2. Аппарат Therac-25 стал самым резонансным случаем в истории программирования для медицинских девайсов. В силу ошибки race condition, при быстром переключении между магнитным и рентгеновским режимами работы девайса заслонка для рентгеновских лучей не успевала установиться. Из-за этого у 10 пациентов диагностировали лучевую болезнь, что привело к смерти или ампутации пораженных частей тела.
3. 25 февраля 1991 года установка ПВО Patriot не смогла перехватить ракету, пущенную со стороны сил Саддама Хусейна. Ракета попала в барак солдат США, что привело к 28 смертям. Расследование показало, что 24-битные процессоры перехватчика при переводе времени совершают ошибку в 0.013 секунды каждый час. Patriot не перезагружали более 100 часов, что привело к ошибкам вычисления положения ракеты на 600 метров. Вот уж где перезагрузка спасла бы жизни.
В отличие от стандартных ручек передач, где положение ручки показывает режим работы двигателя, у новых ручек местоположение выбиралось скорее как рычажок в меню. Антон вместо паркинга выбрал нейтральное положение, от чего машина скатилась и задавила невнимательного хозяина.
5. В 1992 году ошибки системы распределения маршрутов в Лондонской скорой помощи привели к смерти 30-45 человек (разброс большой, потому что не ясно, смогла бы скорая спасти того или иного человека). Все произошло, когда в Лондоне решили заменить людей операторов на компьютерную систему.
В результате система была введена в эксплуатацию без нагрузочного тестирования и с 81! известным багом. Добавьте к этому еще и то, что интегратор решил сэкономить и купил дешевое оборудование, которое сломалось через пару часов после активного пользования системой. Хаос был настолько безумным, что бывали случаи, когда человек, не дождавшись скорой, умирал, его увозили в морг, и только тогда приезжала скорая.
6. 1979 год. Пенсильвания чуть не стала еще одним Чернобылем, и это самый большой прецедент в истории атомной энергетики США. Внешний дизайн датчиков системы там был очень плохо продуман и был расположен по кругу комнаты. Смена, которая следила за состоянием, не заметила всех показателей, которые указывали на то, что есть утечка, и значение температуры реактора приблизилось к критическому значению. Ситуацию спасла следующая смена, которая выходила на вахту и начинала считывать показания датчиков.
7. 1992 год, самолет под управлением опытной команды потерпел крушение возле Страсбурга. 87 из 92 человек погибли. Анализ черного ящика показал, что опытные пилоты перепутали настройки автопилота: угол и скорость снижения.
Дизайнер приборной панели очень стремился сэкономить место и расположил эти два индикатора друг возле друга. При том, что даже не смотря на то, что единицы измерения совершенно разные (пилоты хотели задать 3.3 градуса спуска, а задали 3300 футов в минуту). Но для экономии места оба показателя показывались как 3.3. Кому в голову придет показывать 3300 как 33?
8. Моя любимая история. Станислав Петров в 1983 году спас мир, не сделав ничего. Во время разгара холодной войны между США и СССР он служил в штабе антиракетной обороны. Так как две страны обладали атомным оружием, между ними была заключена доктрина взаимного гарантированного уничтожения. Это значило, что как только одна ракета полетит со стороны одной страны в другую, другая может ответить, как хочет. Грубо говоря — начало третьей мировой.
Расследование определило, что эти 5 ракет — edge case того, как лучи солнца падают на спутник на орбите Молния. Таким образом, Петров, не сделав ничего, подарил нам с вами мир, в котором мы живем. Хотя злые языки говорят, что он тогда был в стельку пьян. Но это не отменяет того, что даже будучи пьяным, ты можешь спасти миллиарды людей.
9. Пациентка Jenny (имя заменено в отчетах) погибла от обезвоживания после химиотерапии. Причина оказалась до ужаса идиотской. Дизайн медицинской системы был настолько плох, что опытные медсестры просто не заметили пункта, который говорил, что для этого пациента необходимо вводить дополнительные элементы сразу после операции.
10. Шестеро велосипедистов сошли с дистанции гонки в Осло в 2014 году. Оказалось, что велосипедисты выпили жидкость для мытья пола, решив, что это энергетик. Дизайн упаковки тоже имеет значение.
11. Два солдата армии США погибли во время учений артиллерийских подразделений. Солдаты понадеялись на данные тактической системы, но не знали, что, если не задать высоту цели — система считает ее равной 0. Вот тебе и рокетджамп.
12. 1994 год, борт авиакомпании China Airlines потерпел крушение и унес жизни более чем 250 человек. При приземлении второй пилот случайно включил автопилот, который начал вносить коррективы в действия пилотов. При снижении пилоты заметили это и смогли выключить автопилот, но, к сожалению, рассинхронизация действий людей и автопилота привела к крушению. При расследовании также была найдена ошибка, патч для которой уже был написан. Борт, потерпевший крушение, был запланирован на апдейт системы сразу после окончания рейса, который, к сожалению, так и не закончился удачно.
13. Knight Capital в свое время перепутали деплои и вместо тестового енва задеплоили новую версию на продакшен. Система думала, что тратятся виртуальные доллары, а на самом деле Knight потеряла 460 миллионов долларов за 45 минут. Скидывались на спасение Knight всем селом.
14. 2015 год, грузовой самолет испанских военно-воздушных сил потерпел крушение около Севильи. Авария была вызвана ошибкой ПО и унесла жизни 4 человек. Airbus после этого случая отозвала все самолеты A400 на проверку. Проблема заключалась в новой версии софта по контролю топлива в двигателях. Система подавала топливо, но очень медленно, от чего 3 из 4 двигателей отключились.
15. 1998 год, один из спутников Nasa, отправленный на Марс, достиг орбиты красной планеты и взорвался. Была ошибка в двух модулях ПО спутника: один ждал данные в метрической системе, а другой отдавал в имперской :) Не додебажили на 327 лямов.
16. Как рассказывает SIG, один из самолетов F-14 разбился вследствие того, что случилась системная ошибка, но программист не обернул ее в catch. Это привело к полному отключению бортового компьютера. Пилот катапультировался, но самолет, конечно же, не спасли.
17. Кибервойна, или взрыв, который было видно из космоса. В 1982 ЦРУ внедрило шпиона в канадскую фирму по разработке софта для газопроводных систем, потому как знало, что этот софт будет использован СССР. Программист-шпион написал методы, из-за которых в 1982 году газопроводная труба взорвалась так сильно, что взрыв можно было наблюдать из космоса. К счастью, никто кроме оленей не пострадал.
18. Новая, в 1996 году, ракета Ariane 5, разработка которой стоила около 8! миллиардов долларов, должна была вывести на орбиту несколько спутников и другое оборудование. Полет ракеты завершился через 4 секунды после взлета. Она взорвалась. Один из модулей системы попытался сконвертировать 64-битное число в 16-битное. Оно оказалось больше, чем влезало в память, и модуль завалился. Но ведь есть дублирующий модуль, которому было передано управление! На нем была та же версия ПО, которая попытался сделать то же самое. Результат — самоликвидация и горящие осколки на площади в 12 км2 на потеху зрителям. Во время расследования инцидента была проведена симуляция полета Ariane 5 с использованием другой инерциальной платформы — баг воспроизвели. Программа сбойнула точь-в-точь как в случае с реальной ракетой.
С одной стороны, причиной сбоя можно назвать оптимизацию кода, который не проверял допустимые значения для той конкретной переменной — программисты не предполагали, что число, описывающее горизонтальную скорость, может быть настолько великим.
С другой стороны, провинились и тестировщики — хоть и были произведены сотни тестов и тысячи последующих корректировок, никто не сделал полноценного анализа опорной инерциальной системы. Проблема была в том, что на Ariane 5, чья траектория полета сильно отличалась от Ariane 4, поставили навигационный софт от Ariane 4. Тот случай, когда железо проапгрейдили, а софтину обновить забыли.
Практика не устает доказывать, что в любом ПО самая главная уязвимость — человеческий фактор. И неважно, появился ли баг из-за нехватки квалифицированности специалиста, выжил после долгих часов дебага в поисках ошибки, или считался хитро замаскировавшейся фичей. Среди некоторых разработчиков даже укрепилось мнение, что баги в принципе существуют всегда и везде. Но если ошибки абстрактны и сложно воспроизводимы в реальных условиях, то проблема не является критичной.
В идеальной ситуации баги исправляют все и сразу. Но в жизни всегда есть куча задач, отодвигающих полный и бесповоротный багфикс (новый функционал, срочные хотфиксы, расставленные приоритеты при исправлении багов). Это значит, что в первую очередь находятся и исправляются очевидные и явные проблемы. Остальные тихо ждут своего часа, превращаясь в бомбы замедленного действия. Иногда ошибки приводят не только к неприятностям в жизни рядового разработчика, но и вызывают настоящие катастрофы. Сегодня у нас подборка и объяснение самых кошмарных багов в истории разработки ПО.
Облучение и радиация
Знаменитый случай гибели нескольких человек, получивших смертельную дозу облучения во время сеансов радиационной терапии с применением медицинского ускорителя Therac-25. Ускорители подобного типа используют электроны для создания лучей высокой энергии, высокоточно уничтожающих опухоли. Но некоторые пациенты получили дозы не в несколько сотен рад, как предписывало лечение, а в 20 000 рад; доза в 1000 рад для человека считается несовместимой с жизнью, причем смерть может наступить сразу после облучения.
Всего один программист создал все ПО, используемое в аппаратах Therac — а это 20 тысяч инструкций, написанных на ассемблере. И при этом во всех Therac встречался один тот же пакет библиотек, содержащий ошибки.
Ускоритель Therac-25, ставший третьим в серии успешных аппаратов лучевой терапии, мог работать с рентгеновскими лучами до 25 МэВ. Несколько лет в середине 80-х аппараты 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
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
Самолеты потеряли доступы к данным о количестве топлива, датчикам скорости и высоты, частично нарушилась связь. В течение нескольких часов самые современные истребители Америки летели через океан совершенно беспомощными. В конце концов их удалось посадить только благодаря мастерству пилотов.
Так в чем же была ошибка? Проектировщики из Lockheed Martin даже не рассматривали вопрос о возможности пересечения линии перемены дат — им просто не пришло в голову, что где-то понадобится либо прибавлять, либо вычитать одни сутки.
Другие истории
В этой бескрайней теме есть еще несколько интересных историй. О них сложилось либо неправильное мнение, либо уже были подробные статьи на ГТ и Хабре.
Взрыв на советской газотранспортной системе в 1982 году из-за программных ошибок, заложенных ЦРУ. Эксперты категорически отрицают не только взрыв на газопроводе «Уренгой-Сургут-Челябинск» в 1982 году, но и вообще возможность возникновения такого взрыва.
Алгоритмическая ошибка привела к аварии самолета А-330 — в результате инцидента 119 пассажиров и членов экипажа получили ранения, из них 12 тяжелые.
Ракета-носитель Ariane 5 превратилась в «конфетти» 4 июня 1996 года — ошибка произошла в компоненте ПО, предназначенном для выполнения «регулировки» инерциальной платформы. Потеряно 500 млн долларов (стоимость ракеты с грузом).
Toyota: из-за корявой электроники и софта 89 человек погибли с 2000 по 2010 годы.
Почему бывает так, что программы работают неправильно? Все очень просто – они создаются и используются людьми. Если пользователь допустит ошибку, то это может привести к проблеме в работе программы – она используется неправильно, значит, может повести себя не так, как ожидалось.
Ошибка (error) – это действие человека, которое порождает неправильный результат.
Однако программы разрабатываются и создаются людьми, которые также могут допускать (и допускают) ошибки. Это значит, что недостатки есть и в самом программном обеспечении. Они называются дефектами или багами (оба обозначения равносильны). Здесь важно помнить, что программное обеспечение – нечто большее, чем просто код.
Дефект, Баг (Defect, Bug) – недостаток компонента или системы, который может привести к отказу определенной функциональности. Дефект, обнаруженный во время исполнения программы, может вызвать отказ отдельного компонента или всей системы.
При исполнении кода программы дефекты, заложенные еще во время его написания, могут проявиться: программа может не делать того, что должна или наоборот делать то, чего не должна – происходит сбой.
Сбой (failure) – несоответствие фактического результата (actual result) работы компонента или системы ожидаемому результату (expected result).
Сбой в работе программы может являться индикатором наличия в ней дефекта.
Таким образом, баг существует при одновременном выполнении трех условий:
- известен ожидаемый результат;
- известен фактический результат;
- фактический результат отличается от ожидаемого результата.
Важно понимать, что не все баги становятся причиной сбоев – некоторые из них могут никак себя не проявлять и оставаться незамеченными (или проявляться только при очень специфических обстоятельствах).
Причиной сбоев могут быть не только дефекты, но также и условия окружающей среды: например, радиация, электромагнитные поля или загрязнение также могут влиять на работу как программного, так и аппаратного обеспечения.
Всего существует несколько источников дефектов и, соответственно, сбоев:
- ошибки в спецификации, дизайне или реализации программной системы;
- ошибки использования системы;
- неблагоприятные условия окружающей среды;
- умышленное причинение вреда;
- потенциальные последствия предыдущих ошибок, условий или умышленных действий.
Дефекты могут возникать на разных уровнях, и от того, будут ли они исправлены и когда, будет напрямую зависеть качество системы.
Качество (Quality) – степень, в которой совокупность присущих характеристик соответствует требованиям.
Качество программного обеспечения (Software Quality) – это совокупность характеристик программного обеспечения, отражающих его способность удовлетворять установленные и предполагаемые потребности.
Требование (Requirement) – потребность или ожидание, которое установлено. Обычно предполагается или является обязательным.
В первом случае все было сделано правильно и мы получили продукт, полностью соответствующий ожиданиям заказчика и удовлетворяющий критериям качества.
В четвертом случае дефекты были заложены еще на этапе формирования требований; вся дальнейшая разработка и даже тестирование пошли по изначально неправильному пути. Во время тестирования мы не найдем багов – программа пройдет все тесты, но может быть забракована заказчиком.
Условно можно выделить пять причин появления дефектов в программном коде.
4 июня 1996 года Европейское космическое агентство запустило ракету Ariane 5. Увы, ошибка в программном обеспечении модуля управления привела к самоуничтожению ракеты через 37 секунд после взлета.
2. Деньги: Knight Capital
В 2013 году сбой программы почти довел инвестиционную компанию Knight Capital до банкротства. Фирма потеряла полмиллиарда долларов за полчаса из-за того, что компьютеры стали покупать и продавать миллионы акций безо всякого человеческого контроля. В итоге цены на акции компании упали на 75% за два дня.
3. Медицина: Лучевая терапия
В 1980-е годы пять пациентов умерли после получения большой дозы рентгеновского излучения в результате программной ошибки блока управления установкой лучевой терапии Therac-25. Как полагают эксперты, сбой был вызван ошибкой в коде, в результате которой программа пыталась выполнять одну и ту же команду многократно.
4. Интернет: Amazon
Отключение серверов Amazon летом 2013 года лишило многих людей их данных, хранившихся в «облаке». Авария, изначально вызванная сильной грозой, усугубилась внезапно обнаруженными программными ошибками, в результате чего произошел каскадный сбой.
5. Инфраструктура: «блэкаут» на северо-востоке США
Массовое отключение электроэнергии в 2003 году стало результатом локальной аварии, которая осталась незамеченной из-за ошибки программного обеспечения для мониторинга работы оборудования General Electric Energy, и также привела к масштабному каскадному сбою.
6. Транспорт: American Airlines
В 2014 году программная ошибка «приземлила» весь воздушный флот авиакомпании American Airlines. Сбой в системе бронирования билетов возник после объединения двух существующих систем в результате слияния нескольких авиакомпаний. Проблемы, вероятно, возникли вследствие неудачной попытки объединить платформы, написанные на разных языках программирования.
Читайте также: