NexTool Solutions

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

Прозрачность, которую GLPI уже даёт, — и где она заканчивается

GLPI поставляется с панелями (dashboards) на Главной и мощным поиском с фильтрами. Для повседневной работы этого хватает во многом: подсчёт по статусу, специалисту, категории. Ограничения проявляются в трёх местах:

• Это работает по запросу, а не проактивно. Панель обновляется только тогда, когда кто-то открывает экран. Никого не предупреждают, когда образуется узкое место, — нужно идти и смотреть самому.
• Считается то, что видит ваш профиль. Число на панели зависит от организации и профиля вошедшего пользователя. Координатор одной организации и глобальный администратор видят разные итоги для одной и той же очереди.
• Показывается агрегат, а не забытая заявка. «42 открытые заявки» не говорит, какая из них стоит без движения уже 20 дней.

Настоящая прозрачность начинается, когда вы перестаёте смотреть на итог и начинаете смотреть на форму очереди и на то, что вот-вот пойдёт не так.

Шаг 1: куда движется бэклог

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

-- Backlog aberto por grupo atribuído (type 2 = atribuído)
SELECT
  g.completename                    AS grupo,
  COUNT(*)                          AS abertos,
  SUM(t.status = 1)                 AS novos_sem_triagem,
  SUM(t.status = 4)                 AS pendentes
FROM glpi_tickets t
JOIN glpi_groups_tickets gt
     ON gt.tickets_id = t.id AND gt.type = 2
JOIN glpi_groups g ON g.id = gt.groups_id
WHERE t.status NOT IN (5, 6)
  AND t.is_deleted = 0
GROUP BY g.id
ORDER BY abertos DESC;

За секунды вы видите, какая группа перегружена и какая часть бэклога — новые заявки, которые никто не разобрал, — число, которое встроенная панель прячет за итогом.

Шаг 2: SLA, который истечёт, — до того как истечёт

Здесь и проходит граница между поддержкой, которая реагирует, и поддержкой, которая предвидит. Когда к заявке применяется SLA, GLPI записывает срок в собственные столбцы glpi_tickets: time_to_resolve (срок решения) и time_to_own (срок назначения). Это часы — можно смотреть, что истекает в ближайшие часы, а не только то, что уже истекло:

-- Chamados abertos com SLA de resolução vencendo nas próximas 4h
SELECT
  t.id,
  t.name,
  t.time_to_resolve,
  TIMESTAMPDIFF(MINUTE, NOW(), t.time_to_resolve) AS minutos_restantes
FROM glpi_tickets t
WHERE t.status NOT IN (4, 5, 6)        -- fora Pendente, Solucionado, Fechado
  AND t.is_deleted = 0
  AND t.time_to_resolve IS NOT NULL
  AND t.time_to_resolve > NOW()
  AND t.time_to_resolve <= NOW() + INTERVAL 4 HOUR
ORDER BY t.time_to_resolve ASC;

Практическая ловушка — в IS NOT NULL. Столбец time_to_resolve заполняется только тогда, когда при создании к заявке применилось правило SLA. Заявка, не попавшая ни под одно правило, остаётся со сроком NULL — и тихо исчезает с панели рисков. Иными словами: заявки без SLA, то есть именно те, которые никто не измеряет, невидимы для любого оповещения на основе сроков. Беря среду на сопровождение, первым делом мы считаем, сколько открытых заявок имеют time_to_resolve IS NULL. Мы видели клиента, у которого 60% бэклога были без какого-либо SLA: панель показывала «всё в срок», потому что у половины очереди просто не было срока.

Шаг 3: ответственный, которого нет

Ещё одно классическое слепое пятно: заявка назначена только группе, без конкретного специалиста. На экране она выглядит назначенной; на практике никто не чувствует себя ответственным. Такие заявки пропадают с личных панелей («мои заявки») и стареют незаметно. Назначение человеку хранится в glpi_tickets_users с type = 2:

