Обновление 1С-Битрикс на новую версию без простоя магазина

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

Ниже — системный разбор того, как безопасно обновить ядро Битрикс и модули на новую версию: как устроена технология обновлений SiteUpdate, зачем нужны лицензионный ключ и активная техподдержка, чем стабильная ветка отличается от бета, почему нельзя править ядро, как обновлять на копии и переносить результат на бой без простоя, как готовить бэкап и план отката, что делать с версией PHP, композитом и кэшем после обновления и как обновлять готовые решения вроде Аспро. Это выжимка из нашей практики технической поддержки и сопровождения магазинов на 1С-Битрикс — без теории ради теории.

Зачем обновлять 1С-Битрикс и почему боятся простоя

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

• Безопасность. В обновления входят исправления уязвимостей. Устаревшее ядро — это известные бреши, для которых уже есть эксплойты. Магазин с персональными данными покупателей и приёмом оплаты не имеет права быть дырявым.
• Совместимость с окружением. Хостинги поднимают версии PHP и MySQL/MariaDB, а старое ядро с новым PHP не дружит. Рано или поздно «железо» уходит вперёд, и несовместимость превращается в вынужденный аврал.
• Функционал и маркетплейс. Новые модули, решения и обновления сторонних разработчиков рассчитаны на актуальное ядро. На старой версии часть маркетплейса просто не поставится.
• Стоимость «догоняющего» скачка. Чем реже обновляешься, тем крупнее и рискованнее каждый переход. Регулярные небольшие обновления безопаснее одного гигантского прыжка через много версий.

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

Обновление — это управляемый процесс, а не событие

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

Как устроена система обновлений SiteUpdate

Первое, что важно понять, — в 1С-Битрикс обновление не делается «руками через FTP». Для этого есть встроенная технология SiteUpdate (система обновлений). Это подсистема платформы, которая по защищённому каналу связывается с серверами обновлений 1С-Битрикс, узнаёт, какие свежие версии ядра и модулей доступны для вашей лицензии, скачивает их и устанавливает прямо из админки. Разработчику не нужно вручную выкачивать архивы и раскладывать файлы — платформа делает это сама и согласованно.

Механика в общих чертах такая: сайт формирует запрос к серверу обновлений, передавая свой лицензионный ключ; сервер проверяет ключ и активность техподдержки и возвращает список доступных обновлений; выбранные обновления скачиваются порциями (патчами), распаковываются в файловую структуру и применяют миграции — изменения в структуре базы данных, если они нужны для новой версии. Обновление накатывается инкрементально: система ведёт учёт установленных версий каждого модуля и догружает только недостающие шаги, а не весь дистрибутив заново.

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

Лицензионный ключ и активная техподдержка

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

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

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

Стабильная и бета-ветка обновлений

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

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

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

Из чего состоит обновление: ядро и модули

Полезно понимать, что именно обновляется. 1С-Битрикс — модульная платформа: помимо ядра (главный модуль main) есть десятки модулей — «Информационные блоки» (iblock), «Торговый каталог» (catalog), «Интернет-магазин» (sale), «Поиск» (search), «Веб-формы», «Highload-блоки» и другие. Обновление приходит по каждому модулю отдельными версиями, и SiteUpdate показывает, у каких модулей есть свежие версии.

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

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

Раздел «Обновление системы» в админке

Практически всё управление обновлениями живёт в админке, в разделе «Настройки → Обновление системы» (SiteUpdate). Это и есть тот интерфейс, через который вы видите доступные обновления, выбираете ветку, запускаете установку и следите за результатом. Разберём, что там есть по существу.

1. Список доступных обновлений. Система показывает, какие модули имеют свежие версии, и краткое описание того, что войдёт. Здесь же виден статус лицензии и техподдержки.
2. Выбор ветки и режима. Переключатель «стабильные / включая бета» и опции установки. Для боевого магазина — стабильная.
3. Проверка системы. Встроенная проверка совместимости показывает требования к окружению (версия PHP, настройки, права), которые нужны для новых версий. Её стоит смотреть до установки.
4. Установка обновлений. Запуск скачивания и применения патчей. Процесс идёт порциями; в конце система сообщает результат и, если нужно, просит выполнить дополнительные шаги (например, конвертацию таблиц).
5. Журнал и история. Что и когда обновлялось, какие версии стоят сейчас. Полезно для аудита и планирования следующего цикла.

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

