Что разъединяет их и что объединяет - индивидуальные особенности или специ

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

Чтобы ответить на эти вопросы, необходимо понять поводы и причины «борьбы противоположностей» — проектирования и эксплуатации, проектного менеджера и специалиста по сопровождению.

Варианты эксплуатации

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

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

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

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

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

Стабильность и развитие

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

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

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

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

  • лучшие системы обработки данных (системы реального времени) простаивают из-за сбоев девять часов в год;
  • выдающиеся — 43 часа незапланированных простоев в год;
  • очень хорошие — 87 часов;
  • средние — 175 часов незапланированных простоев в год (при 250 часах плановых).

Считается, что средние системы обеспечивают 98-процентную доступность услуг автоматизированной системы. Тип готовности к работе «24 часа х 6 дней» или «18 часов х 7 дней» не так важен. Доступность должна определяться с позиций пользователя, а не системного администратора.

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

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

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

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

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

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

2. В систему, сданную в эксплуатацию, не должны вноситься изменения. Этот постулат в целом выглядит вполне логично. Как служба эксплуатации может гарантировать бесперебойную работу системы, если в нее вносится очередная серьезная доработка уже на этапе опытно-промышленной эксплуатации? Внесение каждой доработки, видимо, должно вызывать сдвиг срока завершения опытно-промышленной эксплуатации, или начало опытно-промышленной эксплуатации каждый раз заново.

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

При анализе этой проблемы для системы, созданной собственными силами, не следует недооценивать роли заказчика и пользователя, который не хочет или не может сформулировать задание на достаточно целостную, комплексную разработку и оправдывает это постоянно меняющимися рыночными условиями, требованиями законодателей и регуляторов. Нужно понимать, что чаще всего заказчик — не профессиональный проектировщик или разработчик, но это не должно служить оправданием превращения собственной внутренней разработки в «импровизации на тему». У заказчика, как ни у кого другого, в первую очередь должен быть план на заказной проект, а не просто «поток сознания», запечатленный в виде официально оформленных заявок на доделку недоделок. Еще вопрос: чья вина в их появлении?

Если владелец бизнеса, заказчик осознанно идут на разработку системы собственными силами, то это означает, что требования со стороны бизнеса будут изменяться постоянно, заказчик будет требовать их реализации немедленно, а не в течение года до следующей поставки очередной версии системы. Часто эти требования будут носить далеко некосметический характер и предполагать серьезную доработку (по сути, переделку) уже эксплуатируемой системы.

При собственной разработке проектная документация создается с учетом реализации всех имеющихся на конкретный момент времени требований, но требования реализуются и сдаются в эксплуатацию поэтапно. В результате довольно редко возникают ситуации, когда проектная документация полностью соответствует передаваемой в эксплуатацию системе.

Эта достаточно общая, широко распространенная проблема. Подавляющее большинство автоматизированных информационных систем, по сути находящихся в промышленной эксплуатации, формально находится в постоянно продлеваемой опытно-промышленной эксплуатации по этой причине.

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

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

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

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

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

Эти организационно-технические меры разумны и целесообразны при весьма важном условии: все действия администраторов автоматизированных информационных систем должны фиксироваться в журнале аудита, который должен быть отделен от администраторов, но доступен службе аудита ИТ (согласно требованиям стандарта ЦБ РФ по информационной безопасности банковской системы).

4. Служба эксплуатации должна быть во всеоружии! Под этим каждый может подразумевать то, что приходит на ум ему и не пришло в голову оппоненту. Это может быть и исчерпывающе полный комплект документации вводимой в эксплуатацию системы и всех смежных информационных систем, с которыми вводимая в эксплуатацию система взаимодействует. Это может быть и полный комплекс программных средств администрирования, включая не только средства по управлению пользователями системы, но и средства по рассылке уведомлений, сбора статистики, оперативного мониторинга.

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

Против таких доводов устоять невозможно. Безусловно, документация должна быть, специалисты службы эксплуатации должны быть обучены, программы для администрирования пользователей должны быть разработаны, сбор статистки и мониторинг также должны быть. Проектный менеджер каждый раз должен планировать работы по проекту с учетом этих факторов и вовлекать службу эксплуатации на самых ранних стадиях проекта для более точного понимания требований и раннего начала работ над этими требованиями.

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

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

Что следует понимать под эксплуатацией

Регламентируя взаимоотношения между проектными службами и службой эксплуатации, следует заранее определить понятия, зафиксировать, что считается и является опытной эксплуатацией, что — опытно-промышленной, а что — промышленной эксплуатацией автоматизированных информационных систем. Если не определить эти понятия и не описать процедуру передачи и сопровождения систем, то через какое-то время множество критически важных приложений будут «плавать» в состоянии опытной эксплуатации.

Чем это чревато? Тем, что нет одного ответственного за сбои? Не только — ведь ресурсы проектировщиков не высвобождаются для других проектов. А насколько эти проекты и эти ресурсы велики? Если говорить о проектах закупки и внедрения систем, то они требуют уже других ресурсов…

Разработка программного обеспечения и разработка автоматизированной информационной системы — совокупности функциональной части, технического, информационного, программного, организационного обеспечения, коммуникаций и персонала — это разные не по масштабам, а по содержанию проекты. Программы всегда разрабатывались собственными силами, включая достаточно сложные программные системы. Гораздо реже программы или программные продукты покупаются в готовом виде. Но информационные системы в принципе делаются только на заказ. Часто это внутренний заказ, и разработка системы ведется собственными силами, поэтому ввод прикладной системы в действие, например в банке, не означает ее опытную, опытно-промышленную и даже промышленную эксплуатацию, поскольку это использование системы заказчиком, сопровождение программного обеспечения разработчиком и обеспечение работоспособности (по сути, эксплуатации) системы службой поддержки. Развитие системы в ходе постоянной эксплуатации — неизбежная особенность жизненного цикла информационной системы. Не признавать этого — лукавство.

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

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

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

Виктор Галактионов — главный системный архитектор, директор департамента управления архитектурой АКБ «РосЕвроБанк» (ОАО); vgalax@mail.ru
Юрий Орлов — независимый эксперт; vodolei1@mail.ru

Таблица. Показатели надежности компонентов в сложной системе