Zammad: современная open-source тикет-система на своём сервере

Корректная zammad установка становится критическим этапом для компаний, стремящихся отказаться от облачных сервисов в пользу защищённого контура. Zammad представляет собой веб-ориентированное решение с открытым исходным кодом для поддержки пользователей и обработки заявок, которое можно бесплатно развернуть на собственных серверах. Это обеспечивает полный контроль над данными и независимость от внешних провайдеров.

В отличие от маркетинговых обещаний, реальная ценность системы раскрывается через грамотную архитектуру развёртывания. Официальные пакеты доступны для CentOS, Debian и Ubuntu, а также предусмотрена поддержка Docker. Такой подход позволяет адаптировать инфраструктуру под высокие нагрузки, сохраняя прозрачность процессов и масштабируемость без скрытых лицензионных отчислений.

Zammad — это веб-ориентированная open-source система поддержки пользователей и обработки тикетов, которая закрывает функции service desk и helpdesk на собственном сервере без лицензионных платежей. На фоне трёх близких альтернатив — osTicket, GLPI и OTOBO — Zammad выделяется современным интерфейсом на Vue.js и встроенной омниканальностью, тогда как osTicket остаётся классической PHP-системой с акцентом на email-каналах, GLPI исторически сильнее в учёте оборудования и инвентаризации, а OTOBO продолжает линию OTRS с упором на ITIL-процессы.

По нашему опыту внедрения тикет-систем для отделов поддержки от небольших команд до сотен операторов выбор между этими четырьмя продуктами сводится к тому, какую боль клиент закрывает в первую очередь. Если требуется простой почтовый тикетинг без чатов и мессенджеров — osTicket развёртывается быстрее всех и не требует фоновых воркеров. Если ИТ-отдел одновременно ведёт парк техники, заявки на закупку и контракты — GLPI выигрывает за счёт CMDB и финансового модуля. Если в компании уже формализованы ITIL-процессы и нужны конфигурируемые workflow с глубокой настройкой ACL — OTOBO ближе по духу к корпоративному ITSM.

Zammad же закрывает сценарий, в котором поддержка приходит по разным каналам — почта, веб-форма, Telegram, Facebook, телефон — и требуется единая лента общения с клиентом плюс прозрачные SLA. На наших проектах мы выбирали Zammad именно тогда, когда клиент хотел отказаться от «зоопарка» из почтового ящика support@, чата в Telegram и Excel-таблицы с заявками. В отличие от osTicket, у Zammad есть полноценный поиск по тикетам через Elasticsearch и REST API, по которому удобно интегрироваться с внутренними системами. В отличие от GLPI, интерфейс не перегружен инвентарными вкладками и не требует длительного обучения операторов.

Коротко по технологическому стеку четырёх систем:

Важный отличающий момент — лицензия и стоимость владения. Zammad распространяется бесплатно при self-hosted установке, а платная подписка покрывает только облачную версию и техподдержку вендора. Это делает Zammad предсказуемым по бюджету решением: затраты ограничены сервером, администрированием и временем на zammad установка и поддержку. У клиента среднего размера мы считали трёхлетний TCO и получили цифры в несколько раз ниже, чем у проприетарного service desk сопоставимого класса.

Текущая мажорная ветка — Zammad 7.0: релиз вышел в марте 2026 года, актуальный патч 7.0.1 с исправлениями безопасности — в апреле 2026 года, и именно в 7.0 в helpdesk впервые добавили ИИ-функции (суммаризация тикетов, подсказки при ответе). Ветка 6.5 продолжает поддерживаться как консервативный вариант: она получает бэкпорт-патчи безопасности для тех, кто пока не готов к переходу на мажор. Для новых внедрений мы ставим 7.0.x, а 6.5 оставляем там, где обновление мажорной версии временно отложено.

Омниканальность в Zammad — это не маркетинговый термин, а реально объединённая лента: оператор видит email-переписку, сообщения из Telegram и записи звонков в одном тикете. У клиента с распределённой техподдержкой мы подключили четыре email-ящика, бот в Telegram и веб-форму на сайте — все обращения приземлялись в общую очередь, а правила маршрутизации раскидывали их по группам «Первая линия», «Серверы» и «1С». Это убрало ситуацию, когда клиент пишет в почту, потом дублирует в Telegram, а оператор не видит контекст.

SLA-движок строится на матрице «приоритет × категория × календарь». Можно задать график 8×5 для одних клиентов и 24×7 для VIP, прописать время реакции и время решения, настроить эскалации по почте и в чат руководителю. На наших проектах SLA в Zammad закрывают типовой запрос аудита: руководитель поддержки получает выгрузку «сколько тикетов нарушили SLA в этом месяце и по чьей вине» без сторонних BI-инструментов.

