Управление инцидентами и проблемами: разница по ITIL

Кратко

В ITIL (библиотеке практик управления ИТ-услугами) управление инцидентами и управление проблемами — два соседних, но разных процесса. Цель управления инцидентами — вернуть работу как можно быстрее, пусть даже обходным путём. Цель управления проблемами — найти и устранить причину, из-за которой инциденты одного класса повторяются. Их разводят намеренно: смешанный процесс либо чинит слишком медленно, либо чинит только симптом и оставляет причину нетронутой.

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

Два процесса, а не два слова

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

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

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

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

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

Отсюда в ITIL появляется понятие known error (известная ошибка) — запись о том, что причина найдена, но постоянного решения ещё нет. У known error всегда есть обходной путь, которым может воспользоваться любой инцидент этого класса, пока причину не устранили полностью. Известная ошибка — это мост между «мы поняли, в чём дело» и «мы это исправили окончательно»: команда уже не тратит время на повторную диагностику при каждом новом инциденте, а сразу применяет известный обход.

С какого момента заводить проблему

Практический порог, с которого разумно завести отдельную запись о проблеме, а не разбирать каждый инцидент заново: третий однотипный инцидент за обозримый период (например, месяц). Один случай — это ещё не закономерность, может быть случайностью. Два — уже повод присмотреться. Третий одинаковый инцидент почти всегда означает, что источник системный, и разбираться с ним по одному разу на каждое обращение — не экономия времени, а его трата вслепую.

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

Кто отвечает за что

Разделение процессов оправдано, только если у него есть организационные последствия, а не только запись в глоссарии:

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

Частые ошибки

• Проблему заводят по каждому инциденту. Если завести проблему на единичный сбой, процесс превращается в дублирование инцидентов под другим названием и перестаёт отличать закономерность от случайности.
• Проблему не заводят никогда. Тогда одна и та же причина чинится заново при каждом повторении, а нагрузка на линию поддержки растёт незаметно, потому что каждый отдельный инцидент выглядит небольшим.
• Known error теряется вместе с закрытым инцидентом. Обходной путь, найденный во время инцидента, не фиксируется отдельно — и при следующем повторении команда ищет его заново, с нуля.
• Проблему закрывают сразу после временной меры. Обходной путь снимает симптом, но не причину; закрытие проблемы на этом этапе оставляет причину нетронутой под видом решённой задачи.

Как проверить, что процессы у вас разделены по-настоящему

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

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

Управление инцидентами и проблемами — это одно и то же?

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

Нужен ли отдельный процесс управления проблемами в маленькой команде?

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

Что такое known error в ITIL?

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

Как понять, что инцидент нужно перевести в проблему?

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

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

Отдельной сущности «проблема» в TehProf.kz Support нет — продукт ведёт заявки, их статусы и приоритеты, а не отдельный реестр причин. Полный набор статусов заявки и переходов между ними описан в статье Статусы заявок; приоритет по влиянию и срочности определяет, что чинится в первую очередь, — в статье Приоритет заявки.

Практическая замена процессу управления проблемами — журнал аудита: он фиксирует действия с заявками, включая массовые изменения статуса, и позволяет вручную сопоставить повторяющиеся по теме заявки за период, чтобы увидеть закономерность до того, как её заметят по жалобам клиентов. Устройство раздела — в статье История / Аудит. Отдельный разбор того, как отличать разовый повтор от системной причины, — в статье Как работать с повторными обращениями.

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

• Инцидент или запрос на обслуживание: в чём разница
• Статусы заявок
• Приоритет заявки: как его определяют через влияние и срочность
• История / Аудит
• Как работать с повторными обращениями