Open-source тикет-системы на своём сервере: Zammad vs GLPI vs OTOBO vs Chatwoot vs osTicket (PILLAR)

open-source тикет-системы сравнение — критический этап для ИТ-директоров, выбирающих между Zammad, GLPI, OTOBO, Chatwoot и osTicket. Ошибка в оценке требований к железу или лицензионной модели приводит к росту затрат на поддержку вместо экономии. Российский бизнес всё чаще отказывается от облачных SaaS в пользу self-hosted решений ради контроля данных и соответствия регуляторным нормам.

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

Open-source тикет-система — это программное обеспечение для регистрации, маршрутизации и закрытия обращений в службу поддержки, исходный код которого открыт и доступен для самостоятельного развёртывания на собственной инфраструктуре. В отличие от облачных хелпдесков, такая система устанавливается на ваш сервер, базу данных и веб-сервер, а данные обращений никогда не покидают периметр компании. К этому классу относятся пять систем, которые мы сравниваем в этом материале: Zammad, GLPI (open-source решение для IT Service Management от Teclib’), OTOBO, Chatwoot и osTicket.

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

Вторая причина — экономика на длинной дистанции. Облачные тикет-системы обычно тарифицируются за каждого агента в месяц, и при росте команды поддержки с пяти до пятидесяти инженеров счёт растёт линейно. Self-hosted GLPI, Zammad, OTOBO, Chatwoot и osTicket по основной лицензии бесплатны: вы платите только за сервер, администрирование и опциональную коммерческую поддержку. На горизонте трёх-четырёх лет совокупная стоимость владения у SaaS и open-source расходится тем сильнее, чем больше агентов в поддержке: подписка облака растёт с каждым новым сотрудником, а расходы на self-hosted остаются в основном фиксированными.

Третья причина — глубокая интеграция с тем, что уже есть в компании. У нас был проект, где тикет-система должна была забирать заявки из 1С, отдавать события в Zabbix и держать единую учётную запись через Active Directory. SaaS-хелпдеск такую связку поднял бы через REST-прослойку и набор webhook-ов, но каждое изменение схемы данных превращалось бы в сторонний интеграционный проект. С open-source системой мы добавили поля прямо в таблицы тикетов и написали обработчики на стороне самой системы — без посредников.

Под open-source тикет-системы сравнение в этом тексте мы понимаем именно self-hosted сценарий: ставим у себя, обслуживаем сами или с подрядчиком, расширяем своими силами.

Прежде чем сравнивать продукты, зафиксируем шесть критериев, по которым их имеет смысл оценивать. Любое open-source тикет-системы сравнение, выполненное без этой рамки, превращается в перечисление функций без привязки к задачам бизнеса.

Первый критерий — лицензия и модель монетизации. Здесь важно разделять «бесплатно по лицензии» и «бесплатно по факту». GLPI, OTOBO, osTicket и Chatwoot распространяются по лицензиям семейства GPL или MIT, Zammad — по AGPLv3 для self-hosted версии. AGPLv3 накладывает обязательства публиковать модификации, если вы предоставляете систему как сервис внешним клиентам; для внутреннего использования внутри компании это значения не имеет, но при построении публичного хелпдеска юридическую сторону мы всегда проверяем отдельно.

Второй критерий — технологический стек. От него зависит, кого вы будете нанимать для сопровождения. GLPI и osTicket написаны на PHP и работают с MySQL/MariaDB — самый дешёвый по администрированию вариант, кадры найти легко. OTOBO — Perl плюс PostgreSQL или MySQL, специалистов меньше, но и обращений в код требуется меньше. Zammad — Ruby on Rails плюс PostgreSQL, Elasticsearch и Redis: мощно, но требует опытного DevOps. Chatwoot — тоже Ruby on Rails, ориентирован на чат-каналы.

