ность нх лнюгократного воснронзведення. Необходимо разработать рабочие инструкции такгьм образом, чтобы каждьи! раз воспроизводился один и тот же набор компонентов. Часто в резерве имеются стандартизнроватиле аппаратные С1)едства, которые используется только для компилирования luni создаггпя образов НО. Для надежности желательно, чтобы эта часть процесса б]>1ла автоматизирована. Необходимые для этого программные п аппаратные средства также попадают в С(юру де11ст-впя Процесса Управления Релизами. В среде разработки П1юграмм такая деятельность назьи}ается Управлением Ко.мпонопкоТ и входит в зону ответствсшюстн Управления Релизами.

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

В плане возврата к исходЕюму состояшно на уровне рсл11.за в цеюм опредсляЕОтся действия, необходимые для восстановления услуг в случае сбоя во время внедрения (имплементации) рсли.за. Ответственность за разработку планов возв1)ата несег Процесс Управления Изменениями, 1ю Унравление Релизами должно оказьнзать в этом помони> для обеспечепия практической реализуемости этих планов. В частнопИ, при внедрении пакетного релиза, обьедппяющего necKOJHiKO 3anjx)C0B на Из,\геиеипя (RFC), можег- возникнуть необходимость координацин различных планов BosBjiaia для этог-о релиза. Если возникает сбой 1 Годного ixiium или Дельта-релиза, рекомендуется свернуть [телнз полностью до П1южнего стабильного со-СТ0Я1ШЯ-*. На случай певоз.можтгос ги полтюго свертывания рсли.за должны существовать Планы восстановления на случай чрезвычайных обстоятельств для возобновления предоставления услуг.

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

Реальная ко.мпоновка релиза может- включать компилирование и связывание программных модулей, илп наполнение баз данных тестовыми данными, или такими дашплми, как таблищл почтовых индексов, налоговых ставок, часовых поясов и валютных курсов, а также ин(})ормацией о пользователях. Часто это выполняется автомати;!ироваины.ми иисталляциониыми cкpиптaми храияиц-ьмися в Библиотеке DSL вместе с планами возврата. Помиие релизы должны отражаться в базе CMDB как Стандартные Конфт-урапии для облегчет1я конфигурирования в будуп1ем, Плашл тестирования должны вкаючать тестирование и приемку по качеству программного и аппаратного обеспечепия, процедур, гнгструкций по операционногг деятельности и сцеггариев (скрггптов) развертглвания" перед выходом ])ejrH3a и, возможпо, оцеггочгпяе испглтаггия ггослс виедреггня релиза. Должно также проводиться тестггровагпге иггсталлягцгоннглх скригг тов. Для этого требуется следугогцая нгг(1)ормагп1я:

•оггределеигге релиза;

•графггк гшода релиза:

•инструкгпги iro копфнг\ури])ованию и компоновке релиза;

•ошгсагпге ггозиций, требуюгщгх приобретгчгия или лицсггзггроваггия, с ггриложсггием графггков:1агсупки;

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

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

•гглангл возврата к исходгго.му состояггиго.

Creating imases Build Management Previous Trusted State Disaster Recovery Plans. Installation scripts Rollout scripts

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

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

Наиболее часто!! !ipii4H!io!i неудовлетвор!1тельного В!!едрен1!я naMeiie!!!!!"! и релизов является неадекватность тестирован!!я. Для предотвра!нения этого перед внедре!!!!ем рел!!за должно проводиться фуик!!иональ!1ое тестирование !1редстав!!телями пользователей и опера!И101!иое (эксплуатацио!!-1!ое) тсст!!рование персо!!алом ИТ, оце!!!1ва101цим технические хара!<теристики, фу1!кииоиаль!!ость, оиера!!!!01!!!Ь!е (эксплуата!п-10иные) асписты, производителы!Ость и интеграцию с остальной часть!о инфрастру!сгург>1. Также долж!1ы тестироват1>ся инсталляцио1!ные скрипты, процедуры возврата и любые изме1!е1!ия процедур управле!И1Я. Формальная приемка калсдого этапа должна быть !1редста-BJ!C!!a в Процессе Уиравле!1ия Изме1!е!!иями. Последним этаном является утверл<деиие в!!едрения релиза.

Перед тем, 1сак Про!1есс Управле1!ия Релизами начнет развсрт!>!ва1!!1с релиза. Процесс Уиравле!1ия Изменениями додже!! ор!-а!!изовать ()ормальну1о пр1!емку релиза пользователями и его окончатель-!тую сдачу разработчиками.

Рели31л должны приниматься в 1сонтролируемой тестовой среде, состоя1!1ей из Базовых Коифигура-!!h!i, которые долж!1Ь! быть подроб!10 описаны в ходе оиределе!1ия релиза. Соответству10!1Пте Базо-вь!с Конфигура!1!!и должн!л быть зарегистрированы в CMDB. Если релиз не !1ри!1имается, он возвращается в Про!1есс Управле!!ия Изме!!ениями.

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

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

•1!ротестирова!ШЬ!е ком!!0!1е1!ты релиза;

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

•резул!.таты тестирования;

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

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

•операщтонные (эксплуатациО!П!ые) ииструк!1ии и средства диагностики;

•!1ла!1Ь! 1!а случай !1епредв!!де!!!1ых снтуа!П1Й и протестирова1!пые пла!1ы возврата;

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

•полписаи!1Ь1е приемо-сдаточные документы;

•авторизация из Hpoiiecca Управления Измене1!иям!! для вь!1!0Л!!е1!ия релиза.

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

Составленный i!a предыдупдих эта1!ах пла!1 теперь дополняется иггформацией о действ1!ях по вне-дре1!ию.

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

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

•составление перечня инсталлируе.мых и снимаем!>1х с использова!шя Конфигура!1ион1!Ь!Х Единиц, с укава!!ием способа вывода из операцио1П!ой среды;

•составление пла!!а действий для калсдого территориалы!ого объе!ста с учетом запаса времени ira развсрть!ва!ше и часовых поясов, если речь идет о географическ!! распределенных орга1!иза!И1ях;

•рассылку уведомлений о релизе и другие контакты с вовлечеп!1Ь1ми сторонами;

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

•за!су1!ку, размеще!!ис иа хранение, определение и регистра!1ию всех новых CI для да!1!10!0 релиза в базе CMDB;

•пла!!ирование встреч с руководством, управляю1!и1ми подра.злелениям!!, персоналом по Управле-ии!о Измсие!!иями и представителями Г!ол!.зователсй1

operating instructions

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

8. ynsyuAEJSiC РЕЛИЗЛиИ

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

•полное разве(Г1ъи>ание релиза - подход «большого скачка»;

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

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

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

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

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

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

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

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

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

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

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

8.5. Затраты и проблемы 8.5.1. Затраты

Затраты на Процесс Управления Релизами включают:

•затраты на персонал;

•затраты на хранение в Библиотеке DSL и Складе DHS, а также на поддержку среды компоновки, тестирования и распространения релизов;

•затраты на инструментальные программные средства и необходимое аппаратное обеснечешге.