Паранойя на марше

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

"Выживают только параноики"
Эндрю Гроув, Intel

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

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

Возможно, если бы софт писался самими компьютерами, он и был бы свободен от ошибок, но человек неидеален, и баги остаются проклятием индустрии программного обеспечения. Строго говоря, сама ошибка не страшна - страшно её проявление. В среднем, как гласит статистика, программист (вне зависимости от его квалификации!) делает около 50 ошибок на каждую тысячу строк некомментируемого кода (G.Holzmann, NASA). Тестирование софта позволяет уменьшить это число пятикратно, однако всестороннее тестирование, предполагающее три стадии проверки, во-первых, проводится не всегда в полном объёме, а во-вторых, оно не в состоянии выявить всех ошибок. Известное эмпирическое правило гласит, что от компьютерной программы можно ожидать безошибочной работы в течение такого же периода времени, в течение которого она тестировалась. Применение искусственных моделей для тестирования позволяет сократить сроки проверки качества. И всё же, малейшее изменение условий способно вынести на поверхность скрытые программные дефекты.

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

Но и избыточность - не панацея от всех бед. Существует класс ошибок, которые остаются невидимыми даже при работе программы на разных платформах: попросту говоря, если программа использует неправильную формулу, результат вычислений будет неправильным вне зависимости от того, на каком процессоре идёт работа. Классический пример такой ошибки известен опять же из практики NASA: в 1981 году в программном обеспечении бортовых компьютеров Space Shuttle была найдена именно такая ошибка, к счастью, не успевшая себя проявить. И это несмотря на то, что все компьютеры Space Shuttle дублируют друг друга, их архитектура уходит своими корнями в 60-ые (4Pi AP-1 от IBM, избранные NASA, являются дальними потомками мейнфреймов IBM System 360), со дня начала разработки софта для них прошло почти десять лет, а по степени контроля за качеством разработки с этим проектом не сравнится ни один другой в истории вычислительной техники (возможно, только советские космические программы, но о них почти ничего не известно).

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