Ситуация, когда руководитель проекта и руководитель службы эксплуатации с трудом находят взаимопонимание, а их мнения относительно внедряемого программного обеспечения резко различаются, общеизвестна. Понятно, что эксплуатация требует стабильности, в то время как проект порождает постоянные изменения, эту стабильность нарушающие. Но почему так часто оказывается, что автоматизированную информационную систему проще разработать, чем сдать в эксплуатацию, обеспечив сопровождение и развитие внедрённого продукта? Что есть эксплуатация для проектирования — друг или враг? Или обратный вопрос: проектный менеджер для службы эксплуатации — скорее враг или кто?
Источник противоречий
Чтобы ответить на заданные вопросы, необходимо понять поводы и причины борьбы противоположностей — проектирования и эксплуатации, проектного менеджера и «сопровожденца» (лучшего слова для обозначения этой должности еще не придумано). Без сложностей и обобщений дадим трактовку основных терминов в контексте нашей статьи.
В определениях видов эксплуатации ничего не изменилось за прошедшие два-три десятилетия. Под «опытной эксплуатацией» следует понимать эксплуатацию системы заказчиком в режиме параллельной работы с основной информационной системой, которая находится в «промышленной эксплуатации». В ходе опытной эксплуатации в систему может вводиться заведомо некорректная информация, поэтому результаты такой работы не используются для принятия бизнес-решений, а служат исключительно для сопоставления с результатами «старой» системы или с бизнес-требованиями заказчика (если система разрабатывалась не для замены существующей). Именно это и является главным отличительным критерием понятия «опытная эксплуатация»: результаты работы системы на этом этапе не должны использоваться в реальной деятельности предприятия.
«Опытно-промышленная эксплуатация» отличается тем, что получаемые результаты уже не вызывают сомнений и используются для принятия бизнес-решений. А общее с предыдущим видом здесь состоит в том, что автоматизированная информационная система еще не принята службой эксплуатации на свою ответственность. Система находится в зоне ответственности разработчика, который оперативно исправляет ошибки, вносит изменения, производит доработки, оптимизирует конфигурационные (настроечные) файлы. Другими словами, в ходе опытно-промышленной эксплуатации разработчик не только несет ответственность за созданную им систему, но и имеет все полномочия по ее доработке и настройке.
И в том и в другом случае заказчик (пользователь) может отказаться от новой системы и вернуть ее на доработку, равно как и разработчик может отозвать продукт из опытной (или даже опытно-промышленной) эксплуатации без значительного ущерба для бизнеса. Ответственность за использование результатов работы при этом несет заказчик, за устранение недоработок и ошибок — разработчик, а за регламентную поддержку оборудования и программного обеспечения должна отвечать служба эксплуатации. В таких условиях вполне естественно ограничить сроки опытно-промышленной эксплуатации, которая может быть только временной. В «промышленной эксплуатации» система эксплуатируется без каких-либо альтернатив, без дублирующих систем. И если случается ее незапланированная остановка (по любой причине), критичная для ведения бизнеса, если предприятие несет косвенные убытки, недополучая прибыль и теряя клиентов, то говорить о её возврате в опытную или опытно-промышленную эксплуатацию уже нельзя. Если два вида опытной эксплуатации по сути являются временными (допускающими остановку системы), то промышленная — это уже эксплуатация постоянная, стабильная.
При этом, как уже было сказано, эксплуатационная служба (инженеры, администраторы, сопровождение) несет полную ответственность за действующую систему, и разработчики не могут по своей воле вносить в неё какие бы то ни было изменения (настройки). Конечно, передача продукта в промышленную эксплуатацию не снимает с разработчиков ответственности за локализацию и исправление ошибок. Но разработчик не может что-либо делать в системе минуя службу эксплуатации. Мало того, каждый инцидент должен протоколироваться, а каждое исправление ошибки, каждая доработка — проходить тщательную проверку на предмет работоспособности решения. Необходимо проводить детальный анализ причин и вырабатывать план мероприятий по предотвращению подобных инцидентов в будущем.
Теперь перейдем к проекту. За последние два десятилетия как только не определяли проект! Но практически все определения в том или ином виде включают три обязательных компонента: временный характер, конкретная цель (задача), накладываемые ограничения. В контексте этой статьи важно, что любой проект носит временный, конечный характер. Постоянных проектов не бывает, в отличие от постоянной (промышленной) эксплуатации. В этой статье под проектом будем понимать целенаправленную деятельность по изменению сложившейся к данному времени системной ИТ-архитектуры предприятия (приложений, данных, оборудования) и её переводу к новому состоянию, определяемому как целевое.
Другими словами, проект стремится вывести системную архитектуру из устоявшегося состояния, в то время как основная цель службы эксплуатации (вот где противоречие!) — поддержка устойчивого состояния текущей системной архитектуры. Только в таком состоянии служба эксплуатации может гарантировать пользователям информационных систем и ресурсов услуги надлежащего качества в течение определенного периода времени.
Поняв первоисточник противоречий между проектным менеджментом и промышленной эксплуатацией информационных систем, рассмотрим четыре типичные конфликтные ситуации и способы их преодоления. Эти четыре требования далеко не бесспорны, но они задают свою геометрию отношений «проект против эксплуатации».
Система должна работать без замечаний и сбоев не менее трех месяцев
Желание службы эксплуатации принять в сопровождение систему без единой ошибки понятно и разумно. Но в математической логике доказана неизбежность ошибок программного обеспечения, имеющего заданный уровень сложности. Известно, что неисправности, отказы, сбои в работе системы по времени их обнаружения (возникновения) образуют «корытообразную кривую»: в начале и в конце эксплуатации они возникают чаще, в середине количество неприятностей минимально. Эксплуатация стремится перепоручить устранение краевых (частых) ошибок разработчику, что вполне естественно. Но такова особенность программного обеспечения, что ошибки в работающих программах, тем более программных комплексах и информационных системах обнаруживаются даже спустя значительное время: автомобильные концерны целыми партиями отзывают выпущенные автомобили для замены бортовых программ, сайты производителей телефонов и фотокамер имеют специальные разделы, где размещаются версии «прошивок» с исправленными ошибками, обнаруженными после выпуска продукции на рынок, и т. д. Есть интересная статистика (представлена HP), согласно которой:
- «лучшие» системы обработки данных (системы реального времени) простаивают из-за сбоев девять часов в год;
- «выдающиеся» системы имеют 43 часа незапланированных простоев в год;
- «очень хорошие» — 87 часов;
- «средние» — 175 часов незапланированных простоев в год (при 250 часах плановых).
Считается, что «средние» системы обеспечивают 98-процентную доступность услуг. При этом требование готовности к работе «24 часа × 6 дней» или «18 часов × 7 дней» не является абсолютным, доступность должна определяться с позиций пользователя, а не системного администратора. Пользователь (заказчик) вправе решить, что для него лучше: самому опробовать новое решение, принимая риски возможных сбоев в работе не до конца отлаженной системы, или не рисковать и дождаться выпуска финальной версии программы, в которой вероятность возникновения ошибок будет существенно ниже.
Есть и частные случаи, когда предприятие или организация ведет разработку автоматизированной информационной системы собственными силами. Это характерно для агрессивно настроенных молодых владельцев, работающих на рынке с быстро меняющимися условиями (например, банковский или страховой бизнес). Здесь для них важнее первыми выйти на рынок с новым продуктом, раньше других отреагировать на изменение ставок и другие события. Они не просто могут принять решение о собственной разработке, но и бывают готовы нести «риски ошибок» (связанные с ними потери из-за временной неработоспособности системы). Агрессивная, рискованная политика захвата рынка подразумевает вероятность убытков от простоев системы, которые будут все-таки малы в сравнении с объемами нового (разворачиваемого) бизнеса.
В целом проблема «бесперебойной работы системы в течение трех месяцев» сводится к тому, что если владелец или заказчик готов к определенным рискам из-за простоев новой системы, то консервативная и стабильная служба эксплуатации пойти на такие риски не может. Эксплуатация отвечает за сбои и простои и их сокращение считает своей главной целью, для чего и требуется трехмесячная гарантия разработчика, а служба поддержки пока слагает с себя ответственность за сопровождение системы. По сути здесь речь идёт о времени, которое необходимо администратору-неразработчику для освоения системы или прохождения курсов переподготовки. Но когда плацдарм на рынке уже захвачен, то требовать трехмесячной подготовки к бою (эксплуатации) уже поздно.
То есть при более пристальном рассмотрении три месяца работы без замечаний и сбоев оказываются не более чем карточным домиком. Кроме того, говорить о стабильности сложной информационной системы, интегрированной в пространство (ландшафт) инфраструктуры предприятия, можно только при условии стабильного функционирования всех других, смежных систем. Сложные информационные системы состоят из подсистем, которые взаимодействуют с внешними системами, являющимися поставщиками информации, а значит, и зависят от них. Отказ внешней системы, задержка информации, получение недостоверных данных — всё это означает приостановку или некорректную работу системы внутренней, потребляющей эту информацию. Надежность работы информационной системы является производной величиной от вероятности потери работоспособности, а когда таких систем несколько, то эта вероятность умножается. И говорить об отсутствии простоев в работе системы можно лишь условно, когда не анализировались причины сбоев других систем. В этом плане показательна приведённая ниже таблица.
Таким образом, три месяца работы без сбоев и замечаний хорошо для операционной системы, но на уровне прикладных программ это ненаучная фантастика. А решение проблемы может быть простым: тщательное протоколирование службой эксплуатации всех инцидентов, составление по каждому инциденту и для каждой подсистемы независимого протокола или акта (на основании оперативного аудита) с анализом причин и разработкой плана мероприятий для исключения подобных инцидентов в будущем. В акте обязательно должны указываться смежные системы — как вызвавшие инцидент, так и пострадавшие из-за него.
Штатные процедуры разбора произошедших инцидентов и принятых мер должны проводиться еженедельно (а не аврально) на уровне руководства ИТ-службы предприятия. Только при таком подходе можно ожидать постепенного снижения числа отказов и сбоев в работе информационных систем, находящихся в опытно-промышленной эксплуатации. В противном случае «известие о сбое» может быть истолковано той или иной стороной (проектной или эксплуатационной службой) в зависимости от преследуемых ею целей. Правда, отказов в службе эксплуатации, как правило, не бывает, все ошибки и сбои возникают только в проектах.
В систему, сданную в эксплуатацию, не должны вноситься изменения
И это требование в целом выглядит вполне понятно. Как служба сопровождения может гарантировать бесперебойную работу системы, если в нее вносится очередная серьезная доработка уже на этапе опытно-промышленной эксплуатации? С внесением каждой доработки, видимо, следует сдвигать срок опытно-промышленной эксплуатации, а то и начинать данный этап заново.
Однако работа систем в ситуации агрессивного развития бизнеса, оперативной разработки и вывода на рынок новых продуктов и услуг, постоянного изменения требований со стороны законодателей, регуляторов и партнеров ставит под вопрос возможность «невнесения исправлений в сданную в эксплуатацию систему». Это требование выглядит еще более абсурдно при одном только взгляде на издаваемые производителями компьютеров, сетевого оборудования, операционных систем и т. д. тома «заплаток» на бреши, которые каждый день вновь и вновь отыскиваются прыщавыми хакерами.
Анализируя эту проблему, в случае разработки системы собственными силами не следует недооценивать проблему заказчика и пользователя, которые не хотят или не могут сформулировать задание на целостную, комплексную разработку, оправдывая это постоянно меняющимися рыночными условиями, требованиями законодателей и регуляторов. Конечно, чаще всего компания-заказчик не является ни профессиональным проектировщиком, ни разработчиком, но это не должно служить оправданием для превращения in-house-разработки в «импровизацию на тему». У заказчика как ни у кого другого в первую очередь должен быть план на разработку, а не просто поток сознания, запечатленный в виде официально оформленных заявок на доделку недоделок.
Однако если руководитель бизнеса осознанно идёт на разработку системы собственными силами, это означает, что требования со стороны бизнеса будут изменяться постоянно и заказчик будет требовать их реализации немедленно, а не в течение года до следующей поставки очередной версии системы. Часто эти требования носят далеко не косметический характер и предполагают серьезную доработку (переделку) уже эксплуатируемой системы. При in-house-разработке проектная документация создается с учетом всех реализованных на конкретный момент требований, но требования реализуются и сдаются в эксплуатацию поэтапно. В результате очень редко возникают моменты (если новые требования долго не поступали), когда проектная документация полностью соответствует передаваемой в эксплуатацию системе.
Это широко распространенная проблема. Именно по этой причине подавляющее большинство автоматизированных информационных систем, по сути находящихся в промышленной эксплуатации, формально проходит постоянно продлеваемый этап опытно-промышленной эксплуатации. Но модернизировать (дорабатывать) можно только то, что введено в эксплуатацию. Проектный подход предполагает, что нельзя (не следует) дорабатывать и изменять то, что не введено в опытно-промышленную (три месяца) и постоянную (не ограниченную по времени) эксплуатацию, ибо доработка системы, которая не эксплуатируется, по сути есть разработка этой системы. Если от службы поддержки к проектировщикам нет задокументированных и развернутых в предложения замечаний, то система должна вводиться в промышленную эксплуатацию по умолчанию. Если замечания и предложения есть, тем более дорабатывать можно только то, что сдается-принимается в эксплуатацию (с обязательными доработками). Осознание и принятие службой эксплуатации этого факта поможет снять противоречие в «требованиях по невнесению изменений».
Разработчик не должен иметь доступа к «боевой системе»
Справедливое требование, выдвигаемое эксплуатационщиками, заключается в том, что разработчик не должен иметь доступа ни к данным, ни к коду систем, находящихся в промышленной эксплуатации. Первое ограничение связано с конфиденциальностью хранимой и обрабатываемой информации, второе — с ответственностью эксплуатационной службы за стабильную и устойчивую работоспособность системы.
Но в том, что касается конфиденциальности информации, получается абсурдная ситуация, когда служба эксплуатации является более «доверенным» подразделением, чем проектировщики, при том, что оба отдела работают на одно предприятие. Такое разделение можно считать справедливым, если система была введена (принята) в промышленную эксплуатацию. А опытно-промышленная эксплуатация явно предполагает доступ к системе разработчика, ограниченный только списком ответственных сотрудников.
Однако на практике требование конфиденциальности выполняется редко — какой заказчик будет готов платить деньги за разработку специальных программ генерации тестовых данных, их отладку и, что не менее важно, за поддержание этих программ в актуальном состоянии вместе с развитием основной функциональности самой системы. Поэтому зачастую разработка и отладка ведутся на копиях «живых», реальных данных, предоставляемых службой эксплуатации в виде копий с реальных баз данных.
Второе же требование — ограничение доступа к коду — трактуется и интерпретируется службой эксплуатации весьма жестко: разработчик вообще не должен иметь доступа к промышленной системе, ни к текущим настройкам, ни к версиям установленного программного обеспечения, ни к журналам с сообщениями об ошибках. Как результат разработчик при необходимости запрашивает диагностическую информацию в службе эксплуатации, которая предоставляет ее даже не на несколько часов, а на сутки. При этом выстраиваются сложные многоуровневые процедуры тестирования и приемо-сдаточных испытаний по передаче в эксплуатацию программ, настроечных файлов, документации. Все изменения устанавливаются в промышленную систему исключительно администраторами службы эксплуатации.
Несомненно, эти организационно-технические меры разумны и целесообразны при весьма важном условии: все действия администраторов автоматизированных информационных систем фиксируются в журнале аудита, который должен быть отделен от администраторов и доступен аудиту ИТ.
Служба эксплуатации должна быть во всеоружии!
И последнее требование. Под «всеоружием» каждый может подразумевать то, что приходит на ум ему и не пришло в голову оппоненту. Это может быть предложение по исчерпывающе полному комплекту документации, включая все смежные информационные системы, с которыми взаимодействует система, вводимая в эксплуатацию. Это может быть также полный комплекс программных средств администрирования, куда входят не только средства по управлению пользователями системы, но и инструменты для рассылки уведомлений, сбора статистики, оперативного мониторинга, причём с «нормальным» интерфейсом, понятным не только администратору, но и рядовому дежурному инженеру. И наконец то, что в службе эксплуатации недостаёт грамотных, хорошо обученных специалистов с должной для сопровождения системы квалификацией.
Против таких доводов устоять невозможно. Безусловно, без документации не обойтись, специалистов службы эксплуатации следует обучить, программы для администрирования пользователей должны быть разработаны, сбор статистки и мониторинг также необходимы. Руководитель постоянно должен планировать проектные работы с учетом этих факторов и на самых ранних стадиях проекта вовлекать в него эксплуатационную службу, чтобы лучше понять требования эксплуатации и начать работать над ними как можно раньше. Равномерное планирование работ над этими требованиями в ходе всего проекта во всех отношениях лучше, чем приостановка проекта «на финишной прямой», перед запуском системы в эксплуатацию, только для того, чтобы залатать допущенные в функциональности или в документации дыры. Тем более, что такие приостановки в глазах заказчика выглядят излишне вызывающе. Но следует учитывать, что все эти работы компания будет «оплачивать» из бюджета проекта. Насколько трудозатратны будут требования по приведению службы эксплуатации во всеоружие? Насколько увеличит бюджет реализация этих требований и насколько к этому увеличению бюджета и сроков будет готов заказчик проекта?
Что следует понимать под эксплуатацией
В заключение отметим, что регламентируя взаимоотношения между проектами и эксплуатацией, следует заранее определить понятия, зафиксировать, что является опытной эксплуатацией, что опытно-промышленной, а что — промышленной эксплуатацией автоматизированных информационных систем. Если эти понятия не определить, не описать процедуру передачи и сопровождения систем, то через какое-то время множество критических для бизнеса приложений будет «плавать» в состоянии опытной эксплуатации.
Но чем это плохо? Только тем, что нет одного ответственного за сбои? Не только: дело в том, что в этих случаях ресурсы проектировщиков не высвобождаются для других проектов. А насколько они велики? Ведь если говорить о проектах закупки и внедрения систем, то они требуют уже других ресурсов…
Подчеркнем еще раз, что разработка программного обеспечения и создание автоматизированной информационной системы (совокупности функциональной части, технического, информационного, программного, организационного обеспечения, коммуникаций и персонала) — это разные не по масштабам, а по содержанию проекты. Программы в основном разрабатываются in-house, включая сложные программные системы. И гораздо реже покупаются в готовом виде. Но «информационные системы» в принципе делаются на заказ. Хотя часто это «внутренний заказ», и разработка системы ведется in-house (собственными силами). Поэтому ввод прикладной системы в действие, например, в банке не означает ее опытную, опытно-промышленную и даже промышленную эксплуатацию. Это — использование системы заказчиком, сопровождение программного обеспечения разработчиком и обеспечение работоспособности (эксплуатации) системы службой поддержки. Развитие информационной системы в ходе постоянной эксплуатации — неизбежность ее жизненного цикла. Не признавать этого — лукавство….
Основным выводом, который следует сделать из «противопоставления» проекта и эксплуатации, будет следующее: опытная и опытно-промышленная эксплуатация не является по своей сути эксплуатацией промышленной. На этих этапах полная ответственность лежит на проектировщиках и разработчиках, эксплуатационная служба не несет ответственности за эксплуатацию разработанной автоматизированной системы, и здесь единственно возможным решением может стать организация внутри проекта собственной службы тестирования и администрирования системы.
Для этой цели можно выделить необходимые ресурсы из смежных подразделений либо привлечь в проект специалистов необходимой квалификации (на временной основе) извне. При таком подходе за счет увеличения сроков опытной и опытно-промышленной эксплуатации количество внедрений в эксплуатацию промышленную может быть резко сокращено. Ответственность за опытную эксплуатацию в полной мере будет нести проектная команда, не затрагивая компетенции и не перекладывая непомерно высоких рисков на службу эксплуатации.
Обсудите это с вашим проектным менеджером и службой эксплуатации. Кто из них окажется готов взять на себя ответственность и риски опытно-промышленной эксплуатации «рабочих версий» системы, тот вместе с ответственностью должен будет получить и необходимые для этого права!
1. Впрочем, авторам приходилось встречать и «перманентные» проекты, которые не имели ни четко очерченных сроков, ни зафиксированных целей и задач. Точнее, цели и задачи были, но они постоянно менялись, дополнялись, расширялись, уточнялись, и, соответственно, сроки постоянно сдвигались, плыли, переносились. Это, видимо, было выгодно всем участникам проекта, ибо снимало с них какие бы то ни было обязательства по достижению конкретных целей и завершению «проекта» в обозримые сроки.
