Управление проблемами (Problem Management) по ITIL

Problem Management (управление проблемами) — это процесс ITIL, который ищет и устраняет корневые причины повторяющихся инцидентов. Если управление инцидентами тушит пожар, то управление проблемами выясняет, почему этот пожар вообще случается, и убирает источник.

Страница входит в разбор процессов ITIL и тесно связана с практиками из материала «Договор на IT-обслуживание: на что смотреть», где зрелость процессов поддержки — один из критериев хорошего подрядчика.

Проблема и инцидент — в чём разница

Это ключевое различие в ITIL, и его путают чаще всего.

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

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

Инцидент отвечает на вопрос «как восстановить сервис сейчас». Проблема — на вопрос «как сделать, чтобы это больше не повторялось».

Два подхода: реактивный и проактивный

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

Проактивное управление проблемами работает на опережение: анализирует тренды инцидентов, метрики мониторинга и слабые места инфраструктуры, чтобы найти потенциальные источники сбоев до того, как они выстрелят. Например, замечает, что диск сервера заполнится через две недели при текущем тренде, и инициирует работы заранее.

Поиск корневой причины (RCA)

Сердце процесса — RCA (Root Cause Analysis — анализ корневой причины). Цель — не остановиться на симптоме, а докопаться до настоящего источника. Распространённые методы: «5 почему» (последовательно задавать вопрос «почему?», пока не дойдёшь до корня), диаграмма причинно-следственных связей, анализ логов и временной корреляции событий.

Пример цепочки «5 почему»: сайт недоступен → веб-сервер не отвечает → закончилась память → утечка памяти в приложении → старая версия библиотеки с известным дефектом. Корень — устаревшая библиотека, а не «перезагрузите сервер». Перезагрузка лечит симптом, обновление библиотеки — проблему.

Известные ошибки и обходные решения

Когда корневая причина найдена, но устранить её сразу нельзя (нужно окно работ, бюджет, согласование), проблема переводится в статус known error (известная ошибка) и заносится в базу известных ошибок вместе с workaround (временным обходным решением).

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

Связь с управлением изменениями

Окончательное устранение корневой причины почти всегда требует изменения в инфраструктуре: обновить ПО, переконфигурировать оборудование, заменить узел. Поэтому управление проблемами формирует запрос на изменение и передаёт его в управление изменениями (Change Management) — чтобы исправление прошло контролируемо, с оценкой риска и планом отката. Так замыкается цикл: инцидент → проблема → корневая причина → изменение → устранение.

Сами инциденты и обращения поступают через Service Desk, который и накапливает статистику, питающую управление проблемами. Все эти процессы — части единого каркаса ITIL.

Что это даёт бизнесу

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

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

Связанные термины

• ITIL-процессы — управление IT-услугами — общий каркас процессов, включая управление проблемами
• Управление изменениями (Change Management) — куда передаётся запрос на устранение корневой причины
• Service Desk — единая точка обращений — источник инцидентов и статистики для анализа проблем