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

Одним из способов выполнения таких действий является определение так называемых "предвари­тельно авторизованных"[105] изменений (или "категории 0"), которые записываются в базу данных из­менений (предпочтительно самими запрашивающими), но не требуют использования процедур по Управлению Изменениями. Например, если при приеме на работу нового сотрудника обычно вы­полняются четырнадцать действий (создание новой учетной записи[106], настройка рабочей станции, электронной почты и т. д.), то эти действия не требуют столь внимательного изучения, как значи­тельные изменения инфраструктуры. Такой вид стандартных изменений обрабатывается по типово­му шаблону как предварительно авторизованный "Запрос на Обслуживание".

7.2. Цель процесса

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

7.2.1. Преимущества использования процесса

Для эффективного предоставления ИТ-услуг организация должна уметь обрабатывать большое ко­личество изменений с надлежащим Уровнем Ответственности при принятии решений.

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

? уменьшение отрицательного воздействия изменений на качество ИТ-услуг;

? более точные оценки затрат для предлагаемых изменений;

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

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

? повышение производительности работы пользователей за счет более высокой стабильности и ка­чества ИТ-услуг;

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

? рост способности компании проводить частые изменения без нарушения стабильности ИТ-среды.

7.3. Процесс

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

Рис. 7.2. Позиционирование Процесса Управления Изменениями

Входы Процесса Управления Изменениями включают в себя:

? Запросы на Изменения (RFC);

? информация из базы данных CMDB (в частности, анализ степени воздействия изменений);

? информация из других процессов (из Базы данных мощностей CDB, информация о бюджете и т. д.);

? планирование изменений (Согласованный план изменений[107] FSC).

Выходы процесса включают:

? обновленный план изменений (Согласованный план изменений FSC);

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

? повестка дня Консультативного комитета CAB, протоколы и принятые решения;

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

Управление Изменениями имеет описанную ниже взаимосвязь с другими процессами.

7.3.1. Управление Инцидентами

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

7.3.2. Управление Конфигурациями

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

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

7.3.3. Управление Проблемами

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

7.3.4. Управление Релизами

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

7.3.5. Управление Уровнем Сервиса

Процесс Управления Уровнем Сервиса вовлечен в определение степени воздействия изменений на предоставление услуг и бизнес-процессы. В зависимости от ситуации в Консультативном комитете (CAB) могут участвовать представители Процесса Управления Уровнем Сервиса. Если изменение оказывает значительное воздействие или связано с высоким риском, его внедрение и сроки должны всегда обсуждаться с заказчиком. Управление Изменениями направляет в Управление Уровнем Ус­луг отчет "Проектируемая доступность услуг"[108] (PSA). В этом отчете Управление Изменениями из­лагает изменения в имеющихся Соглашениях об Уровне Услуг (SLA) и воздействие Согласованного плана изменений (FSC) на доступность услуг.

7.3.6. Управление Доступностью

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

7.3.7. Управление Мощностями

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

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

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

7.3.9. Виды деятельности в рамках Процесса Управления Изменениями

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

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

? Прием в обработку – предварительный просмотр (фильтрация) Запросов на Изменения и прием их к дальнейшему рассмотрению.

? Классификация – сортировка Запросов на Изменения по категориям и приоритету.

? Планирование – объединение изменений, планирование их проведения и планирование необхо­димых ресурсов.

? Координация – координирование компоновки, испытаний и проведения изменений.

? Оценка – оценка успешности каждого изменения и составление заключения для будущей дея­тельности (накопление знаний).

Рис. 7.3. Виды деятельности в рамках Процесса Управления Изменениями

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

7.4.1. Регистрация

Прежде всего, все Запросы на Изменения (RFC) должны быть зарегистрированы. При подаче За­проса на Изменение для решения проблемы также регистрируется номер известной ошибки.

Что представляет собой Запрос на Изменения (RFC)?

Не каждый Запрос на Модификацию обрабатывается как изменение: некоторые повседневные за­дания, точно определенные и подчиняющиеся установленным процедурам (стандартизованные), но включающие в себя модификации, могут обрабатываться как Запросы на Обслуживание (на­пример, изменения "категории 0", см. 7.1.1). В результате возникает следующая классификация изменений:

? Запросы на Обслуживание (здесь: стандартные изменения) – полностью определенные и утвержденные изменения, регистрируемые, но не оценивающиеся Процессом Управления Изменения­ми. Эти изменения проводятся в рабочем порядке. (Примечание. Не все Запросы на Обслужива­ние являются изменениями).

? Запросы на Изменения – все другие Запросы на Модификацию инфраструктуры.

Откуда исходят Запросы на Изменения (RFC)?

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

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

