Битва за чаты: как перенести чаты из облака в коробку за 2 недели и не потерять данные

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

В этой статье расскажем как выполнить перенос чатов более 100 пользователей с сохранением хронологии, вложений и структуры диалогов. Задача осложнялась ограничениями API, жесткими сроками (2–3 недели) и необходимостью минимизировать downtime. Отметим, что организация рабочих процессов построена на многосторонних диалогах, в которых участвует около 30 человек.

Как поэтапно выполнялся перенос? 

Процесс переноса чатов был организован следующим образом:

1. Создание мэппинга пользователей: разработка механизма сопоставления пользователей (создание мэппинга и скрипта).

2. Разработка скрипта для импорта чатов: создание основного инструмента для переноса данных.

3. Тестирование на нашей тестовой среде: выявление начальных проблем и ошибок (наша внутренняя среда + частичное тестирование).

4. Тестирование на DevStand клиента: выявление основных проблем и рисков (полное тестирование данных клиента).

5. Отработка замечаний и решение проблем: устранение ошибок и адаптация системы к требованиям клиента.

6. Параллельная разработка решения для дозагрузки: реализация механизма дозагрузки данных из-за срыва сроков.

7. Решение проблемы с интерфейсом Битрикс24: разработка скрипта для устранения проблем с сортировкой чатов.

Технические вызовы и решения

Оптимизация скорости загрузки

Изначально планировали грузить по одному пользователю за шаг, но:

• У некоторых было слишком много чатов → тайм-ауты
• Файлы замедляли процесс

Решение:

• Разбили загрузку на 500 сообщений за шаг
• Для чатов с файлами уменьшили размер партии

Проблема: новые сообщения во время импорта

Импорт занял несколько дней, а пользователи продолжали работать в облаке → часть переписки терялась.

Решение:

• Механизм догрузки
• Система запоминает ID перенесённых сообщений
• После основного импорта загружает только новые данные (за последние 2 дня)

Баг с сортировкой чатов

После переноса диалоги отображались в случайном порядке.

Причина:

• Bitrix24 добавляет системное сообщение с текущей датой при создании чата
• Но мы загружали старые сообщения → конфликт дат

Решение:

Скрипт удаления первого системного сообщения в каждом чате

Теперь рассмотрим подробно как проходил процесс миграции данных

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

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

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

Перенос большого массива данных из облачного Битрикс24 в коробочный портал потребовал нестандартного подхода.

Главная сложность заключалась в технических ограничениях облачного Битрикс24:

1. Нет прямого доступа к БД — только REST API.
2. Строгие лимиты на запросы — не более 2 запросов в секунду.
3. Обязательная пагинация — нельзя получить все сообщения разом.

Пришлось использовать HTTP-запросы для порционной загрузки сообщений, но с учетом жестких сроков (2-3 недели), необходимо было оптимизировать процесс.

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

Представьте, что после переноса многолетней истории переписки с огромным количеством сообщений и файлов, каждый пользователь должен авторизоваться на DevStand и вручную проверить полноту и корректность своих чатов. Только после подтверждения всеми пользователями мы могли приступить к импорту на Production.

Однако у нас не было на это времени, поэтому ИТ-специалисты ограничились быстрой визуальной проверкой контекста диалогов и доступности вложений. После чего мы запустили импорт на Production. 

Изначально мы планировали импортировать все данные по пользователям: один пользователь - один шаг импорта. Но у некоторых пользователей было слишком много чатов с огромным количеством сообщений.

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

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

Отметим, что при импорте файлов важно учитывать расширение хранилища на стороне заказчика, чтобы места хватило для переноса всех данных. 

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

Импорт чатов занимал несколько дней, в течение которых пользователи продолжали использовать облачную версию Битрикс24. Это приводило к ситуации, когда переписка, созданная после начала импорта, не попадала в перенесенные данные. 

Чтобы избежать потери данных, возникших в период импорта, мы разработали специальный скрипт "дозагрузки". 

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

Проблемы с интерфейсом: как разобраться с хаосом из тысячи сообщений 

После успешной загрузки большого объема данных в Битрикс24 мы столкнулись с неожиданной проблемой в интерфейсе. Пользователи обнаружили, что диалоги перемешиваются в случайном порядке, что делало работу в системе крайне неудобной.

Отметим, что проблема была не в созданном коде, а в том, что при создании нового чата в Битрикс автоматически добавляется системное сообщение с текущей датой. При этом, мы загружали сообщения из прошлого, которые имели более старые даты. Из-за этого конфликта дат система некорректно сортировала диалоги.

Для решения этой проблемы был разработан скрипт, который удалял это первое системное сообщение в каждом чате. Это не нарушало логику работы системы, но при этом решало проблему с сортировкой диалогов.

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

Что мы имеем в итоге? Вся история переписки перенесена, файлы и хронология сохранены, пользователи не заметили перехода.