8.3. Процесс

Процесс Управления Релизами состоит из следующих видов деятельности:

• разработка политики в отношении релизов и их планирование;

• компоновка и конфигурирование релизов;

• тестирование и приемка релизов;

• планирование развертывания релизов;

• оповещение, подготовка и обучение;

• распространение и инсталляция релизов.

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

другие действия могут проводиться ежедневно.

Успешное проведение Управления Релизами зависит от входной информации, поступающей из дру­гих процессов ITIL, и от взаимодействия с этими процессами (рис. 8.4). Главными являются интер­фейсы со следующими процессами.

1. Управление Конфигурациями

Управление Конфигурациями отвечает за регистрацию доступных версий программного и аппарат­ного обеспечения в базе данных CMDB в качестве Базисных Конфигураций. Программы, включае­мые в Библиотеку DSL, и аппаратные средства для DHS регистрируются в CMDB с согласованным уровнем детализации. Мониторинг статуса, выполняемый Процессом Управления Конфигурация­ми, отражает статус каждой Конфигурационной Единицы, например, «В активном использовании», «В разработке», «В тестировании», «В запасе» или «В архиве».

2. Управление Изменениями

Деятельность но распространению (тиражированию) релизов контролируется Процессом Управле­ния Изменениями. Кроме того, Управление Изменениями гарантирует, чтобы было проведено адек­ватное тестирование релизов. Управление Изменениями также принимает решение о количестве из­менений, которые могут быть скомбинированы в одном релизе. Управление Изменениями определя­ет процедуры, обеспечивающие авторизацию изменений, включая анализ степени воздействия и анализ необходимых ресурсов. В большинстве случаев Руководитель Процесса Управления Релиза­ми несет ответственность за внедрение программных и аппаратных изменений и он обычно участву­ет в работе Консультативного комитета по изменениям.

3. Управление Уровнем Услуг

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

8.3.4. Виды деятельности

На рис. 8.5 показаны виды деятельности в рамках Процесса Управления Релизами и их связи с жиз­ненным циклом изменения.

8.4. Виды деятельности

1. Выработка политики в отношении релизов и планирование

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

Руководитель Процесса Управления Релизами также определяет, на каком уровне Конфигурацион­ные Единицы могут распространяться независимо друг от друга (релизные единицы). Это зависит от:

• Потенциального воздействия релиза на другие компоненты.

• Количества человеко-часов и времени на компоновку и тестирование раздельных изменении, в сравнении с усилиями, необходимыми для их объединения и одновременного внедрения.

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

• Сложности взаимосвязей между новым программным и аппаратным обеспечением н остальной ча­стью ИТ-инфраструктуры — чем легче изолировать программные или аппаратные средства, тем легче их тестировать.

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

При планировании релиза рассматриваются следующие вопросы:

• координация содержания релиза;

• разработка графика ввода релиза;

• согласование графика, территориальных объектов, на которых произойдет распространение рели­за, и организационных единиц;

• посещение объектов для определения реально используемых аппаратных и программных средств;

• разработка плана оповещения (коммуникаций);

• согласование ролей и ответственностей;

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

• разработка планов на случай возврата к исходному состоянию;

• разработка плана обеспечения качества релиза;

• планирование приемки релиза руководством и пользователями.

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

2. Проектирование, компоновка и конфигурирование

Рекомендуется выработать стандартные процедуры проектирования, компоновки и конфигурирова­ния релизов. Основой релизов могут быть наборы компонентов (Конфигурационных Единиц — CI), разработанные внутри организации или закупленные у третьей стороны и прошедшие этап конфи­гурирования. Руководства но инсталляции и конфигурированию релизов должны рассматриваться как часть релиза и в качестве Конфигурационных Единиц должны включаться в число объектов, на­ходящихся под контролем Процессов Управления Изменениями и Управления Конфигурациями.

Перед инсталляцией на месте рекомендуется настроить и протестировать все аппаратное и про­граммное обеспечение в «лабораторных условиях». Компоненты программных и аппаратных средств необходимо тщательно конфигурировать и зарегистрировать, чтобы обеспечить возмож­ность их многократного воспроизведения. Необходимо разработать рабочие инструкции таким об­разом, чтобы каждый раз воспроизводился один и тот же набор компонентов. Часто в резерве име­ются стандартизированные аппаратные средства, которые используется только для компилирования или создания образов ПО'. Для надежности желательно, чтобы эта часть процесса была автоматизи­рована. Необходимые для этого программные и аппаратные средства также попадают в сферу дейст­вия Процесса Управления Релизами. В среде разработки программ такая деятельность называется Управлением Компоновкой- и входит в зону ответственности Управления Релизами.

План возврата к исходному состоянию

В плане возврата к исходному состоянию на уровне релиза в целом определяются действия, необходимые для восстановления услуг в случае сбоя во время внедрения (имплементации) релиза. Ответственность за разработку планов возврата несет Процесс Управления Изменениями, но Управление Релизами должно оказывать в этом помощь для обеспечения практической реализуемости этих планов. В частности, при внедрении пакетного релиза, объединяющего несколько Запросов на Изменения (RFC), может возник­нуть необходимость координации различных планов возврата для этого релиза. Если возникает сбой I Год­ного релиза или Дельта-релиза, рекомендуется свернуть релиз полностью до Прежнего стабильного со­стояния. На случай невозможности полного свертывания релиза должны существовать Планы восстано­вления на случай чрезвычайных обстоятельств¹ для возобновления предоставления услуг.