? Заказчики – могут запросить больший, меньший Уровень Сервиса или другие услуги. Эти запро­сы могут подаваться прямо как Запрос на Изменения или направляться через Управление Уров­нем Сервиса (SLM) или через Управление Отношениями с заказчиками ИТ (IT CRM).

? Политика компании – тактические и стратегические процессы из области Предоставления услуг (Service Delivery Set) и Указания руководства (Managers Set) могут привести к направлению За­просов на Изменение Услуг. Например, Управление Уровнем Услуг, Управление Доступностью и Управление Мощностями составляют ежегодные планы улучшения услуг, которые позднее могут быть поданы как Запросы на Изменения (RFC).

? Законодательство – если возникают ограничения, регламентирующие бизнес-деятельность, или вводятся новые требования по ИТ-безопасности, непрерывности бизнес-процессов и Управлению Лицензиями.

? Поставщики – поставщики выпускают новые версии и модификации[109] своих продуктов и сообща­ют об исправленных ими ошибках. Они могут сообщить, что больше не поддерживают определен­ные версии или что не могут гарантировать производительность версии (например, из-за "Ошиб­ки тысячелетия" – Millennium bug). Это может дать толчок Процессам Управления Проблемами или Управления Доступностью к подаче Запроса на Изменения (RFC).

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

? Любой другой сотрудник ИТ - в принципе, любой сотрудник может подать предложения по улучшению услуг. В особенности, ИТ-персонал может способствовать усовершенствованию про­цедур по поддержке и предоставлению услуг и обновлению руководств.

Регистрация Запросов на Изменения

Вот примеры информации, которая может включаться в Запросы на Изменения (RFC):

? идентификационный номер Запроса;

? номер проблемы/известной ошибки (если имеется), связанной с Запросом;

? описание и определение соответствующих Конфигурационных Единиц (CI);

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

? текущая и новая версия изменяемой Конфигурационной Единицы;

? имя, адрес и номер телефона лица, направляющего Запрос;

? дата подачи;

? предварительная оценка необходимых ресурсов и времени.

7.4.2. Прием в обработку

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

Проведение изменения ведет за собой обновление в базе данных CMDB, например:

? изменение статуса существующей Конфигурационной Единицы;

? изменение взаимосвязи между различными Конфигурационными Единицами;

? новая Конфигурационная Единица или изменение существующей Конфигурационной Единицы;

? новый владелец или другое месторасположение Конфигурационной Единицы.

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

? назначенный приоритет;

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

? категория;

? рекомендации Руководителя Процесса Управления Изменениями;

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

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

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

? требования по поддержке;

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

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

? фактическая дата и время проведения изменения;

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

? результаты испытания и обнаруженные проблемы;

? причины отклонения Запроса (если необходимо);

? оценка результатов.

7.4.3. Классификация

После приема Запроса на Изменения (RFC) определяются его приоритет и категория.

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

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

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

Пример системы кодирования приоритетов:

? Низкий приоритет – изменение желательно, но его внедрение может быть отложено до более удобного времени (например, до следующего релиза или планового обслуживания).

? Обычный приоритет – нет особой срочности и высокой степени воздействия, но изменение не следует откладывать. На совещании Консультативного комитета (CAB) при выделении ресурсов изменению присваивается обычный приоритет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Внедрение[118]

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

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

7.4.6. Оценка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.6.1. Затраты

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

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

7.6.2. Проблемы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8.1. Введение

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

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

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

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

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

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

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

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

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

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

Релизы

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

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

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

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

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

В отношении аппаратного обеспечения вопросы возникают только при полной замене ПК или при раздельной замене плат и дисководов жестких дисков (или даже оперативной памяти и процессо­ров). Для программного обеспечения изменения возможны на уровне системы, комплекса, програм­мы или модуля. Хорошим примером может быть библиотека 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. Возврат в Процессе Управления Релизами

Типы релизов

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

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

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

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

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

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

Рис. 8.3. Типы релизов

Библиотека эталонного программного обеспечения[132] (DSL)

Библиотека эталонного программного обеспечения (DSL) – это надежное хранилище для эталон­ных авторизованных версий (мастер-копий) всех Конфигурационных Единиц программного обеспе­чения. Физически библиотека DSL может находиться в разных местах и состоять из нескольких на­дежных хранилищ и огнеустойчивых сейфов для носителей информации. Управление Релизами на­чинает контролировать жизненный цикл программ с момента их включения в библиотеку DSL. Ре­лизы конфигурируются из известного надежного программного обеспечения, хранящегося в DSL. После этого разрабатываются инсталляционные скрипты[133], а в децентрализованной среде могут быть записаны соответствующие компакт-диски.

