Введение в ИТ сервис-менеджмент

? содержание запланированных релизов, включая Конфигурационные Единицы аппаратного и программного обеспечения со ссылкой на исходный Запрос на Изменения (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 играет важнейшую роль в ИТ Сервис-менеджменте. Для обозначения более широкого спектра деятельности в книге используется понятие Service 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) как форму "автоматизированной" функциональности Службы Service 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 Цель процесса

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

...