ИТ СЕРВИС–МЕНЕДЖМЕНТ. Вводный курс на основе ITIL
Шрифт:
План возврата к исходному состоянию
В плане возврата к исходному состоянию на уровне релиза в целом определяются действия, необходимые для восстановления услуг в случае сбоя во время внедрения (имплементации) релиза. Ответственность за разработку планов возврата несет Процесс Управления Изменениями, но Управление Релизами должно оказывать в этом помощь для обеспечения практической реализуемости этих планов. В частности, при внедрении пакетного релиза, объединяющего несколько Запросов на Изменения (RFC), может возникнуть необходимость координации различных планов возврата для этого релиза. Если возникает сбой Полного релиза или Дельта-релиза, рекомендуется свернуть релиз полностью до Прежнего стабильного состояния [139] .
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 о планируемом тиражировании (распространении) новых версий. – Прим. ред.
Существует несколько способов осуществления развертывания:
? полное развертывание релиза – подход "большого скачка";
? поэтапное развертывание релиза, включающее несколько разновидностей:
? функциональное наращивание, когда все пользователи получают одновременно новые элементы функциональности;
? наращивание по объектам, когда развертывание ведется от одной группы пользователей к другой;
? эволюционное развертывание с поэтапным расширением функциональности.