Главное правило: не править ядро

Если из всей статьи запомнить одну фразу, пусть это будет она: ядро Битрикса не правят никогда. Ядро — это папка bitrix/modules и всё, что производитель поставляет как системный код. При обновлении SiteUpdate перезаписывает эти файлы новыми версиями. Любая ваша правка внутри ядра при обновлении бесследно исчезнет — файл будет заменён на свежий.

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

Правильная альтернатива всегда существует. Всё, что нужно изменить, выносят в места, которые обновление не трогает:

• Свой шаблон компонента — копируют шаблон в свою тему и правят копию, а не исходник компонента в ядре.
• Кастомный компонент — если логики много, делают собственный компонент в своём пространстве имён, а не хачат штатный.
• Обработчики событий — поведение ядра меняют через события (events), подписываясь на них в init.php или своём модуле.
• Свой модуль — крупную функциональность оформляют отдельным модулем, который живёт рядом с ядром, но обновлением не затрагивается.
• /bitrix/php_interface/ и /local/ — штатные места для кастомизации, которые обновление обходит стороной.

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

Что ломается при обновлении кастомизированного проекта

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

• Правки ядра. Самое опасное (см. раздел 7): затираются молча, ломают то, что на них опиралось.
• Устаревшие вызовы API. Доработки могли использовать методы и параметры, которые в новой версии объявлены устаревшими или удалены. Код падает с фатальной ошибкой или ведёт себя иначе.
• Изменения структуры данных. Миграции меняют схему таблиц; кастомный код, который лез в базу «в лоб» по именам полей, может рассыпаться, если поле переехало.
• Изменения разметки штатных шаблонов. Если ваш JavaScript/CSS цеплялся за конкретные классы штатной вёрстки, а обновление их поменяло, поедет вёрстка или отвалятся интерактивные элементы.
• Несовместимость сторонних модулей. Маркетплейс-модуль, рассчитанный на старое ядро, может конфликтовать с новым — вплоть до белого экрана.
• Требования к PHP. Новое ядро требует более свежего PHP, а старый кастомный код на новом PHP падает — двойная развилка (раздел 14).

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

Шаблоны и компоненты: где прячутся риски

Отдельно стоит разобрать два самых частых источника конфликтов на витрине — шаблоны и компоненты, потому что именно они формируют то, что видит покупатель, и их поломка сразу заметна.

Шаблоны компонентов

Правильно скопированный в свою тему шаблон компонента обновление не трогает — и это хорошо. Но есть обратная сторона: если штатный компонент в новой версии изменил структуру $arResult (данные, которые он передаёт в шаблон), ваш старый шаблон может начать выводить пустоту или падать, потому что ждёт данные в прежнем формате. Это не «поломка обновлением напрямую», а рассинхрон между свежим компонентом и вашим замороженным шаблоном. Лечится сверкой: после обновления проверяют, что кастомные шаблоны получают данные в ожидаемом виде, и при необходимости подтягивают их под новую структуру.

Компоненты 2.0 и комплексные компоненты

Комплексные компоненты (например, bitrix:catalog) — это связка нескольких простых компонентов и общая логика маршрутизации. При обновлении меняются и они. Если вы переопределяли часть шаблонов комплексного компонента или вклинивались в его параметры, после обновления стоит проверить всю цепочку: список раздела, детальную, фильтр, пути ЧПУ. Особенно внимательно — к SEO-настройкам и ЧПУ, чтобы обновление не сбросило кастомные правила формирования адресов.

Кастомные и маркетплейс-компоненты

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

Копия и staging: обновляем не на бою

