Катастрофические последствия ошибок программистов

Катастрофические последствия программных ошибок

Практика не устает доказывать, что в любом ПО самая главная уязвимость — человеческий фактор. И неважно, появился ли баг из-за нехватки квалифицированности специалиста, выжил после долгих часов дебага в поисках ошибки, или считался хитро замаскировавшейся фичей. Среди некоторых разработчиков даже укрепилось мнение, что баги в принципе существуют всегда и везде. Но если ошибки абстрактны и сложно воспроизводимы в реальных условиях, то проблема не является критичной.

В идеальной ситуации баги исправляют все и сразу. Но в жизни всегда есть куча задач, отодвигающих полный и бесповоротный багфикс (новый функционал, срочные хотфиксы, расставленные приоритеты при исправлении багов). Это значит, что в первую очередь находятся и исправляются очевидные и явные проблемы. Остальные тихо ждут своего часа, превращаясь в бомбы замедленного действия. Иногда ошибки приводят не только к неприятностям в жизни рядового разработчика, но и вызывают настоящие катастрофы. Сегодня у нас подборка и объяснение самых кошмарных багов в истории разработки ПО.

Облучение и радиация

Знаменитый случай гибели нескольких человек, получивших смертельную дозу облучения во время сеансов радиационной терапии с применением медицинского ускорителя 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)

Катастрофические последствия программных ошибок +24

Облучение и радиация

Знаменитый случай гибели нескольких человек, получивших смертельную дозу облучения во время сеансов радиационной терапии с применением медицинского ускорителя 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

6 сентября 1989 года парижанам запомнилось надолго — в этот день более 41 тысячи жителей французской столицы получили из полиции официальные письма о том, что они совершили жестокие убийства и грабежи, хотя на самом деле адресаты всего лишь нарушили правила дорожного движения.

Ни одна программа в мире, за исключением, пожалуй, “Hello World!” полностью не застрахована от ошибок. А что уж говорить о больших приложениях, состоящих из миллионов строк кода, разработкой которых занимаются целые команды программистов. Да, прежде чем попасть в продакшен, такие программные продукты тщательно документируются и проходят через заботливые руки тестировщиков, но суровая реальность все равно вносит в логику их работы свои коррективы.

Иногда на стабильность софта оказывают влияние внешние обстоятельства и условия эксплуатации, гораздо чаще причина проблем располагается где-то в пространстве между офисным креслом и клавиатурой. И очень хорошо, если сбой приведет всего лишь к потере парочки важных отчетов. Иногда последствия могут быть куда более серьёзными.

Крупнейшая банковская ошибка в истории Америки

Тёплым майским днем 1996 года инкассатор частной чикагской компании по обслуживанию газового оборудования «Peoples Gas Light and Coke» Сильвестр Дорси отправился на обед. По пути он решил завернуть к ближайшему банкомату, чтобы проверить остаток на счете своей банковской карты. Получив чек с выпиской, Дорси не поверил собственным глазам. Он оказался владельцем скромного состояния размером 924,8 миллионов долларов США. «Я показал чек другу, который находился рядом, и мы просто закричали от восторга», — вспоминал потом этот случай Дорси.

Еще одним счастливчиком стал компьютерный инженер из компании «Zenith Electronics» Джеф Феррера, который позвонил в банк в пятницу утром в попытке уточнить свой баланс. Прослушав сообщение автоматического информатора, Джеф перезвонил еще раз, записал голос робота на диктофон и установил эту запись в качестве приветствия на своем телефоне. Теперь каждый звонящий Феррере абонент слышал в трубке следующее сообщение: «доступный остаток на вашем основном счете в настоящее время составляет 924 844 208 долларов США и 32 цента…». Можно только представить, какие чувства испытывал сам Джеф, когда автоинформатор впервые произнес эти слова.

Такая же участь постигла 825 других клиентов «Первого национального банка Чикаго» — все они неожиданно стали мультимиллионерами. Правда, счастье длилось недолго: всего один день. К вечеру которого сотрудники банка выяснили, что источником неимоверного богатства владельцев счетов стал досадный компьютерный сбой. Обслуживавшая дебетовые карты программа неправильно рассчитала параметры последних транзакций и перевела клиентам ошеломляющую сумму денег — 763,8 миллиарда долларов, что более чем в шесть раз превышало общую стоимость всех активов «Первого национального банка Чикаго».

Уже к вечеру счета новоявленных миллионеров были заморожены, а ошибочно зачисленные суммы — благополучно списаны. По словам представителей банка, никто из клиентов не успел сбежать с неожиданным кушем на острова Карибского архипелага, поэтому реальные финансовые потери компании оказались минимальными. Но этот инцидент и по сей день считается крупнейшей банковской ошибкой в истории США, к которой привел сбой в компьютерной программе.

К слову, за два года до описываемых событий нечто подобное случилось в нью-йоркском Chemical Bank, правда, с обратным математическим знаком. Заглючивший компьютер ополовинил все депозиты и вклады, информация о которых хранилась в базе данных головного офиса, и вместо нескольких сотен счастливых миллионеров банк получил целую армию разгневанных клиентов. Последствия этого сбоя технические специалисты разгребали несколько дней.

Но это же палка!

Впрочем, и Сильвестр Дорси, и Джеф Феррера, и все остальные 825 клиентов чикагского банка выглядят жалкими нищебродами по сравнению с человеком по имени Крис Рейнольдс из Пенсильвании. Развитие электронных платежных систем и цифровых валют сделало денежные транзакции более простыми, удобными и быстрыми, но вместе с тем увеличило риск возникновения проблем, связанных с ошибками в обслуживающих эти платежи программах.

Как и многие другие американцы, Крис Рейнольдс пользовался платежной системой PayPal, и наивно считал ее лучшим финансовым сервисом в мире. Его высокое мнение о достоинствах и возможностях PayPal многократно укрепилось, когда однажды утром 30 июня 2013 года он обнаружил на своем счете 92 233 720 368 547 800 долларов США.

Еще раз: 92 квадриллиона долларов. Для торговца подержанными автозапчастями на eBay это была довольно приличная сумма: состояние самого богатого человека планеты того года — телекоммуникационного магната Карлоса Слима — слегка не дотягивало до богатства Рейнольдса, и насчитывало всего лишь жалкие 67 миллиардов долларов.

Крис даже распечатал на память выписку по своему счету. Однако после того как он воспользовался мудрым советом из телесериала «Компьютерщики», а именно, «попробовал выйти и снова войти», чудесное наваждение рассеялось. На его балансе снова числилось 145 баксов и 25 центов, а Карлос Слим вновь вернулся на почетное место главного богатея Земли. Сказка закончилась, и несметные сокровища превратились в тыкву.

В PayPal признали сбой своего серверного ПО, и в качестве компенсации предложили расстроенному Рейнольдсу перечислить любую разумную сумму на какие-нибудь благотворительные цели. Когда журналисты ВВС спросили несостоявшегося квадриллиардера, на что он потратил бы эти деньги, если бы получил их в реальности, тот ответил: «погасил бы внешний долг США».

Вам счёт, сэр!

Впрочем, финансовые ошибки допускают не только компьютеры банков, в чем смогла лично убедиться семья Бразертон из графства Ланкашир, что расположено в Англии на берегу Ирландского моря. Линда и Найджел Бразертон решили сменить поставщика электроэнергии: раньше они пользовались услугами компании Scottish Power, но однажды подумали, что выгоднее будет покупать электричество у фирмы Npower. Однако они ошибались.

Сотрудник Npower осмотрел установленный в доме Бразертонов электросчетчик и обнулил его показания. Но компьютер компании посчитал, что значение «0» на индикаторе означает: с момента последней передачи сведений об израсходованной электроэнергии счетчик открутил полный цикл, и доступные ему цифры просто закончились. В следующем месяце почтенное семейство получило квитанцию, гласившую, что их платеж за электроэнергию слегка увеличился — с 87 фунтов стерлингов до 53 480 062 фунтов, что составляет примерно 90 миллионов долларов США.

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

Минус 460 миллионов за 45 минут

В среду, 1 августа 2012 года офис инвестиционной компании Knight Capital как всегда начал работу в 8 утра. Включив компьютеры, сотрудники первым делом проверили электронную почту, и среди спама обнаружили автоматические сообщения о том, что запущенная на сервере программа Power Peg настроена неправильно. Никто не обратил внимания на эти предупреждения, потому что Power Peg не использовалась уже без малого 10 лет, с 2003 года. И совершенно напрасно.

