Если коротко: с 1 сентября 2023 года 1С-Битрикс перестал отдавать полные резервные копии облачных порталов. То есть как раньше (привычный сценарий переезда на коробку) больше не работает.
Раньше всё было просто. Покупаешь коробочную лицензию, пишешь в поддержку ключ продукта, тебе в назначенную дату готовят бэкап, ты разворачиваешь его на своём сервере, неиспользованные дни облачной подписки добавляют к сроку коробки. Одна операция, по сути копирование файлов и базы. Да, были проблемы с одновременной работой на облаке во время переноса, но это были допущения.
Сейчас так не выйдет. Причина у вендора техническая и в общем понятная: в полный бэкап попадает не только ваш контент, но и ядро продукта, а ядра облака и коробки за годы разошлись достаточно, чтобы копия облака на коробке начинала сыпать ошибками на ровном месте. Поддерживать это ребята не захотели и услугу закрыли.
На руках у интегратора остаётся REST API облачного портала и пустая коробка, куда всё это надо как-то залить. Ниже расскажу про то, почему это сложнее, чем звучит, и где расставлены грабли.
Почему нельзя «просто перегнать через API»
Раз есть REST, кажется, что всё решается скриптом на выходные: читаем из облака, пишем в коробку. Но на практике мешает несколько вещей.
REST отдаёт текущее состояние сущностей. Это не файловый бэкап и не дамп базы: вы получаете сделки, задачи, сообщения как объекты, но без журналов и части служебных связей.
Прочитать сущность со всеми атрибутами обычно можно. А вот записать её обратно ровно в том же виде получается далеко не всегда, и как раз здесь прячется самое неприятное. К переписке я вернусь отдельно, она заслуживает своего раздела.
Поверх всего этого висят лимиты. Портал на несколько тысяч человек с многомесячной историей не выкачивается в лоб — вы упрётесь в ограничения раньше, чем дойдёте до середины.
Что тянется через REST и с какой скоростью
По методам всё довольно прямолинейно:
-
пользователи и оргструктура —
user.get,department.get; -
CRM —
crm.deal.list,crm.lead.list,crm.contact.list,crm.company.list, пользовательские поля через*.fields. Базу сущностей удобнее гнать выгрузкой в CSV, а связи и кастомные поля дотягивать через API; -
задачи и проекты —
tasks.task.list; -
чаты и сообщения —
im.recent.get,im.dialog.messages.get,im.chat.get; -
Диск и файлы — семейство
disk.*; -
рабочие группы и Живая лента —
sonet_group.get,log.blogpost.*.
Интереснее скорость, потому что от неё зависит, уложитесь вы в одну ночь или будете тянуть три дня.
Частота запросов у REST ограничена: 2 в секунду на большинстве тарифов, 5 на Enterprise, всё по алгоритму Leaky Bucket. Короткие всплески проходят, а на постоянном высоком темпе прилетает QUERY_LIMIT_EXCEEDED. Выручает batch: до 50 вложенных вызовов за один запрос, счётчик при этом растёт на единицу. Пятьдесят *.list по 50 записей дают до 2500 записей за вызов, и это уже рабочие цифры.
Есть и второй лимит, менее известный, об который легко расшибиться на большой выгрузке. Если суммарное время выполнения запросов перевалит за 480 секунд в пределах 10 минут, метод блокируется для всех приложений и вебхуков аккаунта. Под блокировку при этом попадает весь портал, включая живых пользователей. Поэтому большую выгрузку мы режем на порции, ставим паузы и делаем ночью.
Чтобы был понятен масштаб. Портал с парой миллионов сообщений при чтении по 50 штук за вызов — это десятки тысяч запросов, и даже с batch, без единой ошибки, счёт идёт на часы.
Где по-настоящему ломается: переписка
CRM выгрузить несложно: сущности, поля, связи — механическая работа. История чатов сложнее, и за неё в переносе берут основные деньги. Тут важны авторы, даты, вложения, порядок реплик, и всё это должно приехать связным.
Самый простой путь — прочитать сообщения и переотправить их на коробку публичными методами — заканчивается предсказуемо. Вся переписка за годы оказывается отправленной от одного технического пользователя и датированной датой импорта. Сообщения на месте, но пользоваться такой историей нельзя: не видно, кто говорил, когда и в каком порядке шёл разговор.
Дальше идёт длинный список граблей. Идентификаторы пользователей в облаке и в коробке не совпадают, так что вопрос «кто автор» превращается в отдельную задачу сопоставления. Файлы на Диске при загрузке получают новые адреса, и ссылки внутри сообщений приходится держать в согласованном состоянии, иначе вложения вроде бы есть, но не открываются. Сверху те же объёмы: миллионы записей, которые надо провести, не упёршись в лимиты из предыдущего раздела. В общем дичь
Как мы сохраняем авторство и исходные даты, я пошагово выкладывать не буду. Это тот самый узел, ради которого к нам и приходят. Про подход скажу только одно: результату мы не верим на слово и каждый перенос сначала прогоняем на пилоте — на одном чате, со сверкой автора, даты и вложения с оригиналом, до того как трогаем боевой портал. Остальное в статье воспроизводимо, этот кусок сознательно закрыт.
152-ФЗ: личные чаты нельзя переносить молча
Момент, который недооценивают скорее юридически, чем технически. Личная переписка сотрудников — персональные данные, и перенести чужие личные диалоги заодно с рабочими нельзя.
У нас это устроено так: на портал ставится небольшое приложение, где каждый сотрудник в один клик соглашается или отказывается переносить свои личные диалоги. Переносим только то, на что есть согласие, у остальных личные чаты не трогаем. Рабочие чаты, группы и каналы переносятся штатно.
Что не переносится в принципе
Чтобы у заказчика не было завышенных ожиданий, список честнее дать сразу:
-
пароли — Битрикс их наружу не отдаёт, вход на коробке настраивается заново: почта, SSO, что выберете;
-
детальные логи действий пользователей — через API недоступны;
-
полная история изменений сделок и задач — API отдаёт текущее состояние и часть истории, но не весь журнал; глубокую историю, если она нужна, достаём отдельно, и это уже не выгрузка одной кнопкой;
-
бизнес-процессы, роботы, триггеры, системные настройки — это уже конфигурация, и на коробке её собирают заново руками. Тем более при импорте БП он сразу создаст все поля в сущности, очень удобно 🙂
Как не сжечь боевой портал
Что мы делаем всегда.
Пилот. Берём один реальный чат или одного сотрудника, прогоняем через всю процедуру на тестовую коробку и сверяем с оригиналом: автор на месте, дата совпадает, вложение открывается. Что-то не так — правим и повторяем. День-два на пилоте экономят недели переделок на боевом переносе, когда чинить уже поздно.
Сверка «было / стало». После заливки проходим по контрольным точкам: случайные чаты, сделки, задачи, файлы. Сверяем количества и содержимое.
Ночное окно и тишина. Заливаем в нерабочее время с погашенными уведомлениями. Иначе в момент переноса всей компании разом прилетят пуши и письма про «новые» сообщения пятилетней давности, почтовый сервис так же в ауте.
Итого
Перенос Битрикс24 из облака в коробку по-прежнему выполним. Просто с сентября 2023 это перестало быть «одной кнопкой»: данные собираются по частям, переносятся с разной надёжностью, и сверять приходится руками.
ссылка на оригинал статьи https://habr.com/ru/articles/1054438/