Ловушки из прошлого

 

А. А. Захарченко

 

Ни научная дисциплина, ни серьезная профессия не могут основываться на технических ошибках министерства обороны и, главным образом, одного производителя ЭВМ.

Эдсгер Дейкстра (EWD498)

 

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

Следствием высокой сложности разработки программ для первых ЭВМ стали уверенность в неизбежности ошибок и, как следствие, достаточно снисходительное к ним отношение. Компьютерный фольклор десятилетиями пополнялся историями, которые свидетельствовали о чрезвычайной «сырости» технологий. Несмотря на это, «романтики» безбумажной экономики упорно перекладывали на виртуальные мозги все больше проблем, подшучивая по случаю над незрелостью технологий разработки ПО [1]. Хотя бизнес сыграл важную роль в разработке и создании первых ЭВМ, но никто все же не предполагал, что компьютеры (а вместе с ними и ПО) внезапно окажутся товарами массового потребления и будут продаваться в супермаркетах рядом с аналогичным по качеству одноразовым хламом.

При подавляющей доле низкоуровневого кодирования в разработке ПО начала 1950-х естественным было значительное время отладки и существование удивительно «неуловимых» ошибок [2, 3]. Однако появление языков высокого уровня, различных методологий разработки и продвинутого инструментария для отладки ПО, сопряженное со сверхщедрым финансированием, положения дел существенно не улучшало. Так, из анализа ЧП космической программы «Аполлон» был сделан вывод о том, что почти все ее крупные неудачи стали непосредственным результатом ошибок в ПО [3, с. 30].

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

Ненадежность ПО стала привлекать к себе общественное внимание с началом массовой компьютеризации банков, торговли и конторской деятельности. Специалисты к тому времени уже прекрасно осознавали масштабы и причины этой ненадежности. К примеру, проверка эффективности солидных ассигнований, выделенных в 1985–1990 годах министерством обороны США на проекты систем управления полетами, показала, что 90 % из этих разработок так и не были завершены либо никогда не работали [4].

Поиск противоядия в виде методик верификации ПО [3] не принес особых улучшений – тривиальные ошибки (переполнение буфера, например) живут десятилетиями [5]. Встречались и «презабавнейшие» казусы, характеризующие уровень ответственности исполнителей за свою работу. Г. Майерс приводит показательный пример, когда профессиональный журнал опубликовал доказательство правильности программы из 25 строк, в которой затем обнаружили 7 ошибок [3, с. 319]. Поэтому публику уже долгое время продолжают убаюкивать юмористическими рассказами о безразмерных фантомных счетах к оплате, складской неразберихе, да программистах, получивших нулевой чек в день зарплаты, сразу же после «успешной» настройки бухгалтерской системы.

Между тем немало последствий компьютерных ЧП были далеко не столь забавными [6]. Годы работы многотысячных коллективов исследователей над беспилотными космическими экспедициями летели насмарку из-за чьего-то ротозейства. В 1996 году почти сразу же после старта взорвалась французская ракета-носитель Ariane 5. Причиной стала ошибка в непроверенном фрагменте кода, доставшемся по наследству от Ariane 4 и не игравшем никакой роли при взлете Ariane 5. Программисты искусно преодолели ограничения языка Ada, которые специально предназначены для предотвращения потери точности при преобразовании данных, но не удосужились проверить как их «мастерство» скажется на стабильности системы. В результате переполнение переменной в ненужном для полета фрагменте ПО «вышибло» сначала основную управляющую программу, а затем и резервную. Расследование показало, что из семи преобразованных переменных от переполнения были защищены только четыре. Остальным, по мнению разработчиков, эта неприятность никогда (?!) не грозила [7].

NASA потеряло Mars Climate Orbiter в 1999 году только потому, что некто перепутал фунты с ньютонами, направив станцию куда-то на марсианские кулички [8, с. 16]. А вот и совсем свежий пример: переполнение флэш-памяти марсохода Spirit [9] чуть было не пополнило и без того аномально большую череду неудач у Красной планеты.

В начале 1990-х Л. Хэттон показал, насколько ненадежным оказалось квазиинтеллектуальное ПО, используемое для анализа сейсмограмм при поиске новых нефтяных и газовых месторождений, а также для определения районов сейсмической опасности. Неопределенность прогнозируемых координат могла достигать 100 % [10].

Предположения о не слишком высоком уровне надежности военных систем [3, с. 30] стало невозможно отрицать еще в середине 1980-х [11]. Здесь мы видим любопытное ассорти: поражение корабля «дружественной» ракетой, ложную ракетно-ядерную тревогу, потерю двух третей управляющих команд при передаче приказов, разнообразные отказы систем управления вооружениями на боевом корабле, провал опыта по отражению лазерного луча, направляемого с вершины горы (перепутали футы с морскими милями!), провал запуска космического челнока вследствие рассинхронизации управляющих компьютеров из-за неуловимой ошибки (частота ее проявления составляла 1/67), внесенной в ПО при исправлении другой ошибки и т. д., и т. п.

