• разработка плана оповещения (коммуникаций);
• согласование ролей и ответственностей;
• получение подробных коммерческих предложений и переговоры с поставщиками о новых аппаратных и программных средствах, а также услугах по их инсталляции;
• разработка планов на случай возврата к исходному состоянию;
• разработка плана обеспечения качества релиза;
• планирование приемки релиза руководством и пользователями.
Результаты этой деятельности представляют собой часть плана проведения изменения и включают планы релиза, планы тестирования и критерии приемки.
8.4.2. Проектирование, компоновка и конфигурирование
Рекомендуется выработать стандартные процедуры проектирования, компоновки и конфигурирования релизов. Основой релизов могут быть наборы компонентов (Конфигурационных Единиц – CI), разработанные внутри организации или закупленные у третьей стороны и прошедшие этап конфигурирования. Руководства по инсталляции и конфигурированию релизов должны рассматриваться как часть релиза и в качестве Конфигурационных Единиц должны включаться в число объектов, находящихся под контролем Процессов Управления Изменениями и Управления Конфигурациями.
Перед инсталляцией на месте рекомендуется настроить и протестировать все аппаратное и программное обеспечение в «лабораторных условиях». Компоненты программных и аппаратных средств необходимо тщательно конфигурировать и зарегистрировать, чтобы обеспечить возможность их многократного воспроизведения. Необходимо разработать рабочие инструкции таким образом, чтобы каждый раз воспроизводился один и тот же набор компонентов. Часто в резерве имеются стандартизированные аппаратные средства, которые используется только для компилирования или создания образов ПО[137]. Для надежности желательно, чтобы эта часть процесса была автоматизирована. Необходимые для этого программные и аппаратные средства также попадают в сферу действия Процесса Управления Релизами. В среде разработки программ такая деятельность называется Управлением Компоновкой[138] и входит в зону ответственности Управления Релизами.
План возврата к исходному состоянию
В плане возврата к исходному состоянию на уровне релиза в целом определяются действия, необходимые для восстановления услуг в случае сбоя во время внедрения (имплементации) релиза. Ответственность за разработку планов возврата несет Процесс Управления Изменениями, но Управление Релизами должно оказывать в этом помощь для обеспечения практической реализуемости этих планов. В частности, при внедрении пакетного релиза, объединяющего несколько Запросов на Изменения (RFC), может возникнуть необходимость координации различных планов возврата для этого релиза. Если возникает сбой Полного релиза или Дельта-релиза, рекомендуется свернуть релиз полностью до Прежнего стабильного состояния[139]. На случай невозможности полного свертывания релиза должны существовать Планы восстановления на случай чрезвычайных обстоятельств[140] для возобновления предоставления услуг.
Требования плана возврата к исходному состоянию, такие как создание резервных копий и обеспечение запасного сервера, рекомендуется выполнять заранее. В случаях, если внедрение может занять больше времени, чем предполагается, и если задержка может поставить под угрозу нормальное предоставление услуг, в план возврата должен включаться крайний срок, определяющий время приведения в действие плана возврата. Это требуется для своевременного возобновления услуг (например, не позднее 7:00 в понедельник). План возврата к исходному состоянию должен включаться в анализ рисков изменения и должен быть одобрен пользователями.
Реальная компоновка релиза может включать компилирование и связывание программных модулей, или наполнение баз данных тестовыми данными, или такими данными, как таблицы почтовых индексов, налоговых ставок, часовых поясов и валютных курсов, а также информацией о пользователях. Часто это выполняется автоматизированными инсталляционными скриптами[141], хранящимися в Библиотеке DSL вместе с планами возврата. Полные релизы должны отражаться в базе CMDB как Стандартные Конфигурации для облегчения конфигурирования в будущем. Планы тестирования должны включать тестирование и приемку по качеству программного и аппаратного обеспечения, процедур, инструкций по операционной деятельности и сценариев (скриптов) развертывания[142] перед выходом релиза и, возможно, оценочные испытания после внедрения релиза. Должно также проводиться тестирование инсталляционных скриптов. Для этого требуется следующая информация: