Как обновить 1С-Битрикс без простоя сайта

Совсем без простоя обновить «1С-Битрикс» нельзя, но простой можно свести к минутам и сделать незаметным для посетителя. Механика апдейтеров, подготовка, тестовая копия по правилам лицензии, порядок действий в окне, чек-лист проверки после установки и план отката.

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

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

Если вопрос пока другой — нужно ли обновляться вообще и что будет, если этого не делать, — ответ в отдельном материале про обновление 1С-Битрикс. Здесь только про технику безопасного проведения.

Что означает «без простоя» на практике

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

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

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

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

Чтобы понимать, где именно рвется, нужно знать механику. Она описана в документации вендора и объясняет почти все «внезапные» падения.

Обновления модулей ставятся строго друг за другом, по версиям: каждое содержит только изменение относительно предыдущего. Ядро — файлы в /bitrix/modules/ и системные компоненты — обновляется автоматически, простым копированием файлов. Все остальное, включая структуру базы данных и файлы вне ядра, автоматически не обновляется. За это отвечает механизм апдейтеров.

Апдейтер — это PHP-код, который вендор кладет внутрь обновления, чтобы привести базу и служебные файлы в соответствие с новой версией ядра. И вот его особенности, прямо из документации «1С-Битрикс»:

• Один хит. Апдейтер выполняется непосредственно перед копированием файлов обновления в ядро, за один хит. Если хит оборвался по таймауту веб-сервера — вы получаете половину примененных изменений.
• Порядок между модулями не определен. Если за один хит обновляются несколько модулей, апдейтеры выполнятся все, но в каком порядке — не гарантируется.
• Нового API еще нет. На хите обновления API текущего обновления недоступно. Отсюда классическая ошибка вида Class 'Имя\Класса' not found, если ваш код успел обратиться к новым классам.
• Апдейтеры выполняются повторно. Обновление может переустанавливаться, и код апдейтера пишется с учетом многократного запуска. Это же означает, что «доустановить одно обновление поверх» — штатная, а не аварийная ситуация.

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

Из-за чего сайт на самом деле падает после обновления

Ядро вендора протестировано на тысячах установок. Ломается обычно то, что вокруг него.

1. Правки в ядре. Файлы в /bitrix/modules/ перезаписываются как есть. Любая правка, сделанная «по-быстрому» год назад прямо в ядре, исчезает в момент копирования. Симптом: пропал функционал, которого нет ни в одном ТЗ.
2. Старое API в шаблонах и своих компонентах. Методы, которые вендор объявил устаревшими 3 обновления назад, однажды удаляются. Ошибка вылезает там, где используется этот компонент: в фильтре каталога, в форме оформления заказа. Главная при этом открывается нормально, и поломку замечают через сутки.
3. Решения Маркетплейса. Модуль стороннего автора рассчитан на определенную версию ядра. Если автор давно не выпускал обновлений, после апдейта ядра модуль отваливается или роняет страницу целиком.
4. Окружение. Новая версия ядра требует PHP и MySQL не ниже определенных версий. Минимальные требования на сегодня — PHP 8.2 и MySQL 8.0, для Энтерпрайза с поддержкой PostgreSQL — версия 11 и выше (технические требования «1С-Битрикс», август 2026).
5. Кеш и OPcache. После копирования файлов PHP какое-то время отдает из кеша старый байт-код. На сайтах с агрессивными настройками OPcache это выглядит как случайные фатальные ошибки в первые минуты.
6. Права и место на диске. Системе обновлений нужен доступ на запись к ядру. Не хватило прав или свободного места — обновление встанет посередине.
7. Фоновые процессы. Обмен с 1С, импорт прайсов, отправка рассылки, запущенные ровно в момент апдейтера, добавляют к ошибке еще и порчу данных.

Заметьте: в 5 пунктах из 7 проблема известна заранее. Ее можно найти до окна, а не в окне. На этом и строится подготовка.

Подготовка: что сделать до того, как открывать админку