Центральная идея безопасного обновления проста: всё рискованное делается на копии, а не на боевом сайте. Копия (staging, тестовый стенд) — это развёрнутая на отдельном окружении точная копия боевого магазина: те же файлы, та же база (или её актуальный слепок), то же окружение по возможности. На этой копии и проводят обновление в первый раз.

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

Хорошая копия отвечает нескольким требованиям:

• Актуальность. Копия снята с боевого недавно, чтобы данные и код совпадали. Обновлять годовалую копию бессмысленно — на бою всё давно другое.
• Изоляция. Копия не шлёт письма покупателям, не дёргает боевой обмен с 1С, не принимает реальные оплаты. Тестовые действия не должны утекать наружу.
• Похожесть окружения. По возможности та же версия PHP и СУБД, что планируется на бою, — иначе проверка совместимости неполна.
• Закрытость от индексации. Копия закрыта от поисковых роботов (иначе получите дубли в индексе) и от посторонних глаз.

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

Бэкап и план отката

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

Что именно бэкапят и почему согласованно:

• Файлы. Как минимум папка bitrix (ядро и модули), папка /local/ (кастомизации) и публичная часть. Именно файлы меняет обновление, распаковывая новые версии.
• База данных целиком. Обновление применяет миграции — меняет структуру таблиц. Без отката базы файлы старой версии не совпадут с новой схемой.
• Согласованность момента. Файлы и база должны быть сняты на один момент времени. Иначе при откате вы получите файлы одного состояния и базу другого — рассинхрон, который сам по себе ломает сайт.

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

Чек-лист перед обновлением

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

1. Проверить лицензию и техподдержку. Активна ли техподдержка, доступны ли обновления. Если истекла — продлить заранее.
2. Зафиксировать текущие версии. Записать, какие версии ядра и модулей стоят сейчас, чтобы понимать масштаб скачка и иметь точку отсчёта.
3. Провести аудит кастомизаций. Найти правки ядра, устаревший API, сторонние модули без свежих версий, хаки штатных шаблонов. Это карта рисков.
4. Проверить окружение. Версия PHP и СУБД, требования новой версии по «Проверке системы». Понять, не нужен ли попутный апгрейд PHP.
5. Снять и проверить бэкап. Файлы + база согласованно, с проверкой, что разворачивается.
6. Развернуть свежую копию. Изолированную от боевых писем, оплат и обмена, закрытую от индексации.
7. Составить список проверок. Ключевые сценарии магазина (каталог, фильтр, корзина, заказ, оплата, обмен), которые надо прогнать после обновления.
8. Выбрать окно. Время низкой нагрузки для переноса на бой и людей, готовых оперативно откатить в случае проблемы.

Этот чек-лист — не бюрократия, а сжатый опыт: почти каждая авария при обновлении объясняется пропущенным пунктом отсюда. «Не проверили техподдержку — не качается», «не сделали бэкап — нечем откатываться», «не глянули PHP — упало по фаталу», «обновляли сразу на бою — легли в пик».

Регламент обновления без простоя

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

1. Копия. Снимаем актуальный слепок боевого магазина (файлы + база), разворачиваем изолированную копию, закрываем от индексации и внешних интеграций.
2. Обновление на копии. Через SiteUpdate обновляем ядро и модули на копии. Здесь же, при необходимости, поднимаем версию PHP и обновляем решение/модули маркетплейса.
3. Устранение конфликтов. Чиним всё, что сломалось: несовместимый код, поехавшие шаблоны, устаревший API. На копии это безопасно и повторяемо.
4. Тестирование. Прогоняем список ключевых сценариев: каталог, карточка, умный фильтр, поиск, корзина, оформление и оплата заказа, авторизация, личный кабинет, обмен с 1С, письма. Проверяем вёрстку и мобильную версию.
5. Бэкап боевого. Перед переносом снимаем свежий согласованный бэкап боевого сайта — точку отката.
6. Перенос на бой в короткое окно. В час низкой нагрузки переносим выверенные изменения на боевой сайт (обновлённые файлы и, если нужно, применяем миграции), максимально коротко и по заранее описанному сценарию.
7. Постобработка. Сбрасываем кэш, прогреваем композит, перестраиваем фасет фильтра и переиндексируем поиск, проверяем ключевые сценарии уже на бою.
8. Мониторинг. Первые часы и сутки следим за журналом ошибок, скоростью, заказами и обменом. Если что-то всплыло — чиним или откатываемся по плану.

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

