Request Tracker: почему его до сих пор не сняли с прода

MAATRIX

Каждые несколько лет кто-то из новых сотрудников открывает интерфейс Request Tracker, морщится и спрашивает: «а почему мы до сих пор не переехали на что-то нормальное?». А потом узнаёт, что через эту систему пять лет проходит вся переписка с клиентами, ACL настроены под десяток отделов, и любое «просто переехать» — это проект на несколько месяцев с риском потерять историю. RT не держится в проде по инерции — у него есть конкретные причины оставаться там, и не менее конкретные причины, по которым от него стоит избавляться. Разберём обе стороны без религии.

Кто такой Request Tracker и откуда он такой старый

Request Tracker (RT) — открытая система тикетов, написанная на Perl компанией Best Practical Solutions, которую основал Джесси Винсент. Первый релиз вышел ещё в 1996 году, то есть система старше большинства современных helpdesk-платформ на десятилетия. За это время вышло несколько крупных веток: RT3, RT4 (с долгоживущей подверсией 4.4, которая годами оставалась стандартом де-факто), и текущая RT5, куда перенесли часть возможностей, раньше существовавших только как отдельные расширения — например, учёт активов (Assets) стал частью ядра.

Держат RT в проде обычно те, у кого тикеты — это не столько «модуль поддержки», сколько рабочий процесс, завязанный на почту: хостинг-провайдеры и интернет-провайдеры, внутренние ИТ-службы крупных организаций, NOC-команды телекома, университетские службы поддержки. У всех этих сценариев общая черта — заявки в основном приходят по email, объём предсказуемый, а правила маршрутизации и эскалации сложные и годами отлаженные. Именно под такие сценарии RT изначально и проектировался.

Почему от него не отказываются: стабильность и предсказуемость

Первая причина живучести RT — это движок обработки почты. rt-mailgate принимает письмо, парсит заголовки, находит тред по In-Reply-To/References или по метке в теме, создаёт или обновляет тикет — и делает это устойчиво даже на кривых письмах от старых корпоративных серверов, с битой кодировкой или вложениями нестандартного вида. Если веб-интерфейс временно недоступен, почта всё равно продолжает копиться в очереди MTA и обработается, как только сервис поднимется — тикеты не теряются.

Вторая причина — гранулярность прав доступа. ACL в RT настраиваются на уровне очереди, группы и даже отдельного действия («видеть тикет», «отвечать публично», «менять владельца», «видеть внутренние комментарии»). Права можно наследовать через группы, комбинировать ролями Owner/AdminCc/Requestor — и для организаций с десятками отделов и разным уровнем допуска к переписке это ровно та гибкость, которую в современных helpdesk-системах часто приходится собирать из костылей или платных тарифов.

Третья причина — скрипы (scrips). Это механизм «условие → действие», который срабатывает на события жизненного цикла тикета: создание, изменение статуса, ответ клиента, истечение SLA. Через UI можно собрать довольно сложную логику эскалаций, автоматических назначений и уведомлений без единой строчки кода — а если условий стандартных не хватает, пишется кастомный Perl-модуль, который живёт в системе годами без переписывания, потому что менять его особо не приходится: правила бизнеса меняются реже, чем модные UI-тренды.

Наконец — предсказуемость релизов. Best Practical не гонится за частыми редизайнами. Обновления выходят взвешенно, с предупреждениями о депрекейтах заранее, а не «сюрпризом» в мажорной версии. Для админов, которые обслуживают систему параллельно с десятком других задач, это осознанный плюс: RT не заставляет переучиваться заново каждые полгода.

Экосистема расширений — актив, а не пассив

За без малого три десятилетия вокруг RT накопилась библиотека расширений в пространствах имён RT::Extension::* и RTx::* на CPAN. Часть из них стала настолько востребованной, что перекочевала в ядро RT5 — так случилось с учётом активов (раньше RTx::AssetTracker, теперь встроенные Assets). Другие остаются отдельными пакетами, но настолько зрелыми, что воспринимаются как часть стандартного стека:

