NexTool Solutions

Хорошо управляемое изменение в GLPI — это не то, в котором заполнено больше всего полей, а то, которое вы можете откатить в 2 часа ночи, когда оно провалилось. Это руководство проходит по полному жизненному циклу изменений в GLPI: из какого раздела и столбца берётся каждая информация, как смоделировать типы изменений, которых нет в стандартном GLPI, и подводные камни, которые на наших глазах срывали окна обслуживания в средах, сопровождаемых нами для клиентов.

Модель данных, стоящая за изменением

Каждое изменение хранится в таблице glpi_changes. Помимо очевидных полей (название, содержание, срочность, влияние, приоритет), изменение от обычной заявки отличают текстовые столбцы, которые GLPI показывает в разделе анализа и планов формы:

• impactcontent — анализ влияния: что сломается, если что-то пойдёт не так.
• controlistcontent — контрольный список: точки проверки.
• rolloutplancontent — план внедрения (в ядре подписан «Deployment plan»): пошаговый порядок развёртывания.
• backoutplancontent — план отката/rollback (в ядре подписан «Backup plan»): как отменить изменение.
• checklistcontent — чек-лист проверки после внедрения.

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

«Тип изменения» в GLPI: поле, которого нет

Самая частая ошибка тех, кто пришёл из инструментов вроде ServiceNow, — искать селектор «Тип: Нормальное / Экстренное / Стандартное». В стандартном GLPI его нет. У изменения есть категория (itilcategories_id), срочность, влияние и приоритет, но нет поля типа ITIL. Классификацию вы моделируете с помощью отдельных категорий ITIL, которые к тому же питают отчёты и бизнес-правила.

Жизненный цикл, статус за статусом

GLPI проводит изменение через собственный конечный автомат, более богатый, чем у заявки. Текущее состояние хранится в столбце status таблицы glpi_changes:

1. Новое (1) — регистрация в разделе «Поддержка > Изменения» с описанием, обоснованием, влиянием и риском.
2. Оценка (4) — анализ влияния и риска; заполнение разделов анализа и планов.
3. Согласование (11) — раунд согласования с утверждающими.
4. Принято (12), Тестирование (13), Квалификация (14) — планирование и выполнение задач (glpi_changetasks), каждая из которых фиксируется в хронологии.
5. Решено (5) — проверка после внедрения; подтверждает успех и фиксирует извлечённые уроки.
6. Закрыто (6) — итоговая документация и закрытие.

Каждая задача изменения содержит actiontime (фактическое время) и state (к выполнению/выполнено), что позволяет сравнивать запланированные и фактические трудозатраты — данные, которые мы используем для калибровки оценок следующих окон.

Согласование: встроенное или многоуровневое

Встроенное согласование записывается в glpi_changevalidations (статус 2 = ожидание, 3 = согласовано, 4 = отклонено). Нюанс, на котором попадаются почти все: согласование в GLPI информативно, это не шлагбаум. Ничто не мешает перевести изменение из «Согласования» в «Тестирование», пока согласование ещё в ожидании; GLPI не блокирует переход. Если ваше управление требует, чтобы никто не внедрял изменение без зафиксированного согласования, одного встроенного согласования недостаточно. Здесь на помощь приходит Approval Flow с многоуровневым согласованием и условными маршрутами, которые действительно блокируют продвижение.

Шаблон уведомления о запросе согласования

В разделе «Настройки > Уведомления» шаблон события согласования изменения использует теги GLPI. Лаконичный текст сокращает количество уточнений:

Subject: [Change ##change.id##] Approval requested - ##change.title##

Hello,

A change is awaiting your approval.

Title:     ##change.title##
Category:  ##change.category##
Urgency:   ##change.urgency##
Impact:    ##change.impact##
Priority:  ##change.priority##

Description:
##change.content##

Approve or reject at:
##change.url##

Наличие срочности, влияния и приоритета в тексте избавляет утверждающего от необходимости открывать изменение только ради решения. Это сокращает время в статусе «Согласование», где и задерживается большинство окон.

Диагностика: изменения без плана отката

При сопровождении чаще всего пустым оказывается именно самое критичное поле: backoutplancontent. Раздел планов в интерфейсе свёрнут, поэтому специалист заполняет описание и задачи, но никогда — план отката, и проблема проявляется только когда изменение проваливается и никто не знает, как его откатить. Мы выполняем этот SELECT каждую пятницу перед окном обслуживания на выходных:

SELECT c.id,
       c.name AS change_name,
       c.status,
       IF(c.backoutplancontent = '' OR c.backoutplancontent IS NULL,
          'NO ROLLBACK', 'ok') AS rollback_plan
FROM glpi_changes c
WHERE c.is_deleted = 0
  AND c.status NOT IN (5, 6)          -- excludes Solved and Closed
ORDER BY c.date DESC;

Любая строка с NO ROLLBACK — это изменение, которое не должно попадать в окно обслуживания. Мы превращаем это в бизнес-правило: без заполненного плана отката согласование не выдаётся.

Лучшие практики сопровождения

• Документируйте backoutplancontent до запроса согласования, а не после внедрения.
• Связывайте изменение с исходной проблемой (glpi_changes_problems), чтобы сохранять прослеживаемость от корневой причины к корректирующему действию.
• Создавайте шаблоны для повторяющихся (стандартных) изменений и отключайте для них согласование.
• Планируйте работы вне часов пиковой нагрузки и фиксируйте фактическое actiontime для калибровки оценок.
• Завершайте цикл проверкой после внедрения, даже если всё прошло успешно; именно она становится базой знаний.

Если вашей работе нужен шлагбаум согласования, который действительно блокирует продвижение, и проверяемое управление изменениями, сопровождение NexTool настроит такой процесс с модулем Approval Flow поверх GLPI, которым вы уже пользуетесь.

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