Третий критерий — омниканальность. Если ваши клиенты пишут только в почту, подойдёт любая из пяти систем. Если нужны Telegram, WhatsApp, веб-чат на сайте и Facebook одновременно, без дополнительных коннекторов — Chatwoot впереди по умолчанию. Zammad из коробки берёт почту, Telegram, чат и Twitter. GLPI и osTicket традиционно сильны в почтовых обращениях; для мессенджеров там нужны сторонние плагины.

Четвёртый критерий — соответствие ITIL и зрелость процессов. GLPI здесь лидер: помимо Helpdesk и обработки инцидентов и запросов, в нём есть SLA-движок, каталог услуг, CMDB для полной инвентаризации активов и финансовый модуль для централизации бюджетов, затрат, поставщиков и лицензий. OTOBO исторически вырос из OTRS и тоже хорошо ложится на ITIL-процессы. Zammad ближе к классическому хелпдеску. Chatwoot и osTicket про ITIL почти ничего не знают.

Пятый критерий — требования к железу. Здесь работает простое правило: чем тяжелее стек, тем больше памяти. PHP-системы (GLPI, osTicket) запускаются на скромных конфигурациях. Системы на Rails с Elasticsearch (Zammad, Chatwoot) требуют больше оперативной памяти, особенно при росте базы тикетов.

Шестой критерий — экосистема и поддержка. У GLPI есть коммерческая поддержка от Teclib’, сеть платиновых партнёров и 45-дневный бесплатный пробный период для первой инсталляции. У Zammad и Chatwoot есть собственные коммерческие подписки. У osTicket — преимущественно сообщество и подрядчики; у OTOBO коммерческую поддержку, миграцию с OTRS и доработки предоставляет Rother OSS GmbH.

Ниже — сводное open-source тикет-системы сравнение по ключевым параметрам, на которые мы опираемся при выборе на проектах.

GLPI здесь обоснованно занимает отдельное место. Это единственная из пяти систем, которая закрывает связку «тикеты — активы — финансы» в одной установке. По функциональности она включает Helpdesk с обработкой инцидентов и запросов, формами каталога услуг и SLA; модуль учёта активов с автоматизированной инвентаризацией, сканированием сети, генерацией SNMP-отчётов и развёртыванием приложений; CMDB для полной инвентаризации; финансовый модуль для централизации бюджетов, затрат, поставщиков и лицензий; Dynamic Inventory с безагентским сбором; Mobile Application Management и Mobile Device Management; модули управления дата-центром и оценки воздействия на окружающую среду; функциональности Governance, Antivirus Management и Security Alerts Management. Если в требованиях есть «учёт техники» и «единая база лицензий» — GLPI стоит ставить первым на проверку.

Zammad и Chatwoot мы рассматриваем как два разных взгляда на омниканальность. Zammad ближе к универсальному корпоративному хелпдеску, Chatwoot — к контакт-центру для бизнеса, который живёт в мессенджерах.

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

В реальных проектах open-source тикет-системы сравнение почти всегда сводится к пяти повторяющимся сценариям. Разберём, какая система побеждает в каждом и почему.

Сценарий первый: внутренний ИТ-отдел на 200–2000 рабочих мест. Задача — единая точка приёма заявок от сотрудников, учёт компьютеров, мониторов и лицензий, контроль SLA по типам инцидентов. Здесь выбираем GLPI. Причина — связка хелпдеска с CMDB и финансовым модулем: один администратор видит тикет, связанное устройство, договор поставки и оставшийся гарантийный срок без перехода между системами. На практике такая связка ощутимо экономит время первой линии на заявках по железу: оператору не нужно переключаться между системами, чтобы собрать данные об устройстве и договоре.

Сценарий второй: внешняя поддержка SaaS-продукта или интернет-магазина, где клиенты пишут в WhatsApp, Telegram, веб-чат и почту. Здесь выигрывает Chatwoot. Он строился вокруг мессенджеров и отдаёт оператору единое окно с историей переписки по всем каналам. На практике переход с почтового osTicket на Chatwoot позволяет команде поддержки закрыть рост числа каналов без расширения штата: переключение между диалогами в едином окне становится быстрее.