Автоматизация делится на триггеры (срабатывают на событие — создание тикета, смену статуса, ответ клиента) и планировщики (срабатывают по расписанию — например, закрыть тикеты без ответа клиента более семи дней). Через триггеры мы реализовали автоответ «получили обращение, номер такой-то», автоназначение тикетов с упоминанием «1С» на профильную группу и автоматическое повышение приоритета при ключевых словах «упал», «не работает», «срочно». Логика триггеров покрывает большинство сценариев без программирования; на оставшиеся есть webhooks и REST API.

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

Zammad запускается на Linux: официальные пакеты вендор собирает для CentOS, Debian и Ubuntu, а для других сценариев предлагает Docker-образ. Под macOS и Windows нативных пакетов нет — это сознательное решение вендора, и попытки запустить Zammad напрямую под Windows сводятся к WSL или виртуальной машине с Linux, что для продуктивной нагрузки мы не рекомендуем.

Под капотом у Zammad три внешних компонента: PostgreSQL для основной базы, Elasticsearch для полнотекстового поиска и Memcached/Redis для кэша. Само приложение — Rails-бэкенд с фоновыми воркерами и Websocket-сервером, плюс Vue.js-фронтенд. Из этого складываются базовые требования: для песочницы достаточно небольшой ВМ с парой ядер и несколькими гигабайтами ОЗУ, для продакшена с десятками операторов мы планируем больше памяти и отдельные диски, а для крупных установок выносим PostgreSQL и Elasticsearch на отдельные ноды.

По нашему опыту, чаще всего узким местом становится Elasticsearch, а не Rails. На одном из проектов клиент жаловался на медленный поиск по тикетам — выяснилось, что Elasticsearch крутится на минимальных ресурсах, индекс не помещается в память и постоянно вычитывается с диска. После расширения JVM heap и переноса Elasticsearch на отдельный SSD-диск время поиска по большому архиву тикетов сократилось на порядок.

Диск выбираем SSD или NVMe с запасом: база растёт за счёт вложений, особенно если в тикетах гуляют скриншоты и PDF. Для среднего helpdesk на пару лет вперёд берём диск с явным запасом, учитывая, что бэкап-копии и индексы Elasticsearch удваивают потребность.

Для пилотной инсталляции мы отталкиваемся от такого минимума:

• CPU: 4 vCPU;
• RAM: 8 ГБ;
• диск: 80 ГБ SSD, желательно отдельный том под /var/lib/elasticsearch;
• ОС: Ubuntu 22.04 LTS или Debian 12.

Не делайте моноблочную установку «всё на одной ВМ с минимальной памятью» — на наших проектах мы дважды наблюдали, как при росте нагрузки Elasticsearch выедает память, ядро убивает PostgreSQL по OOM, и Zammad падает целиком с потерей переписки за окно отказа. Минимальный продакшен — это либо одна ВМ с явным запасом памяти и swap-ом, либо контейнеры на одной ноде с заданными лимитами.

Сеть и сертификаты — обязательная часть планирования. Zammad должен ходить наружу к почтовым серверам, Telegram API и контроллеру домена для LDAP/AD, поэтому фаервол открываем заранее. HTTPS-сертификат через Let’s Encrypt или внутренний CA: без TLS не подключатся ни почтовые каналы, ни Single Sign-On.

Самый быстрый способ запустить Zammad на своём сервере — это Docker-инсталляция, которая упаковывает Rails-приложение, PostgreSQL, Elasticsearch и Memcached в готовый docker-compose.yml от вендора. На наших проектах zammad установка в Docker занимает порядка часа: примерно четверть времени уходит на подготовку ВМ, четверть — на скачивание образов и инициализацию, остальное — на настройку домена, TLS и первичную конфигурацию.

Перед запуском готовим Linux-хост. Подходит Ubuntu LTS, Debian или другой дистрибутив, который вендор поддерживает официально. На хосте ставим Docker Engine и плагин Compose из репозитория Docker, открываем порты 80 и 443, заводим DNS-запись helpdesk.example.com на IP сервера. Объём диска — с запасом под рост базы и резервные копии.

После поднятия стека первый старт тянет образы и запускает миграции базы — это несколько минут на нормальном канале. Когда все контейнеры в статусе running, открываем сервер в браузере по сервисному порту и проходим мастер первичной настройки: создаём админскую учётную запись, задаём название организации и базовый URL.

