Обновление ядра в Битрикс: как мерить эффект и риски

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

Что именно обновляется в Битрикс

В 1С-Битрикс нужно разделять три операции, которые часто называют одним словом:

• обновление ядра — получение новых версий системных модулей и файлов платформы через штатный механизм обновлений;
• обновление Marketplace-модулей — изменение сторонних или официальных расширений, от которых зависят компоненты сайта;
• обновление окружения — смена PHP, веб-сервера, СУБД, расширений PHP и настроек PHP-FPM.

Эти операции имеют разные риски. Новый релиз ядра может требовать другую версию PHP, но сам по себе не обновляет сервер до нужной версии. А исправление медленного каталога чаще находится не в ядре, а в индексе базы, настройках кеша или коде компонента.

Для материала используется 1С-Битрикс: Управление сайтом веток 24.x–25.x. Номер доступного обновления зависит от редакции, лицензии и даты проверки. Перед работой смотрите конкретную версию в административной панели и требования к ней в описании обновления.

Почему обновление не равно оптимизации

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

Обновление действительно может помочь, если в новой версии исправлена проблема в системном модуле, компоненте или обработке кеша. Но если 70 процентов времени занимает запрос к таблице товаров, замена файлов ядра не создаст нужный индекс. Точную долю каждого участка нужно получить из профилировщика и журналов, а не выводить из общей скорости главной страницы.

Главный результат обновления — не обещанное ускорение, а проверяемое изменение поведения системы. Если метрики не собраны, вы не знаете, стало ли лучше.

Как строить замер до и после

Сравнивайте одинаковые сценарии на одной копии базы и с одинаковыми настройками кеша. Измерение «до» на рабочем сайте утром, а «после» на пустом тестовом стенде даст цифры, которые нельзя честно сопоставить.

1. Зафиксируйте исходное состояние. Запишите версию ядра, PHP, СУБД, активные модули, размер базы, редакцию продукта и список локальных изменений. Отдельно сохраните дату и коммит или архив кода, если проект собирается через систему контроля версий.
   Проверка: другой инженер может по записи понять, что именно сравнивается.
2. Выберите реальные сценарии. Для интернет-магазина это главная, каталог с фильтром, карточка товара, корзина и оформление заказа. Для контентного сайта — главная, раздел, поиск и страница материала. Не ограничивайтесь одним URL: разные компоненты обращаются к разным модулям и таблицам.
   Проверка: каждый сценарий воспроизводится с одинаковыми параметрами и правами доступа.
3. Снимите технические показатели. Нужны время ответа сервера, p95 или p99, доля ошибок 5xx, время выполнения PHP, число и длительность SQL-запросов, загрузка CPU и памяти, состояние PHP-FPM и попадания в кеш. Если метрика недоступна, отметьте это, а не заменяйте её субъективной оценкой.
   Проверка: у каждого сценария есть значения минимум до обновления и после него.
4. Обновите тестовый стенд. Сначала сделайте резервную копию файлов и базы, затем проверьте обновление штатным механизмом в административной панели. Не копируйте системные файлы ядра поверх рабочей директории вручную: так легко потерять контроль над составом файлов и результатом отката.
   Проверка: панель не показывает незавершённое обновление, а журнал не содержит ошибок.
5. Прогрейте кеш и повторите сценарии. Сравните отдельно холодный запрос после очистки кеша и обычный запрос по уже сохранённой странице. Для Битрикс это принципиально: быстрый ответ из кеша может скрыть медленную генерацию страницы.
   Проверка: результаты собраны в тех же условиях, что и исходный замер.
6. Разберите расхождения. Ищите не только среднее время, но и редкие долгие ответы. Если среднее улучшилось, а p99 вырос, пользователи с тяжёлыми фильтрами или пустым кешем могли столкнуться с ухудшением.
   Проверка: для каждого заметного изменения есть гипотеза и подтверждающий лог или профиль.

Какие подходы сравнивать

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

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

Что ломается первым

Локальные изменения в системных файлах

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

Сторонние модули и компоненты

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

PHP и расширения

Ошибка может появиться до загрузки страницы: в логах веб-сервера или PHP-FPM будут видны фатальная ошибка, предупреждение о несовместимом синтаксисе или отсутствие расширения. Не повышайте версию PHP одновременно с ядром без отдельного плана: иначе будет трудно понять, какой шаг вызвал сбой.

Кеш и устаревшие данные

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

Как читать цифры, а не спорить о впечатлениях

Для каждого сценария заведите простую карточку: версия ядра, дата замера, состояние кеша, число параллельных запросов, размер ответа, среднее время, p95, p99, 5xx, SQL-время и потребление памяти. Нагрузку задавайте одинаковую. Если тест выполняется одним запросом, это проверка корректности, а не поведения под нагрузкой.

При сравнении полезно считать относительное изменение: (новое значение − старое значение) / старое значение × 100%. Уменьшение времени на 20 процентов не означает, что сайт стал на 20 процентов быстрее по всем сценариям. Смотрите на медиану и хвост распределения, а для ошибок — на абсолютное число и долю запросов.

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

Где подход ломается

• Данные на стенде не похожи на продакшен. Пустой каталог и десять пользователей не выявят медленный фильтр по миллиону записей.
• Тестируется только главная. Проблема может жить в заказе, поиске, обмене или административной части.
• Меняются несколько компонентов сразу. Тогда нельзя приписать эффект одному обновлению.
• Откат касается только файлов. Изменения схемы базы и внешних интеграций могут остаться.
• Оценивается среднее время. Редкие 10-секундные ответы пропадают в среднем, но именно они создают жалобы пользователей.

Инвалидация кеша[*] здесь рассматривается только как часть контрольного замера. Стратегия его прогрева и сброса после релиза — отдельная задача.

Что делать дальше

Сначала соберите паспорт проекта и базовые метрики по пяти реальным сценариям. Затем скопируйте продакшен на тестовый стенд, обновите ядро и модули по отдельности, проверьте критические пользовательские пути и повторите замер в тех же условиях. После выхода в прод наблюдайте 5xx, p95/p99, медленные SQL-запросы, ошибки PHP-FPM и долю попаданий в кеш. Если показатель ухудшился, не откатывайте вслепую: зафиксируйте, на каком сценарии и после какого изменения началось расхождение.

[*] Инвалидация кеша — удаление или пометка устаревшими сохранённых результатов, чтобы система заново построила их из актуальных данных.