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

Казалось бы, все достаточно просто:

• Разворачиваем хост с коробкой Битрикс24;
• Пишем в техподдержку Битрикс24;
• Заказываем бэкап;
• Ждем его получения;
• Разворачиваем бэкап и наслаждаемся широкими возможностями коробочной версии.

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

К нам обратился крупный застройщик с высоконагруженной CRM-системой на облачном Битрикс24. В CRM активно работали менеджеры по продажам из нескольких филиалов компании, портал был интегрирован с IP-телефонией Asterisk для автоматизированного создания лидов, записи разговоров с клиентами и фиксации фактов звонка в карточке клиента в CRM. В день в CRM через различные каналы создавалось более 100 лидов.

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

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

• Приложения, работающие в облаке, отсутствуют на коробке Битрикс24;
• Стоимость лицензий на приложения для облачного Битрикс24 и коробки может отличаться;
• Риск потери части данных из-за временного лага во время переноса;
• Часть пользователей из разных филиалов будет продолжать работать на облачном Битрикс24 после переноса и необходимо будет дополнительно искать и переносить созданные ими сущности в CRM;
• На закрытом портале не будет работать мобильное приложение Битрикс24;
• После переноса часть пользователей не сможет авторизоваться со своим старым паролем;
• Возможны сбои в работе чат-ботов;
• Частое сбрасывание авторизации при работе на портале;
• Может отображаться только часть комментариев к задачам;
• База данных будет без поискового индекса.

Далее был составлен четки алгоритм действий с разбивкой по ролям, который необходимо было выполнить как со стороны QSOFT, так и со стороны Заказчика:

1 фаза (срочность средняя)

• Разворачивание среды Production (QSOFT);
• Тестирование развернутой среды (QSOFT);
• Разворачивание коробочного Битрикс24 на хостах (QSOFT);
• Покупка и установка SSL-сертификата для работы телефонии (Заказчик-покупка, QSOFT-установка);
• Тестирование коробочного Битрикс24 – производительность, параметры, внутренние тесты Битрикс24 (QSOFT).
• Разворачивание среды Pre-Production – полной копии Production (QSOFT).

2 фаза (срочность высокая)

• Заявка в Битрикс24 на выгрузку бэкапа. Согласование с техподдержкой Битрикс даты предоставления бэкапа. (Заказчик);
• Информирование пользователей о дате бэкапа и составление плана по временному хранению информации из CRM (Заказчик);
• Разворачивание бэкапа на Production (QSOFT);
• Настройка портала после бэкапа (QSOFT);
• Настройка сервера телефонии для работы с порталом (Заказчик);
• Настройка модуля телефонии в Битрикс24 (QSOFT);
• Первичное тестирование телефонии (Заказчик);
• Углубленное тестирование CRM, телефонии, бизнес-процессов CRM (отдел продаж Заказчика);
• Утверждение работоспособности. Удаление тестовых данных (Заказчик);
• Остановка работы менеджеров отдела продаж в облачном Битрикс24. (Заказчик);
• Перенос сделок, лидов, контактов с момента создания бэкапа с облачного Битрикс24 в коробку (QSOFT);
• Старт работы менеджеров отдела продаж на коробочной версии Битрикс24. (Заказчик).

3 фаза (срочность низкая)

• Тестирование коробочной версии Битрикс24 в течение 2-3 дней (Заказчик);
• Утверждение полной работоспособности (Заказчик);
• Актуализация Pre-Production – перенос полной копии Production (QSOFT).

Составив данный план и имея чек-лист с возможными ошибками, стало очевидно, что мы имеем слишком большие риски за счет большого количества неопределенностей:

• Как быстро Битрикс24 предоставит бэкап?
• Сколько время займет разворачивание бэкапа, с учетом того, что база данных CRM огромна?
• Как быстро удастся перенастроить модуль и сервер телефонии для корректной работ с CRM?
• Какие конкретные баги могут появиться на портале, насколько они будут критичные для работы пользователей и сколько времени может уйти на их исправление?

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

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

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

Объем, скорость и битые части

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