Перед выкаткой наружу обязательно ставим обратный прокси с TLS. По нашему опыту удобнее всего Nginx или Traefik на том же хосте: они терминируют HTTPS, проксируют HTTP-запросы и Websocket к контейнеру Zammad. Сертификат выпускаем через certbot или встроенный ACME-клиент Traefik. После переключения на HTTPS правим переменную окружения с базовым URL и перезапускаем стек, иначе вебсокеты для real-time обновлений тикетов работать не будут.

Сразу после первого запуска советуем: вынести тома PostgreSQL и Elasticsearch на отдельные named volumes или bind mount к каталогу с регулярным бэкапом, поднять лимиты памяти у Elasticsearch до уровня, при котором весь рабочий индекс помещается в JVM heap, поменять пароли всех служебных учёток, выключить регистрацию новых пользователей из публичной формы, если планируется только внутренний helpdesk.

Типовая ошибка первого запуска — забыть проверить часовой пояс. Zammad берёт время из контейнера, и если хост в UTC, а Zammad настроен на Europe/Moscow, SLA-таймеры считают неправильно. На одном внедрении мы потратили несколько дней на поиск причины, почему «нарушения SLA» появлялись за час до фактического срока, — оказалось, в docker-compose.yml не была проброшена переменная TZ. Проверяйте часовой пояс до того, как заведёте в систему живые тикеты.

Ниже — минимальная последовательность команд: клонируем официальный репозиторий вендора с docker-compose.yml, переходим в каталог и поднимаем стек.

Каналы в Zammad — это точки входа, через которые в систему попадают обращения. Без настроенных каналов Zammad бесполезен, поэтому на наших проектах сразу после первичной установки мы заводим минимум три: корпоративный email-ящик, бот в Telegram и веб-форму на сайте клиента. Аутентификация операторов привязывается к LDAP или Active Directory.

Email-канал поднимается за четверть часа. В разделе «Channels → Email» добавляем входящий аккаунт по IMAP или POP3 и исходящий по SMTP. Zammad сам проверит соединение, скачает тестовое письмо и предложит правила фильтрации. По нашему опыту, надёжнее всего работает IMAP с отдельным ящиком support@, который никем больше не читается, — иначе письма «исчезают» из Zammad, потому что кто-то читает их в Outlook и помечает как прочитанные.

Telegram-канал требует создать бота через @BotFather, скопировать токен и вставить его в Zammad. Дальше указываем имя группы, в которую попадают обращения, и пробуем написать боту от тестовой учётки. Один нюанс из практики: Telegram-API не отдаёт боту истории переписки, поэтому первое сообщение клиента должно начинаться командой /start. Мы заранее предупреждаем клиентов в инструкции, иначе техподдержка получает «пустые» тикеты без контекста.

Веб-форма генерируется в админке и встраивается на сайт через JavaScript-сниппет. Через форму удобно собирать заявки от клиентов без авторизации, а через iframe или встроенный чат-виджет — обращения от уже залогиненных пользователей с автоматической подстановкой контакта. На одном проекте мы вынесли форму на отдельный поддомен helpdesk.client.ru и настроили reCAPTCHA — поток спам-обращений упал с десятков в день до единичных в неделю.

LDAP и Active Directory подключаются как источники пользователей и группового маппинга. Указываем хост контроллера домена, базовый DN, сервисную учётку для bind и фильтр поиска. Zammad умеет периодически синхронизировать пользователей и переносить их членство в группах AD в свои роли. На клиентах с крупным штатом это закрывает половину работы администратора: новый сотрудник появился в AD-группе «IT Support» — на следующий день он автоматически получает доступ оператора в Zammad.

Не делайте одну ошибку, на которой мы дважды обжигались: не пускайте всех пользователей AD в Zammad без фильтра. Один раз клиент после первой синхронизации получил тысячи лишних пользователей в helpdesk-системе, и интерфейс начал тормозить из-за чрезмерных автодополнений. Правильно — узкий LDAP-фильтр на нужные OU или группы, чтобы синхронизировались только операторы и заявители, а не весь каталог.

Миграция с osTicket в Zammad — типовая задача, для которой у вендора есть встроенный мастер импорта. Он подключается к базе osTicket по реквизитам MySQL, считывает тикеты, пользователей, контрагентов и переносит их в Zammad с сохранением номеров и истории переписки. На нашем последнем проекте мы перенесли крупный архив тикетов и контактов за один вечер, без потери вложений.

Перед запуском мастера готовим обе системы. Старый osTicket переводим в режим «только чтение», предупреждаем операторов о паузе, делаем резервную копию MySQL-базы. На стороне Zammad ставим свежую установку нужной версии, причём желательно актуальной стабильной ветки, потому что мастер импорта стабильнее всего работает на поддерживаемой версии. После проверки бэкапа запускаем мастер и указываем доступ к базе osTicket.

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

