Почему обновление коробки всегда операция с последствиями
Облачный Битрикс24 обновляет вендор, и владелец портала узнаёт об этом постфактум. С коробочной версией по-другому: продукт стоит на вашем сервере, кнопку «Установить обновления» нажимает ваш администратор, и всё, что за этим последует, остаётся внутри компании.
Пока портал свежий и на нём нет ничего, кроме штатной CRM, обновления проходят незаметно. Сложности приходят позже, когда на коробке уже живут доработанные компоненты, модули из Маркетплейса, обмен с 1С, самописные обработчики событий и полтора десятка бизнес-процессов, которые собирали два года. Ядро обновилось, а обработчик, цеплявшийся за старый метод, перестал срабатывать. Портал при этом открывается и выглядит рабочим. Сделки из формы на сайте не создаются, и в отделе продаж это заметят часа через четыре.
Отсюда правило, которое хорошие администраторы соблюдают годами: обновление коробочного Битрикс24 сначала проходит на копии портала и только потом на боевом. Копию принято называть тестовым контуром. Смысл её простой: узнать про сломанный обработчик раньше, чем о нём узнает отдел продаж.
Что даёт тестовый контур, кроме спокойствия
Резервная копия отвечает на вопрос «как вернуть всё назад». Тестовый контур отвечает на другой вопрос: «что именно сломается». Задачи разные, и одна другую не заменяет.
Восстановление из бэкапа на боевом сервере занимает время, и всё это время портал недоступен. Авария в среду в одиннадцать утра означает, что компания стоит. Тестовый контур переносит эту неприятность на площадку, где никто не работает: там можно ломать, откатывать, ставить обновление заново и спокойно разбираться, почему обмен с 1С отвалился именно на этом релизе.
Кроме обновлений копия портала закрывает ещё несколько задач:
- проверить модуль из Маркетплейса до покупки и установки на боевой портал;
- прогнать переезд на новую версию PHP;
- дать подрядчику площадку для доработок, не пуская его в живые данные клиентов;
- обучить новых сотрудников на реальной структуре портала, где случайно удалённая сделка ничего не стоит;
- убедиться, что резервная копия вообще разворачивается.
Последний пункт часто оказывается самым ценным. Компании годами настраивают автоматическое резервное копирование и ни разу не пробуют развернуть архив. До первой попытки восстановления бэкап остаётся гипотезой. Тестовый контур эту гипотезу проверяет: если копия поднялась и портал на ней работает, значит, схема резервирования живая.
Лицензия: сколько копий разрешено держать
Первое, что спрашивают руководители: не нарушим ли мы условия, подняв вторую копию портала.
Не нарушите, если соблюдать ограничения. По лицензионному соглашению с одним лицензионным ключом продукт можно установить не более двух раз, при этом публичный доступ ко второй копии должен быть закрыт, и предназначена она для разработки и тестирования. Законный тестовый контур, таким образом, заложен в лицензию изначально, отдельно покупать его не нужно.
Начиная с версии 16.5.7 в продуктах 1С-Битрикс есть отдельный маркер «Установка для разработки». Он существует ровно под этот сценарий. Пометить им можно как новую установку, на шаге ввода лицензионного ключа, так и уже развёрнутую копию: административная часть, дальше «Настройки», «Настройки продукта», «Настройки модулей», «Главный модуль», вкладка «Система обновлений».
Зачем это нужно технически. Система обновлений сверяет состояние копии с тем, что записано у вендора после последнего обновления. Когда с одним ключом работают две установки и обе ходят на сервер обновлений, состояния расходятся и появляется ошибка ERROR_WRONG_CODE. Маркер разработки этот конфликт снимает.
Вместе с маркером документация просит выполнить несколько условий. Тестовый сайт закрывают от публичного посещения на странице настроек модулей, вкладка «Доступ». Опцию «Автоматически проверять наличие обновлений» отключают, и здесь оговорено исключение: её оставляют, если копия используется как раз для проверки обновлений перед установкой на основной портал. Ещё стоит помнить про телефонию: она завязана на лицензионный ключ, и на копии её возможности ограничены.
Отдельно вендор оговаривает, что регулярное переключение режима отслеживается, и оставляет за собой право отключить функционал, а при грубых нарушениях заблокировать коммерческий ключ. Тестовый контур существует для проверки обновлений и доработок, второй рабочий портал по цене одного из него не сделать.
Как развернуть копию портала
Порядок примерно одинаковый на всех проектах, отличаются детали окружения.
Начинают с резервной копии боевого портала. Штатный механизм находится в административной части: «Настройки», «Инструменты», «Резервное копирование», «Создание резервной копии». Он собирает файлы проекта и базу данных.
Если портал крупный, штатный механизм лучше не мучить. В веб-окружении BitrixVM есть свой пункт меню, «17. Start/Stop site backup». Он настраивает периодичность и время запуска, прописывает задание в крон и складывает архивы в формате .tar.gz в каталог /home/bitrix/backup/archive/. Работает быстрее встроенного, но с особенностью: файлы из облачных хранилищ в такой архив не попадают. Если на портале подключён внешний диск, его содержимое переносят отдельно.
Дальше нужна площадка. Отдельный сервер, отдельная виртуальная машина или отдельный сайт в пуле того же веб-окружения. В BitrixVM пул сайтов управляется пунктом «6. Configure pool sites», внутри него есть «1. Create site».
Держать тестовый контур на том же железе, что и продакшен, это компромисс. Дёшево, но нагрузка от обновления и переиндексации ляжет на сервер, где в это время работают люди. Небольшие порталы такое переживают, для крупных копию лучше вынести на отдельную машину, пусть и слабее по ресурсам.
Восстановление на новой площадке делает скрипт restore.php. Его берут со страницы списка резервных копий в админке (/bitrix/admin/dump_list.php), он лежит там же, под перечнем архивов, либо из свежего дистрибутива продукта. Скрипт кладут в корень новой площадки и запускают из браузера, дальше он забирает архив и раскатывает файлы вместе с базой.
После восстановления имеет смысл зайти в «Настройки», «Инструменты», «Проверка системы». Страница сверяет параметры площадки с минимальными и рекомендованными требованиями продукта и показывает расхождения: права на каталоги, настройки PHP, доступность расширений. Версию PHP проверьте отдельно: официальная инструкция по обновлению коробочного Битрикс24 требует PHP 8.1 или выше, текущая видна в разделе «Настройки», «Производительность», «PHP».
Что отключить на копии до первого входа
Это самая недооценённая часть работы. Свежеразвёрнутый тестовый контур представляет собой полную копию боевого портала со всеми его связями с внешним миром, и о том, что он тестовый, он не знает.
Первое, что выключают, это исходящая почта. Иначе тестовый портал начнёт рассылать уведомления настоящим сотрудникам и клиентам. Самый частый сценарий провала выглядит так: на копии запустили бизнес-процесс, чтобы посмотреть, как он отработает, и клиент получил письмо о заказе, которого нет.
Дальше идут интеграции и вебхуки. Обмен с 1С, телефония, мессенджеры, коннекторы к сайту на копии либо отключают, либо переключают на тестовые реквизиты. Опаснее всего обмен с учётной системой: тестовый портал способен отправить в 1С документы, которых там быть не должно.
Задания планировщика обычно оставляют, иначе портал ведёт себя неестественно, но всё, что отправляет данные наружу, из них убирают.
Публичный доступ закрывают паролем на уровне веб-сервера или доступом только из офисной сети. Помимо требования лицензии здесь есть приземлённая причина: на копии лежат те же персональные данные клиентов, что и на боевом портале, а внимания её безопасности уделяют обычно вдвое меньше.
Полезно ещё пометить копию визуально: сменить название портала и цветовую тему, чтобы человек с двумя открытыми вкладками за секунду понимал, где он находится. Полчаса на такую настройку окупаются первым же случаем, когда сотрудник чуть не отредактировал боевые данные, будучи уверенным, что он на тесте.
Как проходит само обновление
Когда контур готов, обновление ставят сначала на него. Последовательность в админке простая.
Обновления коробочного Битрикс24 живут в разделе «Marketplace», пункт «Обновление платформы» (/bitrix/admin/update_system.php). Первым делом обновляется сама система обновлений, для этого на странице есть отдельное действие «Обновить систему SiteUpdate». Пока механизм обновлений не обновлён, остальное ставить не стоит.
Дальше два пути. Кнопка «Установить рекомендуемые обновления» ставит весь рекомендованный набор. Вкладка «Список обновлений» позволяет выбрать конкретные модули. Есть и экспертный режим, где для каждого модуля указывается конкретная версия. Он пригождается, когда нужно дойти до определённого релиза, а не до последнего.
Зависимости между модулями система разбирает сама и подтягивает связанные компоненты. Процесс можно остановить кнопкой «Остановить установку», но текущий модуль система всё равно доустановит: прервать обновление посреди модуля нельзя.
Для работы всего этого нужен валидный и активированный лицензионный ключ, а также действующая подписка на обновления. Когда подписка истекла, новые версии ядра и модулей просто не приходят; продлевают её активацией купона на той же странице. Адрес сервера обновлений, www.1c-bitrix.ru, задаётся в настройках главного модуля, там же настраиваются защищённое соединение и прокси, если сервер выходит в интернет через него.
Разница между тестовым контуром и продакшеном на этом этапе одна: на копии вы можете позволить себе ошибиться. Поэтому важно ставить на копию тот же набор обновлений, что пойдёт на бой. Если на тесте вы прошли путь до последней версии одним махом, а на боевом решили обновляться по шагам, проверен был другой сценарий.
Второй смысл прогона на копии чисто организационный: вы узнаёте, сколько обновление идёт на объёме именно вашей базы. Одна и та же установка обновлений на портале с тысячей сделок и на портале с сотнями тысяч записей занимает разное время, и предсказать это по документации нельзя. Засеките длительность на тесте, добавьте запас, и у вас появится обоснованное окно работ, которое можно согласовать с руководителями отделов заранее. Без такой цифры окно назначают наугад, а потом объясняют, почему портал недоступен уже третий час.
Полезно по ходу записывать не результат, а сам порядок действий: что обновляли, в какой последовательности, где пришлось вмешаться руками, какие файлы правили. На боевом портале этот же список превращается в сценарий работ, по которому обновление проводит уже любой администратор, а не только тот, кто разбирался на тесте.
Что проверять после обновления
Список зависит от портала, но каркас у него общий. Проверять нужно не «открывается ли портал», а те места, где живут доработки.
Здесь всплывает проблема, о которой вспоминают поздно: чтобы проверить доработки, нужно знать их перечень. На порталах старше двух лет такого перечня обычно нет. Кто-то из подрядчиков дописал обработчик, кто-то поставил модуль, кого-то уже нет в компании. Разумно составить реестр доработок до того, как поднимать копию: список установленных модулей, своих обработчиков событий, интеграций, изменённых шаблонов и правок в файлах ядра, если они есть. Документ занимает страницу, а без него проверка после обновления превращается в угадывание.
- вход пользователей и права доступа: администратор, руководитель, рядовой менеджер;
- CRM: создание лида и сделки, переход по стадиям, обязательные и пользовательские поля;
- бизнес-процессы и роботы: запустить хотя бы один сложный процесс целиком и прочитать журнал;
- формы CRM и приём заявок с сайта, самое частое место поломки после обновления ядра;
- обмен с 1С в обе стороны, на тестовых реквизитах;
- свои модули и обработчики событий: всё написанное под вас проверяется руками;
- отчёты, воронка, сквозная аналитика;
- скорость работы портала, просадку лучше обнаружить на копии;
- журнал обновлений. На странице обновлений есть перечень последних установленных обновлений со статусами и ошибками, его стоит прочитать целиком, а не смотреть на итоговое «Готово».
Проверку удобно вести по короткому документу, а не по памяти. Один раз составленный чек-лист живёт годами и передаётся вместе с порталом от администратора к администратору. Мы ведём такие чек-листы по каждому клиентскому порталу, они обновляются вместе с доработками и входят в сопровождение. Если эту часть работы логичнее отдать на сторону, посмотрите наши услуги по Битрикс24: развёртывание тестового контура и регламент обновлений входят в обычный объём работ, а не выделяются в отдельный героический проект.
Как это выглядит на практике
Пример ниже иллюстративный, ситуация типовая и не про конкретную компанию.
Производственная компания, коробочный портал на 120 сотрудников, два года доработок: обмен с 1С, свой модуль расчёта себестоимости, десяток бизнес-процессов согласования, интеграция с сайтом через вебхуки. Обновления не ставили полтора года по принципу «работает, не трогай». Потом понадобилась функция из свежего релиза, и вопрос встал ребром.
Развернули копию портала на отдельной виртуальной машине, пометили её как установку для разработки, закрыли доступ извне, отключили почту и переключили обмен с 1С на тестовую базу. Обновились на копии. Портал поднялся, CRM работала, а модуль расчёта себестоимости отвалился: он использовал метод ядра, который за полтора года изменился.
На тестовом контуре это стоило двух дней работы разработчика. На боевом портале это стоило бы двух дней простоя расчётов, срочных звонков и объяснений финансовому директору, почему цифры не считаются. После правки модуля обновление на боевом заняло вечер и прошло без сюрпризов, потому что все сюрпризы уже случились на копии.
Полезный вывод здесь про накопленный разрыв: чем дольше портал не обновлялся, тем дороже обходится первое обновление. Полтора года паузы превращают рутинную операцию в проект с бюджетом и сроками.
Когда контур можно не поднимать
Не каждому порталу он нужен постоянно.
Если коробка стоит почти в исходном виде, со штатной CRM, задачами и диском, без своих модулей, обработчиков и обмена с учётной системой, риск обновления невелик. Хватает свежей резервной копии и обновления в нерабочее время. Как только портал доработан, интегрирован с 1С и на нём висят бизнес-процессы, влияющие на деньги, тестовый контур перестаёт быть роскошью.
Есть промежуточный вариант, который выбирают чаще всего: контур поднимают не насовсем, а под задачу. Раз в квартал перед плановым обновлением разворачивают копию из свежего бэкапа, прогоняют обновление и проверку, после чего копию гасят. Дешевле по ресурсам, и заодно регулярно подтверждает, что резервные копии рабочие.
Время на всё это измеряется не неделями. Первое развёртывание копии обычно занимает день с учётом отключения интеграций и настройки окружения, повторные занимают несколько часов, потому что порядок действий уже описан. Обновление на тесте с проверкой по чек-листу отнимает от нескольких часов до пары дней, в зависимости от количества доработок. Рядом со стоимостью одного дня простоя портала на сотню человек арифметика получается понятная, и именно её стоит показывать руководителю, когда он спрашивает, зачем платить за второй сервер.
Частые вопросы
Нужна ли отдельная лицензия для тестового контура?
Нет. По лицензионному соглашению с одним ключом допускается не более двух установок продукта, при этом вторая должна быть закрыта от публичного доступа и использоваться для разработки и тестирования.
Что делать с ошибкой ERROR_WRONG_CODE при обновлении копии?
Она появляется, когда текущее состояние системы не совпадает с состоянием после последнего обновления. Типичная причина: с одним ключом работают две установки. Для этого случая и предусмотрен маркер «Установка для разработки», он включается в «Настройки», «Настройки продукта», «Настройки модулей», «Главный модуль», вкладка «Система обновлений».
Можно ли держать тестовый контур на том же сервере, что и боевой портал?
Технически да, в BitrixVM для этого есть управление пулом сайтов. Но обновление и переиндексация на копии заберут ресурсы у боевого портала. Небольшим порталам это приемлемо, для нагруженных лучше отдельная машина.
Как часто обновлять копию из боевого портала?
Перед каждым обновлением. Проверять релиз на копии полугодовой давности почти бессмысленно: за это время на боевом портале появились новые поля, процессы и данные, и ломается обычно именно они.
Что делать, если подписка на обновления закончилась?
Без активной подписки новые версии ядра и модулей недоступны. Продление оформляется активацией купона на странице обновления платформы. Пока подписка не продлена, тестовый контур всё равно полезен: на нём проверяют доработки и модули.
Обновляться сразу до последней версии или по шагам?
Оба варианта рабочие, и как раз тестовый контур показывает, какой подходит вашему порталу. Важно одно: на бою повторяется ровно тот сценарий, который проверен на копии. Если на тесте шли по шагам через экспертный режим, на боевом портале нужно идти тем же путём.