NexTool Solutions

Настроить SLA и OLA в GLPI — простая часть; в реальной работе ломается эскалация, которая никогда не срабатывает. При сопровождении клиентских сред GLPI чаще всего просят не «как создать SLA», а «я всё настроил, но никого не оповещают, когда срок нарушен». Это руководство настраивает SLA и OLA в GLPI 11 с нуля и показывает SQL-запросы, которые мы используем, чтобы диагностировать, почему сроки не вызывают уведомлений.

SLA и OLA: в чём разница на практике

SLA (Service Level Agreement) — это соглашение с клиентом (внутренним или внешним): оно определяет обязательства по времени реакции и решения. Пример: «на заявки с высоким приоритетом реагируют за 1 ч и решают за 4 ч».

OLA (Operational Level Agreement) — это внутреннее соглашение между командами, которые обеспечивают этот SLA. Пример: «инфраструктура отвечает на эскалации от L1 в течение 30 минут». В GLPI SLA записывает сроки в поля time_to_own и time_to_resolve заявки; OLA — в internal_time_to_own и internal_time_to_resolve. Оба идут параллельно — и здесь кроется первая путаница: эскалация на L2 НЕ приостанавливает SLA клиента.

Как GLPI моделирует SLA и OLA изнутри

Понимание модели данных помогает избежать большинства ошибок настройки. В GLPI SLA и OLA — не самостоятельные объекты: они живут внутри SLM (Service Level), и именно SLM несёт календарь.

• SLM (glpi_slms): общий контейнер. В нём есть calendars_id — то есть календарь принадлежит SLM, а не каждому SLA.
• SLA (glpi_slas) и OLA (glpi_olas): каждая строка — это срок с type (TTO или TTR), number_time и definition_time (minute / hour / day).
• Уровни эскалации (glpi_slalevels / glpi_olalevels): действия, запускаемые при X% срока.

Два понятия, которые обычно путают те, кто пришёл из другого инструмента:

TTO — Time to Own (время реакции)

Срок до того, как заявка будет «принята в работу» (взята специалистом). Внимание: TTO не закрывается, когда кто-то просто открывает заявку на экране; он закрывается при первом назначении или первом комментарии — именно это GLPI записывает в takeintoaccount_delay_stat.

TTR — Time to Resolve (время решения)

Срок до решения заявки.

Пошагово: настройка SLA в GLPI 11

1. Сначала календарь. До SLA определите календарь обслуживания (Настройки > Календари) с реальными рабочими интервалами (например, пн–пт, 08:00–18:00). Если у SLM нет календаря (calendars_id = 0), GLPI считает время круглосуточно; с календарём — только рабочие часы.
2. Создайте SLM и привяжите календарь. Это контейнер, объединяющий SLA и OLA услуги.
3. Создайте SLA для каждого приоритета: один для TTO и один для TTR. Используйте матрицу ниже как отправную точку.
4. Назначайте через бизнес-правило (Администрирование > Правила > Бизнес-правила для заявок): критерий Приоритет = Высокий, действия «Назначить SLA (TTR)» и «Назначить SLA (TTO)». SLA применяется при создании; если приоритет потом изменится, нужно правило, которое пересчитает срок.
5. Настройте уровни эскалации в каждом SLA (действия при 75%, 100% и 150% срока).

Это честные ориентиры для старта: перекалибруйте их через 60–90 дней по реальным данным вашей службы поддержки и никогда не копируйте сроки другого клиента.

Настройка OLA

OLA имеет ту же структуру (TTO/TTR плюс уровни эскалации), но измеряет внутренние обязательства между командами. Типичный сценарий: когда L1 эскалирует на L2, начинает отсчитываться OLA L2 — и GLPI записывает эти сроки в internal_time_to_own и internal_time_to_resolve, отдельно от SLA клиента. Повторим момент, вызывающий больше всего вопросов: OLA не замораживает SLA.

Типичная ошибка: эскалация, которая никогда не срабатывает

В сопровождении повторяющаяся заявка по SLA касается не настройки, а того, что «срок нарушен, и никто не был оповещён». Почти во всех случаях причина одна: автоматическое действие slaticket, которое обходит уровни эскалации, работает во внутреннем режиме (запускается только когда кто-то работает в GLPI), или внешний GLPI cron не активен. Уровень существует, срок записан в time_to_resolve, но на 75% ничего не срабатывает, потому что процесс, читающий уровни, не выполняется. Поэтому в нашем чек-листе внедрения проверка slaticket идёт ДО создания любого уровня эскалации.

Убедитесь, что GLPI cron работает во внешнем режиме:

# /etc/cron.d/glpi - runs GLPI's automatic actions (including slaticket)
* * * * * www-data /usr/bin/php /var/www/glpi/front/cron.php >/dev/null 2>&1

Затем проверьте в базе, что действие активно и работает во внешнем режиме:

-- State of the SLA escalation automatic action.
-- mode:  1 = internal (bad, depends on browsing), 2 = external (correct)
-- state: 1 = waiting, 2 = running, 0 = disabled
SELECT name, state, mode, lastrun, frequency
FROM glpi_crontasks
WHERE name = 'slaticket';

И запрос, который используется в повседневном сопровождении: заявки с уже нарушенным сроком решения, которые всё ещё открыты.

-- Tickets with an overdue TTR that are not yet solved.
-- status: 5 = solved, 6 = closed (excluded)
SELECT t.id, t.name, t.time_to_resolve, t.status
FROM glpi_tickets t
WHERE t.time_to_resolve IS NOT NULL
  AND t.time_to_resolve < NOW()
  AND t.status NOT IN (5, 6)
  AND t.solvedate IS NULL
ORDER BY t.time_to_resolve ASC;

Для аудита настройки (и чтобы поймать SLM без календаря, прежде чем он сломает сроки):

-- Configured SLAs and the calendar inherited from the SLM.
-- NULL/empty calendar = 24h straight counting (the classic trap).
SELECT s.name AS sla,
       CASE s.type WHEN 1 THEN 'TTO' WHEN 0 THEN 'TTR' END AS type,
       s.number_time, s.definition_time,
       cal.name AS calendar
FROM glpi_slas s
JOIN glpi_slms slm ON slm.id = s.slms_id
LEFT JOIN glpi_calendars cal ON cal.id = slm.calendars_id
ORDER BY s.name;

Лучшие практики от тех, кто эксплуатирует

• Начните с 3–5 уровней и перекалибруйте через 60–90 дней по реальным данным.
• Реалистичный календарь: не настраивайте 24x7, если команда работает в рабочее время, — иначе срок «идёт» ночью, и заявка рождается уже просроченной.
• Предупреждайте до нарушения (75%), чтобы было время отреагировать, а не только в момент нарушения.
• Никогда не редактируйте статусы или сроки массово через SQL: вы обходите пересчёт времени ожидания (sla_waiting_duration), и срок становится неверным.
• Документируйте, какое бизнес-правило назначает каждый SLA, — «осиротевшее» правило является второй по частоте причиной «SLA не применён».

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

Когда SLA и OLA заработают, соберите каталог услуг и отслеживайте KPI службы поддержки, чтобы понимать, реалистичны ли сроки.

Если организация уже выросла и SLA становится предметом споров каждую неделю, сопровождение GLPI от NexTool возьмёт на себя настройку, cron и мониторинг сроков.

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