Система должна работать без замечаний и сбоев не менее трех месяцев

Желание службы эксплуатации принять в сопровождение систему без единой ошибки понятно и разумно. Но в математической логике доказана неизбежность ошибок программного обеспечения, имеющего заданный уровень сложности. Известно, что неисправности, отказы, сбои в работе системы по времени их обнаружения (возникновения) образуют «корытообразную кривую»: в начале и в конце эксплуатации они возникают чаще, в середине количество неприятностей минимально. Эксплуатация стремится перепоручить устранение краевых (частых) ошибок разработчику, что вполне естественно. Но такова особенность программного обеспечения, что ошибки в работающих программах, тем более программных комплексах и информационных системах обнаруживаются даже спустя значительное время: автомобильные концерны целыми партиями отзывают выпущенные автомобили для замены бортовых программ, сайты производителей телефонов и фотокамер имеют специальные разделы, где размещаются версии «прошивок» с исправленными ошибками, обнаруженными после выпуска продукции на рынок, и т. д. Есть интересная статистика (представлена HP), согласно которой:

· «лучшие» системы обработки данных (системы реального времени) простаивают из-за сбоев девять часов в год;

· «выдающиеся» системы имеют 43 часа незапланированных простоев в год;

· «очень хорошие» — 87 часов;

· «средние» — 175 часов незапланированных простоев в год (при 250 часах плановых).

Считается, что «средние» системы обеспечивают 98-процентную доступность услуг. При этом требование готовности к работе «24 часа × 6 дней» или «18 часов × 7 дней» не является абсолютным, доступность должна определяться с позиций пользователя, а не системного администратора. Пользователь (заказчик) вправе решить, что для него лучше: самому опробовать новое решение, принимая риски возможных сбоев в работе не до конца отлаженной системы, или не рисковать и дождаться выпуска финальной версии программы, в которой вероятность возникновения ошибок будет существенно ниже.

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

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

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

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

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