← К кейсам

Кейсы

Безопасное обновление коробочного Битрикс24 через тестовую копию

Как обновлять коробочный Битрикс24 через копию портала: резервная копия, VirtualBox или отдельный сервер, поэтапное обновление PHP и окружения, проверка кастомного кода и чек-лист перед production.

Почему обновление сначала нужно репетировать

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

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

Такой подход особенно важен для старых коробок, которые несколько лет не обновлялись и всё ещё работают на устаревших версиях PHP, MySQL или BitrixVM.

Фиксируем исходное состояние

Перед изменениями сначала нужно понять, что именно сейчас работает на сервере. Я фиксирую версии основного модуля Битрикс, BitrixVM или операционной системы, PHP, MySQL, Redis, Node.js и Push/RTC.

Отдельно проверяю всё, что может зависеть от обновления:

  • сторонние модули и решения Marketplace;
  • собственный код в /local;
  • cron и агенты;
  • бизнес-процессы и собственные activity;
  • телефонию и открытые линии;
  • почту;
  • AD/LDAP;
  • REST-приложения, webhook и внешние интеграции.

Также запускаю штатную «Проверку системы». Полезно сохранить результат до обновления, чтобы после завершения работ сравнить состояние окружения.

Разворачиваем тестовую копию

Перед обновлением создаётся актуальная резервная копия сайта и базы данных. После этого портал восстанавливается в отдельном окружении.

Отдельный сервер или VPS

Такой вариант удобен для больших порталов и совместной проверки несколькими специалистами. Среда ближе к production, можно тестировать внешний HTTPS, callback, webhook и интеграции, которым нужен доступ из интернета.

VirtualBox на рабочем компьютере

Для предварительной проверки небольшого или среднего портала достаточно локальной BitrixVM:

Windows
└── VirtualBox
    └── BitrixVM
        └── копия боевого Битрикс24

Такую машину можно изолировать от внешней сети, а перед каждым крупным шагом делать snapshot. Если после обновления PHP портал перестал загружаться, всю VM можно вернуть в предыдущее состояние значительно быстрее, чем выполнять полноценное восстановление сервера.

Копию нужно изолировать

После восстановления я отдельно отключаю всё, что может начать работать как production:

  • реальную почтовую отправку;
  • обмены с 1С;
  • исходящие webhook;
  • внешние API;
  • телефонию и мессенджеры;
  • боевые cron-задачи;
  • автоматизацию, способную изменить внешние системы.

Тестовая копия должна быть безопасным полигоном, а не вторым экземпляром production, который продолжает взаимодействовать с реальными клиентами и сервисами.

Порядок обновления

Для относительно современной коробки я использую последовательность, в которой каждый крупный этап проверяется отдельно:

исправление уже существующих ошибок
        ↓
резервная копия
        ↓
обновление платформы Битрикс
        ↓
обновление Marketplace-решений
        ↓
обновление BitrixVM
        ↓
перезагрузка и проверка
        ↓
обновление PHP
        ↓
проверка
        ↓
обновление MySQL при необходимости
        ↓
проверка
        ↓
исправление собственного кода
        ↓
полный функциональный тест

Сначала полезно максимально обновить сам Битрикс на текущей рабочей версии PHP. Затем уже переходить на новую версию интерпретатора. Это уменьшает количество одновременно меняющихся факторов.

Важно учитывать, что обновление BitrixVM и обновление PHP / MySQL — не одно и то же действие. Версии PHP и СУБД управляются отдельно, поэтому после обновления самой VM нужно отдельно проверить, какие версии компонентов используются на сервере.

После каждого крупного изменения я перезагружаю окружение и снова проверяю портал. Не стоит обновлять одновременно PHP, СУБД и десятки модулей, а потом пытаться понять, после какого шага появилась ошибка.

Если коробка очень старая

Отдельный сценарий — портал, который давно не обновлялся. Например, старый BitrixVM, PHP 5.6, устаревшая СУБД, старое ядро и много собственного кода.

Здесь важно уточнить терминологию: обычно речь идёт именно о PHP 5.6. PHP 6 не был массовой production-веткой, на которой работали коробочные порталы.

Старый портал нельзя просто переключить с PHP 5.6 на актуальный PHP 8.x и рассчитывать, что весь накопленный код продолжит работать. За несколько поколений PHP изменились сигнатуры методов, обработка типов и null, были удалены старые функции и изменилось поведение многих устаревших конструкций.

Поэтому большой разрыв лучше проходить поэтапно:

старый PHP
    ↓
максимально возможное обновление ядра
    ↓
следующая совместимая версия PHP
    ↓
исправление ошибок
    ↓
обновление ядра и модулей
    ↓
следующая версия PHP
    ↓
...
    ↓
актуальное окружение

Это не универсальная формула вида 5.6 → 7 → 8. Конкретный маршрут зависит от версии продукта, BitrixVM и доступных промежуточных версий окружения. Для старой коробки я сначала составляю отдельный маршрут миграции и прохожу его полностью на копии.

Иногда лучше перенести портал на новую VM

Если серверное окружение устарело слишком сильно, обновлять его на месте может быть сложнее, чем развернуть современную BitrixVM и восстановить туда резервную копию. Это позволяет одновременно перейти на актуальную ОС, новую версию PHP, современную СУБД, Redis и Push/RTC.

Но даже при таком варианте обновление самого портала и проверка собственного кода всё равно сначала выполняются на тестовой копии.

Что обычно ломается

Собственный PHP-код

В первую очередь проверяю /local/php_interface/, /local/modules/, /local/components/, собственные activity бизнес-процессов, агенты, cron-скрипты и служебные PHP-обработчики.

Сторонние модули

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

Бизнес-процессы

Особенно внимательно проверяю собственные activity, PHP-код внутри процессов и сценарии, которые зависят от сторонних модулей или старого API.

Интеграции

После обновления отдельно тестируются REST, webhook, 1С, телефония, мессенджеры, внешние API, почта и AD/LDAP.

Серверная часть

Также проверяю cron, агенты, Redis, Push/RTC, права файлов, SSL, nginx / Apache и фоновые задачи BitrixVM.

Чек-лист после обновления

Система и окружение

[ ] Проверка системы без критических ошибок
[ ] PHP соответствует требованиям
[ ] MySQL работает
[ ] nginx / Apache запущены
[ ] Redis доступен
[ ] Push/RTC работает
[ ] cron выполняется
[ ] агенты выполняются
[ ] фоновые задачи завершены
[ ] в PHP-логах нет новых критических ошибок
[ ] достаточно свободного места на диске

CRM

[ ] Лид открывается и сохраняется
[ ] Сделка открывается и сохраняется
[ ] Контакт
[ ] Компания
[ ] Реквизиты
[ ] Смарт-процессы
[ ] Пользовательские поля
[ ] Таймлайн
[ ] Активности
[ ] Поиск CRM

Автоматизация

[ ] Роботы запускаются
[ ] Бизнес-процессы стартуют
[ ] Задания БП создаются
[ ] Собственные activity работают
[ ] Обработчики событий выполняются
[ ] Агенты выполняются
[ ] cron-обработчики выполняются

Совместная работа

[ ] Создание и изменение задач
[ ] Комментарии
[ ] Чат задачи
[ ] Уведомления
[ ] Календарь
[ ] Диск
[ ] Документы
[ ] Мессенджер

Коммуникации

[ ] Исходящая почта
[ ] Входящая почта
[ ] Входящие звонки
[ ] Исходящие звонки
[ ] Открытые линии
[ ] Подключённые мессенджеры

Интеграции

[ ] REST-приложения
[ ] Входящие webhook
[ ] Исходящие webhook
[ ] 1С
[ ] AD/LDAP
[ ] Внешние API
[ ] Синхронизация файлов

Отдельно прохожу все собственные решения из /local, потому что штатная проверка системы не способна проверить их бизнес-логику.

Обновление боевой коробки

Главный результат тестовой установки — не просто работающий тестовый портал. После неё появляется точная инструкция, что и в каком порядке нужно сделать на production.

К этому моменту уже известно:

  • сколько занял каждый этап;
  • какие обновления устанавливались;
  • в какой последовательности менять версии;
  • какие ошибки появились;
  • какой собственный код пришлось исправить;
  • какие модули нужно обновить заранее;
  • какие сервисы необходимо перезапустить;
  • какие проверки выполнить после запуска.

Перед production-обновлением снова создаётся свежая резервная копия. Если инфраструктура позволяет, дополнительно создаётся snapshot виртуальной машины или сервера. Также заранее определяется окно обслуживания и способ отката.

Production
    │
    ├── свежий backup
    ├── snapshot
    ├── остановка критичных интеграций
    │
    ▼
повторение проверенного сценария
    │
    ▼
функциональный чек-лист
    │
    ▼
возврат интеграций
    │
    ▼
контроль логов

На боевой системе я стараюсь не менять последовательность действий, которая уже была проверена на копии. Production должен быть повторением репетиции, а не вторым экспериментом.

Полезные официальные материалы