В библиотеке DSL может храниться несколько версий одного и того же программного обеспечения, включая архивные версии, документацию и исходные коды. Поэтому необходимо создание резерв­ных копий[134] Библиотеки DSL, поскольку она содержит не только текущую версию программного обеспечения, но и копии на случай возврата к прежней версии. При наличии в компании нескольких территориальных объектов с локальным руководством, на каждом из них должна быть копия Биб­лиотеки DSL на случай развертывания программного обеспечения.

Склад эталонного аппаратного обеспечения[135] (DHS)

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

Конфигурационная База Данных (CMDB)

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

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

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

? данные о физическом местонахождении аппаратных средств, имеющих отношение к релизу.

8.2. Цель процесса

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

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

? Планирование, координация и внедрение (или организация внедрения) программных и аппарат­ных средств.

? Разработка и внедрение рациональных[136] процедур для распространения и инсталляции изменений в ИТ-системах.

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

? Коммуникации и оповещение пользователей, учет их ожиданий при планировании и развертыва­нии новых релизов.

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

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

? Обеспечение сохранности оригинальных копий программ в Библиотеке эталонного программного обеспечения (DSL) и регулярного обновления базы данных CMDB; то же касается аппаратных средств на Складе DHS.

8.2.1. Преимущества использования процесса

Вместе с эффективными Процессами Управления Конфигурациями и Управления Изменениями Процесс Управления Релизами способствует тому, чтобы:

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

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

? Бизнес-подразделения внимательно контролировали инвестиции в программное обеспечение, от которых во многом зависит бизнес.

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

? Уменьшалась опасность возникновения инцидентов и известных ошибок за счет тестирования и контроля внедрения.

? Пользователи больше привлекались к участию в тестировании релизов.

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

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

? Бизнес-подразделения могли стандартизировать версии программного и аппаратного обеспечения в своих подразделениях для облегчения их поддержки.

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

? Облегчалось обнаружение неавторизованных копий и некорректных версий.

8.3. Процесс

Процесс Управления Релизами состоит из следующих видов деятельности:

? разработка политики в отношении релизов и их планирование;

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

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

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

? оповещение, подготовка и обучение;

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

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

Рис. 8.4. Управление Релизами

Успешное проведение Управления Релизами зависит от входной информации, поступающей из дру­гих процессов ITIL, и от взаимодействия с этими процессами (рис. 8.4). Главными являются интер­фейсы со следующими процессами.

8.3.1. Управление Конфигурациями

Управление Конфигурациями отвечает за регистрацию доступных версий программного и аппарат­ного обеспечения в базе данных CMDB в качестве Базисных Конфигураций. Программы, включае­мые в Библиотеку DSL, и аппаратные средства для DHS регистрируются в CMDB с согласованным уровнем детализации. Мониторинг статуса, выполняемый Процессом Управления Конфигурация­ми, отражает статус каждой Конфигурационной Единицы, например, "В активном использовании", "В разработке", "В тестировании", "В запасе" или "В архиве".

8.3.2. Управление Изменениями

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

8.3.3. Управление Уровнем Услуг

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

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

На рис. 8.5 показаны виды деятельности в рамках Процесса Управления Релизами и их связи с жиз­ненным циклом изменения.

Рис. 8.5. Виды деятельности по Управлению Релизами (источник: OGC)

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 для облегчения про­верки лицензионных соглашений.

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

8.5.1. Затраты

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

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

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

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

8.5.2. Проблемы

Возможно возникновение следующих проблем:

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

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

? Срочные исправления – не следует действовать в обход Процесса Управления Релизами даже при необходимости срочных изменений.

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

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

Глава 9 Служба Service Desk

9.1. Введение

Служба Service Desk играет важную роль в поддержке пользователей. Современная полномасштаб­ная Служба Service Desk выполняет функции "фронт-офиса" для всей ИТ-организации и сама мо­жет решать большую часть обращений и запросов пользователей, не прибегая к помощи специали­стов. Для пользователей Служба Service Desk является единой точкой контактов с ИТ-организаци­ей, гарантирующей своевременное решение их вопроса. Другими словами, при наличии Службы Service Desk пользователям не нужно тратить время на бесконечные поиски специалистов, которые смогут решить их проблемы. Часто Служба Service Desk занимается не только обработкой внешних обращений пользователей, но и тех обращений, которые были инициированы внутри самой ИТ-ор­ганизации, например, решает инциденты, обнаруженные автоматически или вручную ИТ-персона­лом, или принимает Запросы на Обслуживание от других подразделений ИТ-организации.

