Насколько безопасна достаточная безопасность? Читатели с Восточного побережья заподозрят здесь смягченную и более общую формулу гораздо более важного вопроса: "Сколько в действительности снегоочистителей нужно городу?"
Однако, занимаемся ли мы расчисткой городских улиц или обработкой транзакций компании, во всех этих случаях мы сталкиваемся с тем же важным вопросом: каково соотношение риска и цены. В сфере программирования, в отличие от снегоочистителей, подходящая мера качества обслуживания значительно меняется от одной задачи к другой.
Бывает, что программное обеспечение ошибается достаточно часто, но цена каждой ошибки настолько мала, что она даже не принимается во внимание. Например, многим из нас приходилось в ответ на набор знакомого телефонного номера услышать мертвую тишину на другом конце провода или сообщение о неправильно набранном номере. Ошибка соединения - это следствие не совсем удачной разработки, но большого значения она не имеет. Вы повторяете набор номера, и все.
С другой стороны, есть ПО, используемые достаточно редко, но крайне важно, чтобы в этих редких случаях оно работало безупречно. Непредвиденная остановка химического завода, сборочной линии или даже одного-единственного ядерного реактора очень опасна, ее последствия могут стоить целую кучу денег - и все это может быть следствием одной незначительной ошибки.
В процессе разработки или отладки программного обеспечения следует формализовать и учесть в перспективе возможные последствия каждой из таких ситуаций. Простые модели часто не описывают существа проблемы. Например, сделав за день сотню телефонных звонков, вы будете гораздо более рассержены, если в одном из них вам придется ждать сигнала соединения пять минут (и никаких задержек при остальных звонках!), чем при постоянной задержке на три секунды при каждом из звонков, хотя суммарное время ожидания в каждом из случаев одинаково.
Здесь мы нуждаемся в оценке, придающей больше веса увеличенным задержкам, чем в той, которая основана на их арифметическом среднем. Критерий, задающий длительность задержки в 99 процентах случаев, подошел бы гораздо лучше.
Далее, никогда нельзя недооценивать особенности человеческого характера: исследования показали, что для пользователей предпочтительнее постоянные времена отклика системы, пусть даже секунда или более, чем меньшее среднее время отклика системы, но с большими отклонениями от этого среднего. Скажут ли они сами, что они именно этого хотели? Нет, но косвенные исследования утверждают, что это действительно так.
И как поступать с теми разновидностями риска, которые не могут быть обработаны обычными статистическими методами, поскольку события слишком редки, чтобы вывести надежную численную оценку? Наилучшим инструментом для решения таких проблем является FMEA, или Failure Modes and Effects Analysis (анализ видов ошибок и их последствий): систематический обезличенный обзор всех видов ошибок, которые только могут произойти, и их последствий.
Если бы метод FMEA был применен при разработке одной из старых версий компилятора Microsoft С, то, пожалуй, можно было бы предположить, что открытие файла с сообщениями об ошибках не является лучшей стратегией в случае, когда таким сообщением является "слишком много открытых файлов". Очевидная ошибка, после того как она проявила себя, не правда ли? Но неприятно, когда такая ошибка обнаружена пользователями.
Пользователи подчас становятся циничны, услышав о том, что разработчики допускают наличие ошибок в продаваемых продуктах, поэтому позвольте мне внести ясность: то, что я говорю о приемлемом риске, не значит, что я рассуждаю о приемлемости дефектов в программных продуктах.
Речь идет о том, что необходимо выяснить, какой уровень обслуживания пользователи сочли бы оптимальным как в нормальных, так и в аномальных условиях, и вести разработку с учетом этого критерия. Предварительное обсуждение, пусть даже и неприятное, всегда лучше, чем поиски виновников после того, как "случилось худшее".
ПИТЕР КОФФИ
Нам потребуется мера измерения, отражающая неприемлемость длительных задержек
