{"id":13592,"url":"\/distributions\/13592\/click?bit=1&hash=614144bb31dcda2de138a71c12a8b5f1c2d6612f2981479b7bf423e4bc53c03e","title":"\u041a\u0430\u043a \u043f\u043e\u043f\u0430\u0441\u0442\u044c \u0432 \u0435\u0434\u0438\u043d\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0435 \u043c\u0435\u0441\u0442\u043e \u0432 \u0420\u043e\u0441\u0441\u0438\u0438 \u0441 \u0447\u0430\u0439\u043d\u044b\u043c\u0438 \u043f\u043b\u0430\u043d\u0442\u0430\u0446\u0438\u044f\u043c\u0438","buttonText":"\u0423\u0437\u043d\u0430\u0442\u044c","imageUuid":"d85f2cfe-e0d7-5ad7-8507-983bc3b55643","isPaidAndBannersEnabled":false}
Skolopendra IT Studio

Как мы перенесли данные из приватных каналов Slack в Mattermost

и с какими трудностями при этом столкнулись

В статье рассказываем, как мы в SKÖLOPENDRA нашли достойную альтернативу одному из самых популярных корпоративных мессенджеров и провели миграцию данных. Автор кейса - Виктор Аленьков, экс-руководитель проектной backend-команды IT-studio SKÖLOPENDRA.

Как и многие распределенные команды, в SKÖLOPENDRA мы пользовались корпоративным мессенджером Slack. Когда, по известным причинам, Slack ушел с отечественного рынка, в качестве замены решили использовать Mattermost, который расположили на собственных серверах.

Вопрос, зачем вообще хранить и переносить корпоративную переписку, я сейчас опускаю. Не буду рассуждать и про альтернативные способы остаться на Slack. Будем исходить из того, что данные просто нужно перенести. Я расскажу о том, как провел перенос данных, сколько потратил на это времени и что было самым трудным.

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

· Поднять сервера. Сделали это силами девопс-инженеров.

· Slack не поддерживает экспорт приватных каналов. Тут пришлось повозиться.

Шаг 1. Как запустили гибридный подход

В API обоих приложений (Slack и Mattermost) есть стандартные способы создания данных, но они дают несколько баго-фич. Например, нельзя указать дату сообщения, и при миграции сообщение датируется текущим временем. Поэтому использовался гибридный подход – часть данных перенесли в стандартном API, после чего скорректировали в БД данные в том виде и формате, в котором они были в Slack. В этом большой плюс standalone инсталляции Mattermost как альтернативы Slack – она позволяет работать напрямую с базой данных и править записи. И, при этом, если в БД что-то сделать не так, то эти данные просто проигнорируются клиентом. Вопрос про прямой доступ к БД оставим безопасникам.

Шаг 2. Синхронизация и перелинковка пользователей и каналов

Для корректного переноса нужно было синхронизировать пользователей. Для этого они должны были либо зарегистрироваться у нас на сервере самостоятельно, либо их туда нужно было завести. Так как мы использовали GitLab в качестве каталога пользователей, то мы попросили пользователей регистрироваться самостоятельно в Mattermost, после чего линковал я их по корпоративным email. Если пользователь в Slack и Mattermost имел один и тот же email, идентифицировать было легко.

Но были каналы, в которых некоторые участники уже не работают в компании. Для них напрямую в базе данных Mattermost я создавал фейкового пользователя. Он имел тот же email, что и в Slack, и пометку УДАЛЕН.

У некоторых пользователей email менялись, так как Slack принимал короткие email, а Mattermost/GitLab – нет. Для таких ситуаций была написана таблица маппинга, она давала связку, что пользователь такого-то email в Slack это на самом деле пользователь такого-то email в Mattermost.

Аналогичным способом, с помощью маппинга, решили вопрос синхронизации каналов, которые в Slack и в Mattermost имели разные наименования. Например, канал, который в Slack назывался «Random» - в Mattermost носит название «Off-Topic»

Еще один кейс: в Slack у меня нет доступа во все приватные каналы, а часть информации вообще защищена от третьих лиц требованиями безопасности. Я не хотел заходить в каждый канал, чтобы добавлять туда бота для переноса, и просто написал инструкцию для владельцев каналов, чтобы они сами проводили перенос без предоставления доступа на сторону. Владельцы выполняли инструкцию, после чего запускалась синхронизация, и канал «переезжал».

Шаг 3. Перенос вложений

Доставил хлопот перенос вложений. С этим пришлось повозиться, потому что переносить пришлось большой объем, более 70 Гб, и вложения прогонялись постепенно по мере синхронизации каналов. На фоне этого рядом ходила еще одна проблема – при миграции данных приложение может упасть, поэтому надо понимать, какие сообщения ты уже перенес, а какие нет, чтобы при повторной обработке они не задублировались в основном канале Mattermost. Чтобы решить эти проблемы, я добавил таблицы кэширования. Они содержали информацию, что сущность (сообщение, вложение) с неким идентификатором из Slack уже было перенесено и указывала его идентификатор в Mattermost. Утилита это читала и могла перезаписать данные, не создавая повторную запись и лишние дубликаты. В зависимости от количества файлов один канал переносился от 30 секунд до 20 минут. Не быстро – но и не критично и вполне решаемо, как и миграция в целом.

Шаг 4. Ссылки на каналы внутри сообщений

Особенность - отличается формат ссылок. Например, в Mattermost обращение к имени канала происходит не через решетку, как в Slack, а через частицу тильда, поэтому при переносе сообщений пришлось написать функцию, которая при переносе записи меняла упоминания каналов.

Этот опыт миграции мы считаем очень удачным!

А вы что скажете?)
Класс!
Хотим еще кейсы!
Мы тоже нашли альтернативу, расскажу в комментах
Показать результаты
Переголосовать
Проголосовать
0
Комментарии
Читать все 0 комментариев
null