Это самая длинная часть работы и единственная, которая реально сокращает простой. Обновление сайта, который к нему подготовлен, занимает 10 минут. Обновление сайта, который не подготовлен, занимает неопределенное время и заканчивается по-разному.

1. Проверьте окружение. На хостинге запустите скрипт bitrix_server_test.php от вендора: он покажет соответствие сервера требованиям продукта. Если PHP или MySQL ниже минимальных, обновление ядра нужно откладывать до переезда на нормальные версии — как это делается, разобрано в статье про переход Битрикса на MySQL 8.
2. Прогоните «Проверку системы». В админке: Настройки → Инструменты → Проверка системы. Тестирование конфигурации занимает несколько минут; параметры, выделенные красным, чинятся до обновления. Там же есть проверка доступа на запись, в том числе отдельно по ядру — именно она нужна системе обновлений.
3. Сделайте резервную копию и проверьте ее. Настройки → Инструменты → Резервное копирование. Включите экспертные настройки и отметьте «Проверить целостность архива после завершения»: система виртуально распакует архив и подтвердит, что он не поврежден. Ядро архивировать обязательно. Части архива держите по 100 МБ (больше 200 МБ вендор не рекомендует), длительность шага — не больше таймаута веб-сервера, ориентир 30 сек.
4. Прочитайте описания обновлений. Скучно, но именно там вендор пишет предупреждения о возможных проблемах и особенностях установки. Список смотрится заранее: Marketplace → Обновление платформы → Список обновлений.
5. Убедитесь, что обновления вообще доступны. Включите в настройках главного модуля опцию автоматической проверки наличия обновлений. Тогда о проблеме с лицензией вы узнаете заранее, а не в окне: сообщение ERROR_WRONG_CODE появляется на странице обновлений до начала процедуры.
6. Соберите инвентаризацию сайта. Список решений Маркетплейса с версиями, список своих модулей в /local/, список кастомных шаблонов компонентов, отдельно — известные правки в ядре. Если этого списка нет, его составление и есть первая работа; в Design Lab он входит в паспорт проекта и обновляется после каждой доработки.
7. Заморозьте свои релизы. Обновление платформы и выкладка собственного кода в один вечер — гарантия того, что при поломке вы не поймете, чья она.

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

Тестовая копия: единственный законный способ ничего не бояться

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

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

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

Как поднять копию:

1. Создайте резервную копию боевого сайта (можно исключить из архива статистику, поисковый индекс и журнал событий — они пересоздаются).
2. Возьмите скрипт restore.php с сайта вендора и положите его в корень тестовой площадки. Владельцем файла должен быть пользователь, под которым работает веб-сервер, иначе скрипт не сможет писать файлы.
3. Откройте https://тестовый-адрес/restore.php и пройдите мастер. При переносе на новый сервер включите опцию «Создать базу, если не существует».
4. Закройте копию от посторонних: базовая HTTP-авторизация на уровне веб-сервера и запрет индексации. Копия магазина в открытом доступе — это утечка персональных данных покупателей и дубли в поиске одновременно.
5. После восстановления удалите архив и служебные скрипты — мастер предлагает это отдельной кнопкой.

На копии обновляетесь по тому же плану, что собираетесь применить на бою, и записываете все, что сломалось. Этот список и есть настоящая смета работ. Обычно после первого прогона выясняется, что обновление ядра занимает 12 минут, а починка 2 модулей Маркетплейса — 6 часов.

Полезная деталь про облачные копии: они привязаны к лицензионному ключу, запись возможна только с оригинальной установки и с одной копии для разработки. Объем облака зависит от редакции — от 2 ГБ на «Старте» и «Стандарте» до 60 ГБ на «Энтерпрайзе», и хранится там не больше 3 копий: при создании новой самая старая удаляется автоматически. Рассчитывать на облако как на архив за полгода нельзя.

Как выбрать окно

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

Данные по часам берите из своей системы аналитики — отчет по времени суток за последний месяц. Час, который кажется мертвым, у половины сайтов B2C оказывается вечерним пиком мобильного трафика.

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

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

