Управление релизами и развертыванием

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

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

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

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

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

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

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

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

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

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

Рис. 7. Два подхода к развертыванию услуг

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ключевые этапы деятельности сборки пакета релизов:

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

Если тестирование пакета релизов прошло успешно, релиз и его составляющие попадают под контроль Управления конфигурациями. С этого момента все изменения в пакете релизов осуществляются через Управление изменениями.

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

В рамках тестирования операционной готовности проводятся следующие тесты:

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

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

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

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

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

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

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

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

• удаление избыточных активов. Если услуга отозвана, необходимо пересмотреть использование активов. Активы отозванной услуги могут быть использованы для других услуг либо извлечены из обращения, что приведет к снижению издержек.
• верификация развертывания. После того, как деятельности в рамках развертывания завершены, необходимо убедиться, что пользователи, группа эксплуатации и инвесторы готовы к использованию услуги. Это включает в себя выполнение следующих действий:
• проверка того, что услуги, активы и ресурсы "на своих местах";
• проверка того, что обновление документации и информации завершено;
• материалы для обучения и координации готовы для предоставления инвесторам, пользователям и группе эксплуатации;
• проверка того, что роли и ответственности распределены;
• персонал и другие ресурсы готовы для управления и использования услуги и ее компонентов в нормальных и экстренных условиях;
• участники имеют доступ к информации, необходимой для управления, поддержки и использования услуги;
• настроены механизмы измерения производительности услуги и поддерживающих ее ресурсов.
• поддержка в начале эксплуатации (Early Life Support или ELP) - поддержка, предоставляемая в отношении новой или измененной услуги в течение некоторого времени непосредственно после того, как услуга была введена в эксплуатацию. Во время поддержки в начале эксплуатации поставщик услуг может пересматривать ключевые показатели производительности, уровни услуги и наблюдаемые пороговые значения, а также задействовать дополнительные ресурсы для Управления инцидентами и Управления проблемами. Пример деятельностей в рамках Поддержки в начале эксплуатации показан на рис. 8.

Рис. 8. Пример деятельностей в рамках Поддержки в начале эксплуатации

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

• обзор и завершение развертывания

Обзор развертывания включает в себя следующие действия:

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

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

• обзор и завершение внедрения

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

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

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

Входами процесса Управления релизами и развертыванием являются:

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

Выходами процесса Управления релизами и развертыванием являются:

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

Ключевые показатели производительности Управления релизами и развертыванием можно разделить на два класса:

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

Дата добавления: 2014-01-05