Обновление версии PHP

Обновление Битрикса почти всегда рано или поздно упирается в версию PHP. Связь двусторонняя, и её важно держать в голове. Свежие версии ядра требуют достаточно современного PHP и перестают поддерживать устаревшие; встроенная «Проверка системы» прямо показывает минимально требуемую версию. Если на сервере PHP слишком стар, часть обновлений не встанет или платформа будет жаловаться.

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

Правильный порядок — совмещать оба апгрейда и обкатывать вместе на копии:

1. На копии поднять целевую версию PHP — ту, что планируется на бою.
2. Прогнать проверку системы Битрикса и посмотреть предупреждения о совместимости.
3. Обновить ядро и модули до версий, совместимых с этой версией PHP.
4. Проверить кастомный код на устаревшие конструкции; поймать фаталы и предупреждения в журнале.
5. Прогнать сценарии магазина целиком, и только выверенную связку «PHP + Битрикс» переносить на бой.

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

Композит, кэш и переиндексация после обновления

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

• Сброс кэша. Первое и обязательное. Старый кэш собран на старом коде; пока он не сброшен, часть страниц отдаётся из него, и вы видите поведение прошлой версии. После обновления кэш чистят, чтобы страницы пересобрались на новом ядре.
• Прогрев композита. Композит (HTML-кэш собранной страницы) тоже устаревает. После сброса его нужно заново прогреть, иначе первые посетители словят холодную пересборку. Как устроен композит и что в нём динамика — в отдельном материале про композитный сайт в 1С-Битрикс.
• Перестроение фасетного индекса. Если обновление затронуло каталог или инфоблоки, фасетный индекс умного фильтра стоит перестроить, чтобы фильтр считал корректно.
• Переиндексация поиска. Обновление модуля поиска может потребовать переиндексации, иначе поиск будет отдавать неполные или устаревшие результаты.

Логика кэша и его инвалидации подробно разобрана в статье про кэширование в 1С-Битрикс — после обновления работают ровно те же механизмы, только сброс делается тотально: меняется код, поэтому старый кэш недействителен весь. А вот скорость после обновления стоит замерить отдельно: новая версия может изменить производительность в обе стороны, и её влияние на метрики удобно проверять через Core Web Vitals для интернет-магазина — сравнить TTFB и LCP до и после.

Обновление редакции и переход между редакциями

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

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

Важно: смена редакции меняет доступный функционал, но не отменяет всё, о чём мы говорили. После перехода те же правила — обновляться на копии, бэкапить, проверять сценарии. А новые модули (например, только что открытый интернет-магазин) нужно ещё настроить: типы цен, склады, способы оплаты и доставки, обмен с 1С. Это уже ближе к разработке, чем к обновлению.

Обновление готовых решений (Аспро и другие)

Огромная доля магазинов на Битриксе построена на готовых решениях из маркетплейса — Аспро и подобных. Для них у обновления появляется вторая линия: помимо обновления платформы через SiteUpdate есть обновление самого решения (шаблона) через Marketplace. Эти две линии нужно согласовывать.

Ключевые особенности обновления решений:

• Взаимные требования версий. Свежая версия решения может требовать свежего ядра, и наоборот. Обновлять их вразнобой рискованно — держите совместимую пару.
• Затирание доработок. Витрину решения почти всегда дорабатывают. Если правки вносили прямо в файлы решения, обновление шаблона их затрёт — та же беда, что и с ядром. Правильно — дочерний шаблон, свои включаемые области, штатные настройки решения.
• Changelog вендора. У серьёзных решений есть история изменений и заметки к версиям. Их читают до обновления: там указаны несовместимости, требования и рекомендованный порядок.
• Настройки решения. Обновление может добавить новые опции или изменить существующие; после него настройки решения стоит пересмотреть.

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

Мониторинг после обновления

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