Данная глава отличается от других глав книги, поскольку в ней основное внимание уделяется функ­ции, организационной единице или подразделению, а не процессам, как в других главах. Эта тема включена в книгу, потому что Служба Service Desk играет важнейшую роль в ИТ Сервис-менедж­менте. Для обозначения более широкого спектра деятельности в книге используется понятие Ser­vice Desk, вместо употребляемого долгое время термина Help Desk. Служба Help Desk обычно участ­вовала только в Процессе Управления Инцидентами, в то время как Служба Service Desk охватыва­ет более широкий спектр деятельности ИТ.

Служба Service Desk выполняет действия в рамках ряда базовых процессов ITIL, а именно:

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

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

? Если при регистрации инцидента Служба Service Desk проверяет информацию о пользователе и детали Конфигурации его ИТ-ресурсов, то в этом случае Служба участвует в Процессе Управле­ния Конфигурациями.

Рис. 9.1. Процессы, в которых участвует Служба Service Desk

? Служба Service Desk может выполнять Стандартные Запросы, такие как подключение к LAN и пе­ремещение рабочих станций, в этом случае она участвует в оценке и проведении изменений и, сле­довательно, в Процессе Управления Изменениями.

? Служба Service Desk информирует пользователей о поддерживаемых ею продуктах и услугах. Ес­ли Служба не имеет полномочий на выполнение какого-либо Запроса, ей следует вежливо сооб­щить пользователю об этом и известить Процесс Управления Уровнем Услуг о поступившем За­просе.

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

9.2. Цель

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

Являясь точкой контакта с пользователями, Служба Service Desk позволяет уменьшить нагрузку на другие ИТ-подразделения путем "перехвата" не относящихся к делу обращений и вопросов, на ко­торые легко ответить. Служба Service Desk действует как фильтр, который пропускает звонки на вторую и третью линии поддержки, только когда это действительно необходимо. Как единая точка контактов, Service Desk всегда действует профессионально при общении с пользователями и обере­гает их от бесконечных поисков решения.

9.3. Структура

9.3.1. Доступность[146]

Одной из основных задач Службы Service Desk является обеспечение доступа пользователей к ИТ-организации. Следует поощрять пользователей обращаться в Службу Service Desk, если у них есть вопросы или им нужна поддержка. Возможно осуществлять мониторинг способа обращений с помо­щью отчетов, предоставляемых телефонной станцией РАВХ.

Для создания благоприятного впечатления Служба Service Desk в своей работе с заказчиками долж­на действовать квалифицировано и быть последовательной. Этому могут способствовать специаль­но разработанные процедуры взаимодействия и стандартные анкеты (опросники)[147] с вариантами стандартных ответов.

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

9.3.2. Поддержка бизнеса

Звонки можно разделить на несколько групп: звонки, связанные с инцидентами в технической инф­раструктуре; звонки, связанные с инцидентами и вопросами по использованию приложений; звонки с вопросами о статусе услуг (ходе работы над инцидентами), Запросы на Стандартные Изменения и другие Запросы. В зависимости от организационного типа, Служба Service Desk может рассматривать либо все обращения или только те обращения, которые связаны с техническими проблемами и запросами, а поддержку приложений оставить заказчику. В последнем случае подразделение заказ­чика, где используется приложение, контактирует со Службой поддержки бизнес-операций[148]. Данная Служба будет отвечать на вопросы пользователей по приложениям, а технические вопросы направ­лять в Службу Service Desk ИТ-организации. При такой организации работы Служба Service Desk не будет перегружена вопросами, связанными с использованием приложений.

9.3.3. Варианты организации Службы Service Desk

Существует несколько вариантов организации Служб Service Desk. Наиболее распространенными являются следующие:

? Централизованная Служба Service Desk как единая точка контакта для всех пользователей, воз­можно с отдельной Службой Service Desk, расположенной ближе к пользователям бизнес-прило­жений (Service Desk с разделением функций).

? Локальные (распределенные) Службы Service Desk, расположенные на нескольких объектах. Обычно такое деление Службы Service Desk усложняет управление.

? Виртуальная Служба Service Desk, когда ее географическое расположение не имеет значения в связи с использованием коммуникационных и Интернет-технологий.

Централизованная Служба Service Desk

На рис. 9.2 показана структура Централизованной Службы Service Desk с разделением функций. Ес­ли ИТ-организация несет ответственность и за предоставление услуг, и за поддержку информацион­ных систем, то лучше всего, чтобы Служба Service Desk была для пользователей единой точкой кон­тактов. В этом случае Service Desk отвечает за прием, регистрацию, мониторинг хода обработки и эс­калацию звонков. Функция поддержки бизнес-операций может являться частью функций Службы Service Desk или же за это может отвечать отдельная группа поддержки, контролируемая Службой Service Desk Для такой организации работы требуется общая система регистрации инцидентов. Если ИТ-организация не несет ответственности за поддержку бизнес-операций, тогда служба под­держки бизнес-операций будет действовать от лица пользователей в тех случаях, когда требуется поддержка со стороны поставщика ИТ-услуг.