Ниже — рабочая последовательность для сайта, который уже прошел обновление на копии. Она рассчитана на 20–40 минут вместе с проверками.

1. Свежая копия прямо перед стартом. Даже если вчерашняя есть. Между вчера и сейчас появились заказы и заявки, и именно их вы потеряете при откате.
2. Остановите фоновые процессы. Обмен с 1С, крон-задачи импорта, массовые рассылки. Агенты на хитах остановятся сами, когда сайт закроется, но обмен по расписанию — нет.
3. Обновите систему обновлений. На странице Marketplace → Обновление платформы сначала нажимается «Обновить систему SiteUpdate», если такая кнопка активна. Пока не установлено обновление самой системы обновлений, остальное ставить нельзя.
4. Посмотрите состав. Вкладка «Список обновлений» покажет, что именно поедет. Здесь же отмечаются конкретные обновления, если ставить все сразу вы не собираетесь.
5. Включите экспертный режим и задайте потолок версии. На вкладке «Экспертный режим» указывается, до какой версии ставить обновления по каждому модулю. Для старого сайта это единственный вменяемый способ двигаться ступенями.
6. Не разрывайте связанные модули. Часть обновлений зависит от обновлений других модулей. Вендор предупреждает прямо: для частичного обновления выбирайте либо все связанные модули, либо ни одного. Удаление из списка одного связанного модуля автоматически удалит остальные.
7. Запустите установку и не трогайте вкладку. Кнопка «Остановить установку» не прерывает процесс мгновенно: система завершит загрузку модуля, который обновлялся в этот момент. Если произошел сбой, система уведомит об этом, и процесс нужно будет повторить.
8. Сбросьте кеш. Кеш компонентов, кеш меню, при необходимости — перезапуск php-fpm или сброс OPcache. До сброса любые ошибки на сайте могут быть ложными.
9. Откройте журнал обновлений. В нем видны статусы и ошибки установки по каждому обновлению. Это первое место, куда стоит смотреть, а не логи веб-сервера.
10. Прогоните проверку. Чек-лист из следующего раздела, по нему же принимается решение «оставляем» или «откатываемся».
11. Верните фоновые процессы. Обмен, кроны, рекламу с паузы. Обмен запускается последним и первый цикл наблюдается вручную.

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

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

Кнопка ставит все разом. Для сайта, который обновлялся месяц назад, это ровно то, что нужно: 3–5 обновлений, минута работы. Для сайта, который не трогали 2 года, за одну кнопку прилетают десятки обновлений всех модулей, апдейтеры выполняются пачкой, и когда что-то падает, вы не знаете, на какой из версий это произошло.

Экспертный режим решает ровно эту задачу: он позволяет задать потолок версии и подниматься ступенями. Между ступенями сайт проверяется. Найденная поломка сразу привязана к конкретному диапазону версий, и ее причина ищется за минуты, а не за вечер.

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

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

Что проверять сразу после установки

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

• главная и 2–3 внутренние страницы открываются, в подвале нет PHP-предупреждений;
• каталог: фильтр, сортировка, пагинация, страница товара;
• корзина: добавление, изменение количества, удаление;
• оформление заказа целиком, до страницы «спасибо», с реальным тестовым заказом;
• оплата: переход на платежную страницу и возврат обратно;
• формы обратной связи: заявка доходит на почту и в CRM;
• авторизация и регистрация, восстановление пароля;
• админка: список заказов открывается, товар редактируется и сохраняется;
• обмен с 1С: один цикл вручную, с проверкой цен и остатков у 2–3 товаров;
• поиск по сайту;
• мобильная версия хотя бы бегло;
• журнал событий: новых записей об ошибках нет.

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

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

Ошибки, которые встречаются чаще всего

Формулировки ниже взяты из документации вендора, вместе с причинами. Если увидели что-то из этого — не гадайте, причина известна.