• Журнал ошибок. Следят за php_error/логами и журналом событий Битрикса: свежие фаталы и предупреждения — первый сигнал регресса.
• Ключевые бизнес-метрики. Идут ли заказы, проходят ли оплаты, работает ли обмен с 1С, уходят ли письма. Провал любого из этих потоков — повод немедленно разбираться.
• Скорость и нагрузка. TTFB, время генерации, нагрузка на сервер под реальным трафиком. Новая версия могла изменить производительность; композит после прогрева должен выправить показатели.
• Обратная связь. Обращения покупателей и менеджеров «что-то не работает» — быстрый канал обнаружения того, что не поймала ручная проверка.

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

Частые ошибки обновления

Большинство аварий при обновлении Битрикса повторяются из проекта в проект. Зная их заранее, вы обойдёте почти все грабли.

• Обновление сразу на бою. Самая частая и дорогая ошибка. Конфликт с доработками роняет витрину в продажах. Обновляйтесь на копии, переносите на бой готовое.
• Правки в ядре. Затираются молча, ломают то, что на них опиралось. Никогда не правьте bitrix/modules; выносите кастом в /local, свои шаблоны и события.
• Нет бэкапа или он не проверен. Откатываться нечем, а «архив, который не разворачивается» — не бэкап. Снимайте файлы+базу согласованно и проверяйте восстановление.
• Забыли про техподдержку. Обновление «не качается», потому что истекла поддержка. Проверяйте и продлевайте заранее.
• Игнор версии PHP. Новое ядро требует свежего PHP, а старый код на новом PHP падает. Совмещайте апгрейды и обкатывайте на копии.
• Ручная перезаливка папки bitrix. Не применяет миграции, рассинхронит файлы и базу. Обновляйтесь только через SiteUpdate.
• Не сбросили кэш и композит. «Фантомные баги» из старого кэша. После обновления обязательно чистите кэш и прогревайте композит.
• Обновили решение в обход дочернего шаблона. Правки витрины затёрты, вёрстка поехала. Держите кастом в дочернем шаблоне и настройках решения.
• Огромный скачок через много версий. Чем реже обновляешься, тем рискованнее переход. Обновляйтесь регулярно небольшими шагами.
• Нет мониторинга после. Редкие сценарии (обмен, письма, ночные агенты) всплывают позже. Следите за журналом и метриками первые сутки.

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

Короткий список, по которому удобно свериться на каждом обновлении — от подготовки до постобработки:

• Техподдержка лицензии активна, обновления доступны в разделе «Обновление системы».
• Выбрана стабильная ветка обновлений (бета — только для копии/теста).
• Проведён аудит кастомизаций: нет правок ядра, известны сторонние модули и их совместимость.
• Проверена версия PHP и «Проверка системы»; при необходимости апгрейд PHP запланирован вместе с обновлением.
• Снят и проверен на восстановление согласованный бэкап (файлы + база).
• Развёрнута свежая изолированная копия, закрытая от индексации и внешних интеграций.
• Обновление ядра, модулей и решения выполнено сначала на копии.
• Конфликты устранены; прогнаны ключевые сценарии магазина и мобильная вёрстка.
• Перенос на бой сделан в короткое окно низкой нагрузки по заранее описанному сценарию.
• После обновления сброшен кэш, прогрет композит, перестроен фасет фильтра и переиндексирован поиск.
• Готов и понятен план отката на случай проблемы.
• Первые часы и сутки идёт мониторинг журнала ошибок, заказов, обмена и скорости.

Вывод

Обновление 1С-Битрикс пугает ровно до тех пор, пока остаётся импровизацией. Как только оно превращается в регламент, страх уходит: технология SiteUpdate штатно доставляет свежие версии ядра и модулей при активной техподдержке; стабильная ветка бережёт боевой магазин от сырых сборок; правило «не править ядро» делает обновление предсказуемым; копия и бэкап дают безопасное место для рисков и гарантированный откат. Всё тяжёлое уходит на staging, а на витрину приходит короткая выверенная операция переноса — отсюда и «обновление без простоя».

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