Как безопасно обновлять Битрикс и модули, чтобы не сломать рабочий сайт

«Не трогай — работает» — это плохая стратегия для сайта на Битриксе. С каждым месяцем без обновлений сайт становится менее безопасным, теряет совместимость с новыми версиями PHP и накапливает технический долг. Но и обратное — «сразу обновлять всё» — тоже плохо: одно обновление может сломать кастомный модуль и положить сайт. Разберём, как обновлять Битрикс безопасно, чтобы и риск минимизировать, и не отставать от современности.

Что вообще обновляется

В Битриксе три уровня обновлений, и каждый требует отдельного подхода:

• Ядро (платформа): главные модули `main`, `iblock`, `sale`, `catalog` и т.д. — выходят раз в 1–2 месяца.
• Дополнительные модули: установленные с маркетплейса или сторонние — обновляются по мере выхода патчей.
• Темы и шаблоны: иногда обновляются, но обычно их обновлять небезопасно (если шаблон кастомный, родительские правки затрут ваши).

Когда обновлять, а когда не стоит

Обновлять обязательно: при выходе патчей безопасности (об этом приходит уведомление в админку). Желательно: раз в 1–2 месяца — текущие минорные обновления. Можно отложить: мажорные обновления — лучше переждать первые 2–4 недели, пока выловят баги первых пользователей.

Не стоит обновлять: накануне распродаж, в высокий сезон, в пятницу вечером (классика). Если сайт критичен для бизнеса — обновляйте только в окна низкой нагрузки и с возможностью быстрого отката.

Подготовка: 3 ингредиента безопасного обновления

Без этих трёх вещей обновление = русская рулетка.

• Тестовое (стейджинг) окружение — копия продакшна, на которой проводится обновление до боевого.
• Свежий бэкап продакшна — перед любым обновлением, обязательно.
• План отката — что делать, если после обновления что-то сломалось.

Шаг 1. Стейджинг — обязательно

Стейджинг — это полная копия продакшна (код, БД, файлы) на отдельном домене. На стейджинге в первую очередь катятся обновления, проверяется, что ничего не сломалось, и только потом — на продакшн.

Что важно: данные в стейджинге должны быть свежими (хотя бы недельной давности), а не годовалыми. Иначе обновление пройдёт на «чистой» базе, а на боевой — упадёт. Идеально — автоматическое еженедельное обновление стейджинга из бэкапа продакшна (с маскировкой персональных данных, если требует регламент).

Шаг 2. Бэкап и план отката

Перед обновлением сделайте полный бэкап: файлы (можно инкрементально, кроме `bitrix/cache` и `bitrix/managed_cache`) и БД. Сохраните где-то отдельно от сервера. Проверьте, что бэкап реально читается — недостаточно знать, что файл существует.

План отката должен отвечать на вопрос: что мы делаем, если через 30 минут после обновления сайт не работает? Варианты: восстановить из бэкапа (медленно, 30–60 минут), переключить трафик на запасной сервер с предыдущей версией (быстро, но требует подготовки), вручную откатить ключевые файлы (рискованно).

Если у вас нет ответа на вопрос «как откатить обновление за 5 минут» — значит, у вас нет надёжного процесса обновлений.

Шаг 3. Обновление на стейджинге

Зайдите в админку стейджинга → «Marketplace → Установленные решения → Обновление платформы». Запустите обновление. Битрикс скачает архивы и предложит установить.

Что проверить ПОСЛЕ обновления стейджинга:

• Главная страница открывается без ошибок (проверьте `/bitrix/admin/site_checker.php`).
• Каталог открывается, фильтры работают, поиск отдаёт результаты.
• Карточка товара отображается корректно.
• Корзина: добавление, изменение количества, оформление заказа.
• Тестовая оплата проходит, заказ создаётся в БД.
• Уведомления о заказе приходят.
• Обмен с 1С (если запущен по расписанию) — отрабатывает без ошибок.
• Личный кабинет открывается, история заказов видна.
• Админка — все нужные модули работают, ошибок в логе нет.
• Скорость не упала — прогон через PageSpeed.

