Slack и Teams закрыли доступ: переводим клиентов на российские корпоративные мессенджеры

Когда в начале августа несколько корпоративных аккаунтов Slack у наших клиентов получили уведомления об ограничении доступа, вопрос «чем заменить» из абстрактного превратился в конкретный. Teams к тому времени тоже закрыл расширенные функции для организаций, попавших в санкционные списки. Мы разом получили три запроса на перевод корпоративного мессенджера - от клиентов разного масштаба и с разными требованиями.

Дальше - практика. Не обзор продуктов по документации, а то, с чем реально столкнулись.

Три кандидата и логика выбора

Рассматривали три варианта:

• Rocket.Chat self-hosted - открытый исходный код, разворачивается на своих серверах, данные остаются у клиента. Активно развивается, имеет бизнес-ориентированные функции: каналы, треды, ботов, webhooks, богатый API. На рынке не новый, у некоторых компаний уже был опыт с ним ещё до нынешних событий.
• VK Teams - бывший Mail.ru Myteam, переименованный и перепакованный продукт от VK. Облако или on-premise, фокус на корпоративный рынок. Интеграции с экосистемой VK и российскими сервисами.
• Яндекс Мессенджер - здесь ситуация с корпоративной версией сложнее: речь о Яндекс 360 для бизнеса, куда мессенджер входит как часть пакета. Корпоративного on-premise нет, только облако.

Сразу уточним: у одного клиента был жёсткий запрос на хранение данных исключительно на своих серверах - для него облачные варианты отпали сразу.

Rocket.Chat: разворачиваем у себя

Для клиента с требованием по локализации данных выбор был очевиден. Развернули Rocket.Chat в Docker Compose на выделенной VM с MongoDB в качестве бэкенда - стандартная схема по официальной документации.

Что прошло без проблем: базовая установка, настройка аутентификации через LDAP (у клиента FreeIPA), создание структуры каналов, загрузка истории - Rocket.Chat умеет импортировать историю из Slack через JSON-экспорт. Экспорт из Slack мы успели сделать заблаговременно, пока доступ ещё был.

Где потратили время:

Мобильные клиенты. Push-уведомления в self-hosted варианте идут через серверы Rocket.Chat - это известный архитектурный момент, без которого придётся держать собственный push-proxy. Для клиента с суверенными требованиями это потребовало отдельного разговора: либо мириться с тем, что метаданные уведомлений проходят через внешний сервис, либо разворачивать собственный push gateway. Пока выбрали первое, но зафиксировали как открытый вопрос.

Интеграции с внутренними системами. Клиент активно использовал incoming webhooks в Slack для оповещений от систем мониторинга и CI. В Rocket.Chat аналогичный механизм есть, и он работает - но форматирование сообщений отличается, особенно attachments и block-kit-аналоги. Переписали несколько скриптов формирования уведомлений, часть адаптировали через Rocket.Chat Apps.

Производительность при старте. MongoDB + Node.js при первом запуске на не самой мощной VM (4 vCPU, 8GB RAM) поднимается небыстро. После прогрева - нормально, но если VM перезапускается, старт займёт минуты. Для продакшна стоит закладывать ресурсы с запасом.

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

VK Teams: корпоративный on-premise

Второй клиент был готов к облаку, но предпочёл on-premise из-за внутренних политик. VK Teams предоставляет такую возможность - разворачивается на своих серверах, лицензирование по числу пользователей.

Впечатление двойственное.

Плюсы: установщик понятный, документация на русском, техподдержка отвечает на русском же и достаточно оперативно. Интерфейс знакомый пользователям мобильного мессенджера от Mail.ru/VK, привыкание минимальное. Видеозвонки работают из коробки - это то, чего не хватало некоторым альтернативам.

Минусы: API и webhooks есть, но существенно беднее чем у Slack или Rocket.Chat. Интеграций с внешними системами у этого клиента было меньше, поэтому прошло без серьёзных проблем. Экосистема ботов практически отсутствует - всё нужно писать самому через официальный Bot API. Администрирование через веб-консоль - функционально, но местами угловатое.

Переезд прошёл быстрее: неделя с небольшим, потому что история в этом случае переносить не стали (клиент принял решение начать с чистого листа).

Яндекс 360: когда облако не страшно

Третий клиент - небольшая компания без требований к on-premise и без сложных интеграций. Для них посмотрели на Яндекс 360 для бизнеса, куда входят мессенджер, почта, диск и видеозвонки в одном пакете.

Подключение заняло буквально день: привязка домена, создание пользователей через консоль администратора или импорт из CSV, настройка. Мессенджер в составе пакета - это знакомый интерфейс, пользователи сразу поняли что к чему.

Ограничения здесь очевидны: данные в облаке Яндекса, зависимость от платформы. Для компании без регуляторных требований и без глубоких интеграций - разумный выбор. Но это именно замена потребительского мессенджера, а не корпоративной платформы с API.

Что мы вынесли из этих трёх переводов

Выбор упирается в два главных параметра - требования к локализации данных и наличие интеграций с внутренними системами.

Если данные должны быть на своих серверах и есть интеграции - Rocket.Chat. Порог вхождения выше, но гибкость максимальная. Смотрите на ресурсы под MongoDB и закладывайте время на адаптацию интеграций.

Если нужен отечественный on-premise с поддержкой на русском - VK Teams. Проще в части поддержки и администрирования, беднее по API. Для компаний без сложного DevOps-стека - разумная точка входа.

Если облако допустимо и требования простые - Яндекс 360. Быстро, знакомо, дёшево.

Помощь с интеграцией корпоративных мессенджеров во внутренние системы - это отдельный проект, не надо недооценивать его объём заранее. Мы ещё в процессе по части задач у клиентов - история с Rocket.Chat и webhooks закрыта не полностью. Напишем когда появится что добавить.