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

После обновления ядра Битрикс сайт может пройти ручную проверку и всё равно начать отдавать 500, терять данные в заказах или замедляться под нагрузкой. Первым обычно ломается не шаблон, а связка из кастомного обработчика, кеша, агента и внешней интеграции. Ниже — разбор для «1С-Битрикс: Управление сайтом» на актуальной для проекта ветке 24.x или 25.x: что проверять до обновления, где искать регрессии и какие метрики снять, чтобы не спорить о проблеме на глаз.

Почему обновление проходит, а сайт ломается позже

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

Есть и вторая причина. После обновления часть кода начинает выполняться по другому пути: меняется SQL-запрос, перестраивается кеш, обновляется компонент или меняется порядок обработки события. На малом числе запросов это незаметно. Под нагрузкой растёт время ответа, забиваются PHP-FPM-воркеры и появляются 502 от веб-сервера.

Главный риск обновления — не сам новый файл ядра, а неявный контракт между ядром, кастомным кодом, кешем и внешними системами.

Что проверить до обновления

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

• Запишите точную текущую версию Битрикс, PHP, СУБД и веб-сервера. Для PHP и СУБД сверяйте совместимость с требованиями конкретного релиза.
• Составьте список изменений вне ядра: папка /local, переопределённые компоненты, шаблоны, обработчики событий, агенты, cron-задачи, модульные доработки и интеграции.
• Проверьте резервную копию восстановлением на отдельном стенде. Файл архива без проверенного восстановления не считается рабочим бэкапом.
• Снимите базовые показатели за одинаковый период: p50 и p95 времени ответа, долю 5xx, число медленных SQL-запросов, размер очереди агентов, ошибки обмена и загрузку PHP-FPM.
• Откройте журнал изменений конкретного обновления и отдельно проверьте изменения в модулях, которыми пользуется кастомный код. Общего списка «что сломается у всех» не существует.

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

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

1. Переопределённые компоненты и шаблоны

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

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

2. Обработчики событий с неявными ожиданиями

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

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

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

3. ORM-запросы и скрытые дополнительные обращения к базе

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

Сравните до и после обновления число SQL-запросов для одинакового сценария: каталог, карточка, корзина, оформление заказа и административный список. Фиксируйте объём данных, параметры фильтра и прогрев кеша. Без этих условий сравнение будет случайным.

4. Кеши, композит и устаревшие данные

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

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

5. Агенты, cron и фоновые задачи

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

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

6. Интеграции с оплатой, доставкой и CRM

Внешняя система ломается тихо: сайт показывает успешный заказ, но не передаёт его в CRM; платёжный статус обновляется с задержкой; webhook приходит повторно. После обновления ядра может измениться момент вызова обработчика или формат подготовленных данных.

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

Как сравнивать варианты обновления

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

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

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

• 500 и 502. Разделяйте фатальную ошибку PHP, тайм-аут приложения и исчерпание PHP-FPM-воркеров.
• Рост p95. Если среднее время почти не изменилось, а хвост вырос, ищите редкий тяжёлый сценарий: фильтр каталога, импорт или оформление заказа.
• Дубли. Проверяйте повторные webhook, письма, платежи, записи в CRM и запуск агентов.
• Расхождение кеша. Сравнивайте данные для гостя, авторизованного пользователя и администратора.
• Незаметные ошибки фоновых задач. Просматривайте журналы и фактический результат импорта, а не только код завершения процесса.

Не откатывайте базу вслепую после появления первых ошибок. Сначала зафиксируйте время сбоя, версию релиза, URL или сценарий, идентификатор заказа и записи журналов. Восстановление базы может уничтожить заказы, созданные после обновления.

Как проводить обновление под контролем

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

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

Соберите матрицу совместимости для своего проекта: версия Битрикс, PHP, СУБД, модули, кастомные компоненты, обработчики, агенты и внешние системы. Для каждого пункта укажите владельца проверки и критерий успешного теста.

После ближайшего обновления оставьте в мониторинге четыре группы показателей: 5xx и 502, p95 ключевых страниц, длительность и ошибки агентов, а также расхождения по заказам и платежам. Следующее улучшение — автоматизировать хотя бы сценарий оформления тестового заказа и повторного webhook. Инвалидация кеша и детальный аудит всех переопределений — отдельные задачи, их не стоит смешивать с проверкой самого обновления.

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