Обновление платформы 1С-Битрикс безопасно, когда у вас есть тестовый сервер с той же версией PHP и базы, свежая резервная копия и список собственных доработок. Совместимость проверяют на копии сайта, откат готовят до запуска обновления, а на боевой сайт обновление ставят в часы минимальной посещаемости.
Типичная картина на проектах B2BPRO.KZ выглядит так. Сайт работает три года, лицензия на обновления давно продлена, а кнопку «Установить» никто не нажимает: боятся, что отвалится форма заявки или каталог. Через год-два к этому добавляется второй повод для тревоги, устаревший PHP, и обновление превращается в одновременную смену платформы, модулей и версии языка. Именно в такой связке сайты и падают. Разбираем, как этого избежать.
Что такое совместимость при обновлении и почему сайт ломается
Совместимость при обновлении платформы 1С-Битрикс: это способность вашего кода, сторонних решений и серверного окружения работать с новой версией ядра и модулей без ошибок. Сайт ломается не от самого обновления, а от того, что новая версия платформы встречается с чем-то старым: модулем, шаблоном, версией PHP или нестандартной правкой в ядре.
Источников проблем обычно четыре:
- собственные компоненты и шаблоны, написанные под старое поведение ядра;
- решения из Маркетплейса, которые давно не обновлялись разработчиком;
- версия PHP, не подходящая для новой версии платформы;
- правки, внесённые прямо в файлы ядра, которые обновление перезапишет.
Последний пункт самый неприятный, потому что о таких правках часто никто не помнит. Подрядчик, который работал два года назад, мог поправить файл ядра «на минуточку», и в документации проекта об этом нет ни строчки.
Как проверить совместимость до обновления?
Совместимость проверяют на копии боевого сайта: сначала составляют перечень того, что стоит на проекте, затем ставят обновление на копию и прогоняют сценарии, от которых зависят деньги. На боевом сайте экспериментировать не стоит.
Рабочий порядок такой:
- Выпишите версию платформы, список установленных модулей и список решений из Маркетплейса. Для каждого решения проверьте, обновлялось ли оно разработчиком недавно.
- Найдите собственный код: пользовательские компоненты, шаблоны, обработчики событий, подключаемые файлы. Если проект вёл не один подрядчик, попросите каждого подтвердить, что в ядро правок не вносилось.
- Зафиксируйте текущую версию PHP и базы данных на боевом сервере.
- Составьте короткий перечень критичных сценариев: оформление заказа, отправка форм, оплата, обмен с учётной системой, личный кабинет.
- Поднимите копию сайта на тестовом сервере и обновите её первой.
- Пройдите перечень сценариев вручную и посмотрите журнал ошибок.
Шестой шаг проще всего недооценить. Страница открывается, и кажется, что всё хорошо, а ошибка прячется в обработчике, который срабатывает раз в сутки. Поэтому на тестовом сервере стоит оставить копию на день-два и посмотреть, не появились ли записи в журнале.
Каким должен быть тестовый сервер?
Тестовый сервер должен быть точной копией боевого: те же версии Bitrix Framework, PHP, СУБД и остального программного обеспечения. Так сказано в официальном курсе 1С-Битрикс об обновлении и изменении боевого проекта. Если версии различаются, вы рискуете получить ошибки, которых на тесте не было, или, наоборот, не увидеть тех, что появятся на проде.
Курс описывает и порядок работы на тестовом сервере. Сначала обновляют системное ПО и Bitrix Framework, если для них есть обновления. Затем из системы контроля версий передают код и базу данных. После этого проводят модульное, функциональное и нагрузочное тестирование. Нагрузочное тестирование на небольших сайтах часто пропускают, и это допустимо, но функциональные проверки по перечню критичных сценариев пропускать нельзя.
Для небольшого сайта система контроля версий может отсутствовать вовсе. Тогда копию делают из резервной копии боевого сайта, и это заодно проверяет, что копия вообще восстанавливается. Резервная копия, которую ни разу не разворачивали, остаётся гипотезой.
В каком порядке обновлять платформу, модули и PHP?
Сначала обновляют ядро и модули платформы, затем сторонние решения из Маркетплейса, и только после этого меняют версию PHP. Такой порядок описан в справке Битрикс24 о переходе на PHP 8.x в коробочных версиях, а платформа у коробочного Битрикс24 и «1С-Битрикс: Управление сайтом» общая.
| Шаг | Что делаем | Где в интерфейсе |
|---|---|---|
| 1 | Создаём резервную копию | Настройки > Инструменты > Резервное копирование |
| 2 | Обновляем ядро и все модули продукта | Настройки > Маркетплейс > Обновление платформы |
| 3 | Обновляем сторонние решения | Настройки > Маркетплейс > Обновление решений |
| 4 | Переходим на новую версию PHP на сервере | Настройки сервера или хостинга |
| 5 | Проверяем, не остались ли необновлённые модули и решения | Те же разделы Маркетплейса |
Названия пунктов меню в разных версиях продукта немного отличаются, поэтому сверяйтесь с интерфейсом своей версии. Для нас важна последовательность: PHP меняется последним, когда платформа и решения уже самые свежие.
Что будет, если не обновлять PHP?
Если PHP устарел, вы не сможете установить обновления коробочных версий продуктов 1С-Битрикс: ни исправления ошибок, ни новый функционал. Справка Битрикс24 указывает, что для коробочных версий поддержка ниже PHP 8.2 ограничена начиная с 1 февраля 2026 года, а рекомендуемой названа версия 8.3 и выше. PHP 8.1 достиг конца жизненного цикла и исправлений безопасности больше не получает. Работать на PHP ниже восьмой версии категорически не рекомендуется.
Поэтому на практике откладывать обновление до «когда будет время» означает копить долг: каждый месяц разрыв между версией платформы и версией PHP растёт, а вместе с ним растёт и объём работ.
Какие ошибки появляются после перехода на PHP 8
После перехода на PHP 8.x ошибки возникают чаще всего по трём причинам, и справка называет их прямо: устаревшее ядро или модули, устаревшие сторонние решения, либо разработчик не добавил в свой код поддержку PHP 8.2 и выше. Первые две причины лечатся обновлением, третья требует правки кода.
Если сайт после смены PHP не запускается, справка предлагает запасной путь: вернуться на PHP 7.x, обновить всё до актуального состояния и повторить переход. Он хорош тем, что возвращает сайт в рабочее состояние быстро, но сам по себе проблему не решает. Если собственный код не поддерживает новый PHP, вам всё равно придётся его править, пока версия старого PHP остаётся на сервере и формально продолжает работать.
Для казахстанских компаний к этому добавляется организационный момент: сайт нередко связан с учётной системой, платёжным шлюзом или службой доставки, и каждая такая связь тоже должна пройти проверку после обновления. Составьте перечень интеграций заранее и отметьте, у кого из подрядчиков есть доступ к каждой из них. Когда с ошибкой приходится разбираться ночью, поиск нужного человека отнимает больше времени, чем сама правка.
Что входит в резервную копию и чего в ней нет
Резервная копия 1С-Битрикс: это архив сайта в формате tar.gz, который содержит публичную часть, ядро Bitrix Framework и дамп базы данных. Создаётся она в разделе Настройки > Инструменты > Резервное копирование > Создание резервной копии, место хранения выбирается там же: облако 1С-Битрикс, локальная папка или стороннее облако. Подробности описаны в документации по резервному копированию.
В документации есть несколько ограничений, о которых полезно знать заранее:
- дамп базы данных создаётся только для MySQL; если у вас PostgreSQL, базу нужно выгружать внешними средствами;
- зашифрованную копию нельзя восстановить без пароля, и расшифровать её не сможет ни сама компания, ни техподдержка;
- данные инфоблоков лежат в базе, поэтому восстановить их можно только полным восстановлением базы данных;
- облачное хранилище держит не больше трёх копий;
- на сайте с несколькими сайтами мастер восстановления настраивает только первый, а символические ссылки на /bitrix/ и /upload/ придётся восстанавливать вручную.
Перед обновлением ядра официальный курс рекомендует «горячую» копию, а для быстрого восстановления допускает снимок LVM для файлов и базы данных. Для небольшого проекта достаточно штатной копии, но проверьте, что восстановление реально работает: либо через список копий и мастер восстановления в административной части, либо через скрипт restore.php, который кладут в корень сайта.
Когда и как обновлять боевой сайт?
Боевой сайт обновляют только после успешного тестирования и в часы минимальной посещаемости. Сначала делают резервную копию, затем ставят те же обновления программного обеспечения и Bitrix Framework, что уже прошли проверку на тесте, и только потом переносят код и базу данных из системы контроля версий, если ваш процесс их использует.
«Без простоя» на практике означает «с минимальным окном». Полностью исключить недоступность сайта на время установки нельзя, но её можно сделать короткой и предсказуемой, если подготовка проведена заранее. Окно выбирают по статистике: у интернет-магазина это обычно ночь, у корпоративного сайта выходной день. Конкретное время зависит от вашей аудитории, поэтому смотрите на график посещаемости, а не на общие рекомендации.
Хороший практический приём: заранее договориться, кто принимает решение об откате и по какому признаку. Например, если через полчаса после обновления не проходит оформление заказа, мы возвращаем копию, а не чиним на живом сайте. Решение «чиним на ходу» в пятницу вечером дороже любой копии.
Как откатить обновление платформы, если сайт перестал работать?
Откат у 1С-Битрикс делается восстановлением из резервной копии. Официальный курс называет два варианта действий, если проект перестал работать после обновления по технологии SiteUpdate. Либо как можно быстрее обратиться в техподдержку «1С-Битрикс» и предоставить доступ для восстановления, либо откатиться к предыдущему состоянию, восстановив данные из бекапа.
Поэтому откат нужно готовить заранее:
- Убедитесь, что копия создана непосредственно перед обновлением, а не неделю назад: за неделю в базе накопятся заказы и заявки, и откат их затрёт.
- Проверьте, что копия лежит не только на этом же сервере. Если упадёт диск, потеряются и сайт, и копия.
- Если копия зашифрована, сохраните пароль отдельно от самой копии.
- Заранее решите, что вы делаете с заказами, которые придут между обновлением и откатом. Для небольших магазинов это ручная выгрузка, для крупных нужен отдельный регламент.
Последний пункт обычно забывают. Откат возвращает базу в состояние на момент копии, поэтому всё, что клиенты оставили после неё, исчезает. Чем короче окно между копией и откатом, тем меньше потерь, и это ещё один довод в пользу ночного обновления.
Типичные ошибки при обновлении
Из того, что мы видим на проектах, чаще всего повторяются пять ошибок:
- обновляют сразу всё: платформу, решения и PHP в один вечер, и потом не понимают, что именно сломалось;
- проверяют только главную страницу и забывают про формы, корзину и обмен с учётной системой;
- делают копию, но не проверяют, что её можно развернуть;
- тестовый сервер отличается от боевого по версии PHP, и ошибка проявляется только на проде;
- не фиксируют, какие обновления установлены, и через полгода не могут восстановить картину для подрядчика.
Если у вас много собственных доработок или проект долго не обновлялся, разумнее поручить подготовку специалистам. Мы занимаемся такой работой в рамках разработки и сопровождения сайтов под ключ: составляем перечень доработок, готовим тестовую копию и берём на себя обновление вместе с планом отката.
Как выглядит обновление в день X: чек-лист
В день обновления лучше иметь на руках письменный чек-лист, а не держать порядок в голове: ночью, под давлением, шаги выпадают первыми. Ниже схема, которую мы используем как основу и подстраиваем под проект.
- Предупредите владельца сайта и тех, кто принимает заказы, о времени окна и о том, как долго сайт может быть недоступен.
- Создайте резервную копию и убедитесь, что архив появился в выбранном месте и его размер правдоподобен.
- Запишите текущие версии платформы, модулей, решений и PHP. Эти записи понадобятся и при откате, и при обращении в поддержку.
- Установите обновление ядра и модулей, затем решений из Маркетплейса.
- Пройдите критичные сценарии: оформление заказа, отправка формы, вход в личный кабинет, обмен с учётной системой.
- Посмотрите журнал ошибок и убедитесь, что новых записей нет.
- Если проверка не пройдена, не пытайтесь исправлять на живом сайте: возвращайтесь к копии.
- Сообщите команде, что работы завершены, и зафиксируйте новые версии в журнале проекта.
Этот список выглядит скучно, и в этом его ценность. Обновление платформы должно быть рутиной, а не событием, и каждый шаг чек-листа снижает шанс, что в два часа ночи кто-то поспешит.
Пример: как это работает на практике
Возьмём иллюстративный случай, не конкретного клиента. Интернет-магазин на 1С-Битрикс не обновлялся давно, на сервере устаревший PHP, а в шаблоне каталога лежат собственные компоненты. Задача: привести платформу в актуальное состояние, не потеряв ни одного заказа.
Разумный план из трёх этапов. Сначала разворачиваем копию сайта на тестовом сервере с теми же версиями PHP и базы, ставим обновления ядра и модулей, затем решений и смотрим, что сломалось. На втором этапе исправляем собственные компоненты под новую версию, и этот этап занимает больше всего времени, потому что именно здесь вскрываются правки, о которых никто не помнил. На третьем делаем копию боевого сайта, ставим обновления в ночное окно, проверяем сценарии и только после этого переходим на новую версию PHP, отдельным окном, а не в ту же ночь.
Разделение на два окна выглядит избыточным, но оно экономит время при поиске причины. Если после первого окна всё в порядке, а после второго что-то упало, вы точно знаете, что виновата смена PHP. Если же менять всё сразу, под подозрением оказывается каждое изменение.
Какие признаки говорят, что к обновлению пора готовиться
Есть несколько признаков, при которых откладывать подготовку уже опасно. Каждый из них указывает на то, что разрыв между вашей системой и актуальной версией платформы растёт.
- Сервер работает на версии PHP, которую уже не поддерживает разработчик языка.
- В админке давно висят необновлённые модули и решения из Маркетплейса.
- Подрядчик, который писал доработки, ушёл, а документации по ним нет.
- Резервная копия создаётся, но ни разу не проверялась на восстановление.
- Обновление планируют «когда будет окно», но окно так и не наступает.
Если у вас совпали два пункта из пяти, рассматривайте подготовку обновления как отдельный небольшой проект: с инвентаризацией, тестовой копией и планом отката. Такой проект стоит дешевле, чем экстренное восстановление после неудачного обновления в боевой среде.
Частые вопросы
Как часто нужно обновлять платформу 1С-Битрикс?
Регулярно и небольшими порциями, а не раз в несколько лет. Чем меньше разрыв между версиями, тем проще найти причину ошибки и тем меньше работы по приведению доработок в порядок. Удобный ритм: проверять наличие обновлений раз в месяц и ставить их сначала на тестовую копию.
Можно ли обновить платформу без тестового сервера?
Можно, но риск ложится на боевой сайт. Минимальный вариант: сделать полную резервную копию, проверить, что она восстанавливается, обновлять в ночное время и пройти перечень критичных сценариев сразу после установки. Для магазина с заказами лучше всё же поднять тестовую копию.
Что делать, если сайт упал после обновления?
Сначала восстановить сайт, а разбираться потом. Если окно простоя критично, откатитесь к копии, сделанной перед обновлением, либо обратитесь в техподдержку «1С-Битрикс» и предоставьте доступ для восстановления. Причину ошибки ищите уже на тестовой копии, а не на живом сайте.
Нужно ли обновлять PHP вместе с платформой?
Лучше последовательно: сначала ядро, модули и решения, затем PHP. Справка Битрикс24 рекомендует именно такой порядок, а версию PHP советует поднять до 8.3 и выше. Если сначала сменить PHP на старой платформе, вы получите ошибки совместимости, которых можно было избежать.
Сколько резервных копий хранить перед обновлением?
Минимум одну свежую копию непосредственно перед обновлением и одну предыдущую на случай, если свежая окажется повреждённой. Облачное хранилище 1С-Битрикс держит не больше трёх копий, поэтому при необходимости длинной истории копии стоит дополнительно хранить отдельно.