Znuny и Zammad выросли из одного корня, а чинить их приходится по-разному

MAATRIX

Если вы искали self-hosted helpdesk и наткнулись сразу на Znuny и Zammad, у вас закономерно возникло ощущение дежавю — обе системы говорят на языке OTRS, обе решают одну задачу, а сообщество вокруг них частично пересекается. Но за похожими словами «тикет», «очередь», «SLA» стоят два разных технологических стека, и цена ошибки в выборе — это не «привыкнуть к другому интерфейсу», а месяцы администрирования системы, которая плохо ложится на ваши процессы. Разберём, что на самом деле общего у Znuny и Zammad, а что — принципиально разное на уровне архитектуры и повседневной эксплуатации.

Откуда родом Znuny и почему это не Zammad с другим логотипом

Корень действительно один — проект OTRS, один из первых заметных open-source helpdesk-систем, вокруг которого в 2000-х выросло целое сообщество администраторов техподдержки. Дальше пути разошлись, и разошлись они по-разному, чем кажется на первый взгляд.

Znuny — это буквальный форк кода OTRS. Когда компания-разработчик OTRS сменила модель лицензирования и часть функциональности новых версий стала закрытой (open-core), команда, много лет сопровождавшая OTRS-инсталляции у клиентов, взяла последнюю свободную GPL-версию и продолжила её развивать как самостоятельный проект. Это значит, что структура базы данных, логика SysConfig, консольные скрипты, ACL, процессы (ProcessManagement) — всё это прямое продолжение кодовой базы OTRS с исправлениями и постепенными улучшениями поверх. Если вы администрировали OTRS пять лет назад, в Znuny вы узнаете почти всё.

Zammad — история сложнее. Его начинал один из людей, стоявших у истоков OTRS, но не как форк, а как проект с нуля на другом языке и с другой философией: меньше настроек через недра конфига, больше — через понятный UI; упор на многоканальность (почта, чат, телефония, мессенджеры) как на равноправные каналы, а не надстройку. Общий — только генезис идеи и отчасти терминология («тикет», «очередь» → «группа»), но не строчка кода.

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

Стек технологий: Perl против Ruby на практике

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

Для администратора это выливается в разное количество процессов, которые нужно держать живыми. Znuny в минимальной конфигурации — это Apache с mod_perl и СУБД, всё. Zammad — уже связка из нескольких systemd-юнитов: zammad-web, zammad-websocket, zammad-scheduler, плюс PostgreSQL, Redis и обычно Elasticsearch. Больше движущихся частей — больше поводов заглянуть в статью о частых ошибках Zammad на сервере, где разобраны типичные сбои Elasticsearch и очереди сообщений.

С другой стороны, Perl-стек Znuny — это код, которому больше пятнадцати лет истории, и специалистов, свободно читающих Perl 5 с наследием mod_perl, на рынке заметно меньше, чем Ruby-разработчиков. Если у вас нет штатного администратора, который спокойно полезет в Kernel/Config.pm руками, разница в пороге входа ощутима не в пользу Znuny.

Установка и первый запуск

На бумаге оба продукта устанавливаются «в несколько команд», но реальность отличается количеством зависимостей, которые нужно свести воедино вручную.

Znuny разворачивается классическим для Perl-проектов способом: скачивается архив с исходниками, распаковывается в рабочую директорию, а зависимости — модули CPAN — либо ставятся системным пакетным менеджером, либо через cpanm по списку из bin/znuny.CheckModules.pl. После распаковки нужно вручную настроить виртуалхост Apache с mod_perl, прописать алиасы под /otrs-web/ (это имя каталога — тоже наследие, часто сохраняется даже после ребрендинга в Znuny), выставить права через bin/znuny.SetPermissions.pl и инициализировать базу через веб-установщик или консольный скрипт:

bin/znuny.Console.pl Maint::Config::Rebuild
bin/znuny.Console.pl Maint::Cache::Delete

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

