osTicket: простая бесплатная тикет-система на своём сервере

Развернуть osticket на своём сервере — это прямой способ получить контроль над потоком обращений без ежемесячных платежей за облачные сервисы. Для российских компаний, где требования к хранению данных строго регламентированы, самостоятельное размещение системы учета тикетов становится не только экономией, но и необходимостью. Инструмент позволяет маршрутизировать запросы, созданные через электронную почту, веб-формы и API, обеспечивая прозрачность работы службы поддержки.

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

osTicket — это open-source система тикетов для службы поддержки, которая разворачивается на своём сервере и заменяет в малых командах коммерческие helpdesk вроде Zendesk или Jira Service Management. Если вы сейчас принимаете заявки в общий почтовый ящик и обсуждаете их в чате, потолок виден быстро: письма теряются в треде, два инженера отвечают одному клиенту, статус заявки никто не помнит. osTicket закрывает именно эту дыру — превращает входящие письма, веб-формы и API-вызовы в очередь с номерами, статусами и ответственными.

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

Кому osTicket реально подходит, мы для себя сформулировали так: первый и второй уровень техподдержки, внутренний IT-helpdesk для офиса на 50–500 сотрудников, обработка обращений по гарантии и сервису. Базовые функции — портал клиента, фильтры маршрутизации заявок по отделам, настраиваемые темы помощи и SLA с учётом рабочих часов — закрывают около 80% типовых сценариев службы поддержки малой и средней компании.

Кому он не подходит — тоже скажем честно. Если вы хотите omnichannel с Telegram, WhatsApp и звонками из коробки, sales-pipeline и CRM-карточку клиента с историей сделок, единое окно для маркетинга, продаж и сервиса — osTicket для этого не задуман. На наших проектах, когда у заказчика появлялись эти требования, мы переходили на Zammad или OTOBO, а osTicket оставляли только там, где задача — «принять письмо, назначить инженера, закрыть заявку с историей переписки». В этом сегменте у него до сих пор лучшее соотношение «функции / нулевая стоимость лицензии».

osTicket — это связка PHP + MySQL/MariaDB, и самый быстрый способ поставить его «как надо» — взять контейнеры вместо ручной возни с веб-сервером и расширениями PHP. У нас на проектах docker-compose решает три проблемы сразу: одинаковая среда у разработки и продакшена, простой бэкап в виде каталога с томами и тривиальный откат на предыдущую версию образа. Если вам нужен osticket на своём сервере и при этом не хочется страданий с настройкой PHP-FPM руками — Docker это и есть короткий путь.

Минимальный compose, который мы используем как стартовую заготовку, выглядит так. Версии образов специально не указываем — берите актуальные теги community-образов osTicket и MariaDB на момент установки и фиксируйте их в своём compose явно:

Дальше — пароли в .env, docker compose up -d, и через минуту osTicket доступен на 127.0.0.1:8080. Наружу мы его никогда не пробрасываем напрямую — впереди ставим Nginx с TLS-сертификатом от Let’s Encrypt и проксируем по HTTPS. Открытый 80-й порт контейнера на внешний интерфейс — это первый шаг к компрометации админки.

Веб-инсталлер сам пройдёт по чек-листу: версия PHP, расширения, права на каталоги, доступ к БД. Главное — после установки удалить каталог setup (в наших образах он удаляется автоматически, но это первое, что мы проверяем) и сменить дефолтные права на include/ost-config.php, иначе апдейтер начнёт ругаться.

Бэкап в такой схеме — это mariadb-dump и копия каталога uploads. По нашему опыту, на компании в 50 сотрудников вся история тикетов за два года занимает меньше гигабайта и снимается за минуты, поэтому ночная задача cron с заливкой в S3-совместимое хранилище решает вопрос восстановления навсегда.

Из коробки osTicket разговаривает на английском, и для русскоязычной поддержки это первое, что мы меняем. Если оставить интерфейс агента на английском, клиенты будут получать письма с заголовками вроде «Ticket #123 created» и техническими шаблонами на двух языках одновременно — выглядит непрофессионально и порождает лишние вопросы «а это вообще от вас?».

Языковой пакет ставится через каталог include/i18n/: скачиваете архив ru.phar из раздела Languages на сайте проекта, кладёте в этот каталог внутри контейнера и обновляете список языков в админке. В нашем docker-compose мы для этого делаем bind-mount каталога i18n наружу — это позволяет не пересобирать образ при смене или обновлении пакета.

После этого в админке Admin Panel → Settings → System появляется русский в списке Primary Language, а в Settings → Agents — выбор языка интерфейса по умолчанию для новых агентов. Отдельно нужно зайти в свой профиль и переключить язык там же — параметр на уровне аккаунта перебивает системный, об этом регулярно забывают.

