
- •Оглавление
- •Управление Инцидентами
- •4.1. Введение
- •4.1.1. Терминология
- •4.2. Цель
- •4.2.1. Преимущества использования процесса
- •4.3. Процесс
- •4.4.1. Прием и регистрация
- •4.4.2. Классификация
- •4.4.7. Мониторинг хода решения и отслеживание
- •4.5. Контроль процесса
- •4.5.1. Критические факторы успеха
- •Управление Проблемами
- •5.1. Введение
- •5.1.1. Определение — «проблема» и «известная ошибка»
- •5.1.2. Взаимоотношения с Процессом Управления Инцидентами
- •5.2. Цель процесса
- •5.3. Процесс
- •5.3.3 Управление Конфигурациями
- •5.4.2. Контроль ошибок
- •5.4.3. Проактивное Управление Проблемами
- •5.5.3. Функции и роли
- •5.6. Затраты и проблемы
- •5.6.2. Проблемы
- •Управление Конфигурациями
- •6.1.1. Основные понятия
- •6.2. Цель процесса
- •6.2.1. Преимущества использования процесса
- •6.3. Процесс
- •6.4. Виды деятельности
- •6.4.3. Мониторинг статуса
- •6.4.4. Контроль
- •6.4.5. Верификация и аудит
- •6.5. Контроль процесса
- •6.6. Затраты и проблемы
- •Управление Изменениями
- •7.1. Введение
- •7.3.1. Управление Инцидентами
- •7.3.1. Управление Инцидентами
- •7.4. Виды деятельности
- •7.4.1. Регистрация
- •7.4.4. Планирование
- •7.4.5. Координация
- •7.5 Контроль процесса
- •7.5.1 Отчеты для руководства
- •Управление Релизами
- •8.1.1. Основные понятия
- •8.2. Цель процесса
- •8.2.1. Преимущества использования процесса
- •8.3. Процесс
- •8.3.4. Виды деятельности
- •8.4. Виды деятельности
- •8.5.2. Проблемы
- •Служба Service Desk
- •9.1. Введение
- •9.3.3. Варианты организации Службы Service Desk
- •9.3.4. Персонал Службы Service Desk
- •9.3.5. Технологии для работы Службы Service Desk
- •9.5. Эффективность
- •Управление Уровнем Сервиса (Услуг)
- •10.1. Введение
- •10.1.1. Основные понятия
- •Управление финансами ит
- •Управление Мощностями
- •Управление Непрерывностью ит-сервисов
- •Управление Доступностью
4.4.1. Прием и регистрация
13 большинстве случаев инциденты регистрируются Службой Service Desk, куда поступают сообщения о них. Регистрация всех инцидентов должна производиться немедленно после поступления сообщения по следующим причинам:
трудно произвести точную регистрацию информации об инциденте, если это не сделано сразу;
мониторинг хода работ по решению инцидента возможен, только если инцидент зарегистрирован;
зарегистрированные инциденты помогают при диагностике новых инцидентов;
Управление Проблемами может использовать зарегистрированные инциденты при работе над поиском корневых причин;
легче определить степень воздействия, если все сообщения (звонки) зарегистрированы;
без регистрации инцидентов невозможно контролировать исполнение договоренностей (SLA);
немедленная регистрация инцидентов предотвращает ситуации, когда или несколько человек работают над одним звонком, или никто ничего не делает для разрешения инцидента.
Место обнаружения инцидента определяется по признаку, откуда пришло сообщение о нем. Инциденты могут бьп ь обнаружены следующим образом:
Обнаружен пользователем: он докладывает об инциденте в Службу Service Desk.
Обнаружен системой: при обнаружении события в приложении или технической инфраструктуре, например, при превышении критического порога, событие регистрируется как инцидент в системе регистрации инцидентов и, при необходимости, направляется в группу поддержки.
Обнаружен сотрудником Службы Service Desk: сотрудник производит регистрацию инцидента.
Обнаружен кем-либо в другом подразделении ИТ: этот специалист регистрирует инцидент в системе регистрации инцидентов или докладывает о нем в Службу Service Desk.
Необходимо избегать двойной регистрации одного инцидента. Поэтому при регистрации инцидента следует проверить, нет ли аналогичных открытых инцидентов:
Если есть (и они касаются того же инцидента), информация об инциденте обновляется или же инцидент регистрируется отдельно и устанавливается связь (привязка) к главному инциденту; при необходимости изменяется степень воздействия и приоритет, и добавляется информация о новом пользователе.
Если нет (отличается от открытого инцидента), производится регистрация нового инцидента.
В обоих случаях продолжение процесса одинаково, хотя в первом случае последующие действия гораздо проще.
При регистрации инцидента производятся следующие действия:
Назначение номера инцидента: в большинстве случаев система автоматически назначает новый (уникальный) номер инцидента. Часто этот номер сообщается пользователю, чтобы он мог ссылаться на него при дальнейших контактах.
Запись базовой диагностической информации: время, признаки (симптомы), пользователь, сотрудник, принявший вопрос в обработку, место произошедшего инцидента и информация о затронутой услуге и/или технических средствах.
Запись дополнительной информации об инциденте: добавляется информация, например, из скрипта (script) или процедуры опроса или из Конфигурационной Вазы Данных — CMDB (обычно на основе взаимоотношений Конфигурационных Единиц, определенных в CMDB).
Объявление сигнала тревоги: если происходит инцидент, имеющий высокую степень воздействия, например, сбой важного сервера, производится предупреждение других пользователей и руководства.