Миграция Битрикс24 из облака в коробку: наш опыт переезда

Компания 1С-Битрикс неожиданно прекратила оказывать услуги по переносу данных из облачной версии Битрикс24 в коробочную. Теперь компании, которые начали пользоваться облачной версией Битрикс24 и планируют перейти на коробочную, должны переезжать самостоятельно. Мы прошли этот путь и готовы поделиться опытом.

Зачем нужно переезжать на коробку Битрикс24?

В Битрикс24 реализовано две версии: облачная и коробочная.

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

Если компании нужны более широкие возможности системы, тогда требуется коробочная версия. Она устанавливается на серверы компании, где хранятся данные. Исходный код открыт, можно вносить изменения с помощью модулей или через PHP и JavaScript. Коробочная версия подходит компаниям, которым важна закрытая среда для хранения данных и интеграция с внутренними системами.

Если компания начала работать в облаке, но потребовались дополнительные возможности коробки, то переехать можно, но теперь уже без технической поддержки компании 1С-Битрикс.

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

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

Наша задача усложнялась еще и масштабом портала заказчика.

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

Мы пробовали использовать fast_bitrix24 – библиотеку, которая ускоряет работу с API. И она действительно работает быстро, но недолго. Лимиты Битрикс24 остаются жесткими, а при превышении лимита запросов API блокируется, и приходится долго ждать восстановления доступа.

Битрикс24 не раз отмечали, что их REST API не предназначен для работы с большими данными, но других альтернатив нет, поэтому мы нашли решение, как избежать потерь и длительных простоев.

Как мы выстроили процесс и с чем столкнулись?

Мы проанализировали работающую систему клиента, сущности и данные в Битрикс24, с которыми работали сотрудники, определили ключевые технические требования и оценили существующие ресурсы.

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

Далее мы оценили производительность сервера, который принимает данные. Скорость скачивания составляла 5 задач в секунду, а скорость вставки на сервере – 2 задачи в секунду. Поэтому при использовании стандартной коробочной API Б24 нам пришлось внести временные правки в ядро, чтобы исключить лишние проверки данных.

Неожиданной сложностью в процессе стала работа с файлами в Битрикс24.

Система использует два принципиально разных типа файлов: файлы с Диска, доступные через стандартное API, и так называемые «простые файлы», которые физически хранятся в директории /upload/main/ в коробочной версии.

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

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

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

Результаты и главные выводы

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

Вот главное, что помогло нам осуществить переезд Битрикс24 из облака в коробку:

• Согласование разумных объемов переносимых данных.
• Разделение процесса переезда на относительно независимые этапы: компании, контакты, лиды, сделки, задачи. После добавления задач – добавление чек-листов и комментариев.
• Профилирование коробки на вставках данных, что позволило внести временные правки ядра, которые существенно повысили скорость импорта. Также был предоставлен очень быстрый «железный» сервер с SSD-дисками в RAID-массиве.
• Деление импорта файлов на два этапа: сначала создание пустых файлов без реального скачивания, а затем скачивание содержимого файлов.