Problem Management: поиск и устранение корневых причин

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

Эта путаница — самая распространённая в ITSM. Кратко:

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

Пример: у пяти пользователей "зависает" Outlook (пять инцидентов). В каждом случае мы даём workaround — перезапустить клиент. Инциденты закрыты, пользователи работают. Но причина зависаний не устранена. Это проблема. Её создаёт Problem Manager, ведёт расследование, находит корневую причину (например, конфликт версии плагина), и устраняет её через изменение — обновление плагина. После этого инциденты прекращаются.

Реактивный и проактивный режим

Management проблем делится на два режима:

Реактивный Problem Management

Запускается по факту серии инцидентов. Аналитик видит, что один и тот же тип проблемы возникает 5–10 раз — заводит проблему и начинает расследование. Это 80–90% всей практической работы.

Триггеры для запуска реактивного расследования:

• ≥ 3 инцидента одного типа за неделю
• Инцидент критичного уровня, даже если он единичный
• Инцидент, длившийся больше 4 часов
• Инцидент с массовым impact (> 20 пользователей)
• Повторяющийся инцидент после "решения" прошлого раза

Проактивный Problem Management

Запускается до инцидентов, на основе анализа трендов и слабых мест инфраструктуры. Source:

• Мониторинг: показатели близки к критическим порогам, но ещё не пересекли
• Архитектурные reviews: инженер замечает, что система плохо масштабируется
• Анализ данных: рост нагрузки на диск, близкая исчерпанность лицензий
• Уроки из инцидентов в других компаниях / вендорские security bulletins

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

Жизненный цикл проблемы

1. Регистрация — проблема создаётся с привязкой к инициирующему инциденту (или нескольким).
2. Классификация — тип, приоритет, владелец.
3. Расследование (root cause analysis) — методики см. ниже.
4. Временное решение (workaround) — документируется в базе знаний. Операторы L1 могут применять его к новым инцидентам.
5. Определение корневой причины — конкретная техническая или процессная первопричина.
6. Запрос на изменение (RFC) — для устранения корневой причины создаётся RFC, уходит в Change Management.
7. Внедрение изменения — по процессу из Change Management.
8. Валидация — через 2–4 недели после изменения проверяется, действительно ли инциденты перестали повторяться.
9. Закрытие проблемы — с отметкой о решении и ссылкой на внедрённое изменение.

Методики Root Cause Analysis

Метод «5 почему» (5 Whys)

Самый простой и самый эффективный метод для большинства задач. Задаём вопрос «почему?» пять раз подряд, углубляясь от симптома к причине.

Пример:

• Симптом: Outlook зависает у 5 пользователей.
• Почему? — Плагин архивации блокирует UI-поток при старте.
• Почему? — Плагин синхронизируется с сервером в синхронном режиме.
• Почему? — В версии 3.2 разработчики упустили async.
• Почему? — Не было теста на пользователях с большим архивом.
• Почему? — Чек-листа валидации на типовых окружениях.

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

Диаграмма Исикавы (рыбья кость)

Визуальный метод, раскладывающий возможные причины по 6 категориям (на инженерном: «6M»):

• Man — люди (квалификация, смены, человеческий фактор)
• Method — процессы (регламенты, документация)
• Machine — оборудование (серверы, сеть)
• Material — данные (объём, целостность)
• Measurement — мониторинг (есть ли метрики, алерты)
• Environment — среда (нагрузка, расписание, внешние зависимости)

Подходит для сложных случаев с несколькими возможными причинами. Рисуется на доске в команде за 30 минут, помогает не пропустить ни одну гипотезу.

Временная шкала (Timeline Analysis)

Для сложных инцидентов выстраивается детальный timeline: что происходило в инфраструктуре за часы/дни до начала инцидента. Коррелирует с деплоями, изменениями конфигов, пиками нагрузки. Часто выявляет неочевидную связь типа «обновили библиотеку в 14:00 — проблема начала проявляться с 15:30».

Known Error Database (KEDB)

Known Error — это задокументированная проблема с известной корневой причиной и известным workaround'ом, которая пока не устранена полностью. Известные ошибки заносятся в специальную базу — KEDB.

Зачем это нужно:

• Операторы L1 быстро узнают повторяющиеся инциденты и применяют готовое решение
• Пользователи получают предсказуемый workaround, а не «расследуем, ждите»
• Менеджмент видит список неустранённых проблем и принимает решения о приоритизации

В большинстве ITSM-систем KEDB — это часть базы знаний с отдельной категорией. Не требует отдельной системы.

Приоритизация проблем

В отличие от инцидентов, приоритет проблемы определяется не срочностью, а бизнес-impact. Типовая матрица:

Метрики процесса

• Доля закрытых проблем с устранённой корневой причиной (не через workaround)
• Среднее время от создания проблемы до закрытия
• Количество повторных инцидентов по "решённым" проблемам — должно стремиться к нулю
• Проблемы в бэклоге по возрасту — сколько проблем старше 90 / 180 / 365 дней
• Reopen rate проблем — сколько проблем возвращались в работу после закрытия

Типовые ошибки

• Проблемы не заводятся вообще. Операторы закрывают инциденты, но никто не анализирует их повторяемость. Аварии возвращаются. Решение: еженедельный review инцидентов ответственным (Problem Manager или team lead).
• Проблема закрыта через workaround. "Мы научились жить с этой ошибкой" — не решение. Корневая причина остаётся. Решение: явное разделение статусов «с workaround» и «полностью устранена».
• Нет ответственного за проблему. Все "в курсе", но никто не двигает. Решение: обязательное поле Owner у каждой проблемы.
• Проблемы без приоритизации. Вся работа уходит на последнюю громкую. Старые критичные проблемы годами висят без движения. Решение: P1/P2 проблемы разбираются на еженедельном review, P3/P4 — на квартальном.
• Нет связи с RFC. Проблему «решают», не выполнив изменения. Через месяц возникает снова. Решение: проблема закрывается только после успешного внедрения связанного RFC.

Связь с Change Management

Большинство решений проблем реализуются через изменения. Типовая связка:

1. Инциденты → проблема (с привязкой инцидентов)
2. Расследование → workaround (в KEDB) → корневая причина
3. Создание RFC, связанного с проблемой
4. Одобрение CAB (см. Change Management)
5. Внедрение изменения
6. Валидация + закрытие проблемы

Когда начинать внедрять Problem Management

Problem Management — это не «первая» практика для внедрения. Логичный порядок:

1. Сначала: Service Desk + Incident Management + Service Request Management + SLA.
2. Когда процесс инцидентов стабилизирован (обычно через 3–6 месяцев) и накопилась история инцидентов — добавляйте Problem Management.
3. Одновременно или сразу после: Change Management (чтобы было куда заводить RFC для решения проблем).

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

Вывод

Problem Management — это инвестиция в будущее. Он не даёт быстрого ROI в метриках типа MTTR, но через 6–12 месяцев радикально снижает количество инцидентов в зрелых областях. Компании без Problem Management фиксят одни и те же проблемы годами, с ним — устраняют корни и переходят к новым вызовам.

Начните с простого: один Problem Manager (по совместительству — team lead L2), еженедельный review инцидентов, первые 5–10 проблем на 3 месяца. Остальное придёт с опытом.