Zammad в проде: бэкапы, обновления, безопасность и своя LLM

Модель угроз: в тикетах — самое чувствительное

В предыдущих статьях серии я разбирал, чем хорош Zammad как бесплатный service desk, показывал установку в Docker и настраивал интеграции с Telegram, почтой и Active Directory. Система развёрнута, заявки идут — и вот тут начинается самое интересное. Поставить helpdesk — это процентов десять работы. Остальные девяносто — прожить с ним несколько лет так, чтобы ни один тикет не потерялся, ни одно вложение не утекло и ни одно обновление не положило систему в разгар рабочего дня. Про эти девяносто процентов и статья: регламент, по которому мы в ITfresh сопровождаем Zammad-инсталляции клиентов.

Начну с неудобной мысли, которую я проговариваю каждому клиенту на старте. База тикетов через год эксплуатации — одно из самых чувствительных хранилищ данных в компании. Смотрите сами, что там оседает: полная переписка с клиентами и сотрудниками, сканы договоров и актов во вложениях, ФИО, телефоны и почта людей — то есть персональные данные в чистом виде. А ещё пользователи, как бы вы их ни воспитывали, регулярно присылают пароли открытым текстом прямо в тело заявки: «не могу зайти, логин такой-то, пароль такой-то». Всё это лежит в одной базе PostgreSQL, а сам helpdesk по определению торчит в интернет — иначе сотрудники не смогут писать в поддержку из дома и с телефона.

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

Контур бэкапов: правило 3-2-1 и проверка восстановления

Zammad бэкап — это не один файл, а комплект. Основное живёт в PostgreSQL: тикеты, статьи переписки, пользователи, настройки и — по умолчанию — сами вложения, которые Zammad хранит прямо в базе. Если вы переносили хранилище вложений на файловую систему (так делают на больших объёмах), к дампу добавляется каталог хранилища. Плюс конфигурация: для пакетной установки — файлы в /opt/zammad, для Docker-варианта — файл .env, ваш docker-compose.yml и тома контейнеров. Elasticsearch бэкапить не нужно вовсе: поисковый индекс полностью перестраивается из базы одной командой, это расходный материал.

Для пакетной установки у Zammad есть штатный сценарий резервного копирования — /opt/zammad/contrib/backup/zammad_backup.sh. Перед первым запуском в том же каталоге копируете config.dist в config и задаёте путь назначения и глубину хранения. Скрипт делает полный дамп базы и архив файлов приложения; работает он только с PostgreSQL и только на пакетных установках — для Docker он не предназначен. В Docker-варианте мы снимаем дамп напрямую из контейнера БД:

#!/bin/bash
set -euo pipefail
DEST=/backup/zammad; STAMP=$(date +%F)
# дамп базы из контейнера PostgreSQL
docker compose exec -T zammad-postgresql \
  pg_dump -U zammad -d zammad_production | gzip > "$DEST/db-$STAMP.sql.gz"
# конфиги и тома приложения
tar czf "$DEST/env-$STAMP.tar.gz" .env docker-compose.yml
# ротация 14 дней + копия прочь с сервера
find "$DEST" -name '*.gz' -mtime +14 -delete
rclone copy "$DEST" s3remote:zammad-backup

Расписание — каждую ночь, в окно минимальной активности. И дальше главное — правило 3-2-1 в редакции для малой фирмы: три копии данных, на двух разных носителях, одна — вне площадки. На практике это выглядит так: боевая база на сервере, ночной дамп локально (быстрое восстановление «вчерашнего дня») и выгрузка того же дампа на второй сервер или в S3-совместимое хранилище у другого провайдера. Последняя строка скрипта — самая важная во всём резервном копировании helpdesk: копия, оставшаяся на том же диске, не спасает ни от смерти хостера, ни от шифровальщика.

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

Обновления без страха

Zammad обновление — вторая по частоте операция после бэкапа, и её боятся сильнее всего. Страх лечится разделением обновлений на два класса с разными правилами. Минорные релизы внутри ветки — вида 7.1.0 → 7.1.1 — мы ставим в течение недели после выхода, без обсуждений. Причина простая: именно в минорных релизах приезжают исправления безопасности. Свежий пример — 7.1.1, security-релиз от 25 июня 2026 года: чем дольше публично доступный helpdesk живёт с известной дырой, тем больше окно для автоматизированных сканеров, которые прочёсывают интернет в поисках непропатченных инсталляций.

Мажорные переходы — вида 6.x → 7.0 — это мини-проект. Сначала читаем changelog целиком, с карандашом: что сломается, какие требования к окружению подросли, что из настроек переезжает. Потом обкатываем обновление на копии: разворачиваем клон боевой базы (у нас он и так есть после квартального теста восстановления) и прогоняем миграцию от начала до конца. И только убедившись, что копия поднялась и работает, планируем окно для боевого сервера.