Шаг 4. Smoke-тесты

Smoke-тест — это быстрый прогон по основным сценариям. Идеально — автоматизировать через что-то вроде Playwright или Selenium: сценарий «открой главную → найди товар → добавь в корзину → оформи заказ → проверь, что заказ создан». 5 минут — и видишь, всё ли в порядке.

Если автоматизированных тестов нет — хотя бы пройдитесь руками по чек-листу из шага 3. Это занимает 20–30 минут и спасает от 90% проблем на продакшне.

Шаг 5. Окно обновления продакшна

Когда стейджинг обновлён и проверен, планируйте обновление продакшна. Лучшее время — ночь с воскресенья на понедельник или окно низкой нагрузки по вашей аналитике. Уведомите менеджеров и руководство (но не клиентов — обновление должно пройти незаметно).

Включите режим обслуживания (или хотя бы плашку «временно недоступно»), сделайте свежий бэкап, проведите обновление, прогоните smoke-тесты на продакшне, отключите режим обслуживания. Весь процесс — обычно 20–60 минут.

Шаг 6. Мониторинг после релиза

Первые 24 часа после обновления — повышенное внимание:

• Мониторинг ошибок (Sentry, Rollbar или хотя бы лог Битрикса) — каждые 30 минут.
• Конверсия в заявку и оформление заказа — сравнить с обычным днём.
• Скорость загрузки страниц — не упала ли.
• Жалобы менеджеров и клиентов — обычно приходят первыми.

Если в первые 2–6 часов всплывает критическая ошибка — действуйте по плану отката. Не пытайтесь «починить за час» — лучше быстро вернуться на предыдущую версию и спокойно разобраться.

Особый случай: обновление модулей с маркетплейса

Сторонние модули обновляются отдельно от ядра, и тут больше риски. Перед обновлением проверьте:

• Есть ли у разработчика changelog — что именно меняется?
• Есть ли отзывы и обсуждения нового релиза в маркетплейсе?
• Совместима ли новая версия с вашей версией ядра?
• Не отвалится ли поддержка PHP вашей версии?
• Не сделаны ли в этом модуле кастомные правки (если да — обновление их затрёт).

Если модуль критичный (платежи, доставка, обмен с 1С) — обновляйте его отдельно от других, чтобы можно было точно понять, что сломалось.

Регулярность как привычка

Самая большая ошибка — копить обновления годами, а потом обновляться «одним прыжком». Если последний раз обновлялись 2 года назад — чем больше пропущено, тем выше риск, что что-то сломается необратимо. Лучше обновляться раз в 1–2 месяца понемногу, чем раз в год — много и страшно.

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

Распечатайте и держите рядом с админом перед каждым релизом.

• 1. Стейджинг свежий (данные не старше недели).
• 2. Сделан бэкап продакшна, проверена читаемость.
• 3. План отката — есть, и команда знает, что делать.
• 4. Окно обновления — низкая нагрузка, рабочие на месте.
• 5. Прогнано обновление на стейджинге.
• 6. Прошли smoke-тесты — все основные сценарии работают.
• 7. Обновили продакшн с режимом обслуживания.
• 8. Прогнали smoke-тесты на продакшне.
• 9. Отключили режим обслуживания, мониторим первые 6 часов.
• 10. Зафиксировали в журнале изменений: что обновили, когда, что заметили.

Что в итоге

Обновлять Битрикс не страшно, если делать это регулярно и по понятному процессу. Стейджинг + бэкап + чек-лист + правильное окно — этого достаточно, чтобы 95% обновлений проходили незаметно для бизнеса. Оставшиеся 5% сложных случаев решаются заранее — нужно просто не обновляться «вслепую» в пятницу вечером без бэкапа.

Если у вас нет налаженного процесса обновлений или сайт давно не обновлялся — напишите нам. Поможем «подтянуть» сайт до актуальной версии и настроить регулярные обновления как часть техподдержки.