Система учёта заявок на своём сервере: как навести порядок в обращениях без SaaS-подписки

Система учёта заявок — это журнал обращений с единым номером тикета, таймерами SLA и выгружаемой отчётностью, фиксирующий жизненный цикл запроса от регистрации до закрытия. В отличие от облачных сервисов, развёртывание такого инструмента на собственном сервере снижает риск утечки персональных данных за периметр компании и закрывает требование 152-ФЗ о хранении данных граждан РФ на территории России.

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

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

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

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

Терминологически в русскоязычной практике одно и то же название встречается у разных вещей: «система регистрации заявок», «система обработки заявок», «система управления заявками» — чаще всего это синонимы учётной части. Service Desk в стандарте ITIL — надстройка над учётом, которая добавляет управление инцидентами, запросами на обслуживание и изменениями. GLPI, например, покрывает обе плоскости: позволяет управлять инцидентами и запросами, а также настраивать SLA, что делает его одновременно учётной системой и Service Desk.

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

Учёт заявок на своём сервере снимает три риска, которые SaaS-подписка создаёт по умолчанию: утечку персональных данных заявителей за периметр, несоответствие 152-ФЗ при обработке ПДн российских граждан на иностранной инфраструктуре и отзыв доступа вендором без предупреждения. Эти риски не теоретические: любое обращение содержит минимум ФИО и контакт, то есть уже является обработкой персональных данных.

Юридически 152-ФЗ «О персональных данных» (ч. 5 ст. 18) требует, чтобы персональные данные граждан РФ хранились и первично обрабатывались на серверах, находящихся на территории России. SaaS-сервис с хостингом за рубежом ставит оператора в положение, когда соблюсти закон можно только через оговорки в договоре и постоянные проверки площадки хостинга — а это ровно та нагрузка, которую self-hosted снимает одним архитектурным решением.

Экономически SaaS выглядит дешевле на старте: платите только за активных агентов. Но у подписки есть скрытые расходы, которых нет у self-hosted. Первый — цена за историю: при расторжении договора выгрузка данных часто ограничена форматом и сроком, после которого архив удаляется. Второй — цена за интеграции: подключение к внутреннему AD, мониторингу и системе учёта активов в SaaS обычно оплачивается отдельно или требует среднего/старшего тарифа.

Self-hosted система учёта заявок, напротив, одноразово покупает железо (или арендует VPS в российском ЦОД) и дальше несёт только расходы на администрирование. GLPI — программное обеспечение с открытым исходным кодом, лицензионная плата отсутствует, привязки к вендору нет. То же касается Zammad, OTOBO и osTicket в их открытых редакциях.

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

Остаётся честный минус self-hosted: обновления, бэкапы и мониторинг — ваша зона ответственности. Если в компании нет Linux-администратора хотя бы на часть ставки, этот минус перекрывает любую экономию. Поэтому решение «SaaS или свой сервер» — не идеология, а честная оценка внутренней команды.

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

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

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

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

Выгрузка — функция, о которой вспоминают, когда уже поздно. Проверять её нужно до внедрения: берите тестовый экземпляр и экспортируйте большую пачку заявок в CSV или JSON. Если выгрузка идёт только через UI и падает на объёмах — считайте, что данные заперты в системе. GLPI в этом смысле прозрачен: за ним стоит документированная БД MySQL/MariaDB, доступная для прямых запросов.

Опциональные, но часто окупающиеся функции — CMDB и инвентаризация. GLPI включает функции управления активами и конфигурационной базой данных (CMDB) и поддерживает автоматизацию инвентаризации, сканирование сетей и генерацию SNMP-отчётов. Для компании с собственным парком техники это означает, что заявка «не работает ноутбук» мгновенно связывается с конкретным активом, его серийным номером и историей сервисных обращений — без ручного ввода.

Пять self-hosted систем учёта заявок закрывают разные ниши: GLPI — ITSM с CMDB и инвентаризацией, Zammad — многоканальная поддержка с акцентом на почту и чат, OTOBO — наследник OTRS для корпоративного Service Desk, osTicket — минималистичный тикетинг для малых команд, Chatwoot — open-source ответ на Intercom с упором на омниканальный чат. Детальное сравнение по десяткам критериев вынесено в отдельный материал — здесь только опорные точки для выбора.

