? Сводилась к минимуму возможность возникновения ошибок в программно-аппаратных комплек­сах, или ошибок выпуска некорректных версий.

? Бизнес-подразделения внимательно контролировали инвестиции в программное обеспечение, от которых во многом зависит бизнес.

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

? Уменьшалась опасность возникновения инцидентов и известных ошибок за счет тестирования и контроля внедрения.

? Пользователи больше привлекались к участию в тестировании релизов.

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

? Для целей бизнеса существовали структуры централизованного проектирования и компоновки программных и аппаратных средств или структуры для их закупки с последующим распростране­нием по пользователям.

? Бизнес-подразделения могли стандартизировать версии программного и аппаратного обеспечения в своих подразделениях для облегчения их поддержки.

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

? Облегчалось обнаружение неавторизованных копий и некорректных версий.

8.3. Процесс

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

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

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

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

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

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

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

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

Рис. 8.4. Управление Релизами

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

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

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

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

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

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

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

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

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

Рис. 8.5. Виды деятельности по Управлению Релизами (источник: OGC)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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