Итак, бэкап портала Битрикс24 начал делать ночью в четверг, то есть в CRM были последние данные на конец четверга, и предоставил нам ссылку на бэкап в обед пятницы. Тут мы столкнулись с первой трудностью – бэкап весил порядка 30 ГБ, а скорость скачивания с серверов Amazon.com, на которых располагалось облако Битрикс24 была далека от идеала (в среднем 800 Kb/s). Подсчитав примерно время, за которое загрузились несколько частей бэкапа, мы поняли, что в общей сумме только на скачивание бэкапа уйдет порядка 10 часов.

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

Успешно скачав и развернув бэкап на наших хостах, мы получили рабочую копию облачного Битрикс24 в коробке и перешли к следующему этапу — тестированию и отладке портала.

Мелкие ошибки и коварный push&pull

На наше удивление, тестирование коробки прошло относительно гладко. Мы протестировали CRM, прошлись по всем инструментам Битрикс24, проверили работоспособность мессенджера, прогнали внутренние тесты Битрикс24 и выявили всего 3 ошибки:

• Пропал значок прикрепления файла в мессенджере и не работала отправка файлов в мессенджере в целом;
• Ссылки в уведомлениях имели адрес без домена, например: company/personal/user/1250/tasks/task/view, соответственно были не рабочими;
• Часть пользователей не могла авторизоваться на портале с ошибкой неверный логин/пароль.

О невозможности авторизоваться после переноса мы знали заранее, об этом сразу предупреждает Битрикс24 при предоставлении бэкапа. К сожалению, эта проблема решается только восстановлением пароля пользователями или ручной сменой паролей каждому пользователю администратором, так как пароли от Bitrix24.Network не хранятся на портале.

Ошибка со ссылками в уведомлениях решилась достаточно быстро — путем прописывания домена портала в настройках сайта и настройках главного модуля.

А вот пропавшая иконка прикрепления файлов в мессенджере доставила не мало забот. Задача заняла еще пару часов безуспешных попыток понять причину пропажи иконки. В итоге мы выявили, что причина крылась далеко не в модуле диска, как предполагалось изначально. Причина крылась в отключённом push-сервере в настройках модуля push&pull, который автоматически отключал и передачу файлов в мессенджере.

Финальное тестирование

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

В ходе тестирования существенных проблем не было выявлено. Мы развернули тестовый хост и накатили на него полную копию боевого портала, на тот случай, чтобы у нас был 100% рабочий вариант портала и по которому мы смогли бы провести сравнение в настройках при возникновении нестандартных ошибок, не выявленных при тестировании первого бэкапа.

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

Второй бэкап и почему все может пойти не так?

Согласовав время создания бэкапа также на четверг мы подготовили команду к оперативным действиям к 12 часов дня пятницы. В районе 12-13 часов мы получили долгожданную ссылку и запустили скачивание. Спустя несколько часов было ясно, что архив будет выкачиваться уже не 10 часов, а около 14! Пропускная способность канала нашего провайдера и серверов Amazon.com в этот день оставляла желать лучшего. Мы готовились к ночным работам, так как лиды продолжали падать, и Заказчик ждал отчета, чтобы приступить к настройке сервера телефонии.

Как это часто бывает — не все пошло по плану. Следующим шагом был перенос накопившихся лидов из облачного Битрикс24 в коробку – процесс простой и понятный, но имеет свои нюансы. Если в списке лидов выбрать те лиды, которые необходимо экспортировать и нажать «Экспорт в CSV», то выгрузка будет происходить всех существующих в CRM лидов, а не только выбранных. Логично, что при большой базе лидов облачный Битрикс24 сваливался в ошибку. Решение заключалось в использовании фильтра, только в этом случае лиды выгружались корректно.

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

Весь процесс переноса занял порядка недели работы с момента планирования и до финальных настроек.

В качестве итога хочется отметить важность планирования такого рода сложных и рискованных проектов, обязательного вовлечения Заказчика в процесс и проговаривание возможных рисков, хотя, как показывает практика, отклонения от плана также не исключение.