В 9 утра открылась нью-йоркская фондовая биржа, и автоматические системы трейдинга Knight Capital начали создавать заявки на покупку и продажу активов. Уже спустя 45 минут компания потеряла более 4,5 миллионов долларов, а вскоре общий убыток, полученный фирмой благодаря заключенным бездушными программами сделкам, достиг 460 миллионов долларов США, поставив Knight Capital на грань банкротства. Автоматические алгоритмы других игроков использовали возникшую ситуацию, из-за чего акции некоторых компаний на нью-йоркской бирже подскочили в цене аж на 300%.

Проведенное позже исследование показало: накануне этого злополучного дня на серверы Knight Capital было установлено обновление ПО, которое по недосмотру разработчиков включило устаревшее приложение Power Peg, уже давно отключенное за ненадобностью. В тестовом режиме это приложение продаёт акции по текущей цене и тут же покупает их обратно по рыночной ставке (которая обычно выше цены продажи), совершенно не обращая внимания на стоимость ценных бумаг — в его задачу входит провести как можно больше сделок в единицу времени. После вывода этой программы из эксплуатации разработчики удалили из ее кода проверку того, запущено ли приложение на тестовом сервере в локальной сети, или оно действует в реальной рабочей обстановке.

Как оказалось, установленное обновление запустило Power Peg на сервере, подключенном к нью-йоркской фондовой бирже, после чего программа заработала в тестовом режиме и начала регистрировать огромное количество безумных сделок, стремительно сливая капиталы компании. Чуть позже комиссия по ценным бумагам еще и оштрафовала Knight Capital на 12 миллионов долларов за нарушения правил управления финансовыми рисками.

Яблочные карты

Некоторые ошибки в софте вроде бы не приводят к возникновению прямых финансовых убытков, но иногда влекут за собой косвенные. На первых моделях iPhone использовались карты и навигация от Google, но в борьбе со своим главным конкурентом корпорация Apple решила избавиться от приложения Google Maps. В 2012 году в Купертино разработали собственную версию карт для iOS, однако в отличие от Google, которая потратила на создание своего сервиса много лет и миллионы долларов, в Apple решили, что задачу можно решить быстрее и намного экономнее. Информация о дорогах, мостах, архитектурных объектах и достопримечательностях стекается в Google из тысяч различных источников, хранится в нескольких распределенных базах данных, а сборку всех этих сведений воедино выполняет мощный программный комплекс. У Apple на начальном этапе не было всех этих ресурсов.

В результате на экранах iPhone и iPad многие озера, мосты и вокзалы отсутствовали на своих привычных местах, монумент Вашингтона переехал на соседнюю улицу, супермаркет Publix в городе Джексонвилл, штат Флорида, стал больницей, а главный вокзал столицы Новой Зеландии, города Окленд, и вовсе очутился посреди океана. В трехмерном представлении некоторые участки карт и вовсе выглядели фантастически: шоссе складывались гребёнкой, устремлялись вертикально в небо и скручивались лентой Мебиуса, мосты уходили под воду, а здания громоздились посреди водной глади.

Безусловно, никто из пользователей карт Apple не нырнул на своем автомобиле с оклендской набережной в попытке догнать уходящий поезд, но доверие к программам этой компании все же было слегка подорвано. А репутация в наши дни стоит очень дорого.

Заключение

Чаще всего от ошибок в программах страдают не только компании, но и обычные пользователи. Иногда разработчики пытаются загладить свою вину и компенсировать людям доставленные неудобства. Правда, порой они делают это весьма странным образом. Например, звонок в службу поддержки клиентов «Первого национального банка Чикаго» стоил целых три доллара. После инцидента с ошибочным зачислением на дебетовые карточки 924,8 миллионов руководство банка сделало задушевные беседы со своими сотрудниками бесплатной услугой. Но только для тех клиентов, которые сами сообщили в учреждение о свалившемся на них нежданном богатстве и добровольно вернули деньги. Неслыханная щедрость, не правда ли?

Думаем, каждый из нас так или иначе сталкивался с различными ошибками в софте. Будем рады, если вы поделитесь самыми интересными багами из вашей практики в комментариях!

«Если бы строители строили здания так же, как программисты пишут программы, первый залетевший дятел разрушил бы цивилизацию», — второй закон Вейлера.

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

Слово «безопасность» не сходит со страниц компьютерной прессы. Однако, употребляется оно обычно в контексте поддержания целостности данных и — особенно — обеспечения их конфиденциальности. Что ж, тема интересная: Internet, банки, спецслужбы, хакеры … — все, к чему приложимо вошедшее в повседневный обиход слово «seсurity». Есть, однако, у «безопасности» и другое измерение, чаще обозначаемое не столь популярным термином «safety», про которое говорят меньше, но важность его — применительно к компьютерным системам — поистине нельзя переоценить.

В мире постоянно происходят катастрофы, большие, малые аварии и все чаще их причиной становится ненадлежащее функционирование компьютерных систем и, в частности, их программного обеспечения. Оборона, авиация и космос, медицина, технологические процессы на современных ядерных, химических и других производствах — вот неполный перечень тех предметных областей, где низкое качество ПО и даже единичные дефекты в нем находят воплощение в терминах потерянных человеческих жизней и разрушенных материальных ценностей.

Над такого рода «ответственными» (mission-critical) системами работает целая отрасль, в которой крутятся очень большие (по-преимуществу, бюджетные) деньги и где — как справедливо принято считать — сосредоточено значительное количество высококвалифицированных программистов и проектировщиков, надлежащим образом поставлен менеджмент, отлажены процессы разработки и контроля. И тем не менее, «кое-где… порой…» ПО дает сбой, и резонанс тогда бывет громкий. Разберем две знаменитых истории, в одной из которых программистские ошибки привели к беспрецедентным материальным потерям, в другой — к смерти нескольких человек, и попытаемся за этими частными случаями увидеть некоторые общие проблемы, стоящие сегодня перед всей программной индустрией.

Катастрофа Ariane 5

4 июня 1996 года был произведен первый запуск ракеты-носителя Ariane 5 — детища и гордости Европейского Сообщества. Уже через неполные 40 сек. все закончилось взрывом. Автоподрыв 50-метровой ракеты произошел в районе ее запуска с космодрома во Французской Гвиане. За предшествующие годы ракеты серии Ariane семь раз терпели аварии, но эта побила все рекорды по вызванным ею убыткам. Только находившееся на борту научное оборудование потянуло на пол-миллиарда долларов, не говоря о прочих разноообразных издержках; а астрономические цифры «упущенной выгоды» от несостоявшихся коммерческих запусков и потеря репутации надежного перевозчика в очень конкурентном секторе мировой экономики («стоимость рынка» к 2000 г. должна превысить 60 млрд. долл.) с трудом поддаются оценке. Небезынтересно отметить, что предыдущая модель — ракета Ariane 4 — успешно запускалась более 100 раз.

Буквально на следующий день Генеральный директор Европейского Космического Агенства (ESA) и Председатель Правления Французского Национального Центра по изучению Космоса (CNES) издали распоряжение об образовании независимой Комиссии по Расследованию обстоятельств и причин этого чрезвычайного происшествия, в которую вошли известные специалисты и ученые изо всех заинтересованных европейских стран. Возглавил Комиссию представитель Французской Академии Наук профессор Жак-Луи Лион (Jacques-Louis Lions). Кроме того, был сформирован специальный Технический Комитет из представителей заказчиков и подрядчиков, ответственных за производство и эксплуатацию ракеты, в чью обязанность было вменено незамедлительно предоставлять Комиссии всю необходимую информацию.

13 июня 1996 г. Комиссия приступила к работе, а уже 19 июля был обнародован ее исчерпывающий доклад, который сразу же стал доступен в Сети [1]. Что же касается информации, которую — при участии нескольких институтов — осмысляла Комиссия, то она состояла из телеметрии, траекторных данных, а также оптических наблюдений за ходом полета. Были собраны (что само по себе было непросто, так как взрыв произошел на высоте приблизительно 4 км, и осколки были рассеяны на площади около 12 кв. км. в саванне и болотах) и изучены части ракеты и оборудования. Кроме того, были заслушаны показания многочисленных специалистов и изучены горы производственной и эксплуатационной документации.

Технические подробности аварии

Положение и ориентация ракеты-носителя в пространстве измеряются Навигационной Системой (Inertial Reference Systems — IRS), составной частью которой является встроенный компьютер, вычисляющий углы и скорости на основе информации от бортовой Инерциальной Платформы, оборудованной лазерными гироскопами и акселерометрами. Данные от IRS передаются по специальной шине на Бортовой Компьютер (On-Board Computer — OBC), который обеспечивает необходимую для реализации программы полета информацию и непосредственно — через гидравлические и сервоприводы — управляет твердотопливными ускорителями и криогенным двигателем типа Вулкан (Vulkain).

