Bitrix упал после обновления: откат и стабилизация

Обновление поставили «на пять минут после обеда». Через двадцать сайт отдаёт белый экран или бесконечную загрузку. Телефон отдела продаж разрывается: формы не уходят, корзина молчит, контент менеджер не может зайти в админку. В чате уже пишут «откатите всё», но бэкап вчерашний, а кто делал снимок перед апдейтом — неизвестно.

Страх обновлений Битрикс почти всегда рождается из такого эпизода. После него команда месяцами живёт на устаревших модулях — пока очередная уязвимость или несовместимость не заставит обновляться в ещё худших условиях.

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

Сценарий первый: обновили ядро или модуль на проде без копии. Кастомный код в init.php, старый шаблон или забытый обработчик события конфликтует с новой версией. Сайт падает сразу, откатывать некуда — свежего бэкапа файлов и базы нет.

Сценарий второй: обновление «вроде прошло», но отвалились интеграции. Платёжка, обмен с 1С, вебхуки CRM. Визуально главная страница жива, деньги и заявки — нет. Бизнес узнаёт об этом по пустому отчёту за день.

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

Типичные грабли

Обновлять в пятницу вечером «пока трафик меньше». Если что-то пойдёт не так, команда поддержки уже в нерабочем состоянии, а понедельник встречает накопленным долгом.

Не вести журнал кастомизаций. Через два года никто не помнит, какой агент или событие критичны. Обновление становится лотереей.

Считать, что «хостинг сам бэкапит» и этого достаточно. Общий бэкап хостера часто слишком грубый по RPO: между снимками как раз и успевают сделать злополучный апдейт.

Что делать, когда уже упало

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

Если есть снимок до обновления — откатывают согласованно файлы и базу на одну точку. Если снимка нет, ищут последний целый бэкап и оценивают потерю данных: заказы, контент, регистрации за окно простоя. Это неприятный разговор с бизнесом, но честный.

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

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

Как обновляться, чтобы не бояться

Рабочая схема проста и скучна — поэтому её редко соблюдают. Тестовая копия с актуальными данными (или близкими). Прогон обновления там. Проверка ключевых сценариев: авторизация, оформление заказа, формы, обмен, админка. Только потом — окно на проде с бэкапом непосредственно перед стартом.

Кастомизации выносят из «непонятных правок ядра» в поддерживаемый слой: свой модуль, понятные обработчики, документированные зависимости. Чем меньше сюрпризов в коде, тем короче список регрессий.

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

Роль тестового контура и кастомизаций

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

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

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

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

Что получает бизнес

Управляемые обновления возвращают возможность жить на поддерживаемых версиях без постоянной угрозы «если нажмём — ляжем». Это влияет на безопасность, совместимость модулей и скорость развития сайта.

Главный результат для руководителя — предсказуемость. Есть бэкап, есть тест, есть окно работ, есть откат. Тогда фраза «нужно обновить» перестаёт быть конфликтом между IT и маркетингом и становится обычной эксплуатационной задачей.

Цена спокойствия

Падение после обновления бьёт не по «сайту как таковому», а по каналу продаж и сервиса. Час простоя интернет-магазина или генерации лидов считается деньгами. Страх обновляться потом стоит ещё дороже: растёт технический долг и окно уязвимостей.

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

Ещё один практический совет: договоритесь заранее, кто имеет право нажимать «обновить» в бою. Пока кнопка доступна всем с админ доступом, риск повтора инцидента остаётся организационным, даже если техника готова. Короткий чек перед апдейтом — бэкап свежий, стенд прогнан, окно согласовано, откат понятен — должен стать привычкой, а не героизмом редкого специалиста.

Если после падения пришлось восстанавливаться из неидеальной точки, зафиксируйте потерю данных письменно: какие заказы/контент затронуты, что восстановлено вручную. Эта дисциплина потом спасает споры между отделами и помогает улучшить RPO бэкапов.

Отдельно стоит договориться с бизнесом о окне работ и критерии «можно обновлять»: нет активной рекламной кампании, дежурный на связи, бэкап проверен восстановлением хотя бы выборочно. Тогда обновление перестаёт быть сюрпризом для продаж.

Если кастом глубокий, заложите в календарь не только сам апдейт, но и час на проверку ключевых сценариев после него глазами менеджера и глазами клиента. Технический «сайт открылся» ещё не означает, что заказ проходит до конца.

И последнее: храните историю инцидентов обновлений. Через год это лучший аргумент, какие модули трогать осторожнее и где пора переписать кастом.