Порядок для Docker-установки механический: свежий бэкап → меняем тег версии в .env → docker compose pull → docker compose up -d — миграции схемы контейнер инициализации накатывает сам при старте → смоук-тест: версия в интерфейсе, создание тестового тикета, приём почты, поиск. Для пакетной установки ещё проще: бэкап, затем обновление пакета из официального репозитория штатным менеджером (apt upgrade zammad или аналог), миграции отрабатывают в пост-скрипте пакета, дальше тот же смоук-тест.

Харденинг публичного helpdesk

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

Двухфакторная аутентификация. Zammad умеет 2FA штатно: приложение-аутентификатор или аппаратный ключ. Мы делаем её обязательной для всех агентов и администраторов — то есть для всех, кто видит чужие тикеты и настройки. Пароль агента поддержки — самая ценная добыча на портале: за ним вся переписка компании. Один перехваченный или подобранный пароль без второго фактора превращается в полный доступ; с 2FA — в бесполезную строчку.

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

Транспорт и периметр. Только HTTPS с редиректом с 80-го порта, заголовок HSTS, актуальная версия TLS, автопродление сертификата. Перед Zammad у нас всегда стоит reverse proxy (nginx), и на нём же живёт fail2ban с фильтром на неудачные попытки входа: несколько провалов подряд с одного адреса — бан. Это отсекает тупой перебор паролей, который на любом публичном портале начинается через сутки после появления DNS-записи.

Админка — не для интернета. Пользовательский портал обязан быть доступен отовсюду — в этом его смысл. А вот административные URL мы закрываем на уровне reverse proxy белым списком: IP офиса плюс VPN. Атакующий снаружи видит форму входа портала, но до настроек системы не дотягивается даже с валидным паролем администратора.

152-ФЗ и персональные данные в тикетах

Тема, которую при внедрении helpdesk почти всегда пропускают, а зря: 152-ФЗ service desk касается напрямую. В тикетах лежат ФИО, телефоны, адреса почты, иногда паспортные данные из сканов договоров — то есть ваш service desk с точки зрения закона является информационной системой персональных данных, а компания — оператором ПДн, который обязан обеспечивать локализацию и защиту этих данных.

Хорошая новость: self-hosted Zammad на сервере в России снимает главный вопрос — локализацию баз с ПДн на территории РФ. Это, кстати, один из аргументов, почему для российской компании самостоятельный хостинг предпочтительнее зарубежного SaaS-helpdesk: там вопрос трансграничной передачи встаёт в полный рост, здесь его просто нет. Наши клиентские инсталляции живут на наших серверах в дата-центре МТС в Москве — юридически и физически данные не покидают страну.

Что вписать в документы оператора ПДн, если вы ведёте их сами: включите service desk в перечень ИСПДн, зафиксируйте цели обработки (учёт и обслуживание обращений), состав данных (ФИО, контакты, содержимое обращений), места хранения (адрес ЦОД), меры защиты (разграничение доступа, 2FA, шифрование транспорта, резервное копирование) и сроки хранения. Это не бюрократия ради галочки: при проверке или при инциденте наличие этих документов — разница между рабочим замечанием и штрафом.

И про сроки — retention-политика. Хранить тикеты вечно не обязательно и не нужно: закон требует прекращать обработку ПДн по достижении целей. Мы фиксируем с клиентом срок жизни закрытых заявок (обычно три года — с запасом под гарантийные и бухгалтерские вопросы), а дальше Zammad сам помогает: в админке есть штатный механизм удаления данных пользователя со всеми его тикетами — он появился для GDPR, но для 152-ФЗ работает ровно так же. Плановая чистка старья заодно худеет базу и ускоряет бэкапы — редкий случай, когда требование закона совпадает с интересами эксплуатации.

AI-функции на собственной LLM

С ветки 7.0, вышедшей в марте 2026 года, в Zammad появились штатные AI-функции: помощник агента и суммаризация тикетов — длинная переписка сворачивается в короткую выжимку с сутью проблемы и текущим статусом. Ветка 7.1 (июнь 2026) добавила AI Text Extractor — извлечение структурированных данных из текста заявки в поля тикета — и AI Ticket Tagger, автоматическую расстановку тегов; для простых случаев там же есть извлечение по регулярным выражениям, вообще без нейросети. Zammad AI — это уже не маркетинговая нашлёпка, а рабочие инструменты, которые реально экономят агентам время на рутине.

Ключевой для нас момент: Zammad поддерживает подключение собственного LLM-провайдера, а не только публичные облака. И для helpdesk это принципиально. Вспомните первый раздел: в тикетах — переписка, договоры, ПДн и присланные открытым текстом пароли. Отправлять всё это на суммаризацию в зарубежное облако — значит своими руками организовать утечку самого чувствительного, что есть в компании, да ещё и с трансграничной передачей ПДн в подарок. Поэтому наш вариант — self-hosted LLM helpdesk: разворачиваем OpenAI-совместимый эндпоинт (Ollama или vLLM) на своём железе и указываем его адрес в настройках AI-провайдера Zammad. Переписка не покидает периметр компании ни при каком сценарии.