Как обычно, для обеспечения надежности Системы Управления Полетом используется дублирование оборудования. Поэтому две системы IRS (одна — активная, другая — ее горячий резерв) с идентичным аппаратным и программным обеспечением функционируют параллельно. Как только бортовой компьютер OBC обнаруживает, что «активная» IRS вышла из штатного режима, он сразу же переключается на другую. Впрочем, и бортовых компьютеров тоже два.

Теперь, следуя Докладу Комиссии [1], проследим все значимые фазы развития процесса, оказавшегося в конце концов аварийным. Момент старта обозначим H0 — это и будет точка отсчета для всех событий, хотя отслеживать их мы будем в обратном — начиная с момента саморазрушения системы — порядке. Для полноты картины упомянем, что предшествующие старту операции происходили в нормальном режиме вплоть до момента H0-7 минут, когда было зафиксировано нарушение «критерия видимости». Поэтому старт был перенесен на час; в H0 = 9 час. 33 мин. 59 сек. местного времени «окно запуска» было вновь «поймано» и был, наконец, осуществлен сам запуск, который и происходил штатно вплоть до момента H0+37 сек. В последующие секунды произошло резкое отклонение ракеты от заданной траектории, что и закончилось взрывом. Итак:

• в момент H0+39 сек. из-за высокой аэродинамической нагрузки вследствие превышения «углом атаки» критической величины на 20 градусов произошло отделение стартовых ускорителей ракеты от основной ее ступени, что и послужило основанием для включения Системы Автоподрыва ракеты;
• изменение угла атаки произошло по причине нештатного вращения сопел твердотопливных ускорителей;
• такое отклонение сопел ускорителей от правильной ориентации вызвала в момент H0 + 37 сек. команда, выданная Бортовым Компьютером на основе информации от активной Навигационной Системы (IRS 2). Часть этой информации была в принципе некорректной: то, что интерпретировалось как полетные данные, на самом деле являлось диагностической информацией встроенного компьютера системы IRS 2;
• встроенный компьютер IRS 2 передал некорректные данные, потому что диагностировал нештатную ситуацию, «поймав» исключение (exception), выброшенное одним из модулей программного обеспечения;
• при этом Бортовой Компьютер не мог переключиться на резервную систему IRS 1, так как она уже прекратила функционировать в течение предшествующего цикла (занявшего 72 мсек.) — по той же причине, что и IRS 2;
• исключение, «выброшенное» одной из программ IRS, явилось следствием выполнения преобразования данных из 64-разрядного формата с плавающей точкой в 16-разрядное целое со знаком, что привело к «Operand Error»;
• ошибка произошла в компоненте ПО, предназначенном исключительно для выполнения «регулировки» Инерциальной Платформы. Причем — что звучит парадоксально, если не абсурдно — этот программный модуль выдает значимые результаты только до момента H0 + 7 сек. отрыва ракеты со стартовой площадки. После того, как ракета взлетела, никакого влияния на полет функционирование данного модуля оказать не могло;
• однако, «функция регулировки» действительно должна была (в соответствии с установленными для нее требованиями) действовать еще 50 сек. после инициации «полетного режима» на шине Навигационной Системы (момент H0-3 сек.), что она с усердием дурака, которого заставили богу молиться, и делала;
• ошибка «Operand Error» произошла из-за неожиданно большой величины BH (Horizontal Bias — горизонтальный наклон), посчитанной внутренней функцией на основании величины «горизонтальной скорости», измеренной находящимися на Платформе датчиками. Величина BH служила индикатором точности позиционирования Платформы;
• величина BH оказалась много больше, чем ожидалось потому, что траектория полета Ariane 5 на ранней стадии существенно отличалась от траектории полета Ariane 4 (где этот программный модуль использовался ранее), что и привело к значительно более высокой «горизонтальной скорости».

Финальным же действием, имевшим фатальные последствия, стало прекращение работы процессора; соответственно, вся Навигационная Система перестала функционировать. Возобновить же ее действия оказалось технически невозможно.

Осталось добавить, что всю эту цепь событий удалось полностью воспроизвести с помощью компьютерного моделирования, что — вкупе с материалами других исследований и экспериментов — позволило заключить; причины и обстоятельства катастрофы полностью выявлены.

Причины и истоки аварии

Прежде всего проследим, откуда взялось первоначальное требование на продолжение выполнения операции регулировки после взлета ракеты. Оказывается, оно было заложено более чем за 10 лет до рокового события, когда проектировались еще ранние модели серии Ariane. При некотором (весьма маловероятном!) развитии событий взлет мог быть отменен буквально за несколько секунд до старта, например в промежутке H0-9 сек., когда на IRS запускался «полетный режим», и H0-5 сек., когда выдавалась команда на выполнение некоторых операций с ракетным оборудованием. В случае неожиданной отмены взлета необходимо было быстро вернуться в режим «обратного отсчета» (countdown) — и при этом не повторять сначала все установочные операции, в том числе приведение к исходному положения Инерциальной Платформы (операция, требующая 45 мин. — время, за которое можно потерять «окно запуска»).

Было обосновано, что в случае события отмены старта период в 50 сек. после H0-9 будет достаточным для того, чтобы наземное оборудование смогло восстановить полный контроль за Инерциальной Платформой без потери информации — за это время Платформа прекратит начавшееся было перемещение, а соответствующий программный модуль всю информацию о ее состоянии зафиксирует, что поможет оперативно возвратить ее в исходное положение (напомним, что все это в случае, когда ракета продолжает находиться на месте старта). И действительно, однажды, в 1989 году, при старте под номером 33 ракеты Ariane 4, эта особенность была с успехом задействована.

Однако, Ariane 5, в отличие от предыдущей модели, имел уже принципиально другую дисциплину выполнения предполетных действий — настолько другую, что работа рокового программного модуля после времени старта вообще не имела смысла. Однако, модуль повторно использовался без каких-либо модификаций — видимо из-за нежелания изменять программный код, который успешно работает.

В конце концов, было бы странно, если бы тривиальная ошибка переполнения (даже если она и возникла) была бы столь фатальной, что с ней невозможно бороться. Почему же программный код (написанный на таком оснащенном всеми необходимыми для обеспечения надежности средствами языке, как Ада) оказался незащищеным до такой степени, что наступили столь катастрофические последствия?

Расследование показало, что в данном программном модуле присутствовало целых семь переменных, вовлеченных в операции преобразования типов. Оказалось, что разработчики проводили анализ всех операций, способных потенциально генерировать исключение, на уязвимость. И это было их вполне сознательным решением добавить надлежащую защиту к четырем переменным, а три — включая BH — оставить незащищенными. Основанием для такого решения была уверенность в том, что для этих трех переменных возникновение ситуации переполнения невозможно в принципе. Уверенность эта была подкреплена расчетами, показывающими, что ожидаемый диапазон физических полетных параметров, на основании которых определяются величины упомянутых переменных, таков, что к нежелательной ситуации привести не может. И это было верно — но для траектории, рассчитанной для модели Ariane 4. А ракета нового поколения Ariane 5 стартовала по совсем другой траектории, для которой никаких оценок не выполнялось. Между тем она (вкупе с высоким начальным ускорением) была такова, что «горизонтальная скорость» превзошла расчетную (для Ariane 4) более чем в пять раз.

Но почему же не была (пусть в порядке перестраховки) обеспечена защита для всех семи, включая BH, переменных? Оказывается, для компьютера IRS была продекларирована максимальная величина рабочей нагрузки в 80%, и поэтому разработчики должны были искать пути снижения излишних вычислительных издержек. Вот они и ослабили защиту там, где теоретически нежелательной ситуации возникнуть не могло. Когда же она возникла, то вступил в действие такой механизм обработки исключительной ситуации, который оказался совершенно неадекватным.

Этот механизм предусматривал следующие три основных действия. Прежде всего, информация о возникновении нештатной ситуации должна быть передана по шине на бортовой компьютер OBC; параллельно она — вместе со всем контекстом — записывалась в перепрограммируемую память EEPROM (которую во время расследования удалось восстановить и прочесть ее содержимое), и наконец, работа процессора IRS должна была аварийно завершиться. Последнее действие и оказалось фатальным — именно оно, случившееся в ситуации, которая на самом деле была нормальной (несмотря на сгенерированное из-за незащищенного переполнения программное исключение), и привело к катастрофе.

Осмысление