Рис. 9.2. Служба Service Desk с разделением функций

Такой подход может сочетаться с организацией "моста" с операционной средой[149] (т. е. точкой кон­центрации руководства операционной деятельностью, которой может выступать, например, Служба Service Desk в сочетании с отделом эксплуатации[150]). Это может быть целесообразно для обеспечения взаимодействия между Службой Service Desk и руководством операционной деятельностью[151], вклю­чая Управление Сетями, Серверами и т. д. Такое взаимодействие Службы Service Desk с функцио­нальными подразделениями ИТ обеспечивает быстрое реагирование в тех случаях, когда Служба Service Desk не может сразу же устранить ошибки. В идеале эти подразделения должны размещать­ся близко друг к другу.

Распределенная Служба Service Desk

Распределенная служба размещается в разных зданиях или даже в разных городах и регионах. На рис 9.3 представлен пример распределенной Службы Service Desk. При использовании такой струк­туры целесообразно выбрать один из предлагаемых ниже вариантов:

? Центральная точка контактов, где звонки принимаются и далее маршрутизируются в локальные службы поддержки. Центральная Служба Service Desk является для пользователей начальной точ­кой контактов, где регистрируются инциденты. Современное программное обеспечение маршру­тизации звонков способствует повышению эффективности работы Службы Service Desk в разре­шении инцидентов.

? Локальные точки контактов с центральной Службой Service Desk предназначены для отслежива­ния и мониторинга инцидентов. Данный подход часто используется в тех случаях, когда у локаль­ной организации свой язык и корпоративная культура, а также когда у организации достаточно много специфических приложений собственной разработки для каждого направления бизнеса. Например, у компании в химической отрасли может быть более трехсот категорий собственных приложений, а общее количество приложений – около тысячи. В такой ситуации единственным практическим решением является распределение функций Службы Service Desk между различны­ми направлениями бизнеса, т. к. для решения инцидентов требуются специфические знания в конкретной области. Локальная ответственность за затраты на поддержку может служить дополни­тельным мотивирующим фактором в такой структуре.

Рис. 9.3. Распределенная Служба Service Desk с централизованным управлением (источник: OGC)

? Центр обработки звонков (Call Center). Этот вариант становится все более популярным, и его ча­сто используют провайдеры и поставщики услуг. По центральному номеру телефона, обычно бес­платному, можно получить доступ к голосовому меню, из которого пользователь выбирает пункт, по которому требуется помощь, например, электронная почта или офисные приложения. Звонок затем направляется к специалисту соответствующей группы поддержки. Эти группы могут нахо­диться в разных местах, но пользователь об этом может даже не подозревать.

Виртуальная Служба Service Desk

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

В последнее время мы видим возможности самостоятельного получения помощи пользователями (самообслуживания - self-help) как форму "автоматизированной" функциональности Службы Ser­vice Desk.

Например, возможность самообслуживания посредством Web-доступа к базе знаний (поиск извест­ных ошибок) и записям инцидентов (проверка статуса и т. д.), способствует сокращению расходов и созданию сообщества пользователей

9.3.4. Персонал Службы Service Desk

Требования к персоналу Службы Service Desk определяются ее миссией и структурой. Ниже даются возможные варианты основных способов построения и требования к персоналу, вытекающие из по­ставленных задач:

? Центр обработки звонков (Call Center): производит только запись/регистрацию звонков и не предоставляет какой-либо поддержки. Обращения перенаправляются к специалистам соответст­вующих подразделений для обработки. В некоторых случаях можно автоматизировать запись и маршрутизацию обращений с помощью голосовых меню.

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

? Квалифицированная Служба Service Desk: этот тип Службы Service Desk предполагает наличие высокого уровня профессиональной подготовки и большого опыта у персонала. Используя доку­ментированные решения, сотрудники данной службы могут решать большую часть всех поступаю­щих инцидентов, хотя некоторые из них все же перенаправляются в группы поддержки. Степень решения инцидентов при первом обращении у такой службы обычно бывает выше, чем у неквали­фицированной Службы Service Desk.

? Экспертная Служба Service Desk: персонал данной службы знает всю ИТ-инфраструктуру и рас­полагает экспертными знаниями, позволяющими решать инциденты самостоятельно.

9.3.5. Технологии для работы Службы Service Desk

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

? интеграция инструментальных средств сервис-менеджемента с системами Управления ИТ инфра­структурой;

