Валерий Аджиев - Мифы о безопасном ПО - уроки знаменитых катастроф
Обзор книги Валерий Аджиев - Мифы о безопасном ПО - уроки знаменитых катастроф
Аджиев Валерий
Мифы о безопасном ПО - уроки знаменитых катастроф
Сферу применения Windows вообще надо ограничить использованием в быту и метлой гнать из корпоративных систем в силу безнадежной убогостью в плане безопасности и надежности. Оставить только как одну из систем для кухарок и прочих пользователей, для которых проблема надежности не столь критична.
Вот статейка про ПО вообще и ОС в частности:
Валерий Аджиев
Мифы о безопасном ПО: уроки знаменитых катастроф
Катастрофа Ariane 5 Инциденты с Therac-25 Мифы о безопасности ПО Эпитафия Эпилог Литература
"Если бы строители строили здания так же, как программисты пишут программы, первый залетевший дятел разрушил бы цивилизацию"
Второй закон Вейлера
Не секрет, что ошибки в программном обеспечении "ответственных" систем могут вызвать чрезвычайные последствия, тем не менее, в обществе, особенно на уровне массового потребителя ИТ, продолжает витать иллюзия непогрешимости компьютера и работающего на нем ПО. В статье подробно разбираются две вошедших в историю компьютерной индустрии катастрофы и обсуждаются некоторые мифы, связанные с такими понятиями, как безопасность и риски в контексте разработки и эксплуатации программно-аппаратных систем.
Слово "безопасность" не сходит со страниц компьютерной прессы. Однако, употребляется оно обычно в контексте поддержания целостности данных и особенно обеспечения их конфиденциальности. Что ж, тема интересная:
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 (где этот программный модуль использовался ранее), что и привело к значительно более высокой "горизонтальной скорости".
