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

van Bon Jan

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

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

На случай невозможности полного свертывания релиза должны существовать Планы восстано­вления на случай чрезвычайных обстоятельств [140] для возобновления предоставления услуг.

139

Previous Trusted State.

140

Disaster Recovery Plans.

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

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

141

Installation Scripts.

142

Rollout Scripts.

? определение релиза [143] ;

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

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

? описание позиций, требующих приобретения или лицензирования, с приложением графиков закупки;

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

? исходные копии кодов программ для включения в библиотеку DSL;

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

8.4.3. Тестирование и приемка релиза

143

Т.е. как был определен релиз.

Наиболее частой причиной неудовлетворительного внедрения изменений и релизов является неаде­кватность тестирования. Для предотвращения этого перед внедрением релиза должно проводиться функциональное тестирование представителями пользователей

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

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

Релизы должны приниматься в контролируемой тестовой среде, состоящей из Базовых Конфигура­ций, которые должны быть подробно описаны в ходе определения релиза. Соответствующие Базо­вые Конфигурации должны быть зарегистрированы в CMDB. Если релиз не принимается, он воз­вращается в Процесс Управления Изменениями.

Результатами деятельности по тестированию и приемке релиза являются:

? протестированные процедуры инсталляции;

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

? известные ошибки и недостатки релиза;

? результаты тестирования;

? документация для управления и поддержки;

? перечень систем, подвергающихся воздействию;

? операционные (эксплуатационные) инструкции [144] и средства диагностики;

? планы на случай непредвиденных ситуаций и протестированные планы возврата;

144

Operating Instructions.

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

? подписанные приемо-сдаточные документы;

? авторизация из Процесса Управления Изменениями для выполнения релиза.

8.4.4. Планирование внедрения

Составленный на предыдущих этапах план теперь дополняется информацией о действиях по вне­дрению.

Планирование развертывания релиза включает:

? составление графика, а также перечня задач и требуемых людских ресурсов;

? составление перечня инсталлируемых и снимаемых с использования Конфигурационных Единиц, с указанием способа вывода из операционной среды;

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

? рассылку уведомлений о релизе и другие контакты с вовлеченными сторонами;

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

? закупку, размещение на хранение, определение и регистрацию всех новых CI для данного релиза в базе CMDB;

? планирование встреч с руководством, управляющими подразделениями, персоналом по Управле­нию Изменениями и представителями пользователей [145] .

145

Кроме того, для осуществления эффективной поддержки пользователей необходимо обеспечить информирование службы Service Desk о планируемом тиражировании (распространении) новых версий. – Прим. ред.

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

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

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

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

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

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