и с какими трудностями при этом столкнулись
В статье рассказываем, как мы в 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, а через частицу тильда, поэтому при переносе сообщений пришлось написать функцию, которая при переносе записи меняла упоминания каналов.
Этот опыт миграции мы считаем очень удачным!