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

? Высокий приоритет – изменение касается серьезной ошибки, затрагивающей ряд пользователей, или новой нетипичной ошибки, затрагивающей большую группу пользователей, или связано с другими срочными вопросами. Такому изменению на ближайшем совещании CAB присваивается высокий приоритет.

? Наивысший приоритет – Запрос на Изменения (RFC) касается проблемы, серьезно влияющей на важнейший для заказчиков сервис, или касается срочного изменения в ИТ (например, новой функциональности для целей бизнеса), срочного изменения законодательства или быстрых не­больших изменений, не терпящих отсрочки . Изменения с таким приоритетом классифицируются как "срочные". Для срочных изменений обычные процедуры не используются, так как необходи­мые ресурсы предоставляются незамедлительно. Может потребоваться проведение срочного сове­щания Консультативного комитета (CAB) или Руководящего комитета ИТ . Специально для этих целей в компании должен быть сформирован Комитет по срочным изменениям (CAB/ЕС) с пол­номочиями для принятия экстренных решений. Все принятые ранее планы могут быть отложены или прерваны.

Эти коды могут быть представлены в цифрах, например: низкий приоритет = 1 / наивысший при­оритет = 4.

Определение категории

Категории определяются в рамках Процесса Управления Изменениями, в случае необходимости с участием Консультативного комитета (CAB), который определяет степень воздействия изменения и требования, предъявляемые им к ИТ-организации (в первую очередь, выделение ресурсов). Приме­ры категорий:

? Низкая степень воздействия – изменение, требующее выполнения небольшого объема работ. Руководитель Процесса Управления Изменениями может авторизовать эти изменения без привлече­ния Консультативного комитета (CAB).

? Существенная степень воздействия – изменение, требующее значительных усилий и оказываю­щее существенное воздействие на ИТ-услуги. Эти изменения обсуждаются на совещании Кон­сультативного комитета (CAB) для определения необходимых усилий (ресурсов и др.) и потенци­ального воздействия. Перед совещанием членам Консультативного комитета (CAB) и, возможно, специалистам и разработчикам направляется соответствующая документация.

? Наивысшая степень воздействия – изменение, требующее значительных усилий. Руководителю Процесса необходимо предварительно получить авторизацию на выполнение изменения от руко­водства ИТ или Руководящего комитета ИТ, после чего изменение представляется на рассмотре­ние Консультативного комитета (CAB).

Эти коды могут быть представлены в цифрах, например: низкая степень = 1 / высшая степень = 3.

Большинство изменений относятся к двум первым категориям. В добавление к классификации должны быть также определены группы, участвующие в работе над техническим решением, и услу­ги, затрагиваемые изменением.

7.4.4. Планирование

В рамках процесса осуществляется планирование изменений на основе графика, называемого Согла­сованным планом изменений (FSC). План FSC содержит подробную информацию обо всех утвер­жденных изменениях и их планировании. Члены Консультативного комитета (CAB) дают рекомен­дации по планированию изменений, так как необходимо учитывать наличие персонала, ресурсов, за­траты, различные аспекты задействованных услуг, а также мнение заказчиков. Консультативный ко­митет (CAB) играет роль консультативного органа. В целом Управление Изменениями имеет делеги­рованные полномочия, т. к. оно действует от лица руководства ИТ. Возможно, что изменения наивыс­шей категории необходимо утверждать руководством ИТ до их представления Консультативному ко­митету (CAB). Утверждение изменения имеет несколько аспектов:

? Финансовое одобрение – анализ затрат/выгод и выделение бюджета.

? Техническое одобрение – оценка необходимости, возможности проведения изменения и его сте­пени воздействия.

? Бизнес-одобрение – одобрение пользователями требуемой функциональности приложения и сте­пени воздействия изменения.

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

Политика проведения изменений

Изменения по разным Запросам можно объединять в одном релизе. В этом случае при неудачной реа­лизации будет достаточно одного возврата к исходному состоянию . Такой групповой релиз должен рассматриваться как одно изменение, даже если он содержит в себе несколько изменений. Релизы мо­гут планироваться с учетом функциональных задач, необходимых для бизнеса. Они могут охватывать аппаратные и программные средства, и их внедрение осуществляется Процессом Управления Релиза­ми. Рекомендуется определить политику компании в этой области и информировать о ней ИТ-органи­зацию и заказчиков (см. также "Управление Релизами"). Цель политики – оградить пользователя от ненужного беспокойства ("перекапывание дороги каждую неделю").

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