? коммуникационные технологии, такие как Computer Telephone Integration (CTI) или Voice Over Internet Protocol (VOIP);

? системы интерактивного речевого меню (Interactive Voice Response – IVR);

? электронная почта (E-Mail);

? факс-серверы (факс через электронную почту или Интернет);

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

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

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

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

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

9.4.1. Ответы на обращения

Обращение (звонок) – это контакт пользователя со Службой Service Desk. Все обращения пользо­вателей должны регистрироваться для облегчения дальнейшей обработки, мониторинга хода обра­ботки и предоставления метрик, необходимых для контроля над процессом.

Существует две категории обращений:

? Инциденты: по существу, это все обращения, за исключением тех, что связаны со стандартными изменениями:

? Сообщения об ошибках: реальные сбои в инфраструктуре и жалобы на услуги.

? Запросы на Обслуживание[152]: в библиотеке ITIL Запросы на Обслуживание классифицируются как инциденты, но они не предполагают наличия сбоя в инфраструктуре. Эти Запросы также не попадают в сферу действия Процесса Управления Изменениями. Примером такого Запроса мо­гут послужить вопросы типа "Как мне сделать?", Запросы на Информацию, например, Запросы о Статусах Систем, Запросы на Документацию или получение рекомендации, Запросы на Смену паролей, Запросы на Запуск Пакетных Заданий, восстановление файлов или получение инфор­мации из базы данных, Запросы на расходные материалы (включая замену мыши, клавиатуры и т. д., если они не являются Конфигурационными Единицами), на предоставление документации, например, руководства пользователя и т. д.

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

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

9.4.2. Предоставление информации

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

9.4.3. Взаимодействие с поставщиками

Служба Service Desk часто отвечает за взаимодействие с обслуживающими организациями и внеш­ними поставщиками. Это касается ремонта и замены принтеров, рабочих станций и в некоторых случаях телекоммуникационного оборудования. Такой тип поддержки может быть использован при обработке инцидентов, в своем первоначальном значении – сбоев, а также инцидентов в смысле За­просов на Обслуживание и Изменений.

9.4.4. Операционные задачи

Примерами таких задач могут быть создание резервных копий и восстановление данных из архива, подключение к локальной сети, Управление Дисковой Памятью на локальных серверах, создание учетных записей[153], авторизация и смена паролей.

9.4.5. Мониторинг инфраструктуры

Служба Service Desk может иметь в своем распоряжении инструментальные средства, помогающие определению степени воздействия сбоев на работу критически важных систем, таких как маршрути­заторы, серверы, шлюзы, приложения и базы данник Часто эти средства автоматически обнаружи­вают сам сбой или угрозу его возникновения и передают информацию в Процесс Управления Ин­цидентами. Службе Service Desk необязательно применять эти средства, т. к. обнаружение сбоев яв­ляется главной задачей операционных подразделений[154] ИТ, которые и передают эту информацию Службе Service Desk

9.5. Эффективность[155]

Удовлетворенность заказчика или пользователя является основным показателем эффективности ра­боты Службы Service Desk. Примерами Ключевых параметров эффективности (KPI) могут быть:

? скорость ответа на телефонные звонки (например, на 90% телефонных звонков отвечают в течение X секунд);

? скорость перенаправления звонков на вторую линию поддержки в течение X минут (если звонок нельзя разрешить на уровне Service Desk);

? восстановление сервиса в течение допустимого времени и в соответствии с условиями Соглаше­ния об Уровне Услуг (SLA);

? своевременное информирование пользователей о текущих и будущих изменениях и ошибках.

Некоторые показатели эффективности можно определить только на основе результатов опроса за­казчиков, например такие как:

? Насколько вежливо специалисты Service Desk общаются по телефону?

? Предоставляются ли пользователям хорошие рекомендации по способу предотвращения инци­дентов?

9.5.1. Отчеты руководству

Служба Service Desk должна регулярно (например, раз в полгода) проверять, насколько ее работа отвечает заданным стандартам. Примерами метрик являются:

? процент инцидентов, которые могут решаться на Уровне Service Desk без перенаправления на другие уровни поддержки (например, на вторую или третью линии поддержки или к поставщику);

? количество обработанных звонков на одно рабочее место/пользователя и общее количество звон­ков, обработанных Службой Service Desk;

? среднее время решения инцидентов (по степени воздействия) или время, необходимое для выпол­нения Запроса на Обслуживание. Следует указывать как непосредственное время на выполнение, так и общее время от открытия до закрытия инцидента;

? отчеты телефонной станции (РАВХ) о среднем времени ответа на телефонный звонок, количестве звонков, прерванных пользователями, средней продолжительности звонков и соответствующих метрик на каждого специалиста Службы Service Desk.