Zammad, наоборот, изначально проектировался с прицелом на быстрый деплой: официальный apt/yum-репозиторий ставит пакет целиком со всеми зависимостями за один проход, а для контейнерного варианта есть официальный docker-compose.yml, который поднимает веб, websocket, scheduler, PostgreSQL, Redis и Elasticsearch одним docker compose up -d. Мы разбирали этот файл построчно в статье «Zammad в Docker Compose: готовый файл», а пошаговую установку без контейнеров — в материале «Как установить и настроить Zammad на VPS». Дальше система входит в мастер первичной настройки в браузере: домен, часовой пояс, первый агент — и через несколько минут можно принимать тикеты.

Итог по разделу простой: если вы цените предсказуемость классической LAMP/Perl-инсталляции и готовы один раз аккуратно настроить Apache — Znuny не сложнее любого другого legacy-приложения. Если вы хотите от установки до первого тикета дойти за один вечер без чтения списков CPAN-модулей — Zammad практичнее именно на этом этапе.

Тикеты, очереди и автоматизация: разная философия

Здесь расхождение не техническое, а концептуальное, и оно определяет, насколько система впишется в уже сложившиеся у вас процессы поддержки.

Znuny — наследник модели OTRS, построенной вокруг жёсткой иерархии: очереди (Queues) с правами доступа, состояния тикетов (states) и типы (types) как отдельные, тонко настраиваемые сущности, ACL-правила, блокирующие действия по десяткам условий, и полноценный ProcessManagement — конструктор бизнес-процессов с шагами и переходами, похожий на упрощённый BPMN. Вся эта гибкость живёт в SysConfig — огромном дереве настроек, которое одновременно и сила системы, и источник частой боли новичков: найти нужный переключатель среди множества похожих непросто, а неверное значение может тихо сломать неочевидную часть логики.

Zammad сознательно упростил модель: вместо жёсткой связки «очередь + состояние + тип» — группы (Groups) как единица доступа, теги для гибкой классификации, триггеры (Triggers) как условие-действие для автоматизации попроще, и вебхуки для интеграций со внешними системами. Это менее гибко на уровне сложных многошаговых процессов, зато прозрачнее для рядового агента поддержки: правила автоматизации читаются как «если тема письма содержит X и группа — Billing, то...», без необходимости лезть в отдельный модуль конфигурации.

Практическое следствие: если у вашей поддержки уже выстроен сложный процесс с эскалациями, SLA по нескольким уровням и жёсткими правами доступа между отделами — Znuny даёт для этого готовый, проверенный временем инструментарий. Если процесс проще («принял — обработал — закрыл», с акцентом на скорость ответа и многоканальность), усложнение Znuny просто не окупается, и Zammad закрывает задачу с меньшими трудозатратами на настройку.

Миграция данных между Znuny и Zammad

Вот здесь общий корень скорее мешает, чем помогает: интуитивно кажется, что раз обе системы «про тикеты и OTRS-наследие», перенести данные между ними просто. На практике готового мигратора «из коробки» в обе стороны нет, и вот почему.

Структуры БД несовместимы напрямую. У Znuny (как и у OTRS) тикет, статьи (сообщения внутри тикета), вложения и история изменений хранятся в схеме MySQL/PostgreSQL, спроектированной под Perl-модель объектов OTRS — с таблицами вроде ticket, article, ticket_history, dynamic_field_value и отдельным хранением динамических полей. У Zammad — своя схема Rails-приложения (ActiveRecord), с иной нормализацией и, что важно, обязательной интеграцией с Elasticsearch для индексации содержимого. Прямой SQL-перелив таблиц не сработает: имена полей, типы связей, кодировка динамических атрибутов — всё разное.

Реалистичные пути миграции, если вам нужно перейти с одной системы на другую:

