Jan van Bon - ИТ СЕРВИС–МЕНЕДЖМЕНТ. Вводный курс на основе ITIL Страница 13

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

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

Ни рис. 4.5. показаны этапы процесса:

Рис. 4.5. Процесс Управления Инцидентами

? Прием и регистрация инцидента (Acceptance and Recording) – принимается сообщение и создается запись об инциденте.

? Классификация и начальная поддержка (Classification and Initial Support) – присваиваются тип, статус, степень воздействия, срочность, приоритет инцидента, SLA и т.п. Пользователю может быть предложено возможное решение, даже если оно только временное.

? Если вызов касается Запроса на Обслуживание (Service Request), то инициируется соответствующая процедура.

? Привязка (или сопоставление – Matching) – проверяется, не является ли инцидент уже извест­ным инцидентом или известной ошибкой, нет ли для него уже открытой проблемы, и нет ли для него известного решения или обходного пути.

? Расследование и диагностика (Investigation and Diagnosis) – при отсутствии известного реше­ния производится исследование инцидента с целью как можно быстрее восстановить нормальную работу.

? Решение и восстановление (Resolution and Recovery) – если решение найдено, то работа может быть восстановлена.

? Закрытие (Closure) – с пользователем связываются, чтобы он подтвердил согласие с предложен­ным решением, после чего инцидент может быть закрыт.

? Мониторинг хода работ и отслеживание (Progress monitoring and Tracking) – весь цикл обработ­ки инцидента контролируется, и если инцидент не может быть разрешен вовремя, производится эскалация.

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

4.4.1. Прием и регистрация

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

? трудно произвести точную регистрацию информации об инциденте, если это не сделано сразу;

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

? зарегистрированные инциденты помогают при диагностике новых инцидентов;

? Управление Проблемами может использовать зарегистрированные инциденты при работе над по­иском корневых причин;

? легче определить степень воздействия, если все сообщения (звонки) зарегистрированы;

? без регистрации инцидентов невозможно контролировать исполнение договоренностей (SLA);

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

Место обнаружения инцидента определяется по признаку, откуда пришло сообщение о нем. Инци­денты могут быть обнаружены следующим образом:

? Обнаружен пользователем: он докладывает об инциденте в Службу Service Desk.

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

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

? Обнаружен кем-либо в другом подразделении ИТ: этот специалист регистрирует инцидент в сис­теме регистрации инцидентов или докладывает о нем в Службу Service Desk.

Необходимо избегать двойной регистрации одного инцидента. Поэтому при регистрации инцидента следует проверить, нет ли аналогичных открытых инцидентов:

? Если есть (и они касаются того же инцидента), информация об инциденте обновляется или же инцидент регистрируется отдельно и устанавливается связь (привязка) к главному инциденту; при необходимости изменяется степень воздействия и приоритет, и добавляется информация о новом пользователе.

? Если нет (отличается от открытого инцидента), производится регистрация нового инцидента.

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

При регистрации инцидента производятся следующие действия:

? Назначение номера инцидента: в большинстве случаев система автоматически назначает новый (уникальный) номер инцидента. Часто этот номер сообщается пользователю, чтобы он мог ссылаться на него при дальнейших контактах.

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

? Запись дополнительной информации об инциденте: добавляется информация, например, из скрипта (script) или процедуры опроса или из Конфигурационной Базы Данных – CMDB (обычно на основе взаимоотношений Конфигурационных Единиц, определенных в CMDB).

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

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

Классификация инцидентов направлена на определение его категории для облегчения мониторинга и составления отчетов. Желательно, чтобы опции классификации были как можно шире, но при этом требуется более высокий уровень ответственности персонала. Иногда пытаются объединить в одном перечне несколько аспектов классификации, таких, как тип, группа поддержки и источник. Это часто вносит путаницу. Лучше использовать несколько коротких перечней. В данном разделе рассматриваются вопросы, относящиеся к классификации.

Категория

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

? Центральная процессинговая система – подсистема доступа, центральный сервер, приложение.

? Сеть – маршрутизаторы, сегменты, концентратор (hub), IP-адреса.

? Рабочая станция – монитор, сетевая карта, дисковод, клавиатура.

? Использование и функциональность – услуга (сервис), возможности системы, доступность, резервное копирование (back-up), документация.

? Организация и процедуры – заказ, запрос, поддержка, оповещение (коммуникации).

? Запрос на Обслуживание – запрос пользователя в Службу Service Desk на поддержку, предоставление информации, документации или оказание консультации. Это может быть выделено в отдельную процедуру или обработано таким же образом, как реальный инцидент.

Приоритет

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

Приоритет = Срочность х Степень воздействия.

Услуги (сервисы)

Для определения услуг, подвергшихся воздействию инцидента, может быть использован перечень существующих договоренностей (соглашений) об Уровне Услуг – SLA. Этот перечень позволит также установить время эскалации для каждой из услуг, определенных в SLA.

Группа поддержки

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

Сроки решения

С учетом приоритета и соглашения SLA пользователь информируется о максимальном расчетном времени разрешения инцидента. Эти сроки также фиксируются в системе.

Идентификационный номер инцидента

Абонент информируется о номере инцидента для его точной идентификации при последующих об­ращениях.

Статус

Статус инцидента указывает на его положение в процессе обработки инцидента. Примерами стату­сов могут быть:

? новый;

? принят;

? запланирован;

? назначен;

? активный;

? отложен;

? разрешен;

? закрыт.

4.4.3. Привязка (сопоставление)

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