Первичную настройку администратора мы всегда делаем по одному и тому же списку, чтобы не возвращаться к ней через месяц. Имя компании и логотип — в Settings → Company, потому что они подставляются в шаблоны писем. Часовой пояс по умолчанию — в Settings → System, иначе SLA будет считаться по UTC и сроки разъедутся с реальностью. Политика паролей агентов — в Settings → Access: минимальная длина, срок жизни, ограничение по неудачным попыткам входа. И обязательно — двухфакторная аутентификация для всех агентов с правами администратора, по нашему опыту это единственное, что реально защищает от утечек учётных данных агентов.

Не делайте ошибку, которую мы видели у клиента: они оставили учётку admin с дефолтным логином и слабым паролем, портал был выставлен в интернет напрямую, и через две недели в системе появились «левые» агенты. Сразу после установки переименовываем основную учётку, заводим персональные аккаунты на каждого инженера и роль администратора выдаём минимум двум людям — иначе при увольнении одного админа вы остаётесь без доступа к собственной helpdesk-системе.

Главный канал для osTicket — почта. Система умеет читать входящие письма по IMAP/POP3 и отправлять ответы по SMTP, превращая каждое письмо в тикет. Если этот канал настроен криво, у вас два сценария: либо клиенты пишут в пустоту и думают, что их игнорируют, либо одна и та же заявка дублируется в трёх местах. Поэтому настройку почты мы делаем до того, как пустим клиентов на портал.

Под helpdesk мы всегда заводим отдельный почтовый ящик — например, support@company.ru — и ни в коем случае не используем личный ящик инженера. Причина простая: osTicket вычитывает письма из IMAP и помечает их как прочитанные или удаляет, и личная переписка владельца ящика начнёт «пропадать». Отдельный ящик ещё и упрощает разграничение прав.

Подключение делается в Admin Panel → Emails → Add New Email. Для большинства корпоративных почтовых провайдеров (Яндекс 360, VK WorkMail, Mail.ru для бизнеса, RuPost — корпоративная почта, заменяет Microsoft Exchange) схема одинаковая: IMAP с SSL на стандартном порту провайдера, аутентификация по логину и паролю приложения, fetch interval — 5 минут как разумный компромисс между скоростью реакции и нагрузкой. Если провайдер поддерживает OAuth2 — берите его, пароли приложений всё ещё работают, но утекают чаще.

Эту команду мы вешаем на cron внутри контейнера каждые 5 минут — она вытаскивает почту и обрабатывает отложенные действия. Не полагайтесь на встроенный «autocron» по визитам в админку: если ночью никто не зайдёт в систему, утренние письма будут лежать необработанными до первого логина.

SMTP настраивается отдельно от IMAP, и здесь чаще всего ошибаются. Если SPF/DKIM/DMARC для домена company.ru не настроены, ответы от osTicket поедут клиентам в спам, и вы будете долго гадать, почему «они нам не отвечают». Перед запуском мы прогоняем тестовое письмо через mail-tester.com и подтягиваем все три записи до зелёного — это разовая работа на 30 минут, которая снимает половину будущих обращений «вы мне не ответили».

Автоответ — это шаблон «Ваше обращение №%{ticket.number} зарегистрировано, ответим в течение X часов». Полезно, но с условием: отключайте автоответ для системных адресов (noreply@, mailer-daemon@, рассылки) через фильтры тикетов, иначе попадёте в петлю автоответов с чужими автоматами и ваш домен быстро улетит в чёрные списки.

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

Начинаем с отделов (Departments). Это организационные ведра — «Поддержка», «Биллинг», «Эксплуатация», «Разработка». В каждом отделе свой набор агентов, свой ответственный за SLA менеджер и свой шаблон писем. По нашему опыту, 3–5 отделов хватает почти любой компании до 200 сотрудников — больше превращается в зоопарк, в котором заявка неделю гуляет между отделами «не наше».

Темы помощи (Help Topics) — это то, что видит клиент в форме на портале: «Не работает интернет», «Вопрос по счёту», «Запрос на доступ». Каждая тема привязывается к отделу и SLA-плану, и это ваша точка автоматизации: правильно собранный список тем экономит инженерам 30–40% времени на классификацию заявок. Не делайте 50 тем сразу — начните с 8–10, через месяц посмотрите на статистику и добавьте недостающие.

SLA-планы настраиваются в Manage → SLA Plans и оперируют рабочими часами, заданными в Settings → System → Default Schedule. Это критичная деталь: если рабочие часы заданы 9:00–18:00 будни, то заявка с SLA 4 часа, пришедшая в пятницу в 17:00, будет просрочена не в 21:00 того же дня, а только в понедельник к 12:00. Мы видели проекты, где SLA по ошибке считали в календарных часах, и команда выгорала, бегая по ночным просрочкам, которых на самом деле не было.

Фильтры тикетов (Ticket Filters) — это правила «если письмо пришло от домена @bigclient.ru, поставь приоритет High, отдел Поддержка, тему Premium, назначь на Иванова». Они применяются в порядке, заданном вручную, и срабатывает первый подошедший — это та грабля, на которую новички наступают чаще всего. Если фильтр «всё с @bigclient.ru → High» стоит выше фильтра «темы со словом billing → отдел Биллинг», то премиум-клиенты со счетами будут попадать не туда. Порядок фильтров проверяйте после каждой правки.

