Jan van Bon - ИТ СЕРВИС–МЕНЕДЖМЕНТ. Вводный курс на основе ITIL

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В плане возврата к исходному состоянию на уровне релиза в целом определяются действия, необходимые для восстановления услуг в случае сбоя во время внедрения (имплементации) релиза. Ответственность за разработку планов возврата несет Процесс Управления Изменениями, но Управление Релизами должно оказывать в этом помощь для обеспечения практической реализуемости этих планов. В частности, при внедрении пакетного релиза, объединяющего несколько Запросов на Изменения (RFC), может возник­нуть необходимость координации различных планов возврата для этого релиза. Если возникает сбой Пол­ного релиза или Дельта-релиза, рекомендуется свернуть релиз полностью до Прежнего стабильного со­стояния [139] Previous Trusted State. . На случай невозможности полного свертывания релиза должны существовать Планы восстано­вления на случай чрезвычайных обстоятельств [140] Disaster Recovery Plans. для возобновления предоставления услуг.

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

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