В современном мире бизнес критически зависит от ИТ-услуг. Когда падает сервер, недоступна корпоративная почта или «летит» база данных, компании несут убытки. Именно здесь на сцену выходит IT Service Management (ITSM) и его ключевой процесс — Управление инцидентами (Incident Management).

Но что же такое «инцидент» с точки зрения ITSM, и как правильно выстроить работу с ним, чтобы минимизировать потери и не сойти с ума от потока жалоб? Разберемся максимально подробно.

1. Что такое инцидент?

Согласно методологии ITIL (самой популярной библиотеке практик ITSM), Инцидент (Incident) — это любое событие, не входящее в стандартную операционную деятельность, которое приводит или может привести к нарушению качества ИТ-услуги или ее недоступности.

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

Важно отличать инцидент от других типов обращений (заявок):

• Инцидент: «Не работает электронная почта» (сбой).
• Запрос на обслуживание (Service Request): «Создайте мне новый почтовый ящик» (стандартное изменение).

2. Жизненный цикл инцидента: От катастрофы до закрытия

Управление инцидентами — это циклический процесс. Его главная цель — не выяснить, почему всё сломалось (это задача управления проблемами), а вернуть услугу пользователю максимально быстро.

Процесс проходит несколько ключевых этапов:

• Обнаружение и регистрация
  • Источник: пользователь (звонок в сервис-деск), система мониторинга (автоматическое создание тикета), сотрудник ИТ-отдела.
  • На этом этапе создается уникальная запись (Ticket/Incident Record), фиксируется время начала, пострадавший пользователь и симптомы.
• Классификация
  • Присваиваются атрибуты:
    • Категория: «Оборудование», «ПО», «Доступ».
    • Приоритет: Матрица «Срочность x Влияние».
    • Категория влияния: Сколько пользователей или бизнес-процессов затронуто.
• Диагностика и эскалация
  • Функциональная эскалация: передача тикета более компетентной группе специалистов (например, от 1-й линии поддержки ко 2-й или 3-й).
  • Иерархическая эскалация: подключение руководства для ускорения решения или выделения ресурсов (если инцидент высокого приоритета).
• Решение и восстановление
  • Применение «обходного решения» — временного способа возобновить работу сервиса (например, перезагрузка сервера, переход на резервный канал).
  • Окончательное исправление (если найдено).
• Закрытие инцидента
  • Подтверждение пользователем, что всё работает.
  • Заполнение полей «Код завершения» (например, «Решено», «Безуспешно», «Дубликат»).
  • Важно: перед закрытием проводится проверка удовлетворенности пользователя.

3. Ключевые роли в управлении инцидентами

Чтобы процесс работал, необходимы четко распределенные роли:

• Пользователь (End User): Лицо, столкнувшееся с проблемой.
• Сотрудник Сервис-деска:
  • «Первая линия обороны». Регистрирует инциденты, проводит первичную диагностику.
  • Решает простые инциденты (до 70-80%) по скриптам или базе знаний.
  • Не решает в течение 15 минут — эскалирует.
• Группа поддержки: Специалисты 2-й и 3-й линий (системные администраторы, разработчики, инженеры баз данных). Глубокое техническое решение.
• Менеджер инцидентов:
  • Не чинит «железо», но управляет процессом.
  • Контролирует SLA (Service Level Agreement).
  • Проводит «разбор полетов» по критическим инцидентам.
  • Отвечает за коммуникацию с бизнесом во время масштабных сбоев (Major Incident).

4. Приоритезация: Матрица

В ИТ-поддержке нельзя чинить всё одновременно. Критично определять приоритет. Классическая формула ITIL:

Приоритет = Влияние × Срочность

• Влияние (Impact): Насколько сильно инцидент бьет по бизнесу?
  • Высокий: Не работает ключевая система (ERP, биллинг), пострадал весь офис.
  • Низкий: Проблема у одного сотрудника с неосновной функцией.
• Срочность (Urgency): Насколько быстро нужно это исправить с точки зрения бизнеса?
  • Высокая: Блокируется сделка, дедлайн «горит».
  • Низкая: Можно сделать до конца недели.

На основе пересечения этих параметров инциденту присваивается приоритет: Критический (1) , Высокий (2) , Средний (3) , Низкий (4).

5. Критический инцидент (Major Incident)

Это особая категория. Major Incident — это сбой, вызывающий значительные убытки, ставящий под угрозу жизнь или безопасность, либо затрагивающий критическое количество пользователей/бизнес-процессов.

Для таких ситуаций создается отдельный протокол:

1. Создается отдельный «военный» чат (War Room).
2. Вводится регламент коммуникации: оповещение руководства каждые 15-30 минут.
3. Приоритет — восстановление сервиса (обходное решение). Поиск коренной причины (Root Cause) откладывается до стабилизации ситуации.
4. После устранения обязательно формируется Отчет о расследовании причин инцидента (RCA — Root Cause Analysis) и план предупреждения повторения.

6. Метрики и KPI: Как измерить успех?

Процессом управления инцидентами нужно управлять с помощью цифр. Основные метрики:

• MTTR (Mean Time to Resolve): Среднее время решения инцидента (главный показатель скорости).
• MTTA (Mean Time to Acknowledge): Среднее время до назначения ответственного (реактивность).
• FCR (First Call Resolution): Процент инцидентов, решенных на первой линии (без эскалации). Целевое значение часто > 70-80%.
• SLA Compliance: Процент инцидентов, решенных в сроки, оговоренные в соглашении об уровне услуг.

7. Чем инцидент отличается от проблемы (Problem)?

Это классическая путаница в ITSM.

• Инцидент: Симптом. «Автомобиль не заводится».
• Проблема: Причина. «Сгорел стартер».

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

Заключение

Управление инцидентами — это сердце ITSM. Это не просто техподдержка, это бизнес-процесс, который защищает репутацию компании и финансовые потоки.

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