GLPI — самый «тяжёлый» из пятёрки по функциональности. Помимо учётной части, он включает управление активами и CMDB, автоматизацию инвентаризации и SNMP-отчёты. Это открытое ПО с возможностью бесплатного тестирования первой инстанции в течение 45 дней на управляемой площадке. Подходит, когда учёт заявок — часть зрелого IT-процесса с привязкой к активам.

Zammad выделяется интерфейсом и работой с почтой: входящий ящик, по сути, становится источником тикетов без промежуточных плагинов. Чат, Telegram, Twitter подключаются из коробки. Zammad стоит рассматривать, когда поддержка общается с внешними клиентами через множество каналов и агенты много пишут руками.

OTOBO — форк OTRS, сохранивший старую философию «корпоративного Service Desk»: мощная настройка процессов, роли, динамические поля, глубокая кастомизация шаблонов писем. Хороший выбор для крупной организации с устоявшимися регламентами, но порог входа у OTOBO выше, чем у Zammad или osTicket.

osTicket — ветеран open-source тикетинга, написанный на PHP и до сих пор востребованный у команд, которым нужно «просто завести заявку и назначить агента». Минимум настроек, минимум зависимостей, но и минимум функций: ни CMDB, ни полноценной инвентаризации, ни современных интеграций ждать не стоит.

Chatwoot — самое молодое решение из пятёрки, open-source альтернатива платным чатам поддержки, в которой диалог учитывается как основная сущность. Если ваша «заявка» в основном состоит из общения в веб-чате или мессенджере, Chatwoot ближе к задаче, чем классический тикетинг.

Короткий критерий выбора: нужны активы и CMDB — GLPI; важен внешний клиентский канал через почту и чат — Zammad; корпоративный Service Desk с жёсткими процессами — OTOBO; минимальный тикетинг — osTicket; омниканальный чат — Chatwoot.

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

День 1 — инфраструктура. Поднимите виртуальную машину в периметре, установите LAMP/LEMP-стек или возьмите готовый контейнер, проверьте бэкап и мониторинг. На этом же шаге решается вопрос резервной копии БД: без ежедневных снимков систему учёта заявок в прод запускать нельзя — потерянные заявки стоят дороже дня простоя. Для GLPI есть вариант бесплатного тестирования первой инстанции в течение 45 дней на управляемой площадке — удобно, если нужно показать стейкхолдерам живой интерфейс до покупки железа.

День 2 — установка и первичная настройка. Разверните выбранную систему, подключите её к корпоративному каталогу LDAP/AD, заведите группы агентов и роли. Не увлекайтесь кастомизацией: берите стандартные роли «агент», «супервизор», «администратор», тонкую матрицу прав оставьте на второй месяц.

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

День 4 — SLA и отчёты. Опишите рабочие часы, уровни приоритета и целевые времена реакции и решения. GLPI позволяет настраивать SLA с учётом календаря и приоритета — используйте не больше нескольких уровней на старте, иначе агенты запутаются. Соберите базовые отчёты: открытые заявки, нарушения SLA, нагрузка по агентам.

День 5 — пилот и приёмка. Запустите систему на одной команде поддержки, прогоните через неё реальный поток, соберите замечания и внесите правки. На этом же дне проведите короткое обучение агентов — не теорию ITIL, а конкретные операции: создание, назначение, перевод, закрытие.

Пример-расчёт для условной компании: допустим, у вас небольшая организация с десятками заявок в день, идущими в общий почтовый ящик. Если выделить Linux-администратора на часть ставки на одну рабочую неделю и одного супервизора поддержки на полную занятость, пяти рабочих дней достаточно, чтобы перевести поток в GLPI с SLA, базовыми отчётами и выгрузкой в CSV. Полный переход агентов с почты занимает ещё несколько недель плавной адаптации.

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

Железо. Для средней организации достаточно умеренной VPS в российском ЦОД: умеренный объём оперативной памяти, пара виртуальных ядер, достаточный объём SSD. Арендованная мощность в этом сегменте стоит заметно меньше SaaS-подписки на ту же команду агентов, потому что SaaS берёт плату за каждого активного агента, а VPS — за ресурсы независимо от числа пользователей. На собственном гипервизоре стоимость стремится к стоимости электричества.

Лицензии. Все пять self-hosted систем из нашего сравнения — open-source. У GLPI это подтверждено прямо на сайте проекта: открытое ПО. Платные компоненты появляются только у коммерческих редакций и плагинов (расширенная отчётность, SLA-калькуляторы, outsourcing-модули), и их имеет смысл подключать после первого года эксплуатации, когда базовые потребности известны. Для обкатки есть вариант бесплатного тестирования первой инстанции GLPI в течение 45 дней на инфраструктуре вендора.