• RT::Extension::SLA — учёт и эскалация по соглашениям об уровне обслуживания, с разными правилами по очередям и приоритетам.
• RT::Authen::ExternalAuth — аутентификация через LDAP/Active Directory или внешний SSO, что критично для организаций с уже существующим каталогом пользователей.
• RT::Extension::REST2 — современный (по меркам RT) JSON REST API для интеграций, пришедший на смену неудобному текстовому REST1 из веток RT3/RT4.
• RT::Extension::CommandByMail — управление тикетом прямо из тела письма-ответа, без захода в веб-интерфейс.
• Кастомные поля произвольных типов (Combobox, дата/время, IP-адрес, ссылка на другой тикет) — позволяют не городить отдельную базу для метаданных заявки.

Ключевой момент: многие организации годами пишут собственные локальные расширения и оверлеи (local overlays) под свою специфику — форму заявки, интеграцию с внутренней CRM, нестандартную маршрутизацию. Это накопленный актив, который при миграции на другую систему придётся переписывать с нуля, и именно это — а не любовь к устаревшему интерфейсу — чаще всего держит компании на RT дольше, чем им бы хотелось.

Обратная сторона: часть расширений на CPAN не обновлялась годами, и перед установкой стоит проверять, тестировали ли их с вашей веткой RT — иначе можно сломать апгрейд из-за несовместимого расширения, а не из-за самого ядра.

Что реально устарело — без прикрас

Честно: интерфейс RT выглядит так, как будто застрял где-то между 2008 и 2012 годом. RT5 подвинул тему («Prometheus»), сделал вёрстку чуть аккуратнее и адаптивнее, но по духу это всё ещё классическая серверная генерация страниц на Mason-шаблонах, а не современное SPA с живыми обновлениями. Мобильный UX слабый — работать с тикетами с телефона неудобно, и это ощутимо контрастирует с современными helpdesk-продуктами, которые изначально проектировались под адаптивный интерфейс и push-уведомления.

Стек тоже тянет технический долг. RT — это Perl-приложение, которое запускается через mod_perl, FastCGI или современный вариант — Plack/Starman за обратным прокси. При переезде на новую версию ОС часто всплывает classic Perl dependency hell: нужные версии CPAN-модулей приходится ставить через cpanm с local::lib, чтобы не конфликтовать с системным Perl. Формально процесс документирован и решаем, но требует администратора, который спокойно читает Perl-трейсбеки — а таких специалистов на рынке год от года меньше, и это реальный риск bus factor: система жива, пока жив человек, который умеет её чинить.

Мультиканальность из коробки — тоже слабое место. RT спроектирован вокруг email, и живой чат на сайте, интеграция с мессенджерами или соцсетями требуют либо стороннего моста, либо самостоятельной разработки. Современные helpdesk-системы вроде Zammad изначально собраны как омниканальные — почта, чат, телефония и соцсети сходятся в одну очередь без дополнительной сборки. Если разобраться, как устанавливается Zammad на VPS, разница в подходе видна сразу: там мультиканальность — часть архитектуры, а не надстройка.