Сценарий третий: классический сервис-деск среднего предприятия с зрелыми ITIL-процессами, перенос с OTRS или с локальной самописной системы. Здесь рассматриваем OTOBO и GLPI. OTOBO ближе тем, кто привык к OTRS-логике процессов и шаблонов. GLPI выбираем, если параллельно нужен учёт активов.

Сценарий четвёртый: внешняя техподдержка у небольшого MSP или у разработчика B2B-продукта, штат поддержки до десяти человек, основной канал — почта. Здесь подойдут Zammad и osTicket. Zammad даёт более современный интерфейс, поиск по Elasticsearch и встроенную базу знаний; osTicket — минимальные требования к серверу и админу. Если бюджет на сервер ограничен, osTicket разворачивается за полдня.

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

Не выбирайте систему «на вырост», если рост гипотетический. Мы сталкивались с проектами, где небольшая компания внедряла GLPI ради CMDB «на будущее», а позже выяснялось, что активы так и ведутся в Excel, потому что некому заполнять карточки. В таких случаях правильнее было поставить osTicket или Zammad и закрыть базовую боль, а CMDB добавить позже отдельным проектом.

Главная ошибка при оценке open-source тикет-систем — считать только лицензию. Лицензия у всех пяти продуктов формально нулевая, а стоимость владения за три года отличается в несколько раз. Чтобы корректное open-source тикет-системы сравнение по деньгам имело смысл, считаем минимум пять статей расходов.

Первая статья — инфраструктура. Для PHP-систем (GLPI, osTicket) хватает скромной виртуальной машины с PHP-FPM, веб-сервером и MySQL/MariaDB. Для Zammad и Chatwoot нужна машина с большим объёмом оперативной памяти под Elasticsearch и Redis. Разница в стоимости железа между «лёгкими» и «тяжёлыми» системами за три года в облаке набирается ощутимая, и при сотне агентов это уже значимая сумма.

Вторая статья — администрирование. PHP-стек обслуживает любой системный администратор без специализации. Rails-стек требует инженера, который понимает Ruby, очереди, индексацию Elasticsearch и поведение Redis под нагрузкой. На своих проектах мы видели, что для Zammad и Chatwoot имеет смысл сразу закладывать либо отдельного DevOps на четверть ставки, либо внешний контракт на сопровождение.

Третья статья — коммерческая поддержка. У GLPI есть Teclib’ и сеть платиновых партнёров; у Zammad — собственная коммерческая подписка; у Chatwoot — облачные тарифы и enterprise-договоры. У OTOBO поддержка идёт через Rother OSS GmbH (разработчика OTOBO) и подрядчиков, у osTicket — преимущественно через сообщество и сторонних интеграторов. Подписка на поддержку даёт быстрый канал к разработчикам по критичным инцидентам и доступ к обновлениям безопасности. Перед принятием решения GLPI предлагает 45-дневный бесплатный период для первой инсталляции — этого достаточно, чтобы оценить продукт под реальной нагрузкой.

Четвёртая статья — обучение. Чем сложнее система, тем дольше обучаются агенты. GLPI с её модулями активов, финансов и CMDB требует серьёзного onboarding для операторов второй линии. osTicket агент осваивает за час. Закладывайте время первой линии не только на курс, но и на пилотный период, когда продуктивность будет ниже целевой.

Пятая статья — кастомизация. Любая тикет-система через полгода эксплуатации требует доработок: поля под бизнес-процесс, отчёты, интеграции. У GLPI и Zammad сильные плагинные экосистемы, у Chatwoot развитый API, у osTicket доработка часто означает правку самого кода. Не делайте правок прямо в исходниках — мы видели проекты, где из-за этого обновление застревало на устаревшей версии надолго и закрыть критическую уязвимость в срок не удавалось. Все доработки выносите в плагины или внешние сервисы.