Для этих метрик могут быть определены стандарты, по которым возможно отслеживание улучше­ния или ухудшения в предоставлении услуг. Эффективность Службы Service Desk также может быть измерена путем проведения регулярных опросов и анкетирования пользователей в компании.

9.5.2. Критические факторы успеха

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

Если пользователи пытаются установить контакты напрямую со специалистами, их следует направ­лять в Службу Service Desk.

Для того, чтобы поддержка, оказываемая Службой Service Desk была сфокусированной, следует тщательно прорабатывать Каталог услуг, Соглашения об Уровне Услуг (SLA) и Операционные Сог­лашения об Уровне Услуг (OLAs).

Глава 10 Управление Уровнем Сервиса (Услуг)

10.1. Введение

Управление Уровнем Сервиса (Услуг) – это процесс, в рамках которого происходят переговоры по вопросам предоставления услуг, производится определение, измерение (оценка), управление и улучшение качества ИТ-услуг при соблюдении приемлемого Уровня Затрат. Все эти задачи должны решаться в условиях быстро меняющихся потребностей бизнеса и быстро развивающихся техноло­гий. Процесс Управления Уровнем Сервиса помогает найти нужный баланс между предложением и спросом на услуги требуемого Уровня Качества, их легкостью в использовании и стоимостью. И по­ставщик, и заказчик должны четко осознавать, что услуги не только поставляются, но и используют­ся. Это понимание реализуется в разработке, согласовании и выполнении Соглашений об Уровне Услуг[156] (SLA), Операционных Соглашений об Уровне Услуг[157] (OLA), Внешних Договоров[158] (UC) и Плана Обеспечения Качества Услуг[159] (SQP).

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

Поставщики и заказчики ИТ-услуг

Теоретически, любой, кто получает ИТ-услуги, является заказчиком. В большинстве случаев ИТ-ор­ганизация является поставщиком, но поскольку обычно она тоже получает ИТ-услуги, то одновре­менно выступает и как заказчик ИТ-сервисов у Сервис-провайдеров. Все это создает достаточно сложную сеть взаимоотношений. Например, подразделение разработки программного обеспечения может запросить у отдела центрального процессинга услуги в режиме он-лайн, и одновременно это же подразделение выполняет сопровождение ПО для обеспечения непрерывности запрашиваемых им же услуг. Теоретически Управление Уровнем Сервиса является линейным процессом, нацеленным на определение услуг и заключение соглашений, таких как Внешние Договоры (UC) с внешними по­ставщиками, Операционные Соглашения об Уровне Услуг (OLA) с внутренними поставщиками или Соглашения об Уровне Услуг (SLA) с заказчиками. Однако в данном вопросе требуется гибкий под­ход, так как различие между заказчиком и поставщиком ИТ-сервисов не всегда бывает четким. В контексте Процесса Управления Уровнем Услуг мы используем следующие определения заказчика и поставщика:

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

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

Требования к Уровню Услуг (Service Level Requirements – SLR)

Требования к Уровню Услуг представляют собой детальное описание потребностей заказчика, они используются при разработке, модификации и инициировании услуг. Такие требования можно ис­пользовать в качестве прототипа (кальки) для разработки услуги и соответствующего ей Соглаше­ния об Уровне Сервиса (SLA), а также как проектное задание (design assignment).

Таблицы спецификации сервисов (Service Specification Sheets – Spec Sheets)

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

Каталог услуг (Service Catalog)

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

Соглашение об Уровне Услуг (Service Level Agreement – SLA)

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

Программа улучшения сервиса (Service Improvement Program – SIP)

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

План обеспечения качества услуг (Service Quality Plan – SQP)

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

Операционное Соглашение об Уровне Услуг (Operational Level Agreement – OLA)

Это соглашение с внутренним ИТ-подразделением, в котором конкретизируются договоренно­сти о предоставлении определенных элементов сервисов, например, доступности сети или дос­тупности серверов печати. Например, если соглашение SLA содержит временные показатели в разрешении инцидентов с высоким приоритетом, то Операционное Соглашение об Уровне Услуг (OLA) должно определять цели для каждого элемента цепочки поддержки (параметры для службы Service Desk – время ответа на звонки, эскалация инцидентов и т. д., параметры для Службы поддержки сети – сроки расследования и устранения сетевых ошибок и т. д.). Операци­онные Соглашения об Уровне Услуг помогают ИТ-организации в общем процессе предоставле­ния услуг.

Внешний Договор (Underpinning contract – UC)

