Корпоративный чат уехал: план переезда с зарубежного мессенджера на свой сервер

MAATRIX

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

Выбор платформы: что разворачивать вместо привычного чата

На self-hosted стороне для замены корпоративного Slack-подобного мессенджера де-факто устоялись два зрелых открытых продукта — Mattermost и Rocket.Chat. Оба закрывают базовый набор: каналы, треды, личные сообщения, поиск по истории, файлообмен, десктопные и мобильные клиенты, интеграции через вебхуки и API-ботов. Есть и менее распространённые альтернативы (Zulip, Element на протоколе Matrix), но именно эти два продукта закрывают сценарий «привычный интерфейс а-ля Slack» с минимальной переучиваемостью команды.

Подробный разбор, когда выгоднее одно, а когда другое, — в статье Mattermost или Rocket.Chat: что выгоднее и когда. Если решение нужно принять быстро: берите Mattermost, если у вас уже есть или предполагается PostgreSQL и команда до пары сотен человек — это более распространённый выбор с более простой моделью развёртывания без Docker. Rocket.Chat стоит предпочесть, если в планах глубокая кастомизация под бизнес-процессы или уже есть опыт с MongoDB в команде.

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

Разворачиваем сервер: минимальный жизнеспособный чат за один день

Цель первого дня — не идеально настроенная инфраструктура, а рабочий чат, куда можно завести команду. Мониторинг, бэкапы и отказоустойчивость добавляете уже после того, как люди начали писать сообщения.

Минимальные шаги на Ubuntu 24.04 (на примере Mattermost):

1. Арендуйте VPS — для команды до 50 человек достаточно 2 vCPU / 4 ГБ RAM, для 100+ уже стоит смотреть в сторону 4 vCPU / 8 ГБ, с запасом по диску под файловые вложения.
2. Заведите поддомен (chat.company.ru) и направьте A-запись на IP сервера.
3. Установите PostgreSQL, создайте базу и пользователя под Mattermost.
4. Установите сам Mattermost Server и настройте systemd-юнит для автозапуска.
5. Поставьте Nginx как reverse proxy и получите TLS-сертификат через Let's Encrypt.

Полная пошаговая инструкция с командами — в статье как установить и настроить Mattermost на VPS. Там же разобраны типичные ошибки на этом этапе: неверный pg_hba.conf, забытый порт 8065 наружу (его не нужно открывать — Mattermost должен слушать только localhost, а наружу торчит Nginx), истёкший сертификат при неправильном cron для certbot.

Проверка, что базовая установка отвечает корректно, до заведения пользователей:

curl -s -o /dev/null -w "%{http_code}\n" https://chat.company.ru/api/v4/system/ping

Код 200 и JSON {"status":"OK"} в ответе — сервер готов принимать первых пользователей. Если получаете 502 — проверьте, что systemd-юнит Mattermost действительно запущен (systemctl status mattermost) и слушает 8065 (ss -tlnp | grep 8065).

Перенос истории переписки: что реально можно спасти

Здесь всё зависит от одного факта, который либо есть, либо нет: успели ли вы экспортировать данные из старого сервиса до потери доступа.

Если экспорт есть. У большинства зарубежных корпоративных мессенджеров есть встроенный экспорт истории в архив (обычно JSON с метаданными сообщений плюс отдельные файлы вложений). Mattermost умеет импортировать такой архив штатным инструментом командной строки:

# распаковываем архив экспорта в рабочую директорию
unzip export.zip -d /tmp/import

# запускаем импорт (пример для Slack-подобного формата экспорта)
mmctl import upload /tmp/import/export.zip
mmctl import process <имя_загруженного_файла>

Учтите нюансы, о которых стоит честно предупредить команду заранее, а не после того, как кто-то не найдёт сообщение:

• Форматирование и упоминания могут измениться. Ссылки на пользователей (@username) после импорта иногда рвутся, если ID пользователей в старой и новой системе не совпадают — это нормально, а не баг импортёра.
• Реакции переносятся не всегда полностью — зависит от версии инструмента импорта, часть эмодзи-реакций может потеряться.
• Вложения нужно проверить отдельно. Они переносятся отдельным шагом от самих сообщений — после импорта стоит выборочно открыть несколько тредов со скриншотами и убедиться, что ссылки на файлы рабочие, а не битые.
• Время импорта растёт нелинейно с объёмом — небольшой архив может импортироваться за десятки минут, а многолетний архив крупной компании растянуться на часы; закладывайте это в план заранее, а не в ночь перед переездом.

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

Миграция интеграций: боты, уведомления, вебхуки

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

• уведомления от CI/CD (сборка упала, деплой прошёл);
• алерты от систем мониторинга серверов и сайтов;
• уведомления от таск-трекера (новая задача, комментарий, смена статуса);
• боты для HR-процессов (заявки на отпуск, онбординг);
• интеграции с CRM или биллингом (новая заявка, оплата).

Практически все перечисленные сценарии в старом сервисе были реализованы через один и тот же механизм — исходящие/входящие вебхуки, а не через глубокую интеграцию с закрытым API. И Mattermost, и Rocket.Chat поддерживают тот же самый механизм — значит, для большинства ботов перенос сводится не к переписыванию логики, а к замене одного URL на другой.

Типовой шаблон для Mattermost — входящий вебхук, куда внешняя система шлёт POST-запрос:

curl -i -X POST -H 'Content-Type: application/json' \
  -d '{"text": "Деплой prod завершён успешно, версия v2.4.1"}' \
  https://chat.company.ru/hooks/xxxxxxxxxxxxxxxxxxxxxxxxxx

Если у вас уже есть скрипт, который раньше слал уведомления через webhook-URL старого мессенджера, в большинстве случаев достаточно поменять в конфиге этот URL на новый — тело запроса (простой JSON с текстовым полем) в обеих системах устроено похоже. Исключение — сложные боты с интерактивными кнопками и слэш-командами: их логику придётся адаптировать под API конкретно новой платформы.

Порядок на практике: составьте таблицу «интеграция → что делает → кто настраивал → критичность», начните переключение с самых критичных (алерты мониторинга и деплоя — без них команда не видит, что происходит с продакшеном), проверяйте тестовым сообщением каждую сразу после переключения, и только потом переносите второстепенные HR-боты и уведомления, без которых день простоя не критичен.

Обучение команды и переход без остановки коммуникации

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

Если старый чат ещё жив (переезд плановый, а не аварийный). Дайте команде две-три недели параллельной работы: заведите новый мессенджер, продублируйте туда самые активные каналы, но не отключайте старый резко. За это время люди привыкают к интерфейсу в некритичной обстановке, а не в панике «где теперь писать». К концу периода объявите точную дату отключения старого чата заранее, минимум за неделю, письменно, не только устно на созвоне.

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

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

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

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

Практический чек-лист переезда

Сведём весь план в один список, который можно распечатать или прикрепить в закреплённое сообщение первого дня работы нового чата.

До переезда (если он ещё не аварийный): выгрузите полный экспорт истории со всеми вложениями → составьте опись ботов и интеграций с критичностью каждой → выберите платформу под свои требования к СУБД и масштабу.

Инфраструктура: арендуйте VPS с запасом по RAM → настройте домен, СУБД, мессенджер, Nginx и TLS → проверьте, что сервер отвечает на API-пинг и открывается по HTTPS без предупреждений браузера.

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

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

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