GLPI продержался у нас три месяца — рассказываем, что пошло не так

MAATRIX

Мы честно пытались. Три месяца назад развернули GLPI, потому что устали от разрозненного учёта техники в таблице и заявок в чате, и хотели одну систему, которая закрывает всё сразу — от инвентаря до тикетов и договоров с поставщиками. GLPI на бумаге выглядел идеальным ответом: бесплатный, открытый, с функциональностью уровня взрослого ITSM. На практике мы откатились обратно к более простому стеку раньше, чем успели толком привыкнуть к новому интерфейсу. Разбираем, что именно пошло не так — без злорадства в адрес GLPI, он неплохой инструмент, просто не для нашей задачи.

Что нас привлекло: GLPI как решение всех задач сразу

GLPI (Gestionnaire Libre de Parc Informatique) — открытая французская система, которая объединяет под одной крышей то, что у нас раньше жило в трёх разных местах: учёт активов (ITAM), service desk с обработкой заявок по ITIL-процессам, и управление договорами, лицензиями и бюджетами. Разворачивается на своём сервере как PHP-приложение поверх MySQL/MariaDB, распространяется бесплатно, исходники открыты — то есть по деньгам вход нулевой, платить нужно только временем на администрирование.

Модули, которые нас впечатлили на демо:

• Assets — компьютеры, сетевое оборудование, принтеры, телефоны, программное обеспечение, с автоматическим сбором инвентаря через GLPI Agent (раньше это был отдельный плагин FusionInventory, в актуальных версиях агент официальный и встроенный) — машины сами присылают конфигурацию, не нужно вбивать серийники руками.
• Assistance — полноценный service desk: заявки делятся на инциденты, запросы, проблемы и изменения, как в классическом ITIL, с SLA, эскалациями и бизнес-правилами маршрутизации по условиям (кто автор, какая категория, какая срочность — тикет уходит нужному исполнителю или группе автоматически).
• Management — договоры с поставщиками, лицензии софта с датами продления, бюджеты, финансовый учёт активов (сколько стоила единица техники, какая у неё амортизация) — то, чего в принципе нет в узкоспециализированных трекерах техники.
• Tools — база знаний, бронирование переговорных и оборудования, простой модуль проектов.
• Administration — пользователи, группы, профили прав и, отдельная тема, структура сущностей (entities) — иерархия организационных единиц для мультитенантности: филиалы, отделы, юридические лица со своими правами и видимостью данных.

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

Первые недели: разворачивание и первые тикеты

Установка прошла без сюрпризов — стандартный стек LAMP/LEMP, база MySQL, инсталлятор через веб-мастер, который проверяет зависимости PHP и создаёт схему базы. Первую неделю мы потратили на структуру: завели сущности под два наших офиса, накатили профили прав (администратор, техник, супер-техник, обычный пользователь-заявитель), настроили категории заявок и подключили GLPI Agent на десяток тестовых машин — агент действительно сам подтянул модели процессоров, объём памяти, установленный софт, и это было приятным первым впечатлением: то, что в Excel мы бы вбивали вручную по одной строке, здесь появилось само.

Первые тикеты заводили с энтузиазмом. Настроили пару бизнес-правил: заявки от бухгалтерии с категорией «1С» автоматически уходят конкретному специалисту, заявки с приоритетом «критично» эскалируются, если за час никто не взял в работу. На этом этапе казалось, что система окупает себя уже сейчас — правила работали, тикеты не терялись, история по каждому активу собиралась сама.

Трещины появились не в первую и не во вторую неделю, а ближе к концу первого месяца, когда систему начали трогать не только те, кто её настраивал.

Модель прав и сущностей: где споткнулась администрация

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

Каждый профиль прав в GLPI назначается пользователю в привязке к конкретной сущности (и опционально — рекурсивно на дочерние). Это гибко до предела: можно дать технику права редактировать активы только в своём офисе, но право читать тикеты — во всех. Но конфигурировать эту гибкость руками — отдельная работа, требующая понимания матрицы «профиль × сущность × рекурсия», а не одной галочки «сделать администратором». Мы дважды наступали на одно и то же: новый сотрудник не видел активы соседнего офиса, потому что унаследовал профиль без рекурсивного права, и разбирались с этим не пять минут, а полчаса, листая настройки профилей.

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

