Когда возможностей облачного сервиса уже становится мало, и переход на коробочную версию видится следующим логичным шагом для дальнейшего развития корпоративного портала и 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 в коробочной версии. И уже в рабочем порядке в течение недели мы донастроили портал, резервное копирование, сделали финальную копию портала на тестовый хост.
Весь процесс переноса занял порядка недели работы с момента планирования и до финальных настроек.
В качестве итога хочется отметить важность планирования такого рода сложных и рискованных проектов, обязательного вовлечения Заказчика в процесс и проговаривание возможных рисков, хотя, как показывает практика, отклонения от плана также не исключение.