Управление релизами и развертыванием в рамках Внедрения услуг

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

Основные цели Управления релизами и развертыванием:

1. формирование и согласование планов релизов и развертывания с заказчиками и инвесторами;
2. гарантия того, что каждый пакет для релиза состоит из набора связанных и совместимых компонентов;
3. осуществление управления релизом и его компонентами в рамках процессов Внедрения;
4. гарантия того, что все пакеты для релизов могут быть протестированы, отслежены, проверены, установлены или устранены (при необходимости);
5. гарантия того, что все изменения управляются в рамках деятельностей по управлению релизами и развертыванием;
6. ведение отчетов и управление рисками, проблемами, расхождениями, связанными с новой или измененной услугой. Осуществление корректирующих действий при необходимости;
7. обеспечение доступа к информации для заказчиков и инвесторов, чтобы они могли эффективно использовать новую или измененную услугу;
8. обеспечение доступа к информации для операционного персонала, чтобы он мог предоставлять, поддерживать и управлять услугой.

Управление релизами и развертыванием отвечает за выпуск релизов и их эффективное использование заказчиками.

Единица релиза (Release Unit) - компоненты услуги, которые обычно компонуются вместе и выпускаются в рамках одного релиза. Единица релиза обычно включает в себя компоненты, необходимые для выполнения какой-либо полезной функции. Например, Единицей релиза может быть настольный компьютер, включающий в себя программное, аппаратное обеспечение, лицензии, документацию и т.п. Другим примером Единицы релиза может служить целое приложение для расчета зарплаты, включая процедуры операционного управления IT и тренинги пользователей[1].

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

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

Подход преобразования новой или измененной услуги определяется в рамках этапа Проектирования. Существует две опции внедрения:

1. "большой взрыв" - новая или измененная услуга развертывается сразу для всех пользователей в рамках одной операции;
2. пофазовый подход - услуга развертывается поэтапно. Сначала одной части пользователей, затем остальным.

На рис. 9.1 представлено применение двух подходов.

увеличить изображение
Рис. 9.1. Два подхода к развертыванию услуг

1. Релиз 1 - начальная установка на три рабочие станции (1-3). Две другие станции добавляются в тот же период времени (4-5);
2. Релиз 2 - использование подхода "большой взрыв" для развертывания. Релиз устанавливается сразу на пять рабочих станций (1-5). На другом шаге на две дополнительные станции (6-7);
3. Релиз 3 - пофазовый подход для развертывания. Сначала обновляется только три рабочие станции (1-3), затем оставшиеся четыре (4-7). Еще одна станция добавляется на следующем этапе (8).

Пофазовый подход имеет следующие вариации:

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

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

Рассмотрим последовательность действий в рамках Управления релизами и развертыванием.

Для развертывания релиза необходимо разработать различные планы, в частности, Планы релизов и развертывания. Они должны определять:

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

В рамках Внедрения должны быть определены критерии, которые позволят установить успешность выполнения каждой стадии релиза и развертывания. Результат выполнения либо принимается - pass, либо отклоняется - fail. Отсюда критерии называются прием/отклонение (pass/fail) критерии.

Пример, когда результат принимается:

• Все тесты завершены успешно; отчет по оценке и RFC для сборки и тестирования подписаны.

Примеры, когда результаты отклоняются:

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

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

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

Среды, необходимые для релиза:

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

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

Планирование сборки пакета релизов содержит следующие процедуры:

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

В рамках составления планов развертывания необходимо ответить на следующие вопросы:

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

Далее разрабатываются Планы снабжения и предоставления. Они определяют следующее:

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

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

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

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

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

В ITIL вводится понятие "базовое состояние". Базовое состояние (Baseline) - зафиксированное состояние, используемое как ориентир (контрольная точка)[1]. Трактовка зависит от контекста. В контексте Внедрения базовое состояние может быть использовано для возврата инфраструктуры к исходной конфигурации в случае, если внедрение релиза оказалось неудачным. Информация о базовых состояниях конфигураций хранится в CMS.

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

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

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