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