Управление проблемами ITIL — это практика, которая находит причины инцидентов, снижает их влияние на пользователей и не дает сбоям повторяться. В ITIL (IT Infrastructure Library — библиотека рекомендаций по управлению ИТ-услугами) ее называют Problem Management. Практика связывает похожие инциденты с общей проблемой, выясняет корневую причину, фиксирует известную ошибку и обходное решение и передает постоянное исправление в управление изменениями.
Ниже — отличие проблемы от инцидента, жизненный цикл, анализ причин, база известных ошибок, роли, метрики и автоматизация.
Что такое управление проблемами в ITIL
Управление проблемами в ITIL — практика, цель которой снизить вероятность и влияние инцидентов. Для этого команда выявляет фактические и потенциальные причины сбоев, ведет обходные решения и известные ошибки. Проблемой ITIL 4 называет причину или потенциальную причину одного или нескольких инцидентов. Результат работы практики — устраненная причина, а если исправление пока невозможно, задокументированная известная ошибка с обходным решением.
В ITIL 4 практика делится на три фазы: выявление проблем, контроль проблем и контроль ошибок. Устройство фреймворка разобрано в статье про ITIL.
Инцидент, проблема и известная ошибка
Проблема отличается от инцидента тем, что описывает причину сбоя. Инцидент — сам сбой и его последствия для пользователя; его закрывают после восстановления сервиса, даже если причина осталась. Проблему закрывают после устранения причины или после решения принять риск. Известная ошибка — проблема, причина которой установлена, но постоянное исправление еще не внедрено.
Пример: после обновления VPN-клиента у сотрудников обрывается связь. Service Desk закрывает обращения как инциденты, переподключая пользователей. Серия таких инцидентов — повод завести проблему, найденная причина с обходом — известная ошибка.
Таблица сводит три понятия по одинаковым критериям.
| Понятие | Цель работы | Триггер | Результат | Ответственный |
|---|---|---|---|---|
| Инцидент | Быстро восстановить сервис | Сбой или ухудшение качества услуги | Пользователь продолжает работу | Service Desk, группы поддержки |
| Проблема | Найти и устранить причину | Повторы, крупный инцидент, тренд | Причина устранена или риск принят | Менеджер проблем, эксперты |
| Известная ошибка | Снизить влияние до исправления | Причина установлена, исправления нет | Запись с причиной и обходом | Менеджер проблем, владелец сервиса |
Записи образуют цепочку: инциденты указывают на проблему, проблема становится известной ошибкой, ошибка закрывается изменением. Без этих связей каждый повтор сбоя расследуют с нуля.
Реактивный и проактивный подход
Реактивное управление отвечает на случившиеся инциденты, проактивное ищет причины до того, как пользователи заметят сбой.
Реактивное управление проблемами
Расследование запускается по факту: крупный инцидент остановил сервис или похожие обращения повторяются. Подход быстро дает результат, но команда разбирает уже наступившие последствия.
Проактивное управление проблемами
Команда ищет потенциальные причины по мониторингу, трендам инцидентов и уведомлениям поставщиков. Жалоб по такой проблеме еще нет, поэтому приоритет обосновывают риском: вероятностью сбоя и его влиянием.
Типовые условия запуска расследования:
- крупный инцидент с остановкой критичного сервиса;
- повтор инцидентов с одинаковыми симптомами на одной конфигурационной единице (КЕ, учетном элементе инфраструктуры);
- инцидент, причину которого не удалось установить при восстановлении;
- уведомление поставщика о дефекте или уязвимости.
Пороги повторения и список критичных сервисов фиксируют в регламенте: ITIL числовых значений для них не задает.
Жизненный цикл проблемы
Проблема проходит восемь этапов: выявление, регистрация, категоризация, приоритизация, расследование, решение, закрытие и контроль. В ITIL 4 они группируются в три фазы: на первой проблемы находят и регистрируют, на второй ищут причину и обходное решение, на третьей ведут известные ошибки до исправления. Контроль после закрытия подтверждает, что инциденты перестали повторяться.
Таблица показывает вход, решение и артефакт каждого этапа. Статусы условные, их названия задает система.
| Этап | Вход | Действие | Решение | Статус | Артефакт |
|---|---|---|---|---|---|
| Выявление | Инциденты, тренды, мониторинг | Сгруппировать похожие случаи | Заводить ли проблему | Кандидат | Список связанных инцидентов |
| Регистрация | Решение завести проблему | Создать карточку | Кто владелец | Новая | Карточка проблемы |
| Категоризация | Карточка проблемы | Указать сервис, КЕ, категорию | Какая группа расследует | Новая | Категория и сервис |
| Приоритизация | Влияние и вероятность | Оценить риск для бизнеса | Срок и очередность | В очереди | Приоритет |
| Расследование | Инциденты, логи, изменения | Провести RCA, найти обходной путь | Причина подтверждена | Известная ошибка | Отчет RCA, запись KEDB |
| Решение | Известная ошибка | Подготовить исправление | Изменение или принятие риска | Ожидает изменения | Запрос на изменение |
| Закрытие | Внедренное изменение | Проверить результат | Можно ли закрыть | Закрыта | Итоговая запись |
| Контроль | Данные после закрытия | Следить за повторами | Переоткрыть или подтвердить | Закрыта | Отчет о повторах |
Цикл чаще всего рвется в двух местах: у проблемы нет владельца или ее закрывают без проверки повторов. Поэтому в регламенте закрепляют владельца при регистрации и срок наблюдения после изменения.
Анализ корневых причин RCA
Анализ корневых причин (RCA, Root Cause Analysis) проводят после стабилизации сервиса. Команда собирает данные инцидентов, логи и историю изменений, выбирает метод и проверяет гипотезы, пока не найдет причину, устранение которой предотвращает повтор. Метод выбирают по характеру сбоя: одна цепочка событий, много факторов или недавний релиз.
Методы дополняют друг друга, в одном расследовании их нередко комбинируют.
| Метод | Когда использовать | Данные | Сильная сторона | Ограничение |
|---|---|---|---|---|
| 5 Why (пять почему) | Одна цепочка событий | Описание сбоя, опрос | Быстро, без инструментов | Сводит причину к одной линии |
| Диаграмма Исикавы | Много возможных факторов | Факторы по группам | Показывает все группы причин | Каждую ветку нужно проверить данными |
| Анализ изменений | Сбой начался после релиза или настройки | Журнал изменений | Быстро находит связь со сбоем | Бесполезен, если изменений не было |
| Хронология событий | Сбой в нескольких системах | Логи, мониторинг | Восстанавливает последовательность | Трудоемкий сбор данных |
Итог RCA оформляют записью: причина, доказательства, обходное решение, предложение по исправлению. Без нее вывод остается в памяти участников и не попадает в KEDB.
Обходное решение и KEDB
База известных ошибок (KEDB, Known Error Database) нужна, чтобы Service Desk и группы поддержки быстро находили причину и обходное решение для уже изученного сбоя. Обходное решение снижает или устраняет влияние инцидента, пока постоянного исправления нет. Запись в KEDB избавляет от повторной диагностики: оператор сопоставляет симптомы, применяет обходной путь и связывает инцидент с проблемой.
В записи известной ошибки обычно хранят:
- Симптомы — как сбой выглядит для пользователя и в мониторинге.
- Затронутые сервисы и КЕ — где проявляется ошибка.
- Корневую причину — вывод RCA со ссылкой на проблему.
- Обходное решение — шаги для оператора и ограничения.
- Статус исправления — запрос на изменение и плановый срок.
- Связанные инциденты — масштаб и частоту проявлений.
Оператор Service Desk ищет запись по симптомам при регистрации обращения. Найдя совпадение, он применяет обходное решение и привязывает инцидент к проблеме. Общая база знаний с инструкциями и регламентами живет отдельно и может ссылаться на записи KEDB.
Роли и ответственность
Роли не обязательно совпадают с должностями: в небольшой ИТ-службе их совмещают, в крупной распределяют между подразделениями.
Менеджер проблем
Problem Manager отвечает за практику целиком: у каждой проблемы должны быть владелец, приоритет и срок. Он проводит разборы и отчитывается по метрикам.
Технические команды
Администраторы, разработчики и инженеры ведут диагностику и RCA в своей зоне. Они предлагают обходное решение и готовят исправление.
Service Desk
Первая линия замечает повторы и применяет обходные решения из KEDB. От качества регистрации обращений зависит, увидит ли практика тренд вовремя.
Менеджер изменений
Менеджер изменений оценивает риск исправления, согласует и планирует внедрение. Проблему закрывают после того, как изменение внедрено и результат подтвержден.
Владельцы сервисов
Владельцы оценивают влияние проблемы на бизнес и участвуют в приоритизации. Они же решают оставить ошибку, если исправление дороже последствий.
Метрики управления проблемами
Метрики показывают, устраняет ли практика причины или только копит записи. Целевые значения компания задает сама.
- Доля повторных инцидентов — сколько инцидентов связано с уже известными проблемами.
- Время диагностики — от регистрации проблемы до подтвержденной причины.
- Доля проблем с RCA — сколько закрытых проблем имеют задокументированную причину.
- Число и возраст известных ошибок — сколько записей KEDB ждут исправления и как долго.
- Эффект обходных решений — сколько инцидентов закрыто по обходному пути из KEDB.
- Проблемы, закрытые изменением — доля с внедренным исправлением.
Метрики читают в связке: если известных ошибок больше, а закрытий изменением меньше, узкое место — этап изменений.
Связь с другими практиками ITIL
Управление проблемами получает данные от соседних практик и возвращает им результат.
Управление инцидентами
Инциденты служат главным источником проблем, KEDB возвращает первой линии обходные решения. Связь ведут в обе стороны: инцидент ссылается на проблему, проблема — на свои инциденты.
Управление изменениями
Постоянное исправление известной ошибки проходит через эту практику как запрос на изменение с оценкой риска. Неудачные изменения, в свою очередь, часто порождают новые проблемы.
Управление знаниями
Выводы RCA и обходные решения превращаются в статьи для операторов и пользователей. KEDB при этом остается отдельным хранилищем.
Управление уровнем услуг
Нарушения SLA (соглашения об уровне сервиса) показывают, какие проблемы бьют по обязательствам перед бизнесом. Приоритет проблемы учитывает, какие соглашения под угрозой.
Постоянное улучшение
Тренды проблем выявляют системные слабые места: устаревшую платформу или нехватку тестирования. Выводы попадают в реестр улучшений.
Автоматизация Problem Management
Практика опирается на данные инцидентов и изменений, поэтому ее ведут в одной системе с остальными процессами ITSM (IT Service Management, управление ИТ-услугами). В системе нужны:
- Карточка проблемы с сервисом, приоритетом и владельцем.
- Связи с инцидентами, изменениями и КЕ.
- Маршруты назначения и эскалации по категории и приоритету.
- Хранилище известных ошибок с обходными решениями.
- Аналитика и контроль сроков по повторам, ошибкам и сервисам.
Как это устроено в BPMSoft
В BPMSoft Управление ИТ-услугами проблемы ведутся в отдельном разделе. Проблему регистрируют на основании инцидента: карточка заполняется данными обращения. Решение фиксируется в карточке — временное или через изменение, и проблема связывается с инцидентами и изменениями.
Система определяет тип заявки, приоритет и ответственную группу и запускает эскалацию при приближении к сроку. Выводы расследований пополняют базу знаний, дашборды раздела показывают, например, наиболее проблемные сервисы.
Решение включает более 20 процессов управления с учетом ITIL 4. Маршруты и поля настраиваются под регламент средствами low-code — визуальной настройки с минимумом программирования.