Совещания Консультативного комитета (CAB)

Информация о планировании изменений должна распространяться заранее до совещания CAB. Соответствующая документация и информация о пунктах повестки дня также должны рассылаться до совещания.

Повестка дня совещания CAB должна включать ряд постоянных пунктов, в том числе:

? неавторизованные изменения;

? Запросы на Изменения (RFC), которые должны быть оценены членами Консультативного комите­та (CAB);

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

? открытые и закрытые изменения;

? оценка произведенных изменений.

Оценка степени воздействия и ресурсов

При оценке необходимых ресурсов и степени воздействия изменения члены Консультативного ко­митета (CAB), Руководитель Процесса Управления Изменениями и другие участники (определен­ные Консультативным комитетом) должны учесть следующие аспекты:

? вопросы возможностей ("мощности" или "емкости") подвергающихся воздействию услуг;

? надежность и возможность восстановления;

? планы по Управлению Непрерывностью ИТ-услуг;

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

? вопросы безопасности;

? степень воздействия изменения на другие ИТ-сервисы;

? регистрация изменения и его предварительное одобрение;

? необходимые ресурсы и затраты (поддержка и обслуживание);

? количество и наличие необходимых специалистов;

? необходимое время на весь цикл изменения;

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

? степень воздействия на текущую операционную деятельность;

? какие-либо возможные конфликты с другими изменениями.

Члены Консультативного комитета (CAB) могут также дать рекомендации по определению приори­тета изменения.

7.4.5. Координация

Об утвержденных изменениях сообщают соответствующим техническим специалистам, которые бу­дут разрабатывать и внедрять эти изменения. Перед внедрением происходит этап тестирования. В разработке, испытании и внедрении утвержденных изменений важную роль может играть Процесс Управления Релизами. Большое внимание должно уделяться вопросам информирования персонала внутри компании для поддержки изменений.

Подготовка изменения

Не все изменения проходят отдельную фазу компоновки. Например, стандартные изменения, такие как перемещение персональных компьютеров, могут планироваться и осуществляться незамедли­тельно.

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

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

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

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

? скорость проведения изменений;

? количество отклоненных изменений;

? количество инцидентов, вызванных изменениями;

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

? затраты на произведенные изменения;

? соотношение между расчетными и фактическими затратами ресурсов и времени;

? количество срочных изменений.

Тестирование

Процедура возврата к исходному состоянию, план внедрения изменения и ожидаемый ре­зультат должны проходить тщательную проверку. При этом необходимо учитывать критерии, определенные ранее консультативным комитетом (CAB). В большинстве случаев для испыта­ний необходима изолированная тестовая среда или лаборатория. Тестирование на ранних ста­диях может производиться разработчиками, однако внедрение изменений не может осуществ­ляться без проведения независимого тестирования. Обычно проводится два вида испытаний: приемо-сдаточные испытания для пользователей, при которых представители бизнес-под­разделений (обычно заказчики изменения) проверяют его функциональные характеристики, и операционные (эксплуатационные) испытания , при которых независимое тестирование проводят те, кто должен поддерживать и обслуживать новую инфраструктуру. Сюда включаются также отделы технической поддержки и Служба Service Desk. Они проверяют соответ­ствующую документацию, процедуры резервного восстановления данных (back-up) и т. д. Не­обходимы также четкие инструкции для мониторинга качества тестирования и документиро­вания его результатов.

Внедрение

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

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

7.4.6. Оценка

Необходимо давать оценку произведенным изменениям, за возможным исключением стандартных изменений. При необходимости Консультативный комитет (CAB) принимает решение о проведении последующих дополнительных мероприятий. Должны быть рассмотрены следующие вопросы:

? Привело ли изменение к достижению намеченной цели?

? Удовлетворены ли пользователи результатом?

? Возникали ли какие-либо побочные эффекты?

? Были ли превышены расчеты по затратам и ресурсам?

