Повторяющиеся инциденты — симптом проблемы, которую ещё никто не зарегистрировал. В GLPI заметить, что десять заявок по Wi-Fi пришли из одного филиала за две недели или что одно и то же оборудование вернулось в очередь в четвёртый раз, можно только если кто-то смотрит нужный отчёт в нужный момент. Модуль Problem Flow делает этот анализ сам и автоматически создаёт проблему ITIL, когда паттерн подтверждается.
Проблема: мост между инцидентом и проблемой строится вручную
Кто работает по ITIL, знает, что проблемы — это первопричина повторяющихся инцидентов. В GLPI есть тип объекта «Проблема» и возможность связывать с ней инциденты, но обнаружение повторяемости он не выполняет: эта часть остаётся за человеком. Кто-то должен заметить, что у нескольких заявок одна категория, одно местоположение или одно оборудование в одном временном окне, и только тогда создать проблему и связать инциденты.
У этого пробела есть цена. Промежуток между появлением паттерна и регистрацией проблемы заполняется новыми инцидентами, повторной работой и дополнительной нагрузкой на очередь. В операциях с большим объёмом паттерн обычно остаётся незамеченным, пока ущерб уже не станет большим, и тогда вопрос руководителя всегда один: «почему никто не заметил этого раньше?».
Как работает Problem Flow
Модуль анализирует уже решённые и закрытые заявки и обнаруживает повторяющиеся инциденты по правилам в стиле GLPI: категория, местоположение, связанный объект, тип решения, приоритет, источник, группы, инициатор и текст заголовка, описания или решения. Когда в периоде набирается минимальное число заявок по правилу, в GLPI открывается проблема ITIL, к которой уже привязаны породившие её заявки.
- Двойной триггер — анализ запускается каждый раз, когда заявка решена или закрыта, а также автоматической задачей GLPI, по умолчанию каждые 6 часов, что обеспечивает покрытие даже при пиках нагрузки.
- Правила в стиле GLPI — каждое правило задаёт критерии с теми же операторами, что и встроенные правила (включая «под» для подкатегорий и вложенных местоположений), минимальное число заявок за период, способ группировки (объект, местоположение, категория, группа специалистов, инициатор или отдел), минимальное число различных инициаторов, минимальный интервал между проблемами и то, как создаётся проблема (заголовок, шаблон, категория, срочность, влияние, группа специалистов, специалист, группа наблюдателей). Несколько правил могут сосуществовать, покрывая разные сценарии.
- Одна проблема на общую причину — при группировке по местоположению и минимуме 5 пять инцидентов по Wi-Fi в филиале Центр и пять в филиале Север создают две проблемы, по одной на филиал. Минимум различных инициаторов не даёт одному человеку поднять тревогу, а минимальный интервал предотвращает повторные проблемы.
- 27 готовых шаблонов, неактивных — оборудование с повторяющимися сбоями; Wi-Fi, печать, электропитание и телефония в одном местоположении; почта, VPN, вход в систему, резервное копирование, безопасность и цифровой сертификат; одна и та же категория; повторяющиеся обходные решения; и каждый критический инцидент. Они поставляются выключенными: вы включаете только то, что имеет смысл в вашей среде.
- Повторяющиеся обходные решения — один из шаблонов читает текст решения заявок: когда одно и то же обходное решение повторяется, оно становится проблемой, «кандидатом в известную ошибку» по ITIL.
- Кнопка «Тест» — моделирует правило на заявках периода, ничего не создавая: показывает каждую группу, сколько заявок и инициаторов в ней набралось относительно минимума и предпросмотр проблемы, которая была бы открыта.
- Охват в соответствии с ITIL — 27 готовых шаблонов учитывают только инциденты, как рекомендует ITIL; в вашем собственном правиле тип заявки — это критерий, который выбираете вы.
- Полная прослеживаемость — вкладка «Логи» фиксирует для каждого обнаружения правило, созданную проблему, группу и породившие её заявки.
Паттерн, который автоматизирует модуль
Чтобы понять, что делает Problem Flow, полезно посмотреть на обнаружение вручную. Запрос ниже выводит по категориям и организациям инциденты, решённые или закрытые за последние 30 дней, и выделяет группы с пятью и более случаями — именно кандидатов в проблемы. Запускайте его на реплике для чтения или в период низкой нагрузки:
-- Deteccao MANUAL do padrao que o Problem Flow automatiza:
-- incidentes resolvidos/fechados nos ultimos 30 dias, agrupados por categoria e entidade.
-- Grupos com 5+ ocorrencias sao candidatos a virar um Problema ITIL.
SELECT c.completename AS categoria,
e.completename AS entidade,
COUNT(*) AS ocorrencias
FROM glpi_tickets t
JOIN glpi_itilcategories c ON c.id = t.itilcategories_id
JOIN glpi_entities e ON e.id = t.entities_id
WHERE t.type = 1 -- 1 = Incidente
AND t.status IN (5, 6) -- 5 = Solucionado, 6 = Fechado
AND t.is_deleted = 0
AND t.solvedate >= NOW() - INTERVAL 30 DAY
GROUP BY t.itilcategories_id, t.entities_id
HAVING COUNT(*) >= 5
ORDER BY ocorrencias DESC;Модуль выполняет эту работу сам, при каждом анализе и для каждого правила, причём не только по категории и организации: подходит любое сочетание критериев (местоположение, связанный объект, инициатор, текст решения и остальные), с подсчётом, разделённым по выбранной вами группировке, и без зависимости от того, вспомнит ли кто-то запустить отчёт.
Возможности модуля и встроенное поведение
| Этап управления проблемами | Встроенный GLPI | С Problem Flow |
|---|---|---|
| Обнаружение повторяемости | Вручную: кто-то должен смотреть отчёты и дашборды | Автоматически по правилу, с любым сочетанием критериев, при решении или закрытии заявки и автоматической задачей |
| Калибровка перед автоматизацией | Не существует: результат виден только постфактум | Кнопка «Тест» моделирует правило на заявках периода, ничего не создавая |
| Открытие проблемы ITIL | Вручную: специалист создаёт её и связывает инциденты | Открывается при достижении минимума, с привязанными заявками и полями, заданными действиями правила |
| Охват анализа | Любой тип заявки, без критерия | Тип заявки — критерий правила; 27 готовых шаблонов учитывают только инциденты |
| Предотвращение повторных проблем | Зависит от того, поищет ли кто-то перед созданием | Минимальный интервал между проблемами и игнорирование уже привязанных заявок |
| Прослеживаемость решения | Зависит от ручных заметок | Вкладка «Логи» с правилом, группой, заявками и созданной проблемой |
| Подтверждение зрелости ITSM | Трудно доказать | Зафиксированный след того, что процесс работает |
Как включить
- Установив плагин NexTool в GLPI 11, откройте NexTool > Модули и включите Problem Flow.
- На вкладке Правила выберите один из 27 готовых шаблонов (они поставляются неактивными) или создайте своё правило.
- Нажмите Тест: моделирование выполняется на заявках периода и ничего не создаёт.
- Когда результат откалиброван, включите правило.
- Следите за вкладкой Логи, чтобы видеть, какое правило открыло каждую проблему, для какой группы и с какими заявками.
Что мы узнали в ходе сопровождения
При сопровождении ITIL-операций успех Problem Flow зависит от калибровки минимума заявок, а не от технологии. Слишком низкий минимум — и модуль создаёт по проблеме на категорию в неделю, превращаясь в шум, которым никто не занимается; слишком высокий — и он никогда не срабатывает, и вы возвращаетесь к ручному обнаружению. Мы стандартизировали подход: начинать консервативно и перед включением проходить через кнопку «Тест». Моделирование показывает на ваших собственных заявках каждую группу, которую сформировало бы правило, сколько заявок и инициаторов набралось относительно минимума и предпросмотр проблемы. Настройка делается там же, ничего не создавая, вместо того чтобы неделями ждать логов. Две детали, которые видны только в эксплуатации: во-первых, подсчёт ещё открытых заявок завышает число, потому что один и тот же повторно открытый инцидент появляется несколько раз, — поэтому правильно анализировать решённые и закрытые. Во-вторых, самой частой ошибкой на практике было направить правило на родительскую категорию в расчёте на то, что дочерние суммируются, и увидеть, что инциденты, разбросанные по соседним подкатегориям, не группируются. В текущих правилах это решается оператором: используйте «под», чтобы включить подкатегории; с «равно» учитывается только выбранная категория. То же самое касается местоположения.
Кому подходит (и когда не использовать)
Problem Flow подходит операциям, которые официально работают по ITIL и хотят закрыть разрыв между управлением инцидентами и управлением проблемами, в особенности:
- Средам с большим объёмом, где ручное обнаружение паттернов непрактично;
- Операциям с несколькими организациями, филиалами или распределёнными командами;
- Руководителям, которым для аудита нужно прослеживаемое подтверждение зрелости ITSM.
Он не имеет смысла в операциях, которые ещё не практикуют управление проблемами или имеют очень малый объём: минимум будет достигаться редко, и модуль будет простаивать. А при плохой калибровке он порождает избыток проблем, с которыми команда не справляется, — побочный эффект в виде очереди заброшенных проблем хуже, чем отсутствие автоматизации. Сначала калибровка (для этого и существует кнопка «Тест»), потом доверие.
Совместимость
- GLPI: 11
- План: лицензируемый модуль
- Плагин: NexTool 6.24.1 или выше (текущая публичная версия подходит)
Problem Flow входит в состав NexTool — модульного плагина для GLPI. Чтобы внедрить управление проблемами ITIL с автоматическим и прослеживаемым обнаружением, свяжитесь с командой.
Проверено командой NexTool Solutions.
