Когда возможностей облачного сервиса уже становится мало, и переход на коробочную версию видится следующим логичным шагом для дальнейшего развития корпоративного портала и CRM-системы, то у компаний встает вопрос, как это сделать, что их ожидает и все ли сохранится после переноса?
Казалось бы, все достаточно просто:
Но практика показывает, что переход с облака на коробочную версию — процесс далеко не тривиальный и требует четкого плана действий, анализа возможных рисков и готовности к тому, что все пойдет не так.
К нам обратился крупный застройщик с высоконагруженной CRM-системой на облачном Битрикс24. В CRM активно работали менеджеры по продажам из нескольких филиалов компании, портал был интегрирован с IP-телефонией Asterisk для автоматизированного создания лидов, записи разговоров с клиентами и фиксации фактов звонка в карточке клиента в CRM. В день в CRM через различные каналы создавалось более 100 лидов.
Было ясно, что любой простой во времени в процессе переноса на коробочную версию грозит Заказчику огромными потерями. Проговорив с Заказчиком всю серьезность перехода и возможные риски, мы принялись за работу.
В первую очередь мы проанализировали существующие кейсы и публикации по переносу облака на коробку, составили подробный чек-лист ошибок, с которыми мы можем столкнуться:
Далее был составлен четки алгоритм действий с разбивкой по ролям, который необходимо было выполнить как со стороны Исполнителя, так и со стороны Заказчика:
1 фаза (срочность средняя)
2 фаза (срочность высокая)
3 фаза (срочность низкая)
Составив данный план и имея чек-лист с возможными ошибками, мы поняли, что имеем слишком большие риски за счет большого количества неопределенностей:
Мы поняли, что имеем неопределенный временной лаг, который по мере увеличения приносил бы все больше и больше потерь для клиента. Чтобы минимизировать временной лаг, необходимо было понять, сколько мы потратим времени на перенос портала и его отладку.
Так мы пришли к выводу, что одного бэкапа с облака будет недостаточно, и чтобы свести к минимуму потери необходимо развернуть один бэкап – для выявления всех возможных рисков и оценки временного лага, а затем второй бэкап, который мы бы смогли спланировать так, чтобы минимизировать потери.
Битрикс предоставляет только один бэкап и только один раз, так как процесс переноса с облака на коробку технически сложный. Обратившись в техподдержку и подключив к этому вопросу Заказчика, мы все-таки получили добро на предоставление двух бэкапов с облака в разное время. Было согласовано время первого бэкапа и работа по переносу началась.
Для того, чтобы понимать сколько и на что у нас будет уходить время мы начали вести журнал, в котором фиксировали каждый шаг.
Итак, бэкап портала сервис начал делать ночью в четверг, то есть в CRM были последние данные на конец четверга, и предоставил нам ссылку на бэкап в обед пятницы. Тут мы столкнулись с первой трудностью – бэкап весил порядка 30 ГБ, а скорость скачивания с серверов Amazon.com, на которых располагалось облако, была далека от идеала (в среднем 800 Kb/s). Подсчитав примерно время, за которое загрузились несколько частей бэкапа, мы поняли, что в общей сумме только на скачивание бэкапа уйдет порядка 10 часов.
Следующей пробл��мой стало появление ошибок во время выкачивания различных частей бэкапа, которая выявлялась только при разворачивании. Данные части, как правило, вызывали также ошибку несовпадения хэш-сумм, из-за этого приходилось в тексте ошибки выявлять битую часть архива и вручную переносить ее по SSH, после чего распаковка запускалась заново с нуля всего бэкапа.
Успешно скачав и развернув бэкап на наших хостах, мы получили рабочую копию облака в коробке и перешли к следующему этапу — тестированию и отладке портала.
На наше удивление, тестирование коробки прошло относительно гладко. Мы протестировали CRM, прошлись по всем инструментам сервиса, проверили работоспособность мессенджера, прогнали внутренние тесты и выявили всего 3 ошибки:
О невозможности авторизоваться после переноса мы знали заранее, об этом сразу предупреждает сервис при предоставлении бэкапа. К сожалению, эта проблема решается только восстановлением пароля пользователями или ручной сменой паролей каждому пользователю администратором, так как пароли от Bitrix24.Network не хранятся на портале.
Ошибка со ссылками в уведомлениях решилась достаточно быстро — путем прописывания домена портала в настройках сайта и настройках главного модуля.
А вот пропавшая иконка прикрепления файлов в мессенджере доставила не мало забот. Задача заняла еще пару часов безуспешных попыток понять причину пропажи иконки. В итоге мы выявили, что причина крылась далеко не в модуле диска, как предполагалось изначально. Причина крылась в отключённом push-сервере в настройках модуля push&pull, который автоматически отключал и передачу файлов в мессенджере.
После успешного тестирования и отладки портала был составлен детальный отчет Заказчику и следующим шагом было глубокое тестирование отделом продаж Заказчика CRM, а также настройка сервера телефонии на работу с коробкой и тестирование звонков.
В ходе тестирования существенных проблем не было выявлено. Мы развернули тестовый хост и накатили на него полную копию боевого портала, на тот случай, чтобы у нас был 100% рабочий вариант портала и по которому мы смогли бы провести сравнение в настройках при возникновении нестандартных ошибок, не выявленных при тестировании первого бэкапа.
После разворачивании копии портала мы перешли к анализу журнала, в котором фиксировали ошибки и время их решения. Детально проанализировав журнал, мы актуализировали план переноса второго бэкапа, поняли, сколько мы можем потерять лидов при итоговом переносе и заложили дополнительно время на ручной импорт потерянных лидов из облачной версии. Все детали и риски также проговорили с Заказчиком и составили письмо в техподдержку сервиса с просьбой подготовить второй бэкап.
Согласовав время создания бэкапа также на четверг, мы подготовили команду к оперативным действиям к 12 часов дня пятницы. В районе 12-13 часов мы получили долгожданную ссылку и запустили скачивание. Спустя несколько часов было ясно, что архив будет выкачиваться уже не 10 часов, а около 14! Пропускная способность канала нашего провайдера и серверов Amazon.com в этот день оставляла желать лучшего. Мы готовились к ночным работам, так как лиды продолжали падать, и Заказчик ждал отчета, чтобы приступить к настройке сервера телефонии.
Как это часто бывает — не все пошло по плану. Следующим шагом был перенос накопившихся лидов из облачной версии в коробку – процесс простой и понятный, но имеет свои нюансы. Если в списке лидов выбрать те лиды, которые необходимо экспортировать и нажать «Экспорт в CSV», то выгрузка будет происходить всех существующих в CRM лидов, а не только выбранных. Логично, что при большой базе лидов облако сваливалось в ошибку. Решение заключалось в использовании фильтра, только в этом случае лиды выгружались корректно.
Дальнейшее тестирование прошло уже без неожиданностей, так как мы уже знали: что не будет работать, как это править и где. Успешно подключив и протестировав телефонию, в понедельник менеджеры отдела продаж уже полностью работали с CRM в коробочной версии. И уже в рабочем порядке в течение недели мы донастроили портал, резервное копирование, сделали финальную копию портала на тестовый хост.
Весь процесс переноса занял порядка недели работы с момента планирования и до финальных настроек.
В качестве итога хочется отметить важность планирования такого рода сложных и рискованных проектов, обязательного вовлечения Заказчика в процесс и проговаривание возможных рисков, хотя, как показывает практика, отклонения от плана также не исключение.
Казалось бы, все достаточно просто:
- Разворачиваем хост с коробкой;
- Пишем в техподдержку;
- Заказываем бэкап;
- Ждем его получения;
- Разворачиваем бэкап и наслаждаемся широкими возможностями коробочной версии.
Но практика показывает, что переход с облака на коробочную версию — процесс далеко не тривиальный и требует четкого плана действий, анализа возможных рисков и готовности к тому, что все пойдет не так.
К нам обратился крупный застройщик с высоконагруженной CRM-системой на облачном Битрикс24. В CRM активно работали менеджеры по продажам из нескольких филиалов компании, портал был интегрирован с IP-телефонией Asterisk для автоматизированного создания лидов, записи разговоров с клиентами и фиксации фактов звонка в карточке клиента в CRM. В день в CRM через различные каналы создавалось более 100 лидов.
Было ясно, что любой простой во времени в процессе переноса на коробочную версию грозит Заказчику огромными потерями. Проговорив с Заказчиком всю серьезность перехода и возможные риски, мы принялись за работу.
В первую очередь мы проанализировали существующие кейсы и публикации по переносу облака на коробку, составили подробный чек-лист ошибок, с которыми мы можем столкнуться:
- Приложения, работающие в облаке, отсутствуют на коробке;
- Стоимость лицензий на приложения для облачной версии и коробки может отличаться;
- Риск потери части данных из-за временного лага во время переноса;
- Часть пользователей из разных филиалов будет продолжать работать на облачном сервисе после переноса и необходимо будет дополнительно искать и переносить созданные ими сущности в CRM;
- На закрытом портале не будет работать мобильное приложение сервиса;
- После переноса часть пользователей не сможет авторизоваться со своим старым паролем;
- Возможны сбои в работе чат-ботов;
- Частое сбрасывание авторизации при работе на портале;
- Может отображаться только часть комментариев к задачам;
- База данных будет без поискового индекса.
Далее был составлен четки алгоритм действий с разбивкой по ролям, который необходимо было выполнить как со стороны Исполнителя, так и со стороны Заказчика:
1 фаза (срочность средняя)
- Разворачивание среды Production (Исполнитель);
- Тестирование развернутой среды (Исполнитель);
- Разворачивание коробочной версии на хостах (Исполнитель);
- Покупка и установка SSL-сертификата для работы телефонии (Заказчик-покупка, Исполнитель-установка);
- Тестирование коробочной версии – производительность, параметры, внутренние тесты (Исполнитель).
- Разворачивание среды Pre-Production – полной копии Production (Исполнитель).
2 фаза (срочность высокая)
- Заявка на выгрузку бэкапа. Согласование с техподдержкой сервиса даты предоставления бэкапа (Заказчик);
- Информирование пользователей о дате бэкапа и составление плана по временному хранению информации из CRM (Заказчик);
- Разворачивание бэкапа на Production (Исполнитель);
- Настройка портала после бэкапа (Исполнитель);
- Настройка сервера телефонии для работы с порталом (Заказчик);
- Настройка модуля телефонии (Исполнитель);
- Первичное тестирование телефонии (Заказчик);
- Углубленное тестирование CRM, телефонии, бизнес-процессов CRM (отдел продаж Заказчика);
- Утверждение работоспособности. Удаление тестовых данных (Заказчик);
- Остановка работы менеджеров отдела продаж в облачном сервисе (Заказчик);
- Перенос сделок, лидов, контактов с момента создания бэкапа с облачной версии в коробку (Исполнитель);
- Старт работы менеджеров отдела продаж на коробочной версии (Заказчик).
3 фаза (срочность низкая)
- Тестирование коробочной версии в течение 2-3 дней (Заказчик);
- Утверждение полной работоспособности (Заказчик);
- Актуализация Pre-Production – перенос полной копии Production (Исполнитель).
Составив данный план и имея чек-лист с возможными ошибками, мы поняли, что имеем слишком большие риски за счет большого количества неопределенностей:
- Как быстро сервис предоставит бэкап?
- Сколько время займет разворачивание бэкапа, с учетом того, что база данных CRM огромна?
- Как быстро удастся перенастроить модуль и сервер телефонии для корректной работ с CRM?
- Какие конкретные баги могут появиться на портале, насколько они будут критичные для работы пользователей и сколько времени может уйти на их исправление?
Мы поняли, что имеем неопределенный временной лаг, который по мере увеличения приносил бы все больше и больше потерь для клиента. Чтобы минимизировать временной лаг, необходимо было понять, сколько мы потратим времени на перенос портала и его отладку.
Так мы пришли к выводу, что одного бэкапа с облака будет недостаточно, и чтобы свести к минимуму потери необходимо развернуть один бэкап – для выявления всех возможных рисков и оценки временного лага, а затем второй бэкап, который мы бы смогли спланировать так, чтобы минимизировать потери.
Битрикс предоставляет только один бэкап и только один раз, так как процесс переноса с облака на коробку технически сложный. Обратившись в техподдержку и подключив к этому вопросу Заказчика, мы все-таки получили добро на предоставление двух бэкапов с облака в разное время. Было согласовано время первого бэкапа и работа по переносу началась.
Объем, скорость и битые части
Для того, чтобы понимать сколько и на что у нас будет уходить время мы начали вести журнал, в котором фиксировали каждый шаг.
Итак, бэкап портала сервис начал делать ночью в четверг, то есть в CRM были последние данные на конец четверга, и предоставил нам ссылку на бэкап в обед пятницы. Тут мы столкнулись с первой трудностью – бэкап весил порядка 30 ГБ, а скорость скачивания с серверов Amazon.com, на которых располагалось облако, была далека от идеала (в среднем 800 Kb/s). Подсчитав примерно время, за которое загрузились несколько частей бэкапа, мы поняли, что в общей сумме только на скачивание бэкапа уйдет порядка 10 часов.
Следующей пробл��мой стало появление ошибок во время выкачивания различных частей бэкапа, которая выявлялась только при разворачивании. Данные части, как правило, вызывали также ошибку несовпадения хэш-сумм, из-за этого приходилось в тексте ошибки выявлять битую часть архива и вручную переносить ее по SSH, после чего распаковка запускалась заново с нуля всего бэкапа.
Успешно скачав и развернув бэкап на наших хостах, мы получили рабочую копию облака в коробке и перешли к следующему этапу — тестированию и отладке портала.
Мелкие ошибки и коварный push&pull
На наше удивление, тестирование коробки прошло относительно гладко. Мы протестировали CRM, прошлись по всем инструментам сервиса, проверили работоспособность мессенджера, прогнали внутренние тесты и выявили всего 3 ошибки:
- Пропал значок прикрепления файла в мессенджере и не работала отправка файлов в мессенджере в целом;
- Ссылки в уведомлениях имели адрес без домена, например: company/personal/user/1250/tasks/task/view, соответственно были не рабочими;
- Часть пользователей не могла авторизоваться на портале с ошибкой неверный логин/пароль.
О невозможности авторизоваться после переноса мы знали заранее, об этом сразу предупреждает сервис при предоставлении бэкапа. К сожалению, эта проблема решается только восстановлением пароля пользователями или ручной сменой паролей каждому пользователю администратором, так как пароли от Bitrix24.Network не хранятся на портале.
Ошибка со ссылками в уведомлениях решилась достаточно быстро — путем прописывания домена портала в настройках сайта и настройках главного модуля.
А вот пропавшая иконка прикрепления файлов в мессенджере доставила не мало забот. Задача заняла еще пару часов безуспешных попыток понять причину пропажи иконки. В итоге мы выявили, что причина крылась далеко не в модуле диска, как предполагалось изначально. Причина крылась в отключённом push-сервере в настройках модуля push&pull, который автоматически отключал и передачу файлов в мессенджере.
Финальное тестирование
После успешного тестирования и отладки портала был составлен детальный отчет Заказчику и следующим шагом было глубокое тестирование отделом продаж Заказчика CRM, а также настройка сервера телефонии на работу с коробкой и тестирование звонков.
В ходе тестирования существенных проблем не было выявлено. Мы развернули тестовый хост и накатили на него полную копию боевого портала, на тот случай, чтобы у нас был 100% рабочий вариант портала и по которому мы смогли бы провести сравнение в настройках при возникновении нестандартных ошибок, не выявленных при тестировании первого бэкапа.
После разворачивании копии портала мы перешли к анализу журнала, в котором фиксировали ошибки и время их решения. Детально проанализировав журнал, мы актуализировали план переноса второго бэкапа, поняли, сколько мы можем потерять лидов при итоговом переносе и заложили дополнительно время на ручной импорт потерянных лидов из облачной версии. Все детали и риски также проговорили с Заказчиком и составили письмо в техподдержку сервиса с просьбой подготовить второй бэкап.
Второй бэкап и почему все может пойти не так?
Согласовав время создания бэкапа также на четверг, мы подготовили команду к оперативным действиям к 12 часов дня пятницы. В районе 12-13 часов мы получили долгожданную ссылку и запустили скачивание. Спустя несколько часов было ясно, что архив будет выкачиваться уже не 10 часов, а около 14! Пропускная способность канала нашего провайдера и серверов Amazon.com в этот день оставляла желать лучшего. Мы готовились к ночным работам, так как лиды продолжали падать, и Заказчик ждал отчета, чтобы приступить к настройке сервера телефонии.
Как это часто бывает — не все пошло по плану. Следующим шагом был перенос накопившихся лидов из облачной версии в коробку – процесс простой и понятный, но имеет свои нюансы. Если в списке лидов выбрать те лиды, которые необходимо экспортировать и нажать «Экспорт в CSV», то выгрузка будет происходить всех существующих в CRM лидов, а не только выбранных. Логично, что при большой базе лидов облако сваливалось в ошибку. Решение заключалось в использовании фильтра, только в этом случае лиды выгружались корректно.
Дальнейшее тестирование прошло уже без неожиданностей, так как мы уже знали: что не будет работать, как это править и где. Успешно подключив и протестировав телефонию, в понедельник менеджеры отдела продаж уже полностью работали с CRM в коробочной версии. И уже в рабочем порядке в течение недели мы донастроили портал, резервное копирование, сделали финальную копию портала на тестовый хост.
Весь процесс переноса занял порядка недели работы с момента планирования и до финальных настроек.
В качестве итога хочется отметить важность планирования такого рода сложных и рискованных проектов, обязательного вовлечения Заказчика в процесс и проговаривание возможных рисков, хотя, как показывает практика, отклонения от плана также не исключение.