Произошедшая с Ariane 5 катастрофа имела исключительно большой резонанс — и по причине беспрецедентных материальных потерь, и вследствие очень оперативного расследования, характеризовавшегося к тому же открытостью результатов (впервые такая практика публичности была опробована при расследовании причин аварии космического корабля Challenger в 1986 году). Сразу стало очевидным, что данному событию суждено войти в историю не только космонавтики, но и программной инженерии. Поэтому неудивительно, что авария послужила поводом для оживленной дискуссии, в которой приняли участие многие известные специалисты.

Ж.-М. Жезекель (J.-M. Jezequel) и Бертран Мейер (B.Meyer) [2] пришли к совершенно однозначному выводу: допущенная (и так и не выявленная) программная ошибка носит, по их мнению, чисто технический характер и коренится в некорректной практике повторного использования ПО. Более точная формулировка: роковую роль сыграло отсутствие точной спецификации повторно-используемого модуля. Расследование показало, что обнаружить требование, устанавливающее максимальную величину BH (вмещающуюся в 16 битов), можно было с большим трудом: оно затерялось в приложениях к основному спецификационному документу. Мало того, в самом коде на этот счет не было никаких комментариев, не говоря уже о ссылке на документ с обоснованием этого требования.

В качестве панацеи в такого рода ситуациях авторы предложили задействовать принцип «Контрактного Проектирования» (что и неудивительно, ибо его разработчиком как раз и является Мейер [3]). Именно «контракт» в духе языка Eiffel, явным образом (с помощью пред- и пост-условий) устанавливающий для любого программного компонента ограничения на входные и выходные параметры, и мог бы предотратить катастрофическое развитие событий. Был приведен и набросок такого контракта:

convert (horizontal_bias:INTEGER): INTEGER is require horizontal_bias <= Maximum_bias do … ensure … end

Соответственно, ошибка могла быть выявлена уже на этапе тестирования и отладки (когда проверка логических утверждений включается по специальной опции компилятора); если же пред- и пост-условия проверялись бы и во время полета, то сгенерированное исключение могло быть надлежащим образом обработано (правда, авторы оговариваются, что использование такого режима могло бы нарушить ограничения, связанные с вычислительной нагрузкой). Однако, самым важным достоинством использования контрактных механизмов является, по мнению авторов, явное присутствие легко понимаемых и при необходимости верифицируемых ограничений как в документации, так и в коде. При работе над сложными проектами типа Ariane именно контракты могли бы выступать в качестве опорных ориентиров для групп качества «QA Team», чья задача — выполнять систематический мониторинг ПО на предмет соответствия требованиям. Авторы с сожалением заключают, что контрактные механизмы никак не получат должного распространения в современной практике. Более того, положение только усугубляется: например, в Java даже исчезла присутствовавшая в языке Cи скромная по возможностям инструкция «assert». В составной части CORBA — языке IDL (Interface Definition Language), предназначенном обеспечить полномасштабное повторное использование компонентов в распределенной среде, отсутствует какой-либо механизм спецификации семантики. То же относится и к ActiveX. Авторы заключают: без полной и точной спецификации, основанной на пред- и пост-условиях и инвариантах, «повторное использование программных компонентов — совершенное безрассудство».

Эта точка зрения вызвала многочисленные отклики. Хотя полезность использования контрактных механизмов никто не оспаривал, все же взгляд авторов многим показался упрощенным. Наиболее обстоятельный критический разбор их статьи выполнил сотрудник Locheed Martin Tactical AirCraft Systems, известный специалист в области разработки ответственных систем Кен Гарлингтон (Ken Garlington) [4]. Он начал с того, что указал на ошибку в приведенном наброске контракта, где предполагается, что BH преобразуется не из вещественного (как то было в реальности) числа, а из целого. Показательно, пишет Гарлингтон, что он оказался первым, кто обратил внимание на столь очевидный прокол, а ведь статью читали и публично обсуждали многие квалифицированные специалисты. С тем же успехом (а точнее неуспехом) могла пройти мимо этого дефекта и «QA-team». Так что даже точная спецификация сама по себе не панацея. Гарлингтон также подробно разобрал нетривиальные проблемы, возникающие при написании не «наброска», а действительно полной спецификации контракта для данной конкретной ситуации.

Вывод Гарлингтона вполне отвечает здравому смыслу: проблема носит комплексный характер и обусловлена прежде всего объективной сложностью систем типа Ariane. Соответственно, одним лекарством болезнь, приводящая к появлению ошибок в ПО, вылечена быть не может. Хотя то, что процесс мониторинга спецификаций, кода и документов с обоснованием проектных решений при разработке ПО для Ariane 5, оказался неадекватен, отметила и Комиссия по расследованию аварии. В частности, подчеркнуто, что к процессу контроля не привлекались специалисты из организаций, независимых как от заказчика, так и от подрядчика системы, что нарушило принцип разделения исполнительных и контрольных функций.

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

Было обращено внимание и на невыявленную при анализе требований к проекту взаимную противоречивость между необходимостью обеспечения надежности и декларацией о величине максимально допустимой нагрузки на компьютер, что и явилось предпосылкой принятия программистами потенциально опасного компромиссного решения о защите от переполнения не всех семи, а только четырех переменных. Впрочем, как справедливо замечает Мейер, всякий инженерный процесс предполагает принятие компромиссных решений в условиях множества разноречивых требований; вопрос в том, насколько полна информация, на основании которой такие решения принимаются.

Особый разговор — о механизме обработки исключительных ситуаций, который, как уже говорилось, жил своей особой жизнью — в отрыве от общего контекста всей ситуации с полетом, и в итоге уподобился тому врачу, что без всякого осмотра пристрелил пришедшего к нему с непонятными симптомами больного, дабы тот не мучился. Реализация именно такого механизма явилась следствием распространенной при разработке «ответственных» систем проектной культуры особо — и радикально — реагировать на возникновение случайных аппаратных сбоев. Принцип действий здесь «простой, как мычание», исходящий из критериев безусловного обеспечения максимальной надежности: отключать допустившее сбой оборудование и тут же задействовать резервный блок: вероятность того, что этот блок также выдаст случайный сбой, да еще в той же ситуации, для надлежаще спроектированных и отлаженных аппаратных систем чрезвычайна мала.

В данном же случае, возникла систематическая программная ошибка; «систематическая» — в том смысле, что при повторении тех же входных условий, она обязательно возникнет вновь, ибо — тавтология здесь уместна — запрограммирована. Вот почему подключение резервной Навигационной Системы ничего не дало: ведь ПО на нем исполнялось то же самое, соответственно и обе IRS, и дублирующие друг друга Бортовые Компьютеры с неотвратимостью натыкались на ту же ситуацию и с покорностью обреченных на заклание овец шли к катастрофе. Очевидно, что необходимо по крайней мере отнять у «врача» пистолет: прекращать функционирование аппаратуры при возникновении программного «исключения» целесообразно лишь после комплексного анализа ситуации, но никак не автоматически.

В контексте данной статьи интересно мнение главного редактора журнала «Automated Software Engineering» Башара Нузейбеха (Bashar Nuseibeh) [5], который, дав обзор разных точек зрения на причины аварии и придя к выводу, что «все правы», связал все-таки катастрофу Ariane 5 с более общими проблемами разработки программных систем. Он отметил, в частности, что современные тенденции в программной инженерии, связанные с разделением интересов вовлеченных в разработку независимо работающих персонажей (что связано с широким внедрением таких подходов, как объектно-ориентированные и компонентные технологии) не получают надлежащего балансирующего противовеса в виде менеджмента, способного координировать всю работу на должном уровне. Эта тема заслуживает дальнейшего обсуждения, но сначала обратимся к еще одной печально знаменитой истории.

Инциденты с Therac-25

Вспомним более давнюю историю, почти во всем отличную от ситуации с Ariane 5, а сходную только в том, что она также была подробно задокументирована [6] и получила в свое время большой резонанс как повлекшая наиболее тяжкие последствия за всю не столь долгую историю использования медицинских комплексов, управляемых компьютерами. Правда в этом случае полномасштабного официального расследования проведено не было; источниками информации послужили, в основном, протоколы встреч пользователей системы с производителем и материалы многочисленных судебных разбирательств.

Технические подробности инцидентов

В 1985-87 гг. 6 человек получили смертельную дозу облучения во время сеансов радиационной терапии с применением медицинского ускорителя Therac-25 (количество пациентов, также подвергшихся переоблучению, но выживших, точно не известно). Производителем установки являлось одно из подразделений Канадского Агентства Атомной Энергии (Atomic Energy of Canada Limited — AECL). Модель Therac-25, законченная в виде прототипа в 1976 г. и поступившая в промышленную эксплуатацию в 1982 г. (пять установок в США и шесть — в Канаде) была развитием ранних моделей Therac-6 и Therac-20. При этом некоторые программные модули, разработанные для ранних моделей, использовались повторно (в том числе — поставленные партнером, французской фирмой CGR, сотрудничество AECL с которой прекратилось к моменту начала работ над Therac-25).