Если изменение осуществлено успешно, Запрос на Изменение (RFC) может быть закрыт. Это про­исходит на этапе Анализа результатов внедрения (PIR), т. е. этапе оценки изменения. Если же изме­нение закончилось неудачно, процесс возобновляется с того места, где он вызвал сбой, с использова­нием нового подхода. Иногда бывает лучше сделать возврат назад и создать новый или модифици­рованный Запрос на Изменения (RFC). Продолжение работы с неудачным изменением часто приво­дит к ухудшению ситуации.

Процедуры с автоматическим отслеживанием времени гарантируют, что этап оценки изменений не будет пропущен. В зависимости от природы изменения оценку можно проводить или через несколь­ко дней, или через несколько месяцев. Например, оценка изменения в использующемся ежедневно персональном компьютере может быть совершена через несколько дней, а изменение в системе, ис­пользующейся раз в неделю, может быть сделана только через три месяца.

7.4.7. Проведение срочных изменений

Как бы хорошо ни проводилось планирование, могут быть изменения, требующие наивысшего приоритета. Срочные изменения очень важны для компании и они должны осуществляться как можно скорее. В большинстве случаев на эти изменения направляют ресурсы, предназначенные для других видов деятельности. Срочные изменения могут серьезно повлиять на запланирован­ную работу. Следовательно, задачей является сведение к минимуму числа срочных или неожидан­ных изменений (с "наивысшим" приоритетом). Возможные превентивные меры включают:

? обеспечение своевременной подачи Запросов на Изменения, пока они не стали срочными.

? при исправлении ошибок, возникших в результате плохой подготовки изменений, возврат не дол­жен заходить дальше прежней версии, то есть дальше Прежнего стабильного состояния . После возврата следует тщательно подготовить новый улучшенный план изменения.

Несмотря на указанные выше меры срочные изменения все же могут возникнуть. Они требуют про­цедур для срочной обработки, но с сохранением общего контроля со стороны Процесса Управления Изменениями. В случае возникновения такой ситуации Руководитель Процесса Управления Изме­нениями может организовать чрезвычайное совещание комитета CAB/ЕС. Если для этого нет вре­мени или если Запрос поступил в нерабочее время, должен существовать альтернативный способ получения авторизации изменения. Это не обязательно должна быть встреча "лицом к лицу", вме­сто нее можно провести телефонную конференцию.

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

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

7.5 Контроль процесса

7.5.1 Отчеты для руководства

Задачей Процесса Управления Изменениями является достижение баланса между гибкостью и ста­бильностью. Для характеристики текущей ситуации в организации могут быть использованы следу­ющие отчеты:

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

? перечень причин изменений и перечень Запросов на Изменения;

? количество успешно внедренных изменений;

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

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

? графики и анализ тенденций за соответствующие периоды.

Показатели эффективности определяют, насколько успешно Процесс Управления Изменениями осуществляет эффективную и рациональную обработку изменений при минимальном отрицатель­ном воздействии на согласованный Уровень Услуг. Эти показатели могут быть следующими:

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

? скорость проведения изменений;

? количество отклоненных изменений;

? количество инцидентов, вызванных изменениями;

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

? затраты на проведенные изменения;

? количество изменений, осуществленных в рамках расчетных затрат ресурсов и времени.

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

7.6.1. Затраты

? Затраты на персонал – в большинстве случаев уже имеется персонал, занимающийся координа­цией изменений. Однако для выполнения задач Руководителя Процесса Управления Изменения­ми и организации работы Консультативного комитета по изменениям (CAB) возможны дополни­тельные расходы на персонал. Во многих случаях Управление Изменениями вводится для повы­шения качества услуг, и возникшие дополнительные расходы рассматриваются как расходы на ка­чество. После успешного запуска процесса расходы на координацию изменений компенсируются уменьшением расходов на разрешение инцидентов и проблем.

? Затраты на инструментальные средства – расходы на аппаратное и программное обеспечение должны определяться заранее. Часто при внедрении нескольких процессов закупается общее инст­рументальное средство для Процессов Управления Изменениями, Проблемами, Конфигурациями и Инцидентами. При работе в сложной ИТ-среде почти невозможно контролировать эти процессы без такого инструментального средства.

7.6.2. Проблемы

При внедрении Процесса Управления Изменениями возможно появление следующих проблем:

? Работа без средств автоматизации слишком трудоемка, она будет создавать много проблем.

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

