NexTool Solutions

Внедрять GLPI без планирования — значит создавать технический долг с первого дня. При сопровождении сред клиентов почти ни один проект GLPI не проваливается из-за программного обеспечения. Он проваливается из-за решений об объёме работ, принятых слишком поздно, из-за данных, импортированных до утверждения иерархии, и из-за инфраструктурной детали, которая начинает болеть только после запуска. Этот чек-лист охватывает 12 этапов, но ценность — в решениях, которые нужно принять перед каждым из них.

До чек-листа: объём работ — это бизнес-решение, а не решение ИТ

Главный предиктор успеха, который мы наблюдаем, не технический: это наличие владельца процесса на стороне клиента — человека с полномочиями сказать «этот процесс не входит в фазу 1». Без такого владельца каждое подразделение просит исключение, объём разрастается, и запуск сдвигается на три месяца. Первое решение при внедрении — не какой сервер использовать, а что не будет запущено в первый день. GLPI, который хорошо справляется с заявками и инвентаризацией и запускается в срок, даёт больше вовлечённости, чем идеальный CMDB, который так и не выходит в эфир.

Честный расчёт ресурсов: три слоя, которые растут вместе

Среда GLPI — это три слоя, которые нужно рассчитывать совместно: приложение (PHP/PHP-FPM), база данных (MariaDB/MySQL) и хранилище документов. Без выдуманных бенчмарков: для нескольких сотен пользователей и нескольких тысяч активов среды комфортно работают на 2–4 vCPU и 4–8 ГБ RAM. Два момента, которые чаще всего порождают обращения в поддержку, связаны не с CPU:

• MariaDB — настройте innodb_buffer_pool_size так, чтобы он вмещал «горячий» набор данных. База, зажатая в маленьком буфере, делает поиск в GLPI медленным даже при простаивающем CPU.
• PHP — низкий memory_limit обрушивает отчёты и крупные импорты с общей ошибкой; GLPI рекомендует не менее 128 МБ, а импорт инвентаризации требует большего запаса.
• Диск — больше всего растут папка с вложенными документами и инвентаризация. Планируйте рост, а не только начальный размер.

Поэтапность: матрица, которая определяет момент запуска

Операционный вопрос не «что умеет GLPI», а «что входит в какую фазу». Это матрица, которой мы отделяем запуск (MVP) от последующего развития. Правило: переходить к следующей фазе только после того, как предыдущая реально используется и в неё поступают данные.

Настройка, которая ломается при запуске: cron в режиме CLI

Это ловушка, которая чаще всего на наших глазах портила впечатление от успешного запуска. Автоматические задачи GLPI (отправка уведомлений, расчёт SLA, сбор почты через mailgate, синхронизация) могут работать в двух режимах: GLPI (запускаются при веб-доступе) или CLI (внешний запуск через crontab). В режиме GLPI задачи продвигаются, только когда кто-то открывает страницу. Классический результат: очередь копится всю ночь, а первый утренний пользователь «платит по счёту», обрабатывая сотни застрявших писем, и все думают, что «GLPI тормозит». Исправление тривиально, но почти никто не включает его, пока не заболит: внешний cron каждую минуту.

# /etc/cron.d/glpi -- queue, notifications, SLA and e-mail collection (mailgate)
# Run as the PHP user (Debian/Ubuntu: www-data).
# Valid for GLPI 10 and 11: both run front/cron.php via CLI.
* * * * * www-data /usr/bin/php /var/www/glpi/front/cron.php >/dev/null 2>&1

После установки crontab переведите автоматические задачи в режим CLI в интерфейсе настроек. GLPI начнёт распознавать внешний запуск и будет непрерывно разгружать очередь, не завися от веб-доступа.

Проверка перед запуском: диагностика, которую мы выполняем перед открытием доступа

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

-- 1) Automated actions still in internal mode (mode=1). At go-live they must move to CLI (mode=2)
SELECT name, state, mode FROM glpi_crontasks WHERE mode = 1;

-- 2) Is the notification system on? (0 = off, e-mails never leave)
SELECT value FROM glpi_configs WHERE context = 'core' AND name = 'use_notifications';

-- 3) Active users with no profile assigned (cannot log in to any entity)
SELECT u.id, u.name
FROM glpi_users u
LEFT JOIN glpi_profiles_users pu ON pu.users_id = u.id
WHERE pu.id IS NULL AND u.is_active = 1 AND u.is_deleted = 0;

-- 4) Entity tree: check it matches the approved design
SELECT id, name, completename FROM glpi_entities ORDER BY completename;

Практический бонус: проверьте реальное уведомление от начала до конца (создайте тестовую заявку и убедитесь, что письмо приходит в ящик инициатора). Уведомление, которое «настроено», но не отправляется, — тихий дефект номер один для вовлечённости пользователей.

Чек-лист из 12 этапов

1. Определить цели — конкретные и измеримые (потерянные заявки, отсутствие инвентаризации, неконтролируемый SLA).
2. Собрать требования, опросив поддержку, руководителей и пользователей; описать процессы и болевые точки.
3. Рассчитать инфраструктуру (сервер, ОС, база данных, RAM, диск). См. руководства по Docker или Linux.
4. Установить и настроить GLPI, SSL, SMTP, cron (CLI) и базовую безопасность.
5. Выстроить организации и местоположения до ввода каких-либо данных. См. руководство по организационной иерархии.
6. Настроить минимальные категории и SLA. См. руководство по SLA и OLA.
7. Настроить профили и права, определив, кто что может делать.
8. Импортировать начальные данные (пользователи через LDAP/AD, используемые активы, действующие договоры) — минимум для работы.
9. Настроить приоритетные интеграции (почта, LDAP/AD, мониторинг, GLPI Agent).
10. Обучить команду по ролям: специалисты, руководители и конечные пользователи портала.
11. Пилот (MVP) с небольшой группой, со сбором обратной связи перед общим запуском.
12. Запуск и мониторинг с отслеживанием KPI и корректировками в первые недели.

Подводные камни, которые обошлись дорого

• Импорт пользователей до утверждения иерархии организаций. Перенос объектов между организациями потом затрагивает связанные заявки, договоры и права. Мы определяем дерево организаций и поле синхронизации LDAP до первого импорта, потому что повторный импорт без стабильного ключевого поля дублирует пользователей.
• Перенос пяти лет истории в первый день. Это рецепт задержки запуска. Загрузите операционный минимум, а историю оставьте для последующей загрузки, когда структура уже стабильна.
• Оставить cron в режиме GLPI. Подробно описано выше: застрявшая очередь воспринимается как «медленная работа».
• Не проверить SMTP реальным письмом. Сохранённая настройка — это не доставленное уведомление. Проверьте от начала до конца перед открытием доступа.

Нужен запуск без сюрпризов? NexTool планирует и выполняет внедрения GLPI для B2B-клиентов — от поэтапного определения объёма работ до проверенной среды в продуктиве. Узнайте об услуге «Проекты и внедрение».

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