• «Ошибка соединения с сервером обновлений: [110] Connection timed out». Скрипт обновления не может достучаться до сервера вендора на порт 80. Причины: недоступны функции работы с сокетами (в частности fsockopen()), запрещены исходящие соединения на 80 порт, не хватает памяти на сервере, проблемы в сети. Чинится на стороне администратора сервера.
• [SITE_LICENSE_VIOLATION], превышено количество лицензированных сайтов. В системе не зарегистрировано ни одного сайта, все сайты деактивированы или активных сайтов больше, чем разрешает лицензия. Смотреть: Настройки → Настройки продукта → Сайты → Список сайтов.
• [ERROR_WRONG_CODE]. Текущее состояние установки не совпадает с тем, которое система запомнила после прошлого обновления. Обычно это следствие переноса копии туда-обратно или обновления обеих копий по одному ключу.
• Class 'CUpdateExpertMode' not found. Выглядит как поломка ядра, а на деле это OPcache: параметр opcache.validate_timestamps выставлен в 0, должен быть On.
• Обновления не находятся вовсе. Проверьте поле «Имя сервера, содержащего обновления» в настройках главного модуля. Правильный адрес — www.1c-bitrix.ru.

Белый экран после обновления в этот список не входит, потому что причина у него каждый раз своя. Порядок действий такой: журнал обновлений, журнал событий, лог ошибок PHP на сервере. В 9 случаях из 10 в логе лежит имя файла вашего шаблона или стороннего модуля, и дальше все понятно.

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

План отката

План отката пишется до окна и состоит из 3 вещей: критерий, процедура, ответственный. Без критерия команда чинит сайт до утра, потому что каждый раз кажется, что осталось совсем чуть-чуть.

Разумный критерий: если через 30 минут после установки ключевой сценарий (обычно это оформление заказа) не работает и причина не найдена — откатываемся и разбираемся на копии.

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

Процедурно есть 2 пути. Через админку: Настройки → Инструменты → Резервное копирование → Список резервных копий, в меню нужной копии — «Восстановить». Если админка недоступна — тот же restore.php в корне сайта. При многотомном архиве загружайте все части; при ошибке 413 Request Entity Too Large — партиями по 9–10 файлов.

После восстановления возможны 2 неприятности, о которых вендор предупреждает отдельно: могут не работать вход через AD/LDAP и двухфакторная авторизация. Лечится SQL-запросами к b_user и b_option — держите их под рукой заранее, чтобы не искать в 3 часа ночи.

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

Если сайт не обновлялся 2–3 года

Это отдельный жанр работ, и относиться к нему как к «нажать кнопку» нельзя. Порядок примерно такой.

Сначала окружение, потом ядро. Свежие версии ядра требуют PHP 8.2 и MySQL 8.0. Если на сервере PHP 7.4, обновление ядра либо не поставится, либо поставится и уронит сайт. Правильная последовательность: поднять версии на тестовой копии, починить свой код под новый PHP, перенести на бой, и только потом браться за ядро.

Проверьте лицензию. Обновления доступны, пока действует продление. Если оно закончилось 2 года назад, сначала продление, потом все остальное. Сайт при этом продолжает работать — но замирает в той версии, в которой был, вместе со всеми незакрытыми уязвимостями. Какие именно дыры при этом остаются открытыми, видно в материале про уязвимости 1С-Битрикс.

Идите ступенями. Экспертный режим, потолок версии, проверка после каждой ступени. Да, это дольше. Зато каждая поломка привязана к конкретному диапазону версий.

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

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

Регламент вместо подвига

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

Практический вывод один: перенесите обновления из категории «когда-нибудь дойдут руки» в календарь. Раз в месяц, фиксированный день, заранее известное окно, ответственный человек. Это скучно и работает.

Мы в Design Lab ведем обновления именно так: раз в месяц ступенями через экспертный режим, сначала на копии, потом на бою, с проверкой по чек-листу конкретного проекта. Это часть поддержки сайта на 1С-Битрикс: абонемент считается от 3500 руб./ч. при минимуме 10 ч./мес. Если ваш сайт давно не обновлялся и непонятно, с какой стороны к нему подходить, — напишите нам, посмотрим состояние платформы и скажем, во что обойдется привести ее в порядок.