Кнопка «Обновить» в админке 1С-Битрикс выглядит безобидно — пока после клика на боевом магазине не появляется белый экран в разгар продаж. Обновление ядра трогает и файлы, и структуру базы, и способно поднять на поверхность все накопленные «костыли». Поэтому вопрос не в том, обновляться ли (обновляться нужно), а в том, как делать это так, чтобы сайт не лёг.
Это практическое руководство по безопасному обновлению: разберём, что такое ядро и SiteUpdate, почему нельзя обновляться сразу на боевом, как снять бэкап-план отката, прогнать обновление на стейджинге, проверить обмен с 1С и выстроить регламент. Если ядро давно не трогали и накопился разрыв версий, начать стоит с аудита и оптимизации 1С-контура и сайта.
Коротко
- Никогда не обновляйте ядро сразу на боевом магазине — только на точной копии (стейджинге) с последующим переносом.
- Резервная копия файлов и базы перед обновлением — это ваш единственный план отката; проверьте, что она разворачивается.
- Не правьте /bitrix/ напрямую: логику выносят в /local/, свой модуль и обработчики событий, иначе обновление затрёт доработки.
- После обновления обязательно прогоняйте пробный обмен с 1С: номенклатура, цены, остатки, заказы.
Почему обновление ядра пугает
Страх перед обновлением обоснован: ядро — фундамент, на котором стоит вся платформа, и его изменение может задеть модули, кастомный код и обмен. Но парадокс в том, что не обновляться опаснее, чем обновляться правильно. Устаревшее ядро копит уязвимости, отстаёт от совместимости с новыми модулями и превращает будущий переход в болезненный прыжок через много версий.
Правильный ответ на страх — не избегать обновлений, а сделать процесс предсказуемым: копия, бэкап, проверка, перенос, регламент. Тогда обновление из лотереи превращается в рутинную операцию с понятным результатом.
Что такое ядро и SiteUpdate
Ядро в 1С-Битрикс — это главный модуль main и связанная с ним системная часть в каталоге /bitrix/. Обновления доставляет технология SiteUpdate: система соединяется с сервером обновлений, проверяет активность лицензии и подтягивает новые версии модулей и ядра.
- Проверка лицензии. Обновления доступны при активной подписке на техподдержку.
- Версии по модулям. У каждого модуля своя версия; ядро задаёт совместимость.
- Файлы и база. Обновление может менять и файлы, и структуру БД (миграции).
Понимание, что обновление трогает базу, а не только файлы, — ключ к осторожности: неудачная миграция БД сложнее откатывается, чем перезапись файлов.
Ядро, модули и совместимость
Ядро и модули связаны как фундамент и надстройка. Новая версия модуля магазина может требовать более свежее ядро, а обновлённое ядро — менять поведение методов, на которые опирались доработки. Поэтому обновляют согласованно.
| Что обновляем | Риск | Как снижаем |
|---|---|---|
| Ядро (main) | Меняет поведение API, задевает всё | Проверка на стейджинге целиком |
| Модули каталога/магазина | Требуют совместимого ядра | Обновлять согласованно с ядром |
| Модуль обмена с 1С | Может задеть интеграцию | Пробный обмен после обновления |
| Кастомные модули | Опираются на старое API | Тесты и код-ревью на копии |
Вывод: не обновляйте «по одному модулю на бою». Прогоняйте связку ядро+модули на копии и убеждайтесь, что всё совместимо, прежде чем трогать боевой сайт.
Главное правило: не на боевом
Золотое правило безопасного обновления — сначала на стейджинге, потом на боевом. Стейджинг — это точная копия сайта (файлы + база) на отдельном окружении, где можно ставить обновление, ломать и чинить, не задевая продажи.
Наличие стейджинга — вопрос инфраструктуры и процессов деплоя. Как организовать окружения и безопасную выкладку, подробно разобрано в статье про CI/CD и деплой для 1С-Битрикс, а требования к самим серверам — в материале про хостинг и инфраструктуру на BitrixVM.
Резервная копия как план отката
Бэкап — не бюрократия, а единственный реальный план отката, потому что штатного «отката ядра назад» в 1С-Битрикс нет: версии идут только вперёд. Если обновление на бою сломалось, вернуться можно лишь восстановлением из копии.
- Полная копия файлов. Весь сайт, включая /bitrix/, /local/, /upload/.
- Полный дамп базы. Снятый непосредственно перед обновлением.
- Проверка разворачивания. Бэкап, который не разворачивается, — это не бэкап; проверьте на стейджинге.
- Фиксация версий. Запишите текущие версии модулей — чтобы понимать, откуда и куда идёте.
Регулярные проверенные бэкапы — часть эксплуатации любого магазина, а не разовое действие перед обновлением.
Обновление на стейджинге пошагово
- Разверните точную копию боевого сайта: файлы и база на отдельном окружении.
- Снимите бэкап копии — точку возврата внутри самого стейджинга.
- Запустите обновление через SiteUpdate: ядро и модули согласованно.
- Прогоните проверку: админка, витрина, корзина, оформление заказа, личный кабинет.
- Проверьте кастомный код: доработки, обработчики событий, свой модуль.
- Прогоните обмен с 1С: выгрузку и приём заказов.
- Зафиксируйте проблемы и почините их до переноса на бой.
Ключевая ценность стейджинга: если что-то сломалось, боевой сайт продолжает продавать, а вы спокойно разбираетесь. Откат здесь не нужен — вы просто не переносите проблемное обновление.
Что чаще всего ломается
- Правки прямо в /bitrix/modules/. Обновление перезаписывает эти файлы, и доработки исчезают. Это запрещённая практика — выносите логику в /local/ и свой модуль.
- Устаревшие вызовы API. Код опирается на старые методы, которые изменились или удалены.
- Кастомные шаблоны компонентов. Новая версия компонента меняет структуру данных, шаблон рассыпается.
- Свой модуль на старом ядре. Не проверен на совместимость с новой версией.
- Обмен с 1С. Изменилось поведение модуля обмена или методов торгового каталога.
Большинства этих проблем не будет, если изначально не трогать ядро и вести доработки правильно. О современном подходе к разработке без старых API — в статье про D7 и ORM в 1С-Битрикс, а о структуре собственных модулей — в материале про разработку своего модуля для 1С-Битрикс.
Проверка обмена с 1С после обновления
Для магазина, связанного с учётной системой, проверка обмена — обязательная часть обновления. Если обновились модули каталога, магазина или обмена, поведение интеграции могло измениться.
- Выгрузка номенклатуры. Товары, свойства, разделы приходят корректно.
- Цены и типы цен. Розница, опт, дилеры сопоставлены как раньше.
- Остатки по складам. Наличие обновляется правильно.
- Приём заказов. Заказ с сайта корректно уходит в 1С со статусами.
Пробный обмен на стейджинге снимает главный риск для торговли — тихую поломку интеграции, которую на боевом заметили бы только по расхождению остатков и потерянным заказам. Настройку и надёжность обмена закрывает автоматизация продаж и склада на 1С.
Перенос на боевой и минимизация простоя
После успешной проверки на стейджинге обновление переносят на боевой сайт. Принципы минимизации простоя:
- Окно минимальной нагрузки. Плановое обновление — в часы наименьших продаж.
- Свежий бэкап боевого снят прямо перед переносом.
- Готовый план отката на случай непредвиденного.
- Процесс деплоя. На серьёзных проектах обновление ставят на подготовленное окружение и переключают трафик.
- Постпроверка на бою: витрина, заказ, обмен — сразу после переноса.
Полностью нулевой простой при изменении структуры БД не всегда возможен, но грамотный регламент сокращает его с часов до минут.
Откат при неудаче
Если обновление на бою всё же вызвало проблему, действует один надёжный путь — восстановление из резервной копии файлов и базы, снятой перед обновлением. Именно поэтому бэкап называют планом отката: без него откатываться некуда.
Регламент регулярных обновлений
Обновление — не разовое событие, а процесс. Разумный регламент:
- Патчи безопасности — ставить быстро, уязвимости эксплуатируют массово.
- Функциональные обновления — плановым окном раз в месяц-квартал на стейджинге.
- Не копить разрыв. Регулярные небольшие обновления безопаснее редких больших прыжков.
- Активная подписка. Продлевать обновления, чтобы получать патчи.
- Мониторинг после. Следить за ошибками и обменом первые дни после релиза.
Регулярность — главный фактор безопасности: чем меньше шаг обновления, тем меньше поверхность для поломки.
Частые ошибки
- Обновление сразу на бою. Без стейджинга — прямой путь к простою в разгар продаж.
- Нет проверенного бэкапа. Копия есть, но не разворачивается — откатываться некуда.
- Правки в ядре. Доработки в /bitrix/ затираются обновлением.
- Не проверили обмен с 1С. Интеграция тихо сломалась, остатки разъехались.
- Копят разрыв версий. Год не обновлялись — теперь прыжок через десятки версий.
- Обновляют по одному модулю на бою. Нарушена совместимость ядра и модулей.
- Нет активной подписки. Патчи безопасности не приходят, сайт уязвим.
Чек-лист обновления
- Активна подписка на обновления, зафиксированы текущие версии.
- Снят и проверен бэкап файлов и базы — план отката готов.
- Развёрнут стейджинг — точная копия боевого.
- Обновление прогнано на копии: ядро и модули согласованно.
- Проверены витрина, заказ, кабинет и кастомный код.
- Прогнан пробный обмен с 1С: номенклатура, цены, остатки, заказы.
- Перенос на бой в окно минимальной нагрузки со свежим бэкапом.
- Постпроверка на бою и мониторинг первые дни.
Вывод
Безопасное обновление ядра 1С-Битрикс держится на четырёх опорах: не обновляться сразу на боевом, всегда иметь проверенный бэкап как план отката, не трогать ядро доработками и обязательно проверять обмен с 1С. Обновление перестаёт быть страшным, когда становится регулярной, отрепетированной на стейджинге процедурой, а не редким прыжком через много версий.
Главный риск — не сам факт обновления, а его отсутствие: устаревшее ядро копит уязвимости и усложняет любой будущий переход. Выстройте регламент, держите активную подписку и обновляйтесь небольшими шагами — тогда платформа остаётся защищённой и совместимой, а магазин продолжает продавать без сюрпризов.
