NexTool Solutions

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

Инцидент и проблема: разница в данных, а не только в словах

Классическая путаница в ITSM — считать, что «инцидент превращается в проблему». В GLPI они даже не делят одну таблицу: инцидент живёт в glpi_tickets, проблема — в glpi_problems, и у каждого своя машина состояний. Это разные объекты с противоположными целями:

• Инцидент: восстановить сервис как можно быстрее. Это лечение симптома, и у него есть SLA на решение.
• Проблема: найти и устранить первопричину, чтобы инцидент не повторился. Это профилактика, и у неё другой ритм.

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

Раздел Анализ: где на самом деле хранится первопричина

Форму проблемы от обычной заявки отличает раздел Анализ, который записывает данные в три отдельных текстовых столбца glpi_problems (доступны в параметрах поиска 60, 61 и 62):

• impactcontent — Влияние: на что влияет проблема, пока она не решена.
• causecontent — Причины: здесь хранится первопричина. Это самое важное поле всего процесса.
• symptomcontent — Симптомы: как проблема проявляется для тех, кто создаёт инциденты.

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

Инцидент, проблема или изменение: матрица решений

Прежде чем создавать любую запись, команда должна понимать, что именно она создаёт. Вот матрица, которую мы используем при сортировке:

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

Связывание инцидентов: вкладка Заявки и тип связи

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

Жизненный цикл и ловушка преждевременного «Решено»

У проблемы своя машина состояний в столбце status таблицы glpi_problems, и она не совпадает с машиной состояний изменения. Статусы, которые проблема реально использует:

1. Новая (1) — зарегистрирована, расследование ещё не начато.
2. Принята (7) — отсортирована и взята командой в работу.
3. В работе / назначена (2) и запланирована (3) — расследование идёт.
4. В ожидании (4) — ожидание третьей стороны, поставщика или окна.
5. Под наблюдением (8) — обходное решение применено, идёт мониторинг, действительно ли причина устранена.
6. Решена (5) и Закрыта (6) — причина устранена, цикл завершён.

Вот самая дорогостоящая типичная ошибка: применить обходное решение и в тот же день отметить проблему как Решённую. «Решена» означает «первопричины больше нет», а обходное решение не устраняет никакой причины — оно только скрывает симптом. В сопровождении мы стали использовать статус Под наблюдением (8) именно для этого: обходное решение работает, проблема остаётся живой на панели, и в «Решена» мы переводим её только после того, как внедрено окончательное исправление и прошёл период без повторений. Закрыть слишком рано — всё равно что объявить победу, когда за стеной ещё тлеет пожар.

Обходное решение, окончательное решение и мост к изменению

У проблемы два исхода, которые нельзя путать:

• Обходное решение (workaround): восстанавливает сервис, не затрагивая причину. Документируйте его в хронологии или как задачу проблемы (glpi_problemtasks) для немедленного использования первой линией.
• Окончательное решение: устраняет первопричину. Регистрируется на вкладке Решение и записывается в glpi_itilsolutions (с itemtype = 'Problem'), а для внедрения часто требует изменения.

Когда исправление затрагивает инфраструктуру, создавайте изменение прямо из проблемы: связь записывается в glpi_changes_problems и сохраняет прослеживаемость «первопричина — корректирующее действие». Именно эта связь позволяет потом доказать, что проблема действительно решена, а не просто закрыта.

Шаблон уведомления о закрытии проблемы

В Настройка > Уведомления шаблон события проблемы использует теги GLPI. Текст уведомления о закрытии, который вынуждает фиксировать первопричину, сокращает число проблем, закрытых без извлечённого урока:

Subject: [Problem ##problem.id##] Closed - ##problem.title##

Hello,

The problem below has been closed.

Title:       ##problem.title##
Category:    ##problem.category##
Status:      ##problem.status##
Incidents:   ##problem.numberoftickets##

Symptoms:
##problem.symptoms##

Root cause:
##problem.causes##

Details: ##problem.url##

Теги ##problem.causes## и ##problem.symptoms## берут данные напрямую из causecontent и symptomcontent. Если уведомление о закрытии приходит с пустыми блоками, это явный признак того, что проблему закрыли без задокументированной первопричины, — и само письмо становится аудитором процесса.

Диагностика: проблемы с избытком инцидентов и недостатком причин

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

SELECT p.id,
       p.name AS problem,
       p.status,
       COUNT(pt.tickets_id) AS incidents,
       IF(p.causecontent = '' OR p.causecontent IS NULL,
          'NO ROOT CAUSE', 'ok') AS cause
FROM glpi_problems p
LEFT JOIN glpi_problems_tickets pt ON pt.problems_id = p.id
WHERE p.is_deleted = 0
  AND p.status NOT IN (5, 6)          -- exclude Solved and Closed
GROUP BY p.id
HAVING cause = 'NO ROOT CAUSE'
    OR incidents >= 3
ORDER BY incidents DESC;

Каждая строка с NO ROOT CAUSE и несколькими инцидентами — это проблема, которая поглощает усилия на обходные решения, не продвигаясь к решению. Превращение этого запроса в еженедельную панель меняет разговор на операционном совещании: вместо «сколько заявок мы закрыли» он становится «какие причины мы устранили».

Рекомендации по сопровождению

• Не ждите десятков инцидентов: 3 случая с одинаковым симптомом уже оправдывают проблему.
• Заполняйте causecontent до закрытия, даже если причина кажется очевидной; именно это становится базой знаний.
• Используйте Под наблюдением, пока работает обходное решение; отмечайте «Решена», только когда причина устранена.
• Стандартизируйте тип связи инцидентов, чтобы подсчёт повторяемости что-то значил.
• Связывайте проблему с изменением (glpi_changes_problems) всякий раз, когда исправление затрагивает инфраструктуру.
• Пересматривайте открытые проблемы еженедельно; забытая проблема — гарантированный инцидент в будущем.

Если операции нужно, чтобы повторяющиеся проблемы обнаруживались сами, а не зависели от того, заметит ли кто-то закономерность, модуль Problem Flow выявляет повторяющиеся инциденты по категории и частоте и создаёт проблему уже со связанными заявками. Сопровождение NexTool настраивает этот процесс в том GLPI, которым вы уже пользуетесь, — от триггера обнаружения до панели устранённых причин.

Проверено командой NexTool Solutions.