• Через API. Обе системы предоставляют REST API (у Znuny — классический OTRS-совместимый Generic Interface, у Zammad — современный REST API с токенами). Пишется скрипт, который вытягивает тикеты постранично из системы-источника (клиент, тема, статьи, вложения, метки времени) и создаёт эквивалентные тикеты через API системы-приёмника. Это самый гибкий вариант, но требует ручного маппинга полей: у вас почти наверняка не совпадут один в один статусы, приоритеты и кастомные поля, и часть смысловой нагрузки (например, тонкая ACL-логика Znuny) при переносе в Zammad просто некуда деть — придётся решать, упрощать её или эмулировать тегами.
• Через email-архив. Если для вас критична не вся история взаимодействия, а само содержание переписки, можно экспортировать письма тикетов в формате .eml/mbox и импортировать их в новую систему как новые обращения — вы теряете внутреннюю структуру (кто кому эскалировал, служебные заметки агентов), но сохраняете суть переписки с клиентом.
• Оставить старую систему read-only архивом. Часто практичнее не мигрировать историю вообще, а поднять старую Znuny/Zammad-инсталляцию в режиме «только для чтения» на отдельном поддомене для справки, а новую систему начать с чистого листа — особенно если вы переходите не из-за истории тикетов, а из-за неудобства процесса.

Отдельно про вложения: в Znuny файлы могут храниться либо прямо в БД, либо на файловой системе — это настраивается через ArticleStorage в конфиге. В Zammad вложения по умолчанию тоже идут в БД, но их можно вынести на файловую систему или в S3-совместимое хранилище. При миграции важно заранее понять, где физически лежат файлы в системе-источнике, иначе скрипт миграции скачает пустые заглушки вместо реальных вложений.

Если решаете, что мигрировать вообще не будете, а начинаете с нуля на Zammad — рекомендуем сразу прикинуть требования по ресурсам, мы разбирали их в статье «Сколько RAM нужно для Zammad».

Ресурсы, производительность и кому что подходит

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

Znuny на Perl+mod_perl при небольшом числе одновременных агентов (условно, до нескольких десятков) обычно ощутимо экономнее по памяти — за счёт отсутствия Elasticsearch и Redis как обязательных компонентов. Узкое место чаще возникает не в базовой работе, а при полнотекстовом поиске по большому архиву: встроенный поиск по SQL на десятках тысяч записей заметно медленнее, чем индекс Elasticsearch в Zammad.

Zammad тяжелее по базовому footprint именно из-за Elasticsearch — это отдельная JVM-машина с заметным аппетитом к памяти вне зависимости от числа тикетов, и это фиксированные накладные расходы. Технически Elasticsearch можно отключить, но тогда теряется часть функциональности поиска и индексации вложений, ради которой многие Zammad и выбирают.

С точки зрения профиля команды поддержки, ориентиры такие:

• Znuny подходит, если у вас уже отлажен сложный многоуровневый процесс поддержки (несколько линий эскалации, разные SLA по типам клиентов, жёсткие права между отделами), если в штате есть человек, готовый разбираться в Perl-стеке и SysConfig, и если экономия ресурсов сервера важнее скорости и современности интерфейса. Также логичный выбор, если вы или ваша команда уже администрировали OTRS и не хотите переучиваться с нуля.
• Zammad подходит, если поддержка ведётся по нескольким каналам одновременно (почта + чат на сайте + мессенджеры) и вам важно видеть их в одном интерфейсе, если в команде нет отдельного Perl-администратора, и если приоритет — быстрый онбординг новых агентов через понятный UI, а не тонкая настройка бизнес-процессов.

Отдельный практический момент: обе системы одинаково требовательны к тому, чтобы почта заводилась и уходила без сбоев — учитывая, что helpdesk чаще всего работает поверх email как основного канала, стоит заранее продумать SPF/DKIM/DMARC для домена поддержки и не экономить на этом этапе, независимо от того, какую из систем вы выберете.

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