Требования плана возврата к исходному состоянию, такие как создание резервных копий и обеспе­чение запасного сервера, рекомендуется выполнять заранее. В случаях, если внедрение может занять больше времени, чем предполагается, и если задержка может поставить под угрозу нормальное пре­доставление услуг, в план возврата должен включаться крайний срок, определяющий время приве­дения в действие плана возврата. Это требуется для своевременного возобновления услуг (напри­мер, не позднее 7:00 в понедельник). План возврата к исходному состоянию должен включаться в анализ рисков изменения и должен быть одобрен пользователями.

Реальная компоновка релиза может включать компилирование и связывание программных модулей, или наполнение баз данных тестовыми данными, или такими данными, как таблицы почтовых инде­ксов, налоговых ставок, часовых поясов и валютных курсов, а также информацией о пользователях. Часто это выполняется автоматизированными инсталляционными скриптами, хранящимися в Биб­лиотеке DSL вместе с планами возврата. Полные релизы должны отражаться в базе CMDB как Стандартные Конфигурации для облегчения конфигурирования в будущем. Планы тестирования должны включать тестирование и приемку по качеству программного и аппаратного обеспечения, процедур, инструкций по операционной деятельности и сценариев (скриптов) развертывания" перед выходом релиза и, возможно, оценочные испытания после внедрения релиза. Должно также прово­диться тестирование инсталляционных скрип тов. Для этого требуется следующая информация:

• определение релиза;

• график ввода релиза:

• инструкции по конфигурированию и компоновке релиза;

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

• автоматизированные инсталляционные скрипты и планы тестирования;

• исходные копии кодов программ для включения в библиотеку DSL;

• планы возврата к исходному состоянию.

3. Тестирование и приемка релиза

Наиболее частой причиной неудовлетворительного внедрения изменений и релизов является неаде­кватность тестирования. Для предотвращения этого перед внедрением релиза должно проводиться функциональное тестирование представителями пользователей и операционное (эксплуатацион­ное) тестирование персоналом ИТ, оценивающим технические характеристики, функциональность, операционные (эксплуатационные) аспекты, производительность и интеграцию с остальной частью инфраструктуры. Также должны тестироваться инсталляционные скрипты, процедуры возврата и любые изменения процедур управления. Формальная приемка каждого этапа должна быть предста­влена в Процессе Управления Изменениями. Последним этаном является утверждение внедрения релиза.

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

Релизы должны приниматься в контролируемой тестовой среде, состоящей из Базовых Конфигура­ций, которые должны быть подробно описаны в ходе определения релиза. Соответствующие Базо­вые Конфигурации должны быть зарегистрированы в CMDB. Если релиз не принимается, он воз­вращается в Процесс Управления Изменениями.

Результатами деятельности по тестированию и приемке релиза являются:

• протестированные процедуры инсталляции;

• протестированные компоненты релиза;

• известные ошибки и недостатки релиза;

• результаты тестирования;

• документация для управления и поддержки;

• перечень систем, подвергающихся воздействию;

• операционные (эксплуатационные) инструкции¹ и средства диагностики;

• планы на случай непредвиденных ситуаций и протестированные планы возврата;

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

• подписанные приемо-сдаточные документы;

• авторизация из Процесса Управления Изменениями для выполнения релиза.

4. Планирование внедрения

Составленный на предыдущих этапах план теперь дополняется информацией о действиях по вне­дрению.

Планирование развертывания релиза включает:

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

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

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

• рассылку уведомлений о релизе и другие контакты с вовлеченными сторонами;

• составление планов закупки аппаратного и программного обеспечения;

• закупку, размещение на хранение, определение и регистрацию всех новых CI для данного релиза в базе CMDB;

• планирование встреч с руководством, управляющими подразделениями, персоналом по Управле­нию Изменениями и представителями пользователей².

Существует несколько способов осуществления развертывания:

• полное развертывание релиза — подход «большого скачка»;

• поэтапное развертывание релиза, включающее несколько разновидностей:

• функциональное наращивание, когда все пользователи получают одновременно новые элемен­ты функциональности;

• наращивание по объектам, когда развертывание ведется от одной группы пользователей к другой;

• эволюционное развертывание с поэтапным расширением функциональности.

5. Оповещение, подготовка и обучение

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

Необходимо заранее информировать весь задействованный персонал об изменениях в Соглашениях об Уровне Услуг (SI.A), Операционных Соглашениях об Уровне Услуг (OLA) и Внешних Договорах (UC).

6. Распространение релизов и инсталляция

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

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

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

8.5. Затраты и проблемы 8.5.1. Затраты

Затраты на Процесс Управления Релизами включают:

• затраты на персонал;

• затраты на хранение в Библиотеке DSL и Складе DHS, а также на поддержку среды компоновки, тестирования и распространения релизов;

• затраты на инструментальные программные средства и необходимое аппаратное обеспечение.