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

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

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

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

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

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

Непредсказуемый поток работ

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

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

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

Увеличение количества запросов

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

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

Отсутствие информации по изменениям

Данная проблема актуальна и для эксплуатирующего подразделения, и для конечных пользователей. При регулярном (и достаточно частом) выпуске релизов информация может быть представлена небольшим файлом описания релиза (release notes), который специалистам по поддержке посильно осознать за 15–20 минут. Еще удобнее, если это централизованный ресурс на портале, который позволяет видеть историю изменений по релизам и быстро корректируется в едином источнике при обнаружении ошибок в описании. А наличие ссылок, позволяющих быстро перейти от новой функциональной возможности к требованиям по ее реализации, позволяет дополнительно сократить долю инцидентов, передаваемых на решение разработчикам. При этом во многих случаях эта информация может извлекаться из ALM и публиковаться на доступном веб-ресурсе автоматически, не требуя дополнительных трудозатрат на обновление.

Недостаточно оперативная поддержка

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

Обычно внутренняя политика организации в той или иной форме отдает приоритет поддержке пользователей, однако никто при этом не подразумевает, что срыв планов разработки из-за необходимости решения инцидентов, — нормальная практика. Для решения ресурсного конфликта между разработкой и поддержкой в ряде случаев фиксируется верхняя граница доли времени разработчиков, выделяемой на поддержку, обычно на уровне 20–30%. Зафиксированная величина на самом деле не является жестким пределом сверху, а скорее дает некоторый ориентир для планирования работ, что действительно обеспечивает относительно оперативное решение инцидентов, но этого недостаточно. Дело в том, что в ряде случаев можно повысить надежность информационных систем и сократить трудозатраты на их эксплуатацию за счет оптимизации технических решений (например, реализации удобных средств администрирования учетных записей и прав), а также устранения проблем, приводящих к повторению инцидентов (например, оптимизации запросов к базам данных для повышения быстродействия). Но когда департамент эксплуатации инициирует соответствующие запросы, они попадают в общую очередь разработки, где и живут годами, постоянно вытесняемые более приоритетными запросами бизнеса. То есть привлечь ресурс разработчиков к решению вопросов эксплуатации, выходящих за рамки конкретного инцидента, бывает почти невозможно.

В этом случае также можно попробовать зафиксировать нижнюю границу доли времени, выделяемого разработчиками на запросы эксплуатирующего подразделения, и ввести контроль фактического использования этого времени. Тогда получим, например, те же 30% на вопросы эксплуатации, из них 20% — на решение инцидентов и 10% — на развитие по запросам департамента эксплуатации. Контроль расходования времени должен обеспечить фактическое выделение этих 10%, если только есть соответствующие запросы. При этом определять приоритеты запросов на изменения, поступающих от отдела эксплуатации, может комитет по управлению ИТ-услугами, что позволяет установить более четкую связь инициатив по оптимизации с качеством и стоимостью услуг.

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

Несоответствие решений и режима эксплуатации

Эта проблема более характерна для новых решений, как правило, реализуемых в рамках проектов, и проявляется в том, что при проектировании и разработке не учтены:

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

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

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

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

Дмитрий Исайченко (d.isaychenko@cleverics.ru) — директор по консалтингу, компания Cleverics (Москва).