С GLPI ситуация сложнее: единого встроенного импортёра у Zammad нет, потому что GLPI хранит данные с другой моделью (тикеты, проблемы, изменения и инвентарь связаны через assignations). Мы используем гибридный подход: пользователей и организации переносим через CSV-импорт, тикеты — через скрипт на REST API Zammad, который читает MySQL GLPI и создаёт тикеты с правильными датами и владельцами. Технически порядок переноса через REST API выглядит так:

1. экспорт оргструктуры и пользователей из источника;
2. создание организаций и пользователей в Zammad (POST /api/v1/organizations, /api/v1/users);
3. экспорт тикетов с метаданными и сообщениями;
4. создание тикетов и сообщений (POST /api/v1/tickets, /api/v1/ticket_articles);
5. загрузка вложений (/api/v1/attachments);
6. проверка контрольных сумм и количества записей.

Этот подход требует разработки, но даёт контроль над тем, что именно переносится и как сопоставляются категории.

По нашему опыту имеет смысл переносить только активные и закрытые за последние полгода-год тикеты. Архивные обращения за пять лет лучше оставить в read-only-копии старой системы: они почти никогда не открываются, но раздувают индекс и базу новой системы. Если требуется юридическое хранение — выгружайте старые тикеты в архивный CSV или PDF и храните отдельно от рабочего helpdesk.

Финальная фаза миграции — проверка и переключение. Мы открываем выборку случайных тикетов и сверяем содержимое с оригиналом: совпадает ли история сообщений, на месте ли вложения, корректен ли владелец. Только после этого меняем DNS-запись или адрес support@, чтобы новые письма приземлялись в Zammad. У клиента, который пропустил этап сверки, через месяц обнаружились десятки тикетов с обрезанной перепиской — пришлось докатывать импорт повторно по списку проблемных номеров.

Резервное копирование Zammad — это три согласованных дампа: PostgreSQL (метаданные и текст тикетов), файловое хранилище (вложения, если они не лежат в базе) и Elasticsearch-индекс (опционально, потому что его можно пересобрать из базы). Вендор поставляет скрипт zammad-backup, который мы запускаем по cron ежесуточно, а получившиеся архивы складываем на отдельное хранилище — лучше с дедупликацией и явно заданным сроком хранения.

На наших проектах правило простое: бэкап без проверки восстановления — это не бэкап. Раз в квартал мы поднимаем тестовый стенд из последнего архива и проверяем, что Zammad стартует и тикеты на месте. Один раз обнаружили, что у клиента бэкап PostgreSQL делался корректно, но в архиве не было каталога с вложениями — после восстановления тикеты открывались, а скачать прикреплённый PDF было нельзя. Внесли каталог в скрипт, перепроверили — заработало.

Обновление Zammad между минорными версиями выполняется штатно: для пакетных установок это обновление через системный пакетный менеджер, для Docker — смена тега образа в docker-compose.yml и docker compose pull && docker compose up -d. Между мажорными версиями, например при переходе на 7.0.1, читаем changelog: бывают миграции схемы базы данных, которые могут идти долго на больших инсталляциях, и обязательные шаги по переиндексации Elasticsearch.

Типовые ошибки эксплуатации, с которыми мы сталкивались в продакшене. Первая — переполнение диска под Elasticsearch-индексом. Если диск заканчивается, Elasticsearch переводит индексы в read-only, поиск отваливается, а Zammad начинает выдавать ошибки в фоновых задачах. Лечится расширением диска и снятием флага read_only_allow_delete с индекса. Профилактика — мониторинг свободного места и alert при заполнении выше порога.

Вторая ошибка — забытая ротация лога. Лог-файлы Zammad по умолчанию пишутся в production.log, и без logrotate за полгода они занимают многие гигабайты. Мы добавляем правило ротации с сжатием и хранением за последние недели.

Третья — игнорирование почтовых ограничений. Когда тикеты идут пачками, исходящий SMTP-сервер начинает резать соединения по rate limit. Лечится либо отдельным транзакционным SMTP-провайдером, либо настройкой delivery_method с очередью и ограничением скорости.

И последнее по списку, но не по важности — мониторинг очереди фоновых задач. У Zammad есть Scheduler и Background Jobs; если они не работают, тикеты создаются, но триггеры не срабатывают и SLA не считаются. Мы выводим длину очереди и статус последнего запуска планировщика в Prometheus, чтобы alert приходил до того, как клиент заметит отсутствие автоответов.

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

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