Администрирование — самая большая статья. Реалистичная оценка — несколько часов в неделю системного администратора на обновления, резервное копирование, разбор инцидентов интеграций, плюс разовые работы на масштабирование. Если считать в человеко-часах по внутренней ставке, это основная «цена» self-hosted. SaaS в этой строке тоже не бесплатен: кто-то настраивает интеграции, следит за API-лимитами, разбирает отвалившиеся вебхуки — просто этот труд менее заметен.

Инфраструктура резерва и мониторинга. Ежедневные бэкапы базы и файлов требуют места кратно больше объёма самой БД — отдельный диск или облачное хранилище в периметре. Мониторинг добавляется в существующий Zabbix- или Prometheus-контур без дополнительной лицензии.

Пример-расчёт для условной компании: допустим, у организации несколько десятков пользователей и десятки заявок в день. Если арендовать VPS среднего класса в российском ЦОД, выделить часть ставки администратора на поддержку GLPI и использовать имеющийся Zabbix, годовой бюджет укладывается в стоимость подписки на SaaS-Help Desk для небольшой команды агентов. Разница растёт с ростом команды: SaaS масштабируется линейно по агентам, self-hosted — ступенчато, только при переходе на следующий класс железа.

Отдельная экономия, которую сложно оценить заранее, — отсутствие миграций между вендорами. Переезд между SaaS-платформами — это проект на недели с риском потери истории. На своём сервере вы меняете только версию системы, а база заявок остаётся на месте.

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

Можно ли бесплатно протестировать систему учёта заявок до покупки железа?

Да. У GLPI доступна возможность бесплатного тестирования первой инстанции в течение 45 дней на инфраструктуре проекта — удобный способ показать интерфейс руководству и прогнать типичный поток обращений, не разворачивая собственный сервер. Zammad, OTOBO, osTicket и Chatwoot имеют открытые редакции, которые ставятся на любой тестовый сервер за несколько часов и остаются бесплатными неограниченно долго. Для демонстрации заказчику этого обычно хватает, чтобы принять решение.

Что делать, если в компании нет Linux-администратора?

Два варианта. Первый — брать внешнее сопровождение по SLA: подрядчик обновляет систему, следит за бэкапом и разбирает инциденты. Второй — всё-таки использовать SaaS, несмотря на минусы. Разворачивать self-hosted систему учёта заявок без человека, который умеет администрировать Linux и базу данных, — верный путь к потере данных при первой же проблеме с диском или при неудачном обновлении.

Подходит ли GLPI только для IT-отделов?

Нет. GLPI управляет инцидентами и запросами и настраивает SLA для любых сервисных процессов — АХО, HR-поддержки, обслуживания оборудования, обращений от арендаторов. Привязка к активам через CMDB делает его сильнее именно в технических контурах, но учётная часть одинаково работает для любых сервисных заявок. Для нетехнических отделов часть модулей просто отключается в правах доступа.

Как перенести историю заявок из SaaS на свой сервер?

Через выгрузку из SaaS в CSV или через API и импорт в целевую систему скриптом. Проверьте заранее, что текущий SaaS отдаёт все нужные поля — часто история переписки или вложения остаются за бортом стандартной выгрузки. Полный перенос с сохранением вложений и внутренних заметок почти всегда требует разовой разработки и занимает несколько рабочих дней.

Нужен ли отдельный сервер или достаточно виртуалки на общем гипервизоре?

Для средней организации достаточно виртуальной машины на общем гипервизоре с базовыми ресурсами, выделенным хранилищем и собственной линией бэкапа. Отдельный физический сервер оправдан только при высоких требованиях к изоляции (например, обработка данных под 152-ФЗ в закрытом контуре) или при интеграции с инвентаризацией крупного парка — там GLPI может потреблять заметно больше ресурсов за счёт сканирования сети.

Ответы на часто задаваемые вопросы по теме статьи.

Константин Тютюнник — основатель и инженер IT For Prof. Сопровождает корпоративную ИТ-инфраструктуру российского бизнеса: серверы, почтовые системы, мониторинг, корпоративные мессенджеры и платформы вроде Битрикс24. Делится практикой импортозамещения и self-hosted-решений в блоге и GitHub-организации IT-for-Prof. В рубрике о корпоративных платформах пишет о Битрикс24, ELMA365 и их серверной части.