Управление инцидентами Позиционирование управление Инцидентами Терминология

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

Позиционирование управление Инцидентами

Терминология o Инцидент (Incident) — это любое событие, не являющееся частью стандартных операций по предоставлению услуги, которое привело или может привести к нарушению или снижению качества этой услуги o Запрос на Обслуживание (Service request) — это Запрос от Пользователя на поддержку, предоставление информации, консультации или документации, не являющийся сбоем ИТ-инфраструктуры. o Запрос на Изменение (RFC Request for change ) — это экранная или бумажная форма, используемая для записи детальной информации о предлагаемом Запросе на Изменение какой-либо Конфигурационной Единицы (CI - Configuration item ) в ИТ-инфраструктуре или процедуры или какого-либо иного объекта Ш-инфраструктуры.

Приоритеты

Эскалация o Функциональная эскалация (горизонтальная) (маршрутизация) — означает привлечение большего количества специалистов или предоставление дополнительных прав доступа для разрешения инцидента; при этом, возможно, происходит выход за пределы одного структурного ИТ-подразделения. o Иерархическая эскалация (вертикальная) — означает вертикальный переход (на более высокий уровень) в рамках организации, так как для разрешения инцидента недостаточно организационных полномочий (уровня власти) или ресурсов.

Цель Процесса Управления Инцидентами o Скорейшее восстановление нормального Уровня Услуг, определенного в Соглашении об Уровне Услуг (Service Level Agreement — SLA), с минимальными возможными потерями для бизнес- деятельности организации и пользователей. o Кроме того, Процесс Управления Инцидентами должен вести точную регистрацию инцидентов для оценки и совершенствования процесса и предоставления необходимой информации для других процессов.

Взаимодействие с процессом Управления Конфигурациями o Конфигурационная База Данных (Configuration Management Database — CMDB) играет важную роль в Управлении Инцидентами, так как она определяет связь между ресурсами, услугами, пользователями и Уровнями Услуг (сервисов). o Например, Управление Конфигурациями показывает, o При регистрации инцидента в регистрационные данные добавляется связь (link) с соответствующей Конфигурационной Единицей (Configuration Item — CI), позволяющая предоставить более подробную информацию об источнике ошибки. o В случае необходимости может быть обновлен статус соответствующей компоненты в CMDB. Service support

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

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

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

Взаимодействие с процессом Управления Доступностью o Для определения показателей доступности услуг Процесс Управления Доступностью использует регистрационные данные об инцидентах и данные мониторинга статуса, предоставляемые Процессом Управления Конфигурациями. o Аналогично Конфигурационной Единице (CI) в Конфигурационной Базе Данных (CMDB), сервису (услуге) может быть также назначен статус «не работает» . Это может быть использовано для проверки действительных показателей доступности услуги и времени реагирования поставщика. При осуществлении такой проверки необходима фиксация времени действий, произошедших в процессе обработки инцидента, от момента обнаружения и до закрытия Service delivery

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

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

Регистрация Инцидента o Назначение номера инцидента: в большинстве случаев система автоматически назначает новый (уникальный) номер инцидента. Часто этот номер сообщается пользователю, чтобы он мог ссылаться на него при дальнейших контактах. o Запись базовой диагностической информации: время, признаки (симптомы), пользователь, сотрудник, принявший вопрос в обработку, место произошедшего инцидента и информация о затронутой услуге и/или технических средствах. o Запись дополнительной информации об инциденте: добавляется информация, например, из скрипта (script) или процедуры опроса или из Конфигурационной Базы Данных — CMDB (обычно на основе взаимоотношений Конфигурационных Единиц, определенных в CMDB). o Объявление сигнала тревоги: если происходит инцидент, имеющий высокую степень воздействия, например, сбой важного сервера, производится предупреждение других пользователей и руководства.

Классификация o Классификация инцидентов направлена на определение его категории для облегчения мониторинга и составления отчетов. o Желательно, чтобы опции классификации были как можно шире, но при этом требуется более высокий уровень ответственности персонала. n Категория n Приоритет n Услуги (сервисы) n Группа поддержки n Сроки решения n Идентификационный номер инцидента n Статус

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

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

Решение и восстановление o После успешного завершения анализа и разрешения инцидента сотрудник записывает решение в сие тему. o В некоторых случаях необходимо направить Запрос на Изменение (RFC) в Процесс Управления Изменениями. В наихудшем случае, если не найдено никакого решения, инцидент остается «открытым»

Закрытие o После реализации решения, удовлетворяющего пользователя, группа поддержки направляет инцидент обратно в Службу Service Desk. o Эта служба связывается с сотрудником, сообщившим об инциденте, целью получения подтверждения об успешном решении вопроса. o Если он это подтверждает, то инцидент может быть закрыт; в противном случае процесс возобновляется на соответствующем уровне. o При закрытии инцидента необходимо обновить данные об окончательной категории, приоритете, сервисах (услугах), подвергшихся воздействию инцидента и Конфигурационной Единице (CI), вызвавшей сбой.

Мониторинг хода решения и отслеживание o В большинстве случаев ответственной за мониторинг хода решения является Служба Service Desk, как «владелец» всех инцидентов. o Эта служба должна также информировать пользователя о состоянии инцидента. Обратная связь с пользователем может быть уместной после изменения статуса o Во время мониторинга возможна функциональная эскалация к другим группам поддержки или иерархическая эскалация для принятия руководящих решений.

Критические факторы успеха o Актуальная Конфигурационная База Данных (CMDB), помогающая оценить степень воздействия и срочность инцидентов. o База знаний. Например, актуальная база данных по проблемам/известным ошибкам, описывающая способ распознавания инцидентов, имеющиеся решения и обходные пути. Она также может включать аналогичные базы знаний от поставщиков. o Соответствующую автоматизированную систему регистрации, отслеживания и мониторинга инцидентов.

Показатели эффективности o Для оценки производительности процесса необходимо четко определить контрольные параметры и измеряемые оценки, часто называемые показателями эффективности. o Отчет по этим показателям производится регулярно, например раз в неделю, чтобы получить картину изменений, по которой можно было бы определить тенденции.

Функции и роли o Руководитель Процесса Управления Инцидентами. Во многих организациях роль Руководителя Управления Инцидентами играет менеджер Службы Service Desk. o Персонал групп поддержки o В небольших организациях или в целях снижения общих расходов возможно комбинирование ролей, например, совмещение ролей Руководителя Процессов Управления Изменениями и Управления Конфигурациями.

Проблемы o Пользователи и ИТ-специалисты работают в обход процедур Управления Инцидентами o Перегруженность инцидентами и откладывание «на потом» o Эскалация o Отсутствие Каталога Услуг и Соглашений об Уровне Сервисов (SLA) o Недостаточная приверженность процессному подходу со стороны руководства и персонала