-- Abertos atribuídos a grupo mas SEM técnico responsável nomeado
SELECT COUNT(*) AS sem_dono
FROM glpi_tickets t
WHERE t.status NOT IN (5, 6)
  AND t.is_deleted = 0
  AND NOT EXISTS (
    SELECT 1 FROM glpi_tickets_users tu
    WHERE tu.tickets_id = t.id AND tu.type = 2
  );

Уровни прозрачности: что для чего использовать

Единого инструмента не существует. Каждый уровень решает одну задачу и имеет свой предел. Вот как мы решаем, где разместить каждый показатель:

Шаг 4: превратить диагностику в автоматическое оповещение

Ручные запросы не масштабируются и, хуже того, зависят от того, вспомнит ли кто-то посмотреть. Есть два способа замкнуть этот цикл в GLPI:

1. Встроенными средствами, без дополнительной инфраструктуры: сохраните поиск «истекающий SLA» или «в ожидании более 7 дней» и создайте оповещение сохранённого поиска. Cron GLPI периодически выполняет поиск и отправляет e-mail, когда число превышает заданный вами порог.
2. Вне GLPI, для настенной панели и истории: запланируйте диагностический запрос в системном cron, читая учётные данные из файла .cnf (chmod 600), чтобы пароль никогда не оказывался в командной строке.

# /etc/cron.d/glpi-visibilidade  ->  toda hora útil, como www-data
# Lista chamados com SLA a estourar nas próximas 4h para a fila de plantão
0 8-18 * * 1-5 www-data /usr/bin/mysql --defaults-file=/etc/glpi/kpi-ro.cnf glpi \
  < /opt/glpi-kpi/sla-a-estourar.sql \
  > /var/log/glpi-kpi/sla-risco-$(date +\%Y-\%m-\%d-\%H).csv 2>&1

Перед планированием убедитесь, что cron самого GLPI действительно работает во внешнем режиме (системный cron вызывает front/cron.php), — иначе сроки SLA и встроенные оповещения даже не пересчитываются, и вы измеряете остановившиеся часы.

Перелом на практике сопровождения

Когда мы берём GLPI клиента на сопровождение, первый рентген — никогда не встроенная панель, а подсчёт заявок, назначенных только группе (без ответственного), и заявок с пустым time_to_resolve. В одном случае 40% бэклога было «назначено» группе из восьми человек, и никто не чувствовал себя ответственным; ни одна из этих заявок не появлялась на личной панели, а самой старой было 90 дней. Исправлением стала не новая панель, а бизнес-правило, требующее указывать конкретного специалиста при назначении, плюс оповещение за 4 часа до истечения SLA. Прозрачность появилась не от покупки инструмента, а от взгляда на правильные поля.

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

• Доверять итогу на панели: он агрегирует и прячет застрявшую заявку; смотрите распределение по группам и по возрасту.
• Считать, что у каждой заявки есть SLA: time_to_resolve NULL = вне любого оповещения по срокам. Сначала посчитайте заявки без SLA.
• Принимать «назначена группе» за «есть ответственный»: без записи в glpi_tickets_users с type = 2 никто не отвечает.
• Сравнивать организации по одному и тому же числу: встроенная панель уже фильтрует по профилю и организации; итог меняется в зависимости от того, кто вошёл.
• Забывать is_deleted = 0: корзина GLPI не исчезает из таблицы и искажает любой подсчёт.
• Измерять при остановленном cron: без работающего внешнего cron SLA и встроенные оповещения не обновляются.

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

Начните с трёх подсчётов из этого руководства (без ответственного, без SLA, истекающий SLA), выведите срезы на панель в Metabase или Grafana и свяжите KPI Service Desk с оповещениями. Так очередь перестаёт быть числом в конце месяца и становится сигналом, который срабатывает, пока ещё можно действовать.

В NexTool такой рентген прозрачности — первый результат, который мы передаём, когда берём GLPI на сопровождение: находим слепые пятна, включаем оповещения и сдаём панель. Если вы хотите такого сопровождения для своей среды, познакомьтесь с нашей услугой поддержки и сопровождения.

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