Поверх этого мы строим автоматические уведомления менеджеру при приближении к 80% SLA — простая настройка, которая закрывает 90% «ой, мы забыли» в среднем helpdesk.

osTicket на своём сервере — это не «поставил и забыл», и мы предпочитаем сказать об этом сразу, чем услышать через год «нас взломали». Раз в квартал команда Enhancesoft выкладывает обновления с заплатками безопасности и исправлениями, и пропускать их — значит держать публичный портал с известными дырами.

Сценарий обновления, который мы используем, проходит за 15 минут и опирается на три вещи: бэкап до, бэкап до, и ещё раз бэкап до. В Docker-схеме это выглядит так:

После апгрейдера обязательно заходим в Admin → Dashboard и смотрим версию в правом нижнем углу. Если она не сменилась — апгрейд не прошёл, ищите ошибку в логах контейнера (docker compose logs app), типовая причина — недостаточные права на include/ost-config.php или незавершённая миграция БД.

Бэкап БД сам по себе бесполезен, если вы его ни разу не разворачивали. Раз в полгода мы поднимаем staging из последнего бэкапа на отдельном сервере и проверяем, что он действительно восстанавливается. На одном из проектов клиент год исправно делал дампы, а когда диск физически отказал, выяснилось, что cron-скрипт писал пустые файлы — никто не проверял размер. Минимальная проверка: gunzip -t backup-*.sql.gz в том же cron, и алёрт, если размер дампа уменьшился больше чем на 10% по сравнению со вчерашним.

Типичные грабли, на которые мы регулярно наступаем сами или наблюдаем у клиентов. Первая — забытый автозапуск cron. osTicket требует регулярного запуска api/cron.php, без него отвалятся почта, эскалации и просрочки SLA. Вторая — открытый scp файла ost-config.php или его попадание в git. В этом файле лежит ключ шифрования вложений, утечёт он — утекут все приложенные документы. Третья — отсутствие лимита на размер вложений. По умолчанию в PHP стоят разумные значения, но если ваш php.ini или nginx разрешают загрузку 100 МБ, клиенты быстро превратят helpdesk в файлообменник, и диск кончится в самый неподходящий момент.

И последняя — не накапливайте closed-тикеты без архивации. На дистанции в 3–5 лет таблица ost_thread_entry распухает до миллионов строк и интерфейс начинает тормозить. Раз в год переносим закрытые тикеты старше двух лет в архивную базу и оставляем только ссылку «открыть в архиве».

osTicket — отличный инструмент для своей ниши, но у него есть потолок, и мы научились распознавать его заранее, чтобы клиент не оказался в ситуации «мы вложили два года в настройку, а оно нам уже не подходит». Если вы держите osticket на своём сервере и узнаёте себя в одном из трёх сценариев ниже — пора смотреть на Zammad или OTOBO. Эти варианты мы подробно свели в сравнении open-source тикет-систем.

Первый сигнал — потребность в omnichannel. Если поддержка ведётся не только по почте и веб-форме, но и в Telegram, WhatsApp, чате на сайте и звонками, и вы хотите видеть всю историю общения с клиентом в одной карточке — osTicket этого не закроет. Zammad — open-source helpdesk немецкой разработки — изначально спроектирован под мультиканальность, и интеграции с мессенджерами там идут из коробки. Мы переезжали на него клиентов, у которых половина обращений приходила в Telegram, и osTicket мог дать только костыль через email-gateway.

Второй сигнал — корпоративные процессы по ITIL: change management, problem management, configuration management database. Если ваш IT-отдел созрел до того, что инциденты, проблемы, изменения и активы нужно вести как отдельные сущности с workflow и согласованиями — это территория OTOBO. OTOBO — open-source форк OTRS Community Edition, который активно развивается после ухода OTRS в коммерцию, и он покрывает ITSM-сценарии, под которые osTicket даже не задумывался.

Третий сигнал — масштаб. У osTicket нет официальных жёстких лимитов, но по нашему опыту порог комфортной работы — примерно 10–15 агентов и 200–300 тикетов в день. Дальше начинаются эксплуатационные неудобства: интерфейс не оптимизирован под массовые операции, аналитика беднее, чем хотелось бы менеджеру, а кастомизация workflow упирается в редактирование шаблонов вручную. Если вы видите, что ваш helpdesk растёт по этим метрикам, миграцию лучше планировать заранее, чем экстренно через полгода.

Простой критерий, которым мы пользуемся при аудите: посчитайте, сколько часов в месяц команда тратит на ручные обходы ограничений системы — массовое назначение, перевод между отделами, выгрузку отчётов в Excel и склейку их вручную. Если набирается больше 20–30 часов в месяц — стоимость этих часов уже окупает миграцию на более подходящий инструмент. Если меньше — osTicket остаётся рациональным выбором, и за бесплатность с такой функциональностью на рынке self-hosted helpdesk до сих пор сложно найти альтернативу.

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

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