Обновление модулей 1С-Битрикс: как снизить риск поломок

Обновление модулей 1С-Битрикс лучше не воспринимать как безопасную кнопку в админке. В большинстве случаев всё проходит нормально, но на старых проектах обновление может задеть шаблоны, кастомные обработчики, PHP-версию, сторонние модули или обмен с 1С.

Подход простой: сначала резервная копия и тестовая копия, потом обновление, потом проверка рабочих сценариев. На production без подготовки обновляться рискованно.

Сделать резервную копию

Перед обновлением должна быть свежая копия базы и файлов. Особенно важны upload, local, bitrix/php_interface и кастомные шаблоны.

mysqldump --single-transaction -u user -p database | gzip > before-update.sql.gz
tar -czf before-update-files.tar.gz local bitrix/php_interface upload

Если проект большой, лучше использовать штатный механизм резервного копирования или серверные инструменты. Главное — понимать, как восстановиться.

Проверить тестовую копию

Обновления стоит сначала ставить на копии сайта. Тестовая копия должна быть достаточно похожа на production: та же версия PHP, похожие настройки сервера, актуальная база или её свежая копия.

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

php -v
php -m

Посмотреть кастомизацию

На Битрикс-сайтах часто доработаны шаблоны компонентов, result_modifier.php, component_epilog.php, init.php и обработчики событий. После обновления они могут начать работать иначе.

find local/templates -name "result_modifier.php"
find local/php_interface -type f
grep -R "AddEventHandler" -n local bitrix/php_interface

Если проект дорабатывали прямо в bitrix/components или bitrix/modules, это отдельный риск. Такие правки могут быть потеряны при обновлении.

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

Модули из Marketplace тоже могут конфликтовать с обновлениями. Нужно проверить, поддерживают ли они текущую версию PHP и ядра Битрикс.

• платёжные модули;
• модули доставки;
• интеграции с CRM;
• SEO-модули;
• модули обмена и выгрузок.

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

Обновлять не в час пик

Даже небольшое обновление может занять время или потребовать очистки кэша. Лучше выполнять его в окно низкой активности и заранее понимать, кто проверяет сайт после обновления.

Что проверить после обновления

1. Главная страница и несколько внутренних страниц.
2. Каталог, фильтр и карточка товара.
3. Корзина и оформление заказа.
4. Авторизация и личный кабинет.
5. Формы обратной связи.
6. Отправка почтовых событий.
7. Обмен с 1С, если используется.
8. Агенты и cron.
9. Логи PHP и веб-сервера.

tail -n 150 /var/log/nginx/error.log
tail -n 150 /var/log/php-fpm/error.log

Кэш после обновления

После обновления может потребоваться очистка кэша Битрикс, managed cache, композита и OPcache. Но очистка не должна заменять проверку ошибок.

rm -rf bitrix/cache/*
rm -rf bitrix/managed_cache/*
rm -rf bitrix/stack_cache/*

Если включён OPcache, иногда нужен перезапуск PHP-FPM.

План отката

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

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

Чек-лист

1. Сделать свежий бэкап базы и файлов.
2. Проверить обновление на тестовой копии.
3. Проверить PHP-версию и расширения.
4. Найти кастомные обработчики и шаблоны.
5. Проверить критичные сторонние модули.
6. Обновляться не в час пик.
7. Проверить основные сценарии после обновления.
8. Посмотреть логи и очистить кэш при необходимости.
9. Иметь понятный план отката.

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