Следующий инцидент, случившийся в июле того же года в Онкологическом Центре Онтарио как раз был задокументирован хорошо, но производитель не смог воспроизвести ситуацию, и ее отнесли на счет случайного сбоя аппаратуры; в ПО сомнений по-прежнему просто не было. И трагические инциденты продолжились.

Очередной из них произошел в Онкологическом Центре Восточного Техаса в марте 1986 года. В данном случае процессом управляла опытный оператор, проведшая уже более 500 подобных сеансов. Она быстро ввела предписанные параметры, после чего заметила, что вместо режима облучения электронными лучами заказала лучи рентгеновские (которыми пользовали большинство пациентов). Коррекция требовала исправления всего одной буквы; нажав кнопку, она вошла в режим редактирования, скорректировала в нужном месте «x» на «e», затем несколькими нажатиями клавиши «Return» (благо, все остальные параметры были введены правильно) достигла нижней (командной) строки экрана, убедилась, что против каждого введенного параметра горит «VERIFIED», а статус системы — ожидаемый («BEAM READY»), и выдала команду начать процесс облучения. Однако, неожиданно система встала, на консоли высветилось сообщение «MALFUNCTION 54», а статус системы изменился на «TREATMENT PAUSE», что свидетельствовало о проблеме невысокой степени серьезности. Висевшая тут же бумага с кодами ошибок «исчерпывающе» поясняла, что «MALFUNCTION 54» означает «dose input 2». Забегая вперед, укажем, что много позже, во внутренней документации производителя было обнаружено, что это сообщение выдавалось в случае «ненадлежащей дозы облучения» — причем, как для слишком большой, так и для слишком малой, что само по себе странно (да и просто недопустимо — ведь ситуации принципиально разные). Озадаченная операторша взглянула на высветившееся количество отпущенной дозы и увидела, что оно — пренебрежимо мало. Поэтому она без долгих раздумий выдала команду на продолжение процесса, после чего вся описанная выше ситуация повторилась.

Тем временем пациент, который возлежал на столе в изолированном от оператора помещении, испытал некое подобие электрического шока. Он тоже был опытным (для него это был девятый сеанс), поэтому понял, что творится что-то неладное. Однако, дать сразу же знать об этом оператору через специально для того предназначенные видео и аудио средства он не смог: как выяснилось, видео было по непонятным причинам отключено, а аудиоканал — просто неисправен. После повторного шокового удара пациент вскочил и нимало шокировал уже операторшу, начав ломиться в стеклянные двери ее помещения. Поначалу его и лечили от электрошока (он умер через пять месяцев). Позднейшее моделирование ситуации показало, что пациент получил менее чем за 1 сек. на участок позвоночника в 1 кв. см. дозу в диапазоне от 16500 до 25000 рад (в то время, как ему было предписано принять в этом сеансе 180 рад, а всего — 6000 рад за шесть с половиной недель).

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

Особенности ПО как предпосылки для инцидентов

В комплексе не использовалась какая-либо стандартная операционная система: была разработана специальная мультизадачная ОС реального времени, для компьютера PDP-11/23 с 32Kбайт и написанная на языке ассемблера. Специальный планировщик координировал деятельность всех одновременно исполняющихся процессов. Задачи, запускавшиеся каждые 0,1 сек., разделялись на «критические», исполнявшиеся первыми, и «некритические». К критическим отнесены три приоритетных задачи (рис. 1):

• «Servo», ответственная за все операции, связанные с эмиссией радиационных пучков и доставкой их к месту назначения;
• «Housekeeper», выполнявшая верификацию всех параметров и ответственная за блокировку работы в случае возникновения нештатной ситуации, а также за сообщения о таких ситуациях;
• «Treat», управлявшая самим процессом лечения, который был разделен на 8 операционных фаз. В зависимости от значения переменной Tphase вызывалась одна из восьми подпрограмм, по окончании работы которой Treat — в зависимости от значений нескольких разделяемых с другими критическими и некритическими задачами переменных, вырабатывала план на новый цикл.

Рис. 1. Взаимодействие задач и подпрограмм в ПО для Therac-25

Одна из вызываемых Treat подпрограмм — Datent (Data entry) через разделяемую «флаговую» переменную Data_entry_complete взаимодействует с «некритической» задачей Keyboard Handler, которая управляет вводом информации с клавиатуры, исполняясь параллельно с Treat. Keyboard Handler распознает момент окончания ввода и сигнализирует об этом, изменяя значение Data_entry_complete. В свою очередь, Datent проверяет значение этой переменной. Если оно не изменилось, то значение Tphase остается равным «1», и на следующем цикле Treat опять запустит Datent; если же значение Data_entry_complete изменилось, то Datent меняет значение Tphase с «1» на «3»; в результате после окончания работы Datent монитор Treat вызовет подпрограмму Set Up Test, выполняющую проверку считающихся уже установленными параметров.

Необходимо упомянуть еще одну переменную MEOS ( Mode/Energy Offset), разделяемую между Datent, Keyboard Handler и еще одной некритической задачей Hand. Старшие байты MEOS используются подпрограммой Datent для установки одного из двух режимов облучения и величины энергии испускаемого потока, в то время как младшие используются параллельно работающей задачей Hand для установки коллиматора в положение, соответствующее выбранному режиму и энергии.

Оператор мог после ввода параметров режима и энергии редактировать эти величины по отдельности. Однако, здесь присутствовал тонкий момент — разработчики установили: об окончании процесса ввода (и редактирования!) параметров свидетельствует то, что все параметры заданы и курсор находится в командной строке, на предмет чего каждые 8 сек. (величина выбрана, исходя из некоторых технических соображений, связанных с инерционностью приборов) производится опрос переменной Data_entry_complete. Если в пределах этих 8 сек. курсор покидает командную строку и — после быстрого редактирования параметров — успевает вернуться на нее, то Keyboard Handler этого события просто не заметит, и соответственно, никак переменную Data_entry_ complete не изменит. Иными словами, потенциально существует возможность для следующей последовательности действий:

• Keyboard Handler отследил местонахождение курсора на командной строке и установил флаг Data_entry_complete;
• затем оператор изменил данные в MEOS;
• не заметив этого (если к моменту опроса курсор оказался вновь на командной строке), Keyboard Handler не переустанавливает флаг Data_entry_complete;
• тогда Datent уже не способна обнаружить изменение MEOS — она свою работу закончивает, установив Tphase=3 (а не Tphase=1, чтобы отработать еще один цикл и учесть изменения);
• тем временем, параллельно работающая Hand устанавливает коллиматор в положение, соответствующее младшим байтам MEOS (их установила ранее Datent), которые могли находиться в противоречии со старшими байтами этой разделяемой переменной (как раз и подвергшимся редактированию!). Специальных проверок для обнаружения такой несовместимости предусмотрено не было.

Сноровистая и уже набившая на этой работе руку операторша, в отличие от неторопливых инженеров AECL, скорректировала «режим» и вернула курсор обратно на командную строку очень быстро — уложившись в 8 сек. В итоге, проделанное ею изменение режима воспринято не было — он остался прежним (рентгеновским), а вот задаваемые параметры (включая находящиеся в младших байтах MEOS, критически влияющие на величину и направление потоков частиц) соответствовали электронному (фотонному) режиму. Последний штрих в катастрофическую картину внесли показания дозиметра, дававшего показания в «условных единицах» — то, что высвеченная «малая» величина дозы относилась к другому режиму и потому не подлежала рациональной оценке, операторше не пришло в голову.

Скорректировать данную ошибку удалось просто — введением еще одной разделяемой переменной, которая изменяла значение, как только курсор покидал командную строку. Настоящая беда, однако, заключалась в том, что ошибка такого рода (классическая ошибка, связанная с неправильной синхронизацией одновременно идущих процессов, использующих разделяемые переменные, и приводящая к «race condition») — была далеко не единственной.

Программная блокировка и ее последствия

Рассмотрим еще один инцидент с Therac-25, которому суждено было стать последним. Он произошел в Yakima Valley Memorial Hospital (штат Вашингтон) в январе 1987 г. Пациенту было предписано сначало проделать два рентгеновских снимка с дозой в 4 и 3 рад соответственно, а затем произвести в фотонном режиме облучение в 86 рад. Все это и было выполнено, однако, как потом было установлено, пациент получил переоблучение фотонной дозой до 10000 рад. (Установлено было «потом», а не сразу — оператор, сделав снимки, забыл вынуть рентгеновскую пленку из-под пациента, из-за чего у него на консоли горели все те же 7 рад; однако, и правильная индикация уже выданной дозы была бы здесь как — в буквальном смысле слова — мертвому припарки).