Полнотекстовый поиск в RT тоже не встроен по умолчанию — для приличного поиска по телу тикетов нужен внешний индексатор (Sphinx или Xapian через `RT::Extension::FullTextSearch»), тогда как часть современных систем поставляется с Elasticsearch «из коробки» — правда, ценой заметно большего аппетита к памяти, о чём стоит помнить, если сравнивать варианты по совокупной стоимости.

Установка и требования в 2026: с чем реально столкнётесь

Если вы разворачиваете RT сегодня, путей два. Первый — пакет из репозитория дистрибутива (в Debian/Ubuntu исторически присутствовал пакет request-tracker4, для RT5 актуальность пакета в конкретном релизе дистрибутива стоит проверять отдельно — версия в репозитории почти всегда отстаёт от актуальной ветки Best Practical). Второй, более предсказуемый путь для RT5 — установка из исходников с сайта Best Practical: perl Makefile.PL, затем make testdeps (покажет, каких Perl-модулей не хватает), make fixdeps (попытается доустановить через CPAN/cpanm), make install, и в конце rt-setup-database для инициализации схемы.

Из баз данных поддерживаются MySQL/MariaDB и PostgreSQL — выбор чаще всего диктуется тем, что уже эксплуатируется в инфраструктуре, RT одинаково хорошо работает с обеими. Веб-часть сегодня разумнее поднимать через rt-server (обёртку над Plack/Starman) за Nginx как обратным прокси с терминацией TLS — это проще в обслуживании, чем классическая связка mod_perl внутри Apache, хотя она тоже продолжает поддерживаться.

Конфигурация задаётся в RT_SiteConfig.pm (обычно /opt/rt5/etc/RT_SiteConfig.pm при установке из исходников) — важно не редактировать RT_Config.pm с дефолтами напрямую, а переопределять нужные параметры именно в SiteConfig, иначе правки потеряются при обновлении. Почтовый шлюз подключается через алиас в Postfix или procmail-правило, которое пайпит письмо в rt-mailgate с указанием очереди и адреса RT.

По требованиям к ресурсам RT в целом легче, чем можно ожидать от системы с четвертьвековой историей: это, по сути, пул Perl-воркеров плюс СУБД, без обязательного отдельного поискового кластера. Для сравнения — сколько RAM нужно Zammad: там сама архитектура из пяти-шести сервисов (включая часто обязательный Elasticsearch) съедает заметно больше памяти на сопоставимую нагрузку. Это не довод «RT лучше», а честный компромисс: меньше сервисов и памяти в обмен на менее богатый UX и отсутствие мультиканальности из коробки.

Когда миграция не оправдана, а когда давно пора

Миграция чаще всего не оправдана, если у вас:

• Годы истории тикетов, скрипов и ACL, тонко настроенных под структуру организации — переезд означает не перенос данных, а фактически пересборку бизнес-логики на новой платформе.
• Регулируемая или аудируемая среда, где изменение процесса обработки заявок само по себе требует согласований и рискует нарушить комплаенс.
• Небольшая, но компетентная команда, которая уверенно администрирует Perl-стек и не испытывает проблем с интерфейсом — им RT просто не мешает работать.
• Основной канал — email, а не чат/соцсети, и текущий объём заявок не требует омниканальности.
• Глубокая интеграция RT с внутренними системами через REST API и почтовый шлюз, разрыв которой стоит дороже, чем неудобный интерфейс.

Миграция, напротив, давно назрела, если:

• Команда поддержки растёт, новым агентам тяжело онбордиться в интерфейс из прошлого десятилетия, и это ощутимо замедляет наём.
• Бизнесу нужны живой чат на сайте, обращения из мессенджеров и соцсетей в одной очереди — а не набор отдельных инструментов вокруг RT.
• Человек, который держал систему на себе и разбирался в Perl-внутренностях, уволился или скоро уволится — и bus factor уже не гипотетический риск, а реальность.
• Нужны современные дашборды и отчётность из коробки, без ручной сборки через SQL-репорты или сторонние BI-надстройки.
• Вы сравнивали Zammad и FreeScout и понимаете, что за те же деньги на сервер получаете современный стек с активным сообществом — тогда вопрос действительно в цене миграции, а не в принципиальной невозможности жить без RT.

Стоит и не пытаться натягивать одно решение на всё: если у вас несколько разных потоков заявок — например, тяжёлый внутренний ИТ-хелпдеск с жёсткими ACL и параллельно лёгкая линия поддержки клиентов через чат — иногда разумнее держать RT для первого сценария и поставить рядом более лёгкую систему вроде osTicket для второго, чем пытаться выжать из одной платформы несовместимые требования.

Как выглядит путь миграции, если решение принято

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

1. Выгрузить данные из RT через REST2 API (тикеты, переписку, вложения, custom fields) в промежуточный формат, а не пытаться писать прямой SQL-дамп из внутренней схемы RT — она не документирована как стабильный публичный контракт и меняется между версиями.
2. Спроецировать очереди RT на аналог целевой системы (у Zammad это группы и/или теги), и заранее решить, что делать с полями, для которых прямого соответствия нет — где-то придётся смириться с потерей части метаданных.
3. Держать старую и новую систему в параллельном режиме на переходный период: новые тикеты сразу в новой системе, к старым — доступ только на чтение через сохранённый RT в режиме архива.
4. Переключать почтовые адреса (support@, алиасы очередей) на новый шлюз постепенно, по одному адресу, с проверкой каждого потока — это тот момент, где чаще всего теряются письма при поспешной миграции.
5. Не выключать старый RT сразу — оставить его доступным в read-only ещё на несколько месяцев, пока не убедитесь, что вся нужная история перенесена и никто не полез в архив за старым тикетом, которого не оказалось в новой системе.

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