Управление инцидентами: что это и как устроен процесс

Кратко

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

Актуально на 23 сентября 2026 года.

Зачем нужен процесс, а не просто «чинить по мере поступления»

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

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

Пять шагов процесса

Важное разграничение внутри процесса: диагностика инцидента ищет причину, которая позволяет восстановить работу сейчас, а не причину, которая объясняет, почему сбой вообще стал возможен. Это две разные задачи с разными сроками. Первая должна закрыться в рамках SLA на инцидент. Вторая — отдельный процесс, который называется управлением проблемами, и торопить его тем же сроком бессмысленно: докопаться до корня за 40 минут обычно нельзя.

Приоритет считается через влияние, а не через тон сообщения

Частая ошибка — присваивать приоритет по эмоциональной окраске обращения: кто написал капсом или пригрозил разрывом договора, тот и получил «критический». Рабочая матрица строится на двух осях:

Матрица снимает главный источник спора — не «насколько это серьёзно звучит», а сколько человек не могут работать и насколько сильно. Подробнее конструкция матрицы разобрана в статье Приоритет заявки: как его определяют через влияние и срочность.

Разбор после закрытия — необязательный шаг, который экономит больше всего времени

Разбор проводится не по каждому инциденту: явное правило — только по критическим и по высоким, которые заняли больше договорного срока. Формат разбора — три вопроса, а не поиск виноватого:

• что произошло и как долго длилось;
• что помогло вернуть работу быстрее, а что задержало;
• какое одно изменение снизит вероятность повтора или ускорит устранение в следующий раз.

Без фиксации ответа на третий вопрос разбор превращается в пересказ хронологии, и через два месяца похожий инцидент повторяется теми же шагами с той же задержкой.

Частая ошибка: путать инцидент с запросом на обслуживание

«Не работает интеграция с почтой» — инцидент: было обещано, что работает, перестало. «Настройте нам ещё одну интеграцию с почтой» — запрос на обслуживание: плановая просьба, ничего не сломано. Если оба типа стоят в одной очереди без разделения, плановые просьбы регулярно обгоняют по срочности настоящие сбои просто потому, что их больше, — а инцидент тонет в очереди рутинных задач. Разница и как её проводить на входе — в статье Инцидент или запрос на обслуживание: в чём разница.

Как проверить процесс за час

• Возьмите последний критический инцидент и пройдите по нему на бумаге: сколько заняла регистрация, сколько — присвоение приоритета, сколько — диагностика. Если приоритет присваивался дольше диагностики, процесс не выстроен.
• Проверьте, зафиксировано ли время начала сбоя отдельно от времени регистрации в системе. Если это одно и то же поле — фактическое время простоя всегда занижено на время до обращения.
• Посмотрите, есть ли за последние три месяца хотя бы один разбор по критическому инциденту с конкретным пунктом «что изменили». Отсутствие разборов — сигнал, что одни и те же сбои повторяются без выученного урока.
• Сравните долю инцидентов, закрытых в рамках приоритетного срока, и долю с превышением. Смотрите долю, а не абсолютное число — «два просроченных» звучит спокойно, пока не выяснится, что инцидентов всего было три.

Как это устроено в TehProf.kz Support

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

Частые вопросы

Что такое управление инцидентами простыми словами?

Заранее определённый порядок действий при сбое: зарегистрировать, оценить влияние, найти способ восстановить работу, закрыть и при необходимости разобрать причины. Цель — предсказуемая скорость реакции независимо от того, кто дежурит.

Чем управление инцидентами отличается от управления проблемами?

Управление инцидентами ищет способ быстро восстановить работу. Управление проблемами ищет корневую причину, чтобы сбой не повторился. Это разные процессы с разными сроками: первый — минуты и часы, второй — дни и недели.

Какие этапы включает процесс управления инцидентами?

Регистрация, приоритезация по влиянию и срочности, диагностика непосредственной причины, устранение или обходное решение, закрытие и (для значимых инцидентов) разбор после закрытия.

Кто отвечает за управление инцидентами в компании?

Обычно дежурный или оператор первой линии регистрирует и присваивает приоритет, вторая линия или ответственный инженер устраняет, руководитель утверждает результат разбора по критическим случаям.

Чем процедура управления инцидентами в ITIL отличается от простого подхода без методологии?

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

Связанные статьи

• Что такое ITSM-система простыми словами
• Инцидент или запрос на обслуживание: в чём разница
• Приоритет заявки: как его определяют через влияние и срочность
• Статусы заявок
• Настройка SLA, приоритетов и крайнего срока