Книга: ИТ Сервис-менеджмент. Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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].

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

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

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

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

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

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

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

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

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

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

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

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

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

Оглавление книги