Что же произошло? Выявленная в итоге расследования проблема выходит далеко за пределы частного случая еще одной программистской ошибки. В данном случае не сработала блокировка, реализованная программно позволившая прибору действовать (испускать поток фотонов) при ошибочной установке параметров. Ситуация возникла в момент, когда введенные параметры уже верифицированы подпрограммой Datent и монитор Treat в соответствии со значением переменной Tphase = 3 вызвал подпрограмму Set Up Test.

Во время установки и подгонки параметров подпрограмма Set Up Test вызывается несколько сотен раз — пока все параметры не будут установлены и верифицированы, о чем эта подпрограмма судит по нулевому значению разделяемой переменной F$mal. Если же значение ненулевое — цикл повторяется. F$mal, в свою очередь, устанавливается подпрограммой Chkcol (Check Collimator) из критической задачи Housekeeper, проверяющей, все ли с коллиматором нормально; а вызывает Chkcol другая подпрограмма задачи Housekeeper под названием Lmtchk (analog-to-digital limit checking), и вызов этот происходит, только если значение разделяемой переменной Class3 ненулевое. А ненулевым его делает как раз сама Set Up Test, которая (пока F$mal=0) каждый раз выполняет над Class3 операцию инкремента.

Эта переменная — однобайтовая, следовательно каждый 256-й проход заставляет ее сбрасываться в ноль. А ведь этот ноль — свидетельство, что все параметры, наконец, установлены. Если повезет, что именно в этот момент оператор нажмет клавишу «set» для запуска установки коллиматора в надлежащую позицию (а он это может сделать в любой момент, так как уверен, что система позволит коллиматору начать позиционироваться, только если все параметры заданы и верифицированы), то основываясь на случайно возникшем нулевом значении Class3, подпрограмма Lmtchk уже не станет вызывать Chkcol, а значит установить ненулевое значение F$mal будет некому. Иными словами, в ситуации, когда параметры не установлены должным образом (в данном конкретном случае «челюсти» коллиматора были еще раскрыты слишком широко), программная блокировка не сработала: Set Test Up установила Tphase = 2, что позволило монитору Treat прекратить цикл вызова Set Up Test, а инициализировать подпрограмму Set Up Done, по существу запускающую процесс излучения, который и потек бурным потоком, а не узеньким ручейком, как предполагалось.

Коррекция этой ошибки также выполняется просто — вместо выполнения инкремента переменной Class3 следует просто присваивать фиксированное ненулевое значение. Вот от каких, казалось бы, мелких и чисто технических ляпсусов программиста может зависеть жизнь человека!

Некоторые итоги

История с Therac-25 показательна, прежде всего, своей комплексностью: если в случае с Ariane 5 авария случилась один раз и из-за единственной ошибки, то катастрофические последствия с Therac-25 проявлялись неоднократно в течение длительного времени, и были следствием целого спектра причин, среди которых не только вполне конкретные программистские «баги», но и дефекты в самой постановке выполнявшегося многие годы проекта.

Можно долго перечислять проявившиеся в этом проекте проблемы, например, касающиеся принципов построения человеко-машинного интерфейса (выдаваемые оператору сообщения о критических с точки зрения безопасности ситуациях выглядели как рутинные; при этом не включалась блокировка, препятствующая дальнейшей деятельности оператора и т.д.). Все это является отражением того факта, что — как позволяет утверждать ставшая доступной информация о проектных и технологических особенностях разработки — квалификация коллектива разработчиков и организация их работы не позволяли реализовать столь сложный и тонкий проект с обеспечением безопасности функционирования, необходимой в данной предметной области.

Что же до системной «глобальной особенности», то к ней можно отнести принципиальную переусложненность построения мультизадачной управляющей системы. С чисто программистской точки зрения можно отметить, что для реализации тонкой синхронизации параллельных процессов был выбран механизм разделения переменных, требующий очень внимательной проработки (это именно та область, где необходимо выполнять формальное доказательство правильности алгоритма, благо соответствующие методы разработаны и могут считаться рутинными — для тех, кто ими владеет); получилось же так, что потенциально опасные в плане возникновения «race conditions» операции типа «set» и «test» не были сделаны «неделимыми» (indivisible), что и привело к наложению друг на друга их «критических секций» и — соответственно — к печальным последствиям.

Можно выделить и такой фактор, как переоценка уровня безопасности, в принципе гарантируемого программным обеспечением. Это послужило стимулом заменить используемые в предыдущих версиях системы защитные механизмы, которые контролировали радиационные потоки и блокировали их в случае выхода из нормального режима, с «аппаратных» блокираторов (на базе электронно-механических устройств) на чисто программные. Роковую роль сыграло и отсутствие должным образом поставленной системы контроля и исследования природы задокументированных инцидентов, а также некорректные процедуры оценки риска, которые не учитывали специфику ПО. Каждый раз после очередного случая с переоблучением производитель утверждал, что причина выяснена и корректирующие действия предприняты; это не было ложью, но потребовалось два года, чтобы от исправления частностей (которые не делали систему безопаснее) перейти, наконец, к трезвой оценке глобальных особенностей проекта, изменить дисциплину разработки и выполнить корректный анализ рисков.

Мифы о безопасности ПО

Катастрофы с Ariane 5 и Therac-25, сами по себе беспрецедентные, конечно же не являются уникальными. Можно привести длинный список больших и малых инцидентов в системах, относящихся к классу mission-critical, произошедших по причине дефектов в программном обеспечении и проявившихся только в режиме эксплуатации. Конечно, большинство инцидентов так или иначе расследовалось и осмыслялось. К сожалению, специфика «ответственных» систем часто такова, что это осмысление не становилось достоянием всего программистского сообщества — поэтому, неудивительно, что в разное время и в разных местах повторялись сходные ошибки. Соответственно, слишком многие приобретают специфические знания и опыт на практике, методом проб и ошибок, которые — как лишний раз показывает разобранные инциденты — обходятся дорого.

Что же может предложить в этом отношении наука? Только недавно общесистемные и общеинженерные дисциплины «Безопасность Систем» (System Safety) и «Управление Рисками» (Risk Management) начали настраиваться на ту выраженную специфику, которую имеют программно-аппаратные комплексы в контексте их разработки, эксплуатации и сопровождения. Крупнейший специалист в данной области профессор Вашингтонского Университета Нэнси Левесон (Nancy Leveson) ввела даже специальный термин Safeware, который вынесла в название своей книги [7] — пока единственной в мировой литературе, где систематически рассматриваются вопросы безопасности и рисков в компьютерных системах. В частности, в этой книге разбираются некоторые распространенные мифологические представления о ПО и связанных с ним безопасности и рисках, бытующие на фоне все более широкого использования сложных систем в потенциально опасных приложениях. Остановимся на некоторых из них.

О «дешевом и технологичном» ПО

Бытует мнение, что стоимость программно-аппаратных систем обычно меньше, чем аналоговых или электромеханических, выполняющих ту же задачу. Однако, это миф, если, конечно, не говорить о «голом» hardware и однажды оплаченном ПО, сработанном «на коленке». Стоимость написания и сертификации действительно надежного ПО очень высока; к тому же необходимо принимать во внимание затраты на сопровождение — опять же такое, которое не подрывает надежности и безопасности. Показательный пример: только сопровождение относительно простого и не очень большого по объему (около 400 тыс. слов) программного обеспечения для бортового компьютера, установленного на американском космическом корабле типа Shuttle, стоит NASA 100 млн. долл. год.

Следующий миф заключается в том, что ПО при необходимости достаточно просто модифицировать. Однако, и это верно только на поверхностный взгляд. Изменения в программных модулях легко выполнить технически, однако трудно сделать это без внесения новых ошибок. Необходимые для гарантий безопасности верификация и сертификация означают новые большие затраты. К тому же, чем длиннее время жизни программы, тем более возрастает опасность вместе с изменениями внести ошибки — например, потому, что некоторые разработчики с течением времени перестают быть таковыми, а документация редко является исчерпывающей. Оба примера — что с Ariane 5, что с Therac-25 вполне подтверждают эту точку зрения. Между тем, масштабы изменений в ПО могут быть весьма велики. Например, ПО для космических кораблей типа Shuttle [8] за 10 лет сопровождения, начиная с 1980 г., подверглось 14-ти модификациям, приведшим к изменению 152 тысяч слов кода (полный объем ПО — 400 тысяч слов). Необходимость модернизации ПО диктовалась периодическим обновлением аппаратной базы, добавлением функциональности, а также происходило по причине необходимости исправления выявленных дефектов. По оценке независимых экспертов, эти модификации поначалу не сопровождались должными процедурами по поддержке безопасности, однако, случившаяся в 1986 г. авария с кораблем Challenger, которая хотя и произошла по причинам, не связанным с ПО, послужила толчком к пересмотру всей политики NASA в области безопасности, затронув и область ПО.