Сумма этих пяти статей и есть реальная стоимость владения. Лицензия в ней — самая маленькая строчка.

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

Telegram и WhatsApp — отдельная история. Chatwoot подключает Telegram через Bot API и WhatsApp через WhatsApp Business API или провайдеров вроде 360dialog. Zammad имеет встроенный коннектор к Telegram и поддерживает Twitter; WhatsApp подключается через сторонние шлюзы. GLPI, OTOBO и osTicket работают с мессенджерами через сторонние плагины и шины интеграций — n8n, Make, собственные прослойки. Если мессенджеры в требованиях — не пытайтесь вкрутить их в GLPI или osTicket «на коленке»; берите Chatwoot или ставьте Zammad плюс отдельный коннектор.

Active Directory и LDAP — мастхэв для корпоративных внедрений. Все пять систем поддерживают LDAP-аутентификацию и синхронизацию пользователей и групп. GLPI дополнительно умеет сопоставлять группы AD с профилями и сущностями, что критично для крупных холдингов с десятком юрлиц. Через SSO по SAML или OpenID Connect интегрируются Zammad, GLPI, Chatwoot и OTOBO; в osTicket SSO часто закрывают сторонними плагинами.

Мониторинг и эксплуатация — отдельный пласт. На своих проектах мы заводим тикеты из Zabbix и Prometheus прямо в систему поддержки, чтобы инциденты сразу попадали в общую очередь дежурной смены. GLPI здесь даёт ещё и Security Alerts Management и Antivirus Management, то есть критичные события из периметра попадают в тот же интерфейс, где работает оператор. Это упрощает реакцию первой линии и сокращает время на эскалацию.

Миграция между системами — самая болезненная часть. На наших проектах мы переносили базы из osTicket в Zammad и из OTRS в OTOBO. Базовые поля (тема, тело, автор, статус, история) переносятся скриптами или штатными утилитами. Кастомные поля, ссылки на активы, прикреплённые файлы и журналы изменений почти всегда требуют отдельной работы. Не закладывайте на миграцию меньше двух недель — мы сталкивались с проектом, где план «перенесём за выходные» растянулся на недели, и команда поддержки всё это время работала параллельно в двух системах.

Перед миграцией всегда снимайте полный дамп и тестируйте перенос на копии, а не на проде. Это очевидное правило, которое нарушают чаще, чем кажется.

Внедрение open-source тикет-системы редко проваливается из-за плохого продукта. Чаще ошибки лежат на стороне процессов, инфраструктуры и ожиданий. Соберём те, на которые мы натыкались сами или видели у заказчиков.

Первая ошибка — выбор системы «по красивым скриншотам». Команда внедряет Zammad, потому что у него современный интерфейс, не проверив, что для нормальной работы нужны Elasticsearch и Redis, а внутренний регламент запрещает ставить новые движки баз без согласования. В итоге система простаивает месяцами в ожидании согласования стека. Не делайте так — мы сталкивались с этим не раз. Сверяйте требования системы с тем, что у вас уже разрешено эксплуатировать, до начала пилота.

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

Третья ошибка — игнорировать обновления. Open-source системы регулярно выпускают патчи безопасности. Команды, которые ставят GLPI или osTicket «и забывают», через год обнаруживают, что отстают на несколько мажорных версий и обновление превратилось в проект на месяц. Закладывайте регламент обновлений сразу: тестовый стенд, окно для обновления, ответственный администратор.

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

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

Шестая ошибка — править исходники вместо плагинов. Каждое обновление превращается в ручной merge, и однажды команда просто останавливается на старой версии. Все доработки выносите в плагины, в API или в отдельные сервисы — пересборка должна оставаться штатной операцией.

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

Константин Тютюнник — ведущий инженер IT For Prof. Специализируется на внедрении self-hosted решений для ITSM и автоматизации процессов технической поддержки. Имеет опыт миграции крупных инфраструктур на open-source стек.