Управление изменениями IT инфраструктуры Центра информационных технологий валютного рынка

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

Работа посвящена модернизации процесса управления изменениями IT инфраструктуры Банка. Целью работы является моделирование и реализация процесса управления изменениями в IT инфраструктуре организации в интересах решения стратегических задач, определенных топ менеджментом организации.

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

Процесс управления изменениями по ITIL состоит в контроле за изменениями в IT инфраструктуре в интересах исполнения действительно необходимых изменений и снижения риска сбоя в результате изменений.

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

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

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

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

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

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

Остановимся на реализации существующего процесса управления релизами подробнее.

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

В различных проектах применяются различные технологии развертывания, управление релизами децентрализовано. Это, с одной стороны, дает возможность независимого внедрения изменений в разные IT системы, но с другой стороны каждая команда “изобретает велосипед” при реализации процесса (или уже его изобрела). Обмен опытом затруднен, т.к. области, в которых функционируют приложения слабо связаны (нет прямого информационного обмена). Даты выхода в продакшн не всегда согласованы. Любое изменение в совместно используемом компоненте крайне рисковано, т.к. не обладает единственным владельцем.

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

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

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

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

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

Плановый релиз – это совокупность определенных заранее, своевременно подтвержденных и приоритизированных изменений с запланированной датой реализации.

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

С точки зрения управления изменениями плановый релиз – это изменение, обладающее высокой степенью риска. Это связано с объемом изменений. Для эффективного управления рисками, связанными с релизом, реализация релиза содержит обязательные стадии и Deadline-ы: Planning Deadline, Dev Freeze, Code Freeze, QA sign off и др. Данные стадии соответствуют моменту фиксации требований, окончанию внесения новой функциональности, прекращению любых модификаций и др.

Реализация стадий позволяет снизить риски при развертывании релиза в продакшн-системе. Выполнение deadline-ов и процедур контроля качества позволяет сделать реализацию и развертывание релиза контролируемыми.

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

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

Подход предполагает произведение изменений за рамками времени функционирования информационной системы и разрешение конфликта за счет ранней нотификации об изменении и обязательной верификации изменения. Это осуществляется через введение ряда контрольных точек процедур, реализуемых за некоторое фиксированной время до момента реализации: Announcement, QA sign off, Change Meeting, RfC Review, и т.д. Эти практики реализуются еженедельно. В частности, это позволяет команде-исполнителю правильно спланировать ресурсы и выделить время. В случае отсутствия возможности работы с изменением, запланированному к развертыванию по нестандартному графику, инициатор узнает об этом заранее, а не непосредственно перед запланированной реализацией.

Подробное описание жизненного цикла изменений на базе и недельного цикла приводится в тексте работы. В работе также показана реализация предложенного жизненного цикла изменений на базе систем BMC Remedy, Atlassian JIRA и Atlassian Confluence. Модернизация процесса управления изменениями с внедрением автоматизированного процесса уточнения изменений и недельного цикла позволила:
• снизить количество отклоненных запросов на изменение;
• снизить количество запросов, реализуемых повторно;
• уменьшить количество инцидентов, произошедших в результате развертывания новой функциональности за счет и интеграции процессов управления изменениями и управления релизами;
• снизить временя реализации стандартного изменения за счет раннего уточнения запроса и корректного назначения исполнителей;
• повысить прозрачность при приоритезации за счет раннего анонсирования изменений и внедрения специализированного Workflow;
• повысить качество предоставляемых подразделение сервисов за счет выделения новых типов стандартных запросов и их автоматизации;
• улучшить процесс накопления знаний за счет интеграции системы накопления знаний в процесс управления изменениями;
• повысить эффективность разрешения конфликтов плановых и незапланированных изменений за счет введения формального недельного цикла.

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

Copyright © 2009 Борисов А.В.