Наконец, вряд ли справедливо мнение, что все более входящий в практику принцип повторного использования ПО дает повышенные гарантии безопасности.

Мысль о том, что использование имеющего длительную историю и уже зарекомендовавшего себя с положительной стороны модуля, равно как и «коробочного» продукта, дает гарантии отсутствия в нем ошибок, весьма естественна с точки зрения «здравого смысла» и способна притупить бдительность. На самом деле повторное использование программных модулей может и понизить безопасность по той простой причине, что данные модули изначально разрабатывались и отлаживались для использования в ином контексте, а спецификация обычно не дает исчерпывающего отчета о всех видах возможного поведения модуля (произошедшая с Ariane 5 авария имеет основной причиной именно повторное использование модуля с некорректной для изменившегося контекста спецификацией).

В случае с Therac-25 большой вклад в произошедшие инциденты внесли модули, изначально разработанные для предыдущей версии системы (Therac-20) — во всяком случае, было точно установлено, что именно ошибки в этих повторно-используемых модулях вызвали по крайней мере два смертных случая. Причем, эти ошибки (как уже было установлено задним числом) проявлялись и при работе Therac-20, но та система была устроена так, что массивного переоблучения не происходило, а потому и процесс коррекции ошибок не запускался.

Можно привести еще несколько любопытных иллюстраций к проблемам, связанным с повторным использованием. Так, попытка внедрить в Англии программную систему управления воздушным движением, которая до того несколько лет успешно эксплуатировалась в США, оказалась сопряжена с большими трудностями — ряд модулей весьма оригинальным образом обращались с информацией о географической долготе: карта Англия уподоблялась листу бумаги, согнутому и сложенному вдоль Гринвичского меридиана, и получалось, что симметрично расположенные относительно этого нулевого меридиана населенные пункты накладывались друг на друга. В Америке, через которую нулевой меридиан не проходит, эти проблемы никак не проявлялись. Аналогично, успешно функционировавшее авиационное ПО, изначально написанное с неявным прицелом на эксплуатацию в северном полушарии, создавало проблемы, когда его стали использовать при полетах по другую сторону экватора. Наконец, ПО, написанное для американских истребителей F-16, явилось причиной нескольких инцидентов, будучи использованным израильской авиацией при полетах над Мертвым морем, которое, как известно, находится ниже уровня моря. Это лишний раз подтверждает мысль, что безопасность ПО нельзя оценивать в отрыве от среды, в контексте которой эксплуатируется вся система.

О «корректном» ПО

Заветная мечта (не столько программистов, сколько потребителей), чтобы в ПО не было ошибок, увы, никак не исполняется. И иллюзий на этот счет уже не осталось. Соответственно, утверждение, что тестирование ПО и/или «доказательство» его корректности позволяют выявить и исправить все ошибки, можно признать тем мифом, в который мало кто верит.

Причина очевидна. Прежде всего, исчерпывающее тестирование сложных программных систем невозможно в принципе: реально проверить только небольшую часть из всего пространства возможных состояний программы. В результате, тестирование может продемонстрировать наличие ошибок, но не может дать гарантию, что их нет. Как ядовито замечают Жезекель и Мейер [2], собственно, сам запуск Ariane 5 и явился весьма качественно выполненным тестом; правда, не каждый согласится платить полмиллиарда долларов за обнаружение ошибки переполнения.

Что же касается использования математических методов для верификации ПО в плане его соответствия спецификации, то оно (несмотря на оптимизм, особенно явный в 70-х г.) пока не вошло в практику в сколько-нибудь значительном масштабе, хотя и сейчас некоторые влиятельные специалисты продолжают утверждать, что это непременно случится в будущем. Вопрос, реалистично ли ожидать, что для систем масштаба Ariane 5 возможно выполнить полный цикл доказательства правильности всего ПО, остается открытым. Нет сомнений, однако, что для отдельных подсистем такая задача может и должна ставиться — уже приводились аргументы о полезности использования формальных методов при разработке механизмов синхронизации в Therac-25.

Формальные методы разработки — это тема специального большого разговора. Здесь же в качестве примера формального подхода, имеющего промышленные перспективы, упомянем только «B-Method» [9], получивший недавно широкое паблисити в связи с созданием ПО для автоматического управления движением на одной из линий парижского метро. Разработчик метода — Жан-Раймон Абриал (J.-R. Abrial), до того известный как создатель формального метода Z (вошедшего в учебные программы всех уважающих себя университетов), использовал идеи таких классиков, как Эдсгар Дийкстра (E.W.Dijkstra) и Тони Хоар (C.A.R.Hoare). Важно, что основанная на формализмах методология поддержана практической инструментальной средой разработки Atelie B (которая, кстати, не единственная).

Эта среда включает в себя инструменты для статической верификации написанных на B-коде компонентов и для автоматического выполнения доказательств, автоматические трансляторы из B-кода в Си и Ада, повторно-используемые библиотеки B-компонентов, средства графического представления проектов и генерации документации, гипертекстовый навигатор и аниматор, позволяющий в интерактивном режиме моделировать исполнение проекта из спецификации, и, наконец, средства по управлению проектом. При разработке ПО для метро, включавшего около 100 тысяч строк B-кода (что эквивалентно 87 тыс. строк на Ада) пришлось доказать около 28 тысяч лемм. Насколько этот подход (и аналогичные ему) будет востребован практикой, покажет будущее.

И все же, такого рода верификация все равно не способна решить все проблемы, в частности, потому, что требуется специфицирование «корректного поведения» программной системы на формальном математическом языке, а это может быть очень непросто. К тому же, источник многих потенциально опасных ошибок может быть не связан непосредственно с вычислительными и алгоритмическими аспектами. Например, в 1992 году большой резонанс получил произошедший в Англии случай, когда «пошел в разнос» компьютер на станции скорой помощи: причина — неожиданно проявившиеся трудности с синхронизацией процессов в условиях большого количества поступивших заявок.

О «надежном» ПО

Теперь — о менее очевидном мифе, который звучит так: программно-аппаратные системы обеспечивают заведомо большую надежность по сравнению с теми традиционными (например, электро-механическими) приборами, которые они заменяют.

Понятно, что аппаратные системы способны выдать случайный сбой, могут неправильно реагировать на изменившиеся условия окружающей среды и со временем изнашиваются. К тому же управление ими критически зависит от «человеческого фактора». А вот программное обеспечение ничему этому вроде бы не подвержено, а значит уже поэтому возложение на него функций, до того реализуемых на аппаратном или «операторном» уровне, уменьшает риски и повышает безопасность. И с этим очень хотелось бы согласиться, вот только рассмотренные частные случаи не позволяют — вероятность систематических проектных ошибок даже в программных разработках, выполняемых высококвалифицированными коллективами для требовательных заказчиков, совсем ненулевая.

В конце 80-х гг. такая влиятельная в оборонных кругах организация как British Royal Signals and Radar Establishment сделала попытку оценки распространенности дефектов в ПО, написанном для ряда очень ответственных систем. Оказалось, что «до 10% программных модулей и отдельных функций не соответствуют спецификациям в одном или нескольких режимах работы» [7]. Такого рода отклонения были обнаружены даже в ПО, прошедшем полный цикл всестороннего тестирования. Хотя большинство обнаруженных ошибок были признаны слишком незначительными, чтобы вызвать сколь-либо серьезные последствия, все же 5% функций могли оказывать разного рода значимое негативное воздействие на поведение всей системы. Примечательно, что среди прочего авторы исследования особо упомянули выявленную в одном из модулей неназванной системы потенциальную возможность переполнения в целой арифметике, что могло привести к выдаче команды приводу повернуть некую установку не направо (как следовало), а налево. Достаточно предположить, что речь в ПО шла об управлении ориентацией пусковой ракетной установки, чтобы представить возможные последствия.