Обновления тоже требовали внимания: как у любого self-hosted PHP-приложения с базой данных, апгрейд между версиями означает бэкап базы и файлового хранилища, прогон миграций, и отдельную проверку, что кастомизированные бизнес-правила и профили пережили обновление в целости. Ничего катастрофического не случилось ни разу — но каждое обновление превращалось в вечер, который нужно было заранее планировать, а не в фоновую задачу.

ITIL из коробки — когда процессов больше, чем реальных задач

Assistance-модуль реализует классическую ITIL-модель: инцидент (что-то сломалось, нужно починить), запрос (нужна новая возможность или доступ), проблема (повторяющийся инцидент, требующий анализа первопричины), изменение (плановая модификация инфраструктуры с процессом согласования). Для крупной ИТ-организации с формальным процессным управлением это ровно тот язык, на котором стоит говорить. Для нашей команды из айтишников и обычных сотрудников, которые просто хотят написать «принтер не печатает» и получить решение, это оказалось четырьмя дверями там, где нужна одна.

На практике почти все заявки заводились как «инцидент», потому что остальные три типа сотрудники просто не понимали, когда выбирать — и не должны были: это внутренняя терминология ITSM, а не то, о чём думает бухгалтер, когда у него не печатает принтер. Мы попытались упростить форму заведения заявки, скрыть лишние поля, оставить дефолтным один тип — но сама архитектура интерфейса всё равно тянула за собой сопутствующие сущности: SLA привязывается к типу и категории, эскалации настроены под конкретный workflow, и упрощение одного места ломало логику в другом.

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

Отдельно стоит модуль «Изменения» с процессом согласования — многоступенчатое одобрение планового изменения инфраструктуры. Для команды в несколько человек, где решение «обновить сервер в выходные» принимается в одном сообщении в чате, формальный workflow согласования — это не контроль качества, а лишний клик перед тем, что и так все понимают.

Что реально использовала команда из всего этого богатства

Через два месяца мы честно посчитали, чем из функциональности GLPI мы пользуемся регулярно, а что стоит настроенным, но не тронутым с момента установки:

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

Почему решили откатиться и что подняли вместо GLPI

Решающим стал не один инцидент, а сумма мелких: очередной час на разбор, почему сотрудник не видит свои же активы после смены профиля; очередное обновление, требующее вечера на проверку миграций и бизнес-правил; очередной новый сотрудник, которого приходится отдельно учить, чем «Запрос» отличается от «Инцидента», хотя разница ему не нужна для работы. Мощь GLPI — это ровно то же самое, что стало его слабостью для нас: система спроектирована под организацию с формальным ITSM-процессом, выделенным администратором и штатом на десятки-сотни активов с реальной оргструктурой, а у нас — компактная команда без формального процессного управления.

Мы вернулись к связке из двух более узких инструментов вместо одной широкой системы: Snipe-IT — только под учёт активов, без модели сущностей, без ITIL-типизации, с историей выдачи и уведомлениями об истечении лицензий, ровно тем, что мы реально использовали в GLPI. Здесь важно честно развести эти два инструмента, а не представлять их конкурентами в одной весовой категории: GLPI — это полноценная ITSM/ITAM-платформа с service desk, управлением инцидентами по ITIL и финансовым учётом активов (договоры, бюджеты, амортизация), а Snipe-IT — узкоспециализированный трекер техники, который сознательно не пытается быть системой обращений или процессным инструментом. Если вашей команде реально нужен формальный service desk с SLA и разделением инцидент/проблема/изменение — GLPI выбор куда более обоснованный, чем для нас. Мы просто такой команде не были.

Заявки на ремонт и доступы мы перенесли в отдельный лёгкий helpdesk — по тому же принципу «одна задача — один простой инструмент», без обязательной ITIL-типизации и без обязательного заполнения десятка полей на каждую заявку про сломанную мышку. Разворачивание такой системы с нуля на своём сервере в общих чертах устроено похоже на то, что описано в статье про быстрое разворачивание open source трекера за выходные — принцип «поднять минимально достаточное, а не максимально функциональное» сработал у нас и здесь.

Отдельный урок — административная нагрузка self-hosted решения не сводится к разовой установке, она растёт вместе с богатством функциональности, которую вы решили включить, а не только с количеством пользователей. Общий разбор того, во что реально обходится содержание своего сервера сверх аренды, есть в статье про экономику self-hosted — час администратора на разбор прав и бизнес-правил стоит вполне реальных денег, даже если сама лицензия системы бесплатна.

Частые вопросы