Это договор с внешним поставщиком, который определяет договоренности по предоставлению кон­кретных услуг, например, поддержку рабочих станций или аренду линии связи. Действие такого до­говора аналогично внешней реализации соглашения OLA. Во многих организациях ИТ-услуги пре­доставляет внутреннее ИТ-подразделение. В этом случае соглашения SLA и OLA в большей степени представляют собой описание того, о чем договорились между собой внутренние подразделения, чем юридический документ. Однако договор с внешним поставщиком обычно оформляется в форме официального правового документа.

10.2. Цель процесса

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

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

Преимущества использования процесса

В целом, введение в практику Процесса Управления Уровнем Сервиса может дать следующие преи­мущества:

? ИТ-услуги разрабатываются в соответствии с Требованиями к Уровню Услуг и, следовательно, бу­дут отвечать ожиданиям заказчика;

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

? если ИТ-организация выставляет счета заказчику за пользование ИТ-услугами, то заказчик смо­жет сопоставить Уровень Качества услуг с предъявленной в счете стоимостью;

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

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

? и заказчик, и ИТ-организация знают о своих обязанностях и ролях, следовательно, будет меньше недопонимания и упущений.

10.3. Процесс

Управление Уровнем Сервиса – это процесс, который связывает поставщика ИТ-услуг и заказчика. Этот процесс имеет следующие задачи:

? интеграцию элементов, необходимых для предоставления ИТ-услуг;

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

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

? согласование ИТ-стратегии с потребностями бизнеса;

? контролируемое улучшение предоставления ИТ-услуг.

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

Рис. 10.1. Процесс Управления Уровнем Сервисов

В рамках Процесса Управления Уровнем Сервиса выполняются следующие виды деятельности:

? Идентификация – идентификация потребностей заказчика, управление взаимоотношениями и внутреннее продвижение[160] ИТ-организации. Понимание бизнес-процессов и потребностей заказчи­ка.

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

? Окончательное оформление соглашения – заключительный этап работы над соглашением, т. е. обсуждение с заказчиком требуемого Уровня Сервисов и связанных с этим затрат, закрепление до­стигнутых договоренностей в Соглашении об Уровне Сервиса (SLA). Подкрепление соглашения SLA Операционными Соглашениями об Уровне Услуг (OLA) и Внешними Договорами (UC). Сос­тавление или обновление Каталога Услуг с указанием в нем доступных для заказчиков услуг.

? Мониторинг – мониторинг Уровней Сервисов.

? Отчетность – составление Отчетов об Уровне Сервисов. Регулярное предоставление отчетов за­казчику и ИТ-организации о реальных текущих Уровнях Предоставления Услуг в сравнении с об­щим достигнутым Уровнем (Service Level Achievement).

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

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

Взаимоотношения со Службой Service Desk

Хотя Служба Service Desk является функцией (функциональным подразделением), а не процессом, ее взаимосвязь с Процессом Управления Уровнем Сервиса является особенно важной. Служба Ser­vice Desk является начальной точкой контактов для пользователей, и ее цель в случае возникнове­ния сбоя – восстановить согласованный Уровень Предоставления Услуг как можно скорее посредст­вом Процесса Управления Инцидентами. Поскольку данная служба напрямую контактирует с поль­зователями, она может предоставить ценную информацию об их восприятии Уровня Сервисов (сте­пени удовлетворенности). Обычно существует сильная зависимость между степенью удовлетворен­ности пользователя и заказчика. Служба Service Desk также играет важную роль в определении вре­мени реагирования и времени разрешения при возникновении сбоя в предоставлении сервисов.

Взаимоотношения с Процессом Управления Доступностью

Процесс Управления доступностью отвечает за реализацию и оптимизацию доступности услуг. Уп­равление Уровнем Сервиса предоставляет Процессу Управления доступностью входную информа­цию о требуемом Уровне Доступности ИТ-услуг, и этот процесс, в свою очередь, дает Управлению Уровнем Услуг информацию о реально существующем Уровне Доступности ИТ-сервисов.

Взаимоотношения с Процессом Управления Мощностями

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

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

Взаимоотношения с Процессами Управления Инцидентами и Проблемами

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

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

Наличие механизмов разрешения инцидентов и проблем является необходимым условием для пре­доставления высококачественных услуг. Процесс Управления Уровнем Сервиса использует инфор­мацию из этих процессов при составлении своих отчетов заказчику.

Взаимоотношения с Процессом Управления Изменениями

В соглашении SLA могут быть определены изменения, которые запрашивает организация заказчика, и соглашения, которые будут регулировать эти изменения (кому изменения адресованы, какое вре­мя цикла, затраты, способы информирования организации и т. д.). Изменение может повлиять на уже согласованные Уровни Сервисов.