Коварство программных ошибок и в том, что они могут проявиться далеко не сразу, иногда после сотен тысяч часов нормальной эксплуатации — как реакция на вдруг возникшую специфическую комбинацию многочисленных факторов. Так, установка Therac-25 вполне корректно работала в течение нескольких лет до первого переоблучения; и последующие зафиксированные инциденты происходили спорадически в течение 2.5 лет на общем «нормальном» фоне. NASA инвестировала огромные средства и ресурсы в верификацию и сопровождение программного обеспечения для космических кораблей Shuttle. Несмотря на это, за 10-летие с 1980 г. — времени начала использования ПО — выявлено 16 ошибок «первой степени серьезности» (способных привести к «потере корабля и/или экипажа»). Восемь из этих ошибок не были обнаружены своевременно и присутствовали в коде во время полетов, хотя, к счастью, без последствий. Зато во время полетов были задокументированы проблемы, возникшие от проявившихся 12 значимых ошибок, из которых три относились ко «второй степени серьезности» («препятствуют выполнению критически важных задач полета»). А ведь NASA имеет, может быть, самую совершенную и дорогостоящую комплексную систему процессов разработки и верификации ПО.

В то время как надежность аппаратуры может быть увеличена за счет ее дублирования, что резко нивелирует опасности от случайных сбоев, эквивалентного способа защиты от систематических программных ошибок не найдено (даже если некоторые вендоры, с подачи оторванных от практики исследователей, рекламируют методики и инструментарий, позволяющие разрабатывать «zero-defect software»). Впрочем, если бы методы производства идеального ПО существовали, то резонно предположить, что следование им потребовало бы нереалистично большого количества ресурсов и времени. Повсеместно, в том числе и при создании ответственных систем, наблюдаемая тенденция свидетельствует о движении в обратном направлении — в сторону снижения издержек, и стоимостных, и временных.

Наконец, как ни парадоксально это звучит, даже если бы компьютерные системы действительно были надежнее «традиционных», то это вовсе не обязательно означает, что они обеспечивают большую безопасность. Дело в том, что надежность ПО традиционно определяется степенью его соответствия зафиксированным в спецификациях требованиям; однако, часто бывает так, что ПО делает именно то, что ему и было предписано, и авария Ariane 5 — классический тому пример: и злополучное вычисление посторонней для полета величины горизонтального отклонения Инерциальной Платформы, и реакция на него вплоть до выведения из строя всех навигационных систем и бортовых компьютеров — все это случилось в полном соответствии с Требованиями, которые были частично унаследованы от Ariane 4 и не отражали новых реальностей. Более того, по сравнению с ошибками в коде именно спецификационные ошибки обычно ведут к более тяжелым последствиям — компетенции разработчиков ПО недостаточно для обнаружения таких ошибок. Программный комплекс — сложная система, однако реальный мир, отражаемый в спецификационных требованиях — еще более сложен и требует специальных экспертных знаний. Так что надежность ПО и его безопасность — понятия, хотя и перекрывающиеся, но не идентичные.

Фактически любая сложная программная система при определенных обстоятельствах способна вести себя неожиданно для разработчиков и/или пользователей. Вероятность такого поведения, особенно если оно может привести к тяжелым последствиям, следует реалистически оценивать и предусматривать специальные средства защиты, в том числе — уже не на уровне самого ПО, а на уровне всей системы. Собственно, авария с Ariane 5 продемонстрировала это в полной мере: реагируй система на выброшенное исключение не столь радикально, аварии бы не произошло — ведь сам полет проходил нормально, но этот «глобальный контекст» просто не принимался во внимание!

Аналогично, катастрофические последствия при использовании Therac-25 наступили не столько из-за ошибок, допущенных в ПО, сколько вследствие того, что на аппаратном уровне не было предусмотрено защиты против этих ошибок. Шлейф программных ошибок тянулся к Therac-25 от ранних версий этого сложного программно-аппаратного комплекса, но в предыдущей модели Therac-20 надлежащие аппаратные защитные механизмы были задействованы — от них отказались по соображениям достижения большей производительности. К тому же программных ошибок оказалось много: в каждом конкретном инциденте проявлялась одна из них, ее исправляли — затем следующий инцидент (уже со смертельным исходом) показывал, что исправлено не все. Безопасность — это свойство всей системы, а не только ее программного компонента.

Эпитафия

Очевидный урок: приводящие к катастрофическим последствиям дефекты в ПО являются результатом пренебрежения хорошо структурированными и стандартизованными инженерными методами и технологиями, которые, впрочем, должны применяться в контексте контроля всех аспектов разработки и функционирования ответственных систем, включая «человеческий фактор». К сожалению, далеко не всем понятно, что разработка программно-аппаратных систем — это именно инженерный процесс, требующий продуманной и поставленной технологии и опирающийся на исполнителей высокой квалификации. Об этом не устают напоминать классики (например, Никлаус Вирт [10]), но слышат ли их?

На наших глазах повышается сложность программно-аппаратных систем, традиционно не относящихся к разряду mission-critical. Не за горами время, когда на массовый потребительский рынок начнут поступать программные комплексы, дефекты в которых могут оказаться крайне неприятными для неготовых к принятию риска «простых» граждан. В конце концов, даже обычный утюг способен вызвать пожар и наверное, какой-нибудь программно-управляемый супер-кухонный-комбайн XXI века может (при ПО надлежащего «качества») повести себя неожиданно (а то и опасно) для домохозяйки.

Между тем, сегодня на массовом рынке программных продуктов стандарты качества сознательно занижены (о чем мне уже доводилось писать применительно к производственной культуре Microsoft [11]). Торжествует «good enough software», когда критерии качества не имеют столь высокого приоритета, как удобство пользования, простота освоения и дешевизна — и все это в сочетании с избыточной функциональностью, пожирающей компьютерные ресурсы, и отсутствием у производителя стимула выбрасывать на рынок действительно отлаженный продукт. Весьма взрывчатая смесь. В обозримом будущем мы можем оказаться свидетелями катастрофических ситуаций, в которые попадут пользователи массовых продуктов, и, похоже, что только это способно сдвинуть ситуацию с ее нынешнего печального положения.

К тому же, функционирующий в соответствии с законами «массовой культуры» рынок обрастает глашатаями того же розлива, обслуживающими тех, кто заказывает музыку. Как и положено в шоу-бизнесе, музыка играет громко и агрессивно. К сожалению, именно в России, по сравнению с западными странами, нарушен баланс между «популярной» компьютерной периодикой и той, что ориентирована на программистов-профессионалов, которым не так просто найти материалы, полезные для совершенствования. В результате размываются критерии, и энтузиасты (которых можно, в зависимости от точки зрения отнести и к «хакерам», и к «чайникам»), освоившие какой-нибудь новомодный инструмент «за 21 день», считают себя готовыми к серьезной работе. А если найдутся менеджеры того же пошиба, которые им эту работу действительно доверят?

Небезынтересно в этом контексте упомянуть, что та же Microsoft пытается проникнуть на рынок «ответственных» систем; во всяком случае, она не прочь получить подряд на поставку большой партии Window NT для федеральных организаций, чья работа завязана на «обеспечение национальной безопасности». А для этого надо сертифицировать эту ОС на соответсвие одному из базовых уровней безопасности компьютерных систем С2 (в соответствии с критериями, определенными в «Оранжевой книге» Агенства Национальной Безопасности США). Хотелось бы, конечно, надеяться, что осваивая сегмент рынка с принципиально иными требованиями к продуктам, производители массового ПО поднимут планку качества и в своей традиционной вотчине. А ну как окажется наоборот?

И последнее. Все примеры в данной статье относятся к зарубежным системам. В России всегда была очень мощная отрасль mission-critical систем, выглядевшая вполне конкурентоспособно на общем мировом фоне. Отрадно, что и в нынешние турбулентные времена еще сохранились работоспособные коллективы. Однако с авариями самых разных видов и масштабов в России недостатка тоже никогда не было. Например, можно вспомнить о нескольких не столь давних авариях при пусках ракет — носителей, внешне очень похожих на катастрофу Ariane 5, да и произошедших примерно в то же время. Что нам известно об их причинах?

Эпилог

Что касается Therac-25, то после выполненной-таки в 1988 году капитальной ревизии комплекса и коррекции ряда проектных и реализационных решений, ни о каких новых инцидентах не сообщалось.

Первый после аварии запуск Ariane 5 несколько раз откладывался и состоялся 30 октября 1997 г. Между тем, летопись катастроф при запусках ракет продолжала пополняться. Так, в августе 1998 г. взорвались при старте ракета Titan-4 (производства Lockheed Martin), выводившая на орбиту американский шпионский спутник (стоимость аварии оценена в 1.2 млрд. долл.), а неделей позже — ракета Delta-3 (производитель — Boeing), убытки — «всего» 225 млн. долл. В начале сентября та же судьба постигла украинскую ракету Зенит, стартовавшую с Байконура. Виновато ли в этих авариях ПО? Может быть, может быть?