Попытка привить «мозговой протез» набитому до отказа высокотехнологичными штучками сверхсовременному крейсеру Yorktown закончилась делением на ошибочно введенный оператором нуль. Паралич управляющей сети корабля превратил его на некоторое время (по разным источникам от получаса до двух часов) в громадный плавучий буй.

Система Patriot во время первой войны в Заливе прозевала вражескую ракету, которая в итоге убила под три десятка военнослужащих. Причина ошибки: недостаточная точность представления константы «0,1» (24 бита), используемой для определения времени. Для следящей системы накопившаяся со временем погрешность прогноза положения перехватываемой ракеты составила около семисот метров, что и предопределило промах. Интересно, что в отдельных фрагментах кода ошибка уже была исправлена (точность представления числа повышена до 48 битов), но до нужного места руки дошли только на следующий день после ЧП [12].

Военная и космическая области все же отличаются повышенным уровнем риска и, соответственно, частотой нештатных ситуаций, к которым заранее готовятся. Совсем иное дело, когда, к примеру, из-под компьютерного контроля выходит медицинская техника, и гибнут люди [3, с. 31]. Обслуживающий персонал чрезмерно полагается на компьютерное управление и не всегда способен быстро и, главное, правильно отреагировать на критическую ситуацию. Так, из-за просчетов при разработке интерфейса оператора ускорителя Therac-25 в процессе лучевой терапии опухолей шесть человек получили дозы облучения в сотни раз превышающие допустимые [13].

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

Сбои и отказы в сетях могут распространяться лавинообразно, и «эффект домино» стоимостью в миллиард долларов уже никого не удивляет. Так, единственная ошибка принесла в 1990 году At&T 1,1 млрд долл. убытков, отключив телефонную связь на 9 часов. Годом позже 12 млн человек остались без телефонной связи на Восточном побережье США, поскольку программистам, обслуживающим систему в 10 млн строк кода, не пришло в голову протестировать три строчки изменений.

В настоящее время крупнейшим (как по масштабам, так и по стоимости) компьютерным ЧП можно считать энергозатмение в США, случившееся 19 августа 2003 года. Уже в предварительном отчете «мозгового треста», расследовавшего причины каскадного отключения электроэнергии, под которое попали 50 млн жителей США и Канады, содержалось достаточно информации для такого вывода. Диспетчеры FirstEnergy на протяжении полутора часов не догадывались, что их система предупреждений об аварийной ситуации просто не работает. Полагаясь на устаревшую информацию, они игнорировали тревожные предупреждения от служб перекрестного контроля, обнаружив аварию только после включения аварийного питания.

Характер компьютерных сбоев (резкое замедление обмена данными в сети, поочередное падение с минимальным временным промежутком основного и резервного сервера контрольно-управляющей системы) вызвал достаточно обоснованные предположения, что одной из основных причин крупнейшего ЧП мог стать сетевой червь Blaster [14]. В окончательном отчете [15] следственная комиссия отвергла эту гипотезу, как и бахвальство «хакеров-террористов» [15, с. 131–137]. Видимо в силу отсутствия вирусно-диверсионной составляющей этот отчет не привлек к себе сколько-нибудь заметного внимания. Надо полагать, что с «обычными» компьютерными ошибками все уже давно свыклись.

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

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

ЛИТЕРАТУРА

1. Тихонов В. Теория ошибок (http://lib.ru/anekdoty/errors.txt).

2. Wilkes M. V. Memoirs of a Computer Pioneer. MIT Press, 1985. – 200 p.

3. Майерс Г. Надежность программного обеспечения. Пер. с англ., М.: Мир, 1980. – 360 с.

4. Hatton Les. Some notes on software failure. (http://www.leshatton.org/RS_1001.html).

5. Hatton Les. Repetitive failure, feedback and the lost art of diagnosis (http://www.leshatton.org/JSS_1099.html).

6. http://www.cs.tau.ac.il/~nachumd/horror.html (К сожалению много ссылок на сайте уже не

работают).

7. Hatton Les. The Ariane 5 bug and a few lessons (http://www.leshatton.org/Documents/Ariane5_ STQE499.pdf).

8. ftp://ftp.hq.nasa.gov/pub/pao/reports/1999/MCO_report.pdf.

9. http://www.compulenta.ru/news/2004/2/2/44831.

10. Hatton Les. The T-experiments: errors in scientific software. IEEE Computational Science and Engineering, 1997, 4(2), p. 27–38.

11. Lin H. The development of software for ballisticmissile defense. Scientific American, vol. 253, no. 6 (Dec. 1985), p. 48.

12. Arnold D. Patriot Missile Failure (http://www.ima.umn.edu/~arnold/455.f96/disasters.html).

13. http://www.cs.washington.edu/research/projects/safety/www/papers/therac.ps.

14. Schneier Bruce. Blaster and the August 14th Blackout. CRYPTO-GRAM, December 15, 2003 (http://www.schneier.com/crypto-gram.html).

15. http://www.iwar.org.uk/cip/resources/blackout-03.

 

"Защита информации. Кофидент", №5, 2004