NexTool Solutions

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

Где в GLPI хранится инцидент

Инцидент и запрос — не отдельные модули: это один и тот же объект Ticket в таблице glpi_tickets, различающийся по столбцу type — 1 для инцидента, 2 для запроса. Различаются процесс, SLA и управленческая интерпретация. Согласно ITIL 4, инцидент — это незапланированное прерывание или снижение качества сервиса, и цель — восстановить сервис как можно быстрее, а не выяснить причину: этим занимается управление проблемами.

Каждый инцидент проходит фиксированную машину состояний. Знать код каждого статуса важно, потому что отчёты, бизнес-правила и диагностический SQL работают с числом, а не с названием:

Деталь, которая портит отчёты: статус В ожидании (4) приостанавливает отсчёт SLA, если вы так настроили. Специалист, который переводит всё в В ожидании, чтобы «не нарушить срок», маскирует показатель, а не улучшает обслуживание.

Классификация: матрица Срочность × Влияние

GLPI не позволяет специалисту выбирать приоритет произвольно. Он вычисляется на пересечении двух полей, которые указывают инициатор и сотрудник, проводящий сортировку: срочность (насколько быстро это нужно бизнесу) и влияние (сколько затронуто и насколько это критично). Матрица находится в Настройка > Общие > Поддержка и полностью редактируется. Упрощённый фрагмент логики:

GLPI поддерживает до пяти уровней срочности и влияния, а также приоритет Major (критический). Матрица по умолчанию симметрична — срочность и влияние имеют одинаковый вес. Подстройте веса под реальность клиента: в рознице неработающая касса в час пик — максимальная срочность независимо от числа затронутых магазинов.

Процесс обработки шаг за шагом

1. Регистрация: портал самообслуживания, e-mail (сборщик почты), телефон или интеграция. Бизнес-правила (RuleTicket) автоматически задают категорию, группу и приоритет при item_add.
2. Take into account (первый ответ): GLPI записывает в takeintoaccount_delay_stat время до первого действия специалиста. Это ваш SLA на принятие в работу (TTO — time to own), отличный от SLA на решение (TTR — time to resolve).
3. Расследование: база знаний, история похожих заявок и CMDB. Модуль AI Assist кратко излагает длинные переписки и предлагает решения на основе базы.
4. Решение: окончательное (причина исправлена) или обходное (workaround). Если обходное решение повторяется, свяжите его с Проблемой — инцидент не «превращается» в проблему, это разные объекты.
5. Закрытие: после подтверждения заявка переходит в Закрыта и запускает опрос удовлетворённости.

Ловушка № 1 в сопровождении: cron не в том режиме

С этой неисправностью мы чаще всего сталкиваемся в среде нового клиента. SLA настроен, уровни эскалации созданы, и всё равно никто не получает оповещения при нарушении срока, а решённые заявки никогда не закрываются сами. Причина почти всегда одна: автоматические действия GLPI работают в режиме GLPI (веб), который выполняется, только когда кто-то загружает страницу. У клиента с небольшим трафиком вне рабочего времени эскалация по SLA просто не запускается.

Исправление — перевести планировщик в режим CLI, запускаемый cron операционной системы. В каждом автоматическом действии (Настройка > Автоматические действия) задайте Режим выполнения = CLI и добавьте запись в crontab:

# /etc/cron.d/glpi - runs the GLPI scheduler every minute
# GLPI 10 and 11: front/cron.php is the version-portable path
* * * * * www-data /usr/bin/php /var/www/glpi/front/cron.php >/dev/null 2>&1

От этого cron зависят: closeticket (автоматически закрывает то, что осталось в статусе Решена дольше срока), createinquest (создаёт опрос удовлетворённости) и эскалация по уровням SLA. Деталь переносимости, на которой спотыкаются многие: в GLPI 11 нет консольной команды glpi:cron, которую упоминают некоторые руководства по GLPI 10, — путь, который работает в обеих версиях, это front/cron.php выше.

Диагностика: поиск инцидентов с нарушенным SLA

Когда клиент говорит «SLA не сходится», первый шаг — посмотреть на сырые данные, а не на дашборд. Этот SQL выводит открытые инциденты, срок решения которых уже прошёл, и отмечает те, которые даже не были приняты в работу (takeintoaccount_delay_stat = 0):

SELECT t.id,
       t.name AS title,
       c.completename AS category,
       t.priority,
       t.time_to_resolve,
       IF(t.takeintoaccount_delay_stat = 0,
          'NO FIRST RESPONSE', 'ok') AS handling
FROM glpi_tickets t
LEFT JOIN glpi_itilcategories c ON c.id = t.itilcategories_id
WHERE t.is_deleted = 0
  AND t.type = 1                       -- 1 = incident
  AND t.status NOT IN (5, 6)           -- excludes Solved and Closed
  AND t.time_to_resolve IS NOT NULL
  AND t.time_to_resolve < NOW()        -- resolution deadline already breached
  AND t.solvedate IS NULL
ORDER BY t.time_to_resolve ASC;

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

Уведомление об эскалации, которое руководитель прочитает

Стандартный шаблон эскалации отправляет общий блок текста. Лаконичный шаблон с правильными тегами позволяет руководителю действовать, не открывая GLPI. Теги ##ticket.*## подставляются GLPI при отправке:

Subject: [SLA breached] Ticket ##ticket.id## - ##ticket.title##

The ticket below has passed its resolution deadline.

Title:       ##ticket.title##
Category:    ##ticket.category##
Priority:    ##ticket.priority##
Status:      ##ticket.status##
Assigned to: ##ticket.assigntousers##
Deadline (TTR): ##ticket.time_to_resolve##

Open the ticket: ##ticket.url##

Типичные ошибки на практике

• «Всё срочно»: когда каждая заявка поступает с высоким приоритетом, у вас нет приоритизации — есть дорогая хронологическая очередь. Зафиксируйте срочность в управляемой форме и обучайте по матрице.
• Приоритет, изменённый вручную: специалист, который перезаписывает вычисленный приоритет, ломает интерпретацию SLA и матрицу. Если переклассифицировать приходится постоянно, дефект в матрице, а не в специалисте.
• Путаница TTO и TTR: «открыл заявку, чтобы прочитать» уже считается take into account и выполняет SLA первого ответа, хотя никто ничего не решил. Контролируйте TTR (решение), а не только TTO.
• Обходное решение, ставшее окончательным: workaround применён, заявка закрыта, Проблема не открыта — инцидент возвращается на следующей неделе. Связывайте повторяющиеся обходные решения с Проблемой.

Следующий шаг

Когда управление инцидентами отлажено, переходите к управлению проблемами (устранению первопричины) и управлению изменениями. Для ускорения сортировки модуль Smart Assign распределяет инциденты между специалистами по правилам нагрузки и компетенций, а руководство по SLA и OLA описывает настройку сроков.

Нужен GLPI, который действительно соблюдает SLA? NexTool сопровождает среды GLPI от начала до конца — от матрицы приоритетов до cron эскалации. Узнайте об услуге поддержки и сопровождения.

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