Большинство багов в программном обеспечении причиняют маленькие неудобства, которые пользователь может обойти, но были и такие случаи, когда обычная ошибка влияла на миллионы людей в том или ином плане, или даже влекла за собой травму или смерть.
Программное обеспечение пишут люди, поэтому в каждой программе есть свои баги, или «недокументированный функционал», как это назвал бы маркетолог. Для тех, кто не знает, что такое баги – это когда программа делает что-то, что не должна делать или не делает то, что должна делать. Баги могут возникать из-за неправильного проектирования, не полного понимания проблемы или просто из-за человеческой ошибки – примерно, как опечатка в книге. Проблема заключается в том, что книгу читает человек, который может догадаться о том, что именно имел в виду автор, а машинный код исполняется компьютерами, которые способны делать только то, что им сказано.
Ниже представлены десять примеров тех случаев, когда последствия багов были огромными в том или ином плане:
10. Терак-25 (Therac-25)
Терак-25 – аппарат для лучевой терапии, используемый чаще всего для лечения онкологических больных. У аппарата было два режима работы. В первом режиме аппарат направлял луч электронов прямо на пациента маленькими дозами и непродолжительное время. Во втором режиме аппарат направлял интенсивный луч электронов на металлическую «цель», что позволяло фактически преобразовать луч в рентгеновское излучение, которое затем достигало пациента.
В предыдущих моделях Терака для второго режима работы были физические предохранители, которые обеспечивали наличие металлического отражателя, без которого лучи высокой энергии могли бы попасть по ошибке прямо на пациента. В новой модели физические предохранители были заменены «предохранителями» в программном обеспечении.
К сожалению, в программе был баг: иногда во время автоматических проверок на безопасность случалось «арифметическое переполнение». При таком баге система использует в вычислениях слишком большое число, которое она не может обработать. Если в этот момент оператор настраивал аппарат, предохранители не срабатывали, и металлическая пластина не помещалась на нужное место. В результате на пациента попадали лучи, интенсивность которых была в 100 раз больше, чем нужная. В шести случаях пациенты получили передозировку радиацией, 4 из этих случаев закончились смертью пострадавшего.
9. Глюк «Заражённая кровь» (Corrupted-Blood) в World of Warcraft
World of Warcraft – очень популярная онлайн игра, созданная компанией «Blizzard Entertainment». После очередного обновления, вышедшего 13 Сентября 2005 года, в игре появился странный глюк, который повлёк массовые смерти (виртуальные). Во время обновления в игру ввели нового вражеского персонажа Хаккар (Hakkar), у которого была возможность накладывать на игроков заклинание «Заражённая кровь», от которой у игроков постепенно уменьшалось здоровье. Эта «болезнь» могла передаваться от игрока игроку, как и в реальной жизни, и могла убить любого заражённого персонажа. Этот эффект по задумке должен был действовать только на территории, где жил Хаккар.
Разработчики не предусмотрели одно: инфицированные игроки могли телепортироваться в другие локации игры и передавать это заболевание другим игрокам – что и произошло. Сколько именно персонажей погибло от этой болезни неизвестно, но целые игровые города опустели – повсюду на улицах городов валялись трупы игровых персонажей. К счастью, смерть персонажа в World of Warcraft неокончательна, и вскоре «чума» закончилась – администраторы игры перезагрузили сервера и применили программную «заплатку», которая исправила баг. Интересно, что реакция игроков на заражение и заражённых была похожа на реакцию людей в подобных ситуациях в реальной жизни.
8. Отсутствие электричества в Северной Америке
Отключение электричества в 2003 году на северо-востоке США и в Онтарио, Канада повлияло на 55 миллионов людей и стало одной из самых крупных аварий в энергосистемах за всю историю. Авария началась в момент, когда электростанция на южном берегу озера Эри (Erie) штате Огайо прекратила свою работу по причине слишком высокого потребления электроэнергии, что повлекло за собой увеличение нагрузки на остальную электрическую сеть. Когда линии электропередач перегружены, они нагреваются, из-за чего происходит тепловое расширение проводов. Несколько линий электропередач провисли настолько, что задели деревья, из-за чего произошло короткое замыкание, в результате которого нагрузка на электросеть возросла. Все эти факторы повлекли за собой каскадный эффект, из-за которого мощность энергосистемы упала до 20% от нормального значения.
Причина аварии никак не связана с багом в программном обеспечении, но её можно было бы предотвратить, если бы не баг в программе, отвечающей за систему оповещения в центре управления энергосистемами. Две части системы «соревновались» за один ресурс и не могли разрешить конфликт (ошибка проектирования под названием «состояние гонки»), из-за этого система оповещения зависла и перестала обрабатывать сигналы тревоги. К сожалению, остановка системы оповещения была «тихой», то есть она не оповестила никого о своей поломке. Не было произведено никаких звуковых или визуальных оповещений, которые бы предупредили работников об остановке системы, которые полностью опираются на подобные оповещения для получения информации о статусе энергосистемы. Последствия аварии широко освещались в масс-медиа: многие территории оставались без электричества на протяжении нескольких дней, что повлияло на промышленность, предоставление коммунальных услуг и связи. Считается, что даже несколько смертей были результатом аварии.
7. Происшествие на авианосце USS Yorktown
В мире разработки программного обеспечения есть несколько широко известных багов с которыми сталкиваются программисты и которые они должны обязательно учитывать при написании кода. Одним из таких багов является «деление на ноль» - когда производится вычисление, в котором любое число делится на ноль. Такое вычисление невозможно произвести, по крайней мере, если не использовать высшую математику, из-за чего большинство программ, устанавливаемых на суперкомпьютеры или даже на карманные калькуляторы, пишутся таким образом, чтобы учитывать такую возможность.
К стыду программистов движущая система USS Yorktown полностью остановилась, оставив авианосец беспомощным в воде на 3 часа, когда один из членов экипажа корабля ввёл ноль в бортовую систему управления базами данных, а система попыталась произвести операцию деления на ноль. Программное обеспечение было установлено в ходе проекта по использованию компьютеров для уменьшения необходимо количества людей в экипажах некоторых кораблей. К счастью, корабль в это время участвовал в учебных манёврах, и не был в разгаре битвы, иначе последствия ошибки были бы плачевными.
6. Взрыв на Транссибирском газопроводе
Этот пункт надо воспринимать с долей скептицизма, так как это возможно слухи, но, если это правда – это прекрасный пример преднамеренно оставленного бага, который повлёк за собой большую аварию.
Во время Холодной Войны, когда отношения между США и СССР были, мягко скажем, напряжёнными, ЦРУ, якобы, преднамеренно ввело несколько багов в программное обеспечение, продаваемое канадской компанией, которое использовалось для управления газопроводом в Сибири. ЦРУ посчитало, что Россия покупала это программное обеспечение у канадской компании в попытке получить технологию США, и это было бы прекрасной возможностью дать СССР неполноценную технологию.
Такие операции были позже открыты в результате рассекреченного «Досье Farewell» (Farewell Dossier), где помимо всего остального, утверждалось, что в газопроводе были установлены бракованные турбины. Бывший министр военно-воздушных сил США, Томас Рид (Thomas Reed) утверждает, что в систему было введено несколько багов, которые бы не проявили себя во время тестирования, но привели бы к аварии во время непосредственного использования. Настройки насосов и клапанов были изменены, что привело к внештатному давлению в газопроводе, что в свою очередь привело к самому большому неядерному взрыву в мире.
Ветеран КГБ, Анатолий Медецкий опровергает вариант диверсии, по его мнению, взрыв произошёл по причине ошибок, допущенных при строительстве. К счастью, от взрыва никто не пострадал, так как он произошёл на удалённом от цивилизации участке территории.
5. Потенциальное начало ядерной войны во время Холодной Войны
Станислав Петров – офицер, служивший в секретном командном пункте, неподалёку от Москвы, в котором была расположена система раннего предупреждения. В одну из ночей, когда Петров был на дежурстве, ему поступило предупреждение о том, что США запустило 5 межконтинентальных баллистических ракет Минитмен (Minuteman). Согласно доктрине обоюдного уничтожения, превалирующей во время Холодной Войны, в ответ на атаку США, СССР должен был отомстить такой же атакой.
Если атака была настоящей, офицер должен был быстро отреагировать на неё. Однако, Петрову показалось странным, что США атаковало бы таким малым количеством боеголовок: хотя и эти ракеты бы нанесли огромный ущерб и большие человеческие потери, они бы не смогли нанести непоправимый ущерб СССР. Помимо этого, радары, расположенные на земле ничего не показывали, хотя они и не могли заметить ничего за линией горизонта из-за кривизны Земли, что объяснило бы задержку в наземных радарах.
Другим фактором, повлиявшем на решение Петрова, было то, что сама по себе система раннего предупреждения была ещё «сырой» и иногда ошибалась. Офицер взвесил все факторы и решил, что тревога была ложной. Несмотря на то, что сам Петров не мог запустить ответный ядерный удар, если бы он передал рекомендацию атаковать вышестоящему руководству, это бы послужило началом разрушительной ядерной войны. Решение Петрова было правильным, неважно было ли оно принято, опираясь на опыт, интуицию или просто удачу.
Позже было определено, что программное обеспечение раннего предупреждения среагировало на солнечный свет, отражённый от высотных облаков, который она восприняла как запуск ракет.
4. Вредоносная защита от копирования на дисках Sony
Война между корпорациями шоу-бизнеса и пиратами не прекращается. Как только придумываются новые способы защиты от копирования и безопасного распространения мультимедиа, появляются и новые пути обхода подобных методов защиты.
Некоторые считают, что музыкальная компания Sony BGM в 2005 году зашла слишком далеко, когда они ввели новую форму защиты от копирования на некоторых аудио дисках. Когда диск проигрывался на компьютере под управлением операционной системы Windows, в систему внедрялся «руткит» (rootkit). Руткит – программное обеспечение, которое глубоко встраивается в операционную систему и изменяет некоторые из её фундаментальных процессов. Хотя руткиты, не всегда являются вредоносными, они зачастую используются для незаметной установки вредного и трудноудаляемого программного обеспечения – вирусов, троянов и т.д. В случае с Sony BMG целью было управлять тем, как Windows использует их аудио диск и не дать скопировать диск или сконвертировать звуковые дорожки в MP3 формат, что помогло бы снизить уровень пиратства для их продукции.
Руткит достиг своей цели, но из-за того, что он пытался скрыться от пользователя, это позволило и другому вредоносному программному обеспечению скрывать своё присутствие на компьютерах пользователей. Плохо продуманная имплементация и растущая уверенность пользователей, что Sony BMG не имело права пытаться незаметно управлять их компьютерами, привело к тому, что схема провалилась. Многие компании, занимающиеся компьютерной безопасностью, классифицировали руткит, как вредоносный код, а Sony BMG пришлось отвечать за свои действия в суде и отозвать партию аудиодисков с руткитом.
3. Баг в ракетном комплексе Пэтриот (Patriot)
Во время операции «Щит пустыни» (Desert Shield) США приняло на вооружение ракетный комплекс «Пэтриот» для защиты от ракетных ударов и вражеской авиации – в этом случае, от иракских ракет SCUD. Управляющее программное обеспечение ракет Пэтриот использует скорость своей цели и текущее время для предсказания траектории движения цели. Учитывая, что цели могут достигать скорости в 1.5 км/с, эти вычисления должны быть очень точны.
На тот момент в программном обеспечении, отвечающем за ведение цели, присутствовал баг, из-за которого со временем внутренние часы постепенно отходили от истинного значения времени. Баг уже был известен, и его можно было решить регулярной перегрузкой системы, и сбросом значения системных часов.
Отвечавшие за это люди, не совсем поняли что такое «регулярная» перезагрузка и система работала на протяжении 100 часов. Когда Ирак запустил свою ракету в сторону аэродрома США в Дахране (Dhahran), система Пэтриот определила запуск. Однако, к тому времени, внутренние часы уже были смещены на 0.34 секунды, поэтому, вычисленная ПО траектория оказалась ошибочной и система посчитала, что вражеской ракеты больше не существует и отменила попытку сбития ракеты. Ракета долетела до своей цели, в результате чего 28 американских солдат погибло, и 98 было ранено.
2. Проблема 2000 года
Баг Тысячелетия (Millennium Bug) или Проблема 2000 года – самый известны баг в этом списке и многие из нас слышали о нём в то время. Вкратце, этот баг был результатом «близорукости» компьютерных профессионалов в десятилетии, предшествующем 2000 году. Во многих компьютерных системах для обозначения даты использовалось две цифры, к примеру, 98 вместо 1998 года – это казалось достаточно логичным решением и использовалось даже до компьютеров.
Впрочем, многие не предвидели, что может случиться проблема, когда дата превысит 2000 год. Используя те системы, 2000 год мог представляться только как ‘00’, из-за чего программное обеспечение могло воспринять это как наступление 1900 года. Такое представление повлекло бы за собой неправильные результаты в вычислениях на промежутках лет, находящихся по две стороны от 2000 года. К примеру, кто-то родившийся в 1920 году и умерший в 2001 мог получить значение возраст -19 лет.
В ответ на эту проблему, софтверные компании быстро обновили свои продукты, задействованные в управлении банковскими структурами, больничным оборудованием и другими важными сферами. Для подтверждения того, что баг может повлиять на компьютеры всего мира, в феврале 1999 года был создан «Интернациональный центр по разрешению проблемы 2000 года». Задачей центра была координация работы, необходимой для подготовки к новому тысячелетию. В конце концов, Новый Год прошёл без каких-либо проблем, помимо обычного похмелья.
Сложно сказать было ли успешное разрешение проблемы результатом проведённой работы или сама проблема была изначально преувеличена – скорее всего, и то и другое.
1. 2038 год
Хотя мы успешно преодолели 2000 год, проблемы ещё не закончились. Не все компьютеры одинаково работают с датами. Большинство операционных систем семейства UNIX представляют даты в виде прошедшего количества секунд с 1 января 1970 года. К примеру: 1 января 1980 года представляется, как 315532800 секунд после 1 января 1970 года. Это число хранится в компьютерах, как беззнаковое 32-битное целое число, которое может держать максимальное значение в 2147483647. Это означает, что компьютер может хранить 2147483647 в качестве даты, чего хватит только до 19 января 2038 года, после чего у нас опять могут появиться проблемы.
Баг может принести намного больше вреда, если учитывать что UNIX используется во встраиваемых системах, в которых связь между «железной» и софтверной частью намного сильнее – к примеру, в роботах, используемых на конвейерах, в часах, в рутерах и т.д.
Кому-то ещё надо подумать, что мы будем делать 1 января 10000 года. Но это уже явно не нам.
