Incident Management по ITIL 4: жизненный цикл инцидента

Что такое инцидент и чем он не является

По ITIL 4 инцидент — это незапланированное прерывание услуги или снижение её качества. Ключевое слово — «незапланированное». Если почта работает медленно, не открывается портал, отвалился VPN — это инциденты. Цель процесса одна: как можно быстрее восстановить нормальную работу, даже временным обходным решением (workaround), не дожидаясь устранения первопричины.

Что инцидентом не является:

• Сервисный запрос — «дайте доступ к папке», «установите 1С». Это штатная, заранее согласованная операция. Её обрабатывает Request Fulfillment, а не управление инцидентами.
• Проблема — первопричина одного или нескольких инцидентов. Инцидент «почта упала» закрывают восстановлением; проблему «почему она падает раз в неделю» решают отдельно и не спеша.
• Изменение — плановое обновление сервера. Если оно идёт по согласованному окну, это Change Management, а не инцидент.

Эта развилка — основа всей классификации обращений. Если её не провести на входе, в одну очередь сваливаются «срочно лежит прод» и «хочу второй монитор», и приоритеты перестают что-либо значить.

Жизненный цикл инцидента

Стандартный поток инцидента состоит из шести этапов. На каждом важно фиксировать в карточке тикета, что произошло — это и аудит, и материал для будущего Knowledge Management.

1. Регистрация (identification & logging). Инцидент попадает в систему — из портала, почты, чата или автоматически из мониторинга. Фиксируются время, заявитель, описание, затронутая услуга.
2. Категоризация. К какой услуге/CI относится, какой тип. От этого зависит маршрутизация и подбор шаблона решения.
3. Приоритизация. Назначается приоритет по матрице impact × urgency (см. ниже) — он определяет дедлайны SLA.
4. Диагностика и эскалация. L1 пытается решить по базе знаний; если не может — эскалация на L2/L3. Важно различать функциональную (по компетенции) и иерархическую (по полномочиям) эскалацию.
5. Решение и восстановление. Применяется workaround или полное решение. Услуга восстановлена — фиксируется время решения.
6. Закрытие. Подтверждение от пользователя, проставление кода решения, при необходимости — запуск опроса CSAT и создание проблемы для разбора первопричины.

Приоритизация: матрица impact × urgency

Приоритет инцидента — это не «как громко кричит заявитель», а функция двух осей: влияние (impact) — сколько пользователей/услуг затронуто, и срочность (urgency) — как быстро влияние нарастает. Их пересечение даёт приоритет:

             Срочность
            Высокая  Средняя  Низкая
Влияние ┌─────────────────────────────
Высокое │   P1       P2       P3
Среднее │   P2       P3       P4
Низкое  │   P3       P4       P4

P1 (critical) — «лежит сервис для всех», реакция в минутах, при необходимости поднимается Major Incident. P4 — мелочь, влияющая на одного человека и терпящая до завтра. Под каждый приоритет — свой SLA по времени реакции и решения.

Главное правило: приоритет инцидента и приоритет запроса считаются по разным шкалам. Запрос на новый ноутбук никогда не должен конкурировать за P1 с упавшим прод-сервисом.

Модели инцидентов и known errors

Модель инцидента (incident model) — это заранее описанный сценарий обработки для повторяющихся типовых ситуаций: шаги, ответственные, дедлайны, шаблон ответа. Когда «снова не печатает сетевой принтер на 3-м этаже» — оператор не импровизирует, а идёт по готовой модели. Это резко снижает время решения и разброс качества между операторами.

Known error (известная ошибка) — это задокументированная проблема с найденным workaround. Если первопричина известна, но ещё не устранена, статья known error в базе знаний позволяет L1 закрывать инцидент за минуты, не эскалируя. Связка «инцидент → проблема → known error → статья КБ» — это и есть переход от тушения пожаров к управляемому процессу.

В TIQQET модели реализуются через шаблоны заявок и канонические ответы, а known errors живут в базе знаний со ссылками прямо из карточки тикета.

Метрики и антипаттерны

Здоровье процесса управления инцидентами показывают:

• FRT и время решения — см. разбор отличий. Отдельно по приоритетам, иначе средние врут.
• FCR (First Contact Resolution) — доля инцидентов, решённых на L1 без эскалации. Цель — 60–75%.
• % соблюдения SLA — по реакции и по решению.
• Reopen rate — доля повторно открытых. Рост означает «закрываем не починив».

Частые антипаттерны: закрывать инцидент по тайм-ауту без подтверждения пользователя; искусственно занижать приоритет ради SLA; смешивать инциденты и запросы в одной очереди; не создавать проблему после серии однотипных инцидентов. Последнее особенно дорого — команда бесконечно тушит один и тот же пожар вместо того, чтобы один раз погасить источник.