Для суммаризации и расстановки тегов не нужна флагманская модель: компактные 7–8B в квантованном виде справляются достойно, а тексты тикетов короткие. Мы обычно начинаем с CPU-инференса на уже имеющейся виртуалке — это бесплатный способ проверить, приживётся ли AI в процессах конкретной команды, — и только при реальной нагрузке добавляем GPU.

Мониторинг: узнавать о проблеме раньше клиента

У Zammad есть встроенный health-check: в админке в разделе мониторинга генерируется токен, и система отдаёт своё состояние по адресу /api/v1/monitoring/health_check?token=…. В ответе — сводный статус и список проблем: упавшие фоновые задачи, застрявший планировщик, недоступный Elasticsearch, ошибки почтовых каналов. Мы цепляем этот эндпоинт к Zabbix HTTP-агентом: одна проверка закрывает сразу весь внутренний слой приложения.

# быстрая проверка руками
curl -s "https://helpdesk.example.ru/api/v1/monitoring/health_check?token=XXX"
# {"healthy":true,"message":"success",...}

Вокруг health-check добавляем стандартный обвес. Место на диске — с порогами предупреждения и аварии: переполненный диск роняет PostgreSQL и ломает ночные дампы одновременно. Очередь фоновых задач — если она растёт и не разгружается, письма-уведомления копятся и не уходят, а снаружи всё выглядит нормально. Отдельно — память и статус Elasticsearch: это самый прожорливый компонент стека, и падает он первым. И обязательно срок действия TLS-сертификата — за две недели до истечения, потому что «сертификат протух в субботу» до сих пор лидирует среди причин внезапно «сломавшегося» портала. Критичные алерты уходят в Telegram-чат дежурных инженеров: смысл сопровождения в том, чтобы фразу «у вас поддержка лежит» мы никогда не слышали от клиента первыми.

Из практики назову ранние симптомы деградации, которые видно до аварии: поиск начал отвечать секундами — Elasticsearch задыхается по памяти или индекс требует перестройки; уведомления приходят с опозданием в минуты — затор в фоновых задачах; ночной дамп стал идти в разы дольше — база распухла, пора смотреть на вложения и retention. Каждый такой симптом — это тикет нам самим, а не повод подождать, пока само рассосётся.

Производительность на дистанции

Свежий Zammad на виртуалке с 8 ГБ памяти летает. Проблемы приходят с историей: через год-два в базе десятки тысяч тикетов, и система начинает подтормаживать в предсказуемых местах. Хорошая новость — рычагов немного и все они штатные.

Первый — переиндексация Elasticsearch. Индекс со временем деградирует, а после мажорных обновлений его и вовсе положено перестроить. Делается одной командой (на пакетной установке — с префиксом zammad run, в Docker — внутри контейнера rails):

zammad run rake zammad:searchindex:rebuild
# процесс идёт в фоне, поиск в это время работает с неполными результатами

Второй — чистка attachment-мусора. Главный источник роста базы — вложения: пользователи шлют скриншоты по 5 МБ и сканы по 20, а почтовый канал складывает всё это в тикеты, включая логотипы из подписей в каждом письме цепочки. Retention-политика из раздела про 152-ФЗ решает и эту задачу: удаление тикетов старше согласованного срока уносит и их вложения. На больших объёмах дополнительно имеет смысл вынести хранилище вложений из базы на файловую систему — дампы становятся кратно легче и быстрее.

Третий — PostgreSQL-гигиена. Автовакуум в современных версиях справляется сам, но после массовых чисток стоит прогнать VACUUM ANALYZE руками, чтобы вернуть место и обновить статистику планировщика. И четвёртый — память: когда Elasticsearch и Rails-процессы начинают толкаться локтями в 8 ГБ, добавление RAM до 12–16 ГБ решает больше проблем, чем любой тюнинг. Признак «пора» — сервер стабильно в свопе при обычной дневной нагрузке. Мы закладываем ревизию ресурсов в годовой цикл: смотрим динамику роста базы и запас по памяти, чтобы расширяться планово, а не под жалобы «у нас всё висит».

Наш регламент одним списком

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

Сколько это стоит времени? На отлаженной инсталляции — три-четыре часа инженера в месяц: почти всё автоматизировано, руки нужны на обновления, ревизию учёток и разбор алертов. В квартал с тестом восстановления добавляется ещё пара часов. Немного — но именно эти часы отделяют сервис, который переживёт и смерть диска, и шифровальщика, и кривой релиз, от бомбы замедленного действия с тремя годами переписки внутри.

Что из этого разумно делать самим, а что отдавать на сопровождение? Ежедневный контур — бэкап и мониторинг — обязан работать без людей вообще, его достаточно один раз правильно собрать. Ревизию учёток осмысленно держать у себя: кто уволился, знаете только вы. А вот обновления, тесты восстановления, харденинг и разбор инцидентов — типовая работа, где аутсорсер с десятками инсталляций делает за час то, на что штатный админ-универсал потратит день с перекурами на чтение форумов. Мы в ITfresh сопровождаем Zammad ровно по этому регламенту — он весь перед вами, пользуйтесь им как инструкцией или приходите, обсудим ваш случай.