? Возможны попытки проведения изменений в обход согласованных процедур. Абсолютно необхо­димо, чтобы такие попытки встречали соответствующую реакцию со стороны компании. Целост­ность Процесса Управления Изменениями зависит от полного соответствия процедурам. Претен­зии сотрудников и предложения по усовершенствованию Процесса Управления Изменениями должны пониматься и приветствоваться, однако неподчинение необходимо решительно пресекать, иначе весь процесс будет поставлен под угрозу.

? Другие способы обеспечения исполнения процедур по Управлению Изменениями включают:

? проведение регулярного аудита, возможно, независимым инспектором, для оценки соответствия процедурам Управления Изменениями;

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

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

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

? включение необходимых условий и процедур в контракты с внешними поставщиками;

? назначение на должность Руководителя Процесса Управления Изменениями сотрудника с об­ширным опытом и достаточными бизнес- (что часто недооценивается) и техническими знания­ми. Правильный выбор претендента на эту должность имеет критически важное значение, это не должно упускаться из виду, как часто бывает.

7.6.3. Предложения

Некоторые проблемы могут быть решены за счет реализации следующих предложений:

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

? наладить контакт со всем ИТ-персоналом и всеми поставщиками, чтобы гарантировать их понима­ние Процесса Управления Изменениями и отказ от попыток проведения изменений без координа­ции;

? обеспечить постоянное проведение окончательной оценки изменений (Анализ результатов внедре­ния - PIR);

? организовать взаимодействие с Управлением Конфигурациями для гарантированного ввода изме­нений Конфигурационных Единиц в базу данных CMDB.

Глава 8 Управление Релизами

8.1. Введение

С повышением зависимости организаций от ИТ-процессов все большее значение приобретает их эффективный мониторинг и защита. С ростом количества изменений возрастает и потребность в контроле над процессом проведения изменений.

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

Задачей Процесса Управления Релизами является обеспечение качества рабочей среды за счет ис­пользования формальных процедур и проверок при вводе в работу новых версий. В отличие от Уп­равления Изменениями, занимающегося верификацией, Процесс Управления Релизами занимается внедрением. Управление Релизами осуществляется в тесном контакте с Управлением Конфигураци­ями и Управлением Изменениями, что гарантирует обновление единой базы CMDB с учетом каждо­го нового релиза. Управление Релизами также обеспечивает обновление содержания релизов (про­граммных кодов) в Библиотеке эталонного программного обеспечения DSL. С помощью базы CMDB также отслеживаются спецификации аппаратных средств, руководства по инсталляции и се­тевые конфигурации. Запас аппаратных средств, в частности стандартизованные базовые конфигу­рации, хранится на Складе эталонного аппаратного обеспечения DHS. Однако, в первую очередь объектом Процесса Управления Релизами является программное обеспечение.

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

? большие перерывы в работе из-за плохого планирования выпуска релизов;

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

? неэффективное использование ресурсов из-за отсутствия информации об их местонахождении;

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

? отсутствие защиты от вирусов, приводящее к необходимости "лечения" всей сети.

8.1.1. Основные понятия

Релизы

Релизы содержат одно или несколько авторизованных изменений. Они могут классифицироваться в первую очередь по уровню релиза. Часто релизы разделяют на:

? Значительные релизы – крупномасштабное развертывание новых аппаратных и программных средств, обычно со значительно расширенными функциональными возможностями. Такие релизы часто помогают в устранении ряда известных ошибок, включая известные обходные решения и быстрые исправления .

? Малые программные релизы и модернизация аппаратного обеспечения (апгрейды) – эти релизы обычно представляют собой незначительные усовершенствования и исправления известных оши­бок. Среди них могут быть такие, которые внедрялись ранее в виде срочных исправлений и теперь окончательно проработаны и включены в данный релиз. За счет такого релиза обеспечивается обно­вление "Прежнего стабильного состояния ", являющегося отправной точкой для всех испытаний.

? Срочные исправления – обычно внедряются как быстрые исправления проблем и известных ошибок.

Релизные единицы

В отношении аппаратного обеспечения вопросы возникают только при полной замене ПК или при раздельной замене плат и дисководов жестких дисков (или даже оперативной памяти и процессо­ров). Для программного обеспечения изменения возможны на уровне системы, комплекса, програм­мы или модуля. Хорошим примером может быть библиотека DLL (Dynamic Link Library) в среде Windows, часто используемая несколькими программами. Иногда в составе пакета поставляется но­вая версия DLL, что может потребовать нового тестирования и переустановки всех других про­граммных пакетов. В данном процессе также прорабатывается принцип минимального содержания релиза.

Идентификация релизов

Копии программ могут распространяться из Библиотеки DSL по соответствующим средам:

? Среда разработки — разработка новых версий может вестись на основе более ранних версий из Библиотеки DSL. С каждой новой версией увеличивается ее номер. Изменение программного обеспечения возможно только в среде разработки.

? Среда испытаний – среда для тестирования версий. Часто тестирование разделяют на техниче­ские испытания разработчиками, функциональные испытания пользователями, испытания вне­дрения компоновщиками релизов и, возможно, окончательные приемочные испытания пользователями и руководством.

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

? Архив – служит для хранения старых версий программных единиц, которые больше не используются.

Так как возможно использование нескольких релизов, им присваиваются уникальные идентифика­торы. В идентификационном номере релиза должна быть ссылка на соответствующую Конфигура­ционную Единицу, и он должен включать номер версии из двух или более цифр, например:

? Значительные релизы – система расчета зарплаты v.1, v.2, v.3 и т. п.

? Малые релизы – система расчета зарплаты v.1.1, v.1.2, v.1.3 и т. п.

? Релизы - срочные исправления – система расчета зарплаты v.1.1.1, v.1.1.2, v.1.1.3 и т. п.

На рис. 8.1 показаны тестирование и возможные модификации каждой новой версии перед ее выпу­ском. Старая версия архивируется как часть запуска нового релиза на случай возможного возврата.

На рис. 8.2 показан возврат.

Рис. 8.1. Выпуск версии в Процессе Управления Релизами

Рис. 8.1. Возврат в Процессе Управления Релизами

Типы релизов

Должна быть произведена оценка, какое количество изменений может быть разработано, испытано и внедрено за определенный период времени. Может оказаться, что пакетный релиз, представляющий собой комбинацию нескольких изменений для одного развертывания, может быть слишком слож­ным для безопасного внедрения.

Быстрая разработка и продвижение на рынок новых версий аппаратного и программного обеспече­ния может привести к тому, что релиз может устареть до его внедрения. С другой стороны, частые изменения могут оказать отрицательное воздействие на предоставление услуг.

В рамках Процесса Управления Изменениями принимается решение о количестве изменений, кото­рое может быть включено в релиз, и о способе его развертывания. Возможен выбор одного из следу­ющих вариантов:

? Дельта-релиз – в дельта-релиз включаются только измененные аппаратные и программные сред­ства. Это часто связано с экстренными и быстрыми исправлениями. Недостатком этого типа релизов является то, что часто невозможно проверить все связи с остальной частью среды, в результате чего не удаляются модули, к которым программа больше не обращается. Дельта-релиз удобен в случае, если программное обеспечение может быть изолировано от остальной части ИТ-среды. Преимуществом дельта-релиза является то, что для создания тестовой среды требуется меньше усилий.

? Полный релиз – при полном релизе идет распространение полного комплекта ПО, включая неизме­ненные модули. Такой подход предпочтителен в случаях, когда точно не известно, что изменено в программном обеспечении. Более тщательные испытания программных и аппаратных средств обес­печивают в этом случае меньшее число инцидентов после внедрения. При подготовке полного рели­за легче определить, достигается ли запланированный уровень производительности. Преимущест­вом полного релиза является возможность одновременного внедрения нескольких изменений. Под­готовка облегчается благодаря возможности использования стандартных сценариев инсталляции . Также при инсталляции может быть «очищена» программная среда. Однако полный релиз требует большей подготовки и ресурсов, чем дельта-релиз.

? Пакетный релиз – пакетный релиз, или комплект релизов, обеспечивает пользователям более длительные периоды стабильной работы. Исправление незначительных программных ошибок, с которыми пользователи могут мириться, и внедрение новых функций часто являются действиями, которые можно эффективно объединить. Так же плановые апгрейды, например системного про­граммного обеспечения и офисных приложений от внешних разработчиков, могут включаться в пакетные релизы.