Как безопаснее обновлять коробочный Bitrix24

На чистом портале обновление обычно проходит проще. На живом портале почти всегда есть доработки: локальные модули, обработчики событий, агенты, бизнес-процессы, REST-приложения, изменённые шаблоны и сторонние решения.

После обновления могут проявиться такие проблемы:

• ошибки PHP в старом кастомном коде;
• несовместимость локального модуля с новой версией ядра;
• изменения в интерфейсе, из-за которых ломается JavaScript-доработка;
• ошибки в обработчиках событий CRM;
• неработающие агенты или cron-задачи;
• ошибки сторонних решений из Marketplace;
• проблемы после смены версии PHP.

Поэтому безопасный подход — сначала получить эти ошибки на тестовой копии, а не на рабочем портале.

Я бы перед обновлением сохранял минимум такой список:

• текущую версию главного модуля и важных модулей;
• версию PHP;
• версию MySQL/PostgreSQL;
• тип окружения: BitrixVM, свой сервер, хостинг, контейнеры;
• список локальных модулей в /local/modules;
• список сторонних решений из Marketplace;
• список агентов и cron-задач;
• критичные бизнес-процессы и роботы;
• кастомные обработчики событий;
• интеграции: REST-приложения, вебхуки, обмены, телефония, почта.

Отдельно стоит проверить активность лицензии и доступность обновлений. Если планируется переход на новую версию PHP, сначала нужно проверить требования Bitrix24 и совместимость своих модулей.

Резервная копия

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

Что важно проверить:

• бэкап действительно содержит файлы и базу;
• архив не битый;
• есть место для восстановления;
• понятно, где лежат .settings.php, dbconn.php, .htaccess и nginx/apache-конфиги;
• есть доступы к серверу, базе и административной части;
• известно, сколько примерно занимает восстановление.

Сам факт создания бэкапа ещё не гарантирует откат. Хороший бэкап — это тот, который уже получилось поднять на отдельной копии.

Копию лучше поднимать в окружении, максимально похожем на боевой сервер: та же версия PHP, похожие настройки nginx/apache, cron, права на файлы, расширения PHP и параметры базы.

На копии нужно проверить:

• открывается ли административная часть;
• работает ли публичная часть портала;
• открывается ли CRM;
• работают ли авторизация и права;
• нет ли ошибок в PHP-логах;
• не запускаются ли внешние интеграции в боевые сервисы.

Перед проверкой лучше отключить или перенастроить опасные внешние действия: отправку писем клиентам, реальные вебхуки, обмены с 1С, SMS, телефонию и любые интеграции, которые могут повлиять на боевые данные.

На тестовой копии обновления ставятся так же, как потом будут ставиться на боевом портале. В админке это раздел Marketplace → Обновление платформы.

Я бы обновлял в таком порядке:

1. зафиксировать список доступных обновлений;
2. обновить ядро и стандартные модули;
3. обновить сторонние решения из Marketplace;
4. если нужно — отдельно проверить переход на новую версию PHP;
5. очистить кеши;
6. проверить агенты и cron;
7. проверить логи ошибок.

Если обновление зависло или оборвалось, это уже полезный результат теста. Значит на бою такой же сценарий может закончиться нестабильным состоянием.

После обновления тестовой копии нужно проверить не только главную страницу. В коробочном Bitrix24 проблемы часто проявляются в конкретных сценариях.

Минимальный набор проверки:

• CRM: лиды, сделки, контакты, компании, смарт-процессы;
• карточки CRM с кастомными вкладками и встройками;
• роботы и бизнес-процессы;
• агенты и cron;
• локальные модули;
• REST-приложения и вебхуки;
• открытые линии и чаты;
• задачи и уведомления;
• почта и отправка писем;
• права доступа;
• PHP-логи и журнал событий.

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

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

Порядок действий:

1. выбрать окно работ, когда порталом пользуются меньше всего;
2. предупредить пользователей;
3. сделать свежий бэкап файлов и базы;
4. зафиксировать текущие версии модулей;
5. при необходимости временно отключить внешние регламентные задания;
6. поставить те же обновления, которые уже проверены на копии;
7. обновить сторонние решения;
8. очистить кеши;
9. применить подготовленные правки кастомных доработок;
10. проверить ключевые сценарии.

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

После обновления чаще всего приходится смотреть не только платформу, но и свой код. Особенно если портал давно не обновлялся.

Что обычно проверять в доработках:

• локальные модули в /local/modules;
• компоненты и шаблоны в /local/components;
• обработчики событий;
• агенты;
• PHP-код в бизнес-процессах;
• REST-приложения;
• JavaScript-встройки в карточках CRM;
• использование устаревших классов и методов;
• совместимость с текущей версией PHP.

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

Когда лучше откатиться

Иногда правильнее не чинить всё на бою, а быстро откатиться на бэкап и спокойно разбирать проблему на копии.

Откат стоит рассматривать, если:

• не открывается административная часть;
• массово не открываются CRM-карточки;
• сломалась авторизация;
• не работают критичные бизнес-процессы;
• появились ошибки базы данных;
• обновление оборвалось в середине;
• непонятно, какие файлы и модули успели обновиться;
• исправление требует долгой разработки прямо на бою.

Откат — это не провал обновления. Это нормальная часть плана, если обновление пошло не по проверенному сценарию.