Чёрная пятница — это когда за один вечер приходит трафик целого месяца, и магазин либо зарабатывает годовую выручку, либо ложится на самом интересном месте. И обиднее всего, что падает он предсказуемо: узкие места были известны заранее, просто до них «не дошли руки». Распродажа не прощает импровизации — она усиливает любую слабость архитектуры в десятки раз.
Хорошая новость в том, что подготовка магазина на 1С-Битрикс к пику — это набор понятных, проверяемых шагов, а не магия. В статье разберём, что именно ломается под нагрузкой, как снять её композитом и кэшем, где узкое место база и обмен с 1С, зачем нужно нагрузочное тестирование и как защитить оформление заказа. Системную подготовку инфраструктуры и учётной части мы закрываем услугой аудита и оптимизации 1С.
Коротко
- В пик падает не каталог, а тяжёлая динамика: оформление заказа, корзина, авторизация и обмен с 1С, которые бьют в базу.
- Композит и многоуровневый кэш снимают нагрузку с витрины; база и оформление требуют отдельной подготовки.
- Обмен с 1С и агенты на время пика переводят в щадящий режим и непиковые окна.
- Без нагрузочного тестирования вы не знаете реальный предел системы — узкие места вскроются под живым трафиком.
Что именно ломается в пик
Первый шаг к устойчивости — понимать, что именно не выдерживает нагрузку. Вопреки интуиции, чаще всего падает не отдача страниц каталога, а тяжёлые динамические операции, которые идут в обход кэша и напрямую нагружают PHP и базу данных.
- Оформление заказа. Транзакции, расчёт доставки и оплаты, обмен с CRM — самое узкое место в пик.
- Корзина и «купить». Каждое действие — динамический запрос, кэш здесь не помогает.
- Авторизация. Всплеск входов и регистраций нагружает базу и сессии.
- Обмен с 1С. Тяжёлая выгрузка, запущенная в час пик, конкурирует с покупателями за ресурсы.
- Агенты «на хите». Фоновые задачи, стартующие при запросе пользователя, тормозят обычные страницы.
Каталог и карточки товара обычно спасает композит и кэширование — они отдаются почти без нагрузки. А вот транзакционная часть и база становятся бутылочным горлышком, и готовить их надо прицельно.
С чего начать: измерить, а не гадать
Подготовку начинают не с «включить кэш побольше», а с измерений. Пока вы не знаете реальный предел системы и её узкие места, любые улучшения — это стрельба вслепую.
- Соберите метрики. Время ответа страниц, нагрузка на CPU и базу, медленные запросы, статистика монитора производительности Битрикса.
- Найдите тяжёлые страницы. Определите, что генерируется дольше всего и чаще всего вызывается.
- Оцените ожидаемый пик. Возьмите прошлый трафик распродаж и заложите рост.
- Зафиксируйте базовую линию. Текущие показатели — чтобы понимать эффект от каждого изменения.
На этом этапе часто вскрываются проблемы не в коде сайта, а в данных и обмене: разросшиеся справочники, тяжёлые выгрузки, неоптимальные свойства товаров. Их лечит аудит и оптимизация 1С ещё до того, как трафик вырастет.
Композит: снимаем нагрузку с каталога
Композитный сайт — базовая мера для витрины. Он делит страницу на статическую часть (кэшируется и отдаётся мгновенно почти без участия PHP) и динамическую (корзина, цена клиента, персональные блоки), которая догружается отдельным запросом. Для каталога и карточек товара это радикально снижает нагрузку в пик.
Как правильно настроить композит, что выносить в динамику и как не сломать персонализацию — подробно в отдельном материале про композитный сайт на Битрикс. Здесь важно другое: композит должен быть включён и проверен заранее, а не «в ночь перед».
Кэширование: уровни и инвалидация
Кэш — главный инструмент масштабирования на Битриксе, и работать он должен на всех уровнях. Задача — чтобы под нагрузкой большинство запросов обслуживалось из кэша, а не пересчитывалось заново.
| Уровень | Что кэширует | Риск в пик |
|---|---|---|
| Кэш компонентов | Каталог, меню, блоки | Слишком короткий TTL — частый пересчёт |
| Управляемый кэш | Выборки с тегами инвалидации | Массовая инвалидация при обмене |
| HTML-кэш / композит | Готовые страницы | Не покрывает динамику |
| Хранилище кэша | Memcached / Redis вместо файлов | Файловый кэш не тянет пик |
Отдельная опасность — инвалидация кэша в момент обмена с 1С: массовое обновление товаров сбрасывает кэш, и в пик система начинает пересчитывать всё разом. Поэтому обмен в час пик душат, а кэш держат в быстром хранилище (Memcached или Redis), а не в файлах. Как устроено окружение под это — в материале про хостинг и инфраструктуру на BitrixVM.
База данных как узкое место
Когда кэш настроен, следующим падает база — именно в неё бьют некэшируемые операции: корзина, оформление, авторизация. Подготовка базы к пику включает несколько направлений.
- Медленные запросы. Найдите и оптимизируйте самые тяжёлые запросы, добавьте недостающие индексы.
- Разросшиеся таблицы. Логи, сессии, старые данные — чистка и архивация снижают нагрузку.
- Пул соединений. Настройте лимиты так, чтобы всплеск не исчерпал соединения к базе.
- Тяжёлые свойства товаров. Большое число свойств и вариантов замедляет выборки каталога.
Писать выборки под нагрузку лучше на D7-ORM: она даёт контроль над запросами, выбором нужных полей и кэшированием результатов. Подробнее — в статье про D7 и ORM в Битрикс.
Highload-блоки и тяжёлые данные
Если у вас большие объёмы однотипных данных — характеристики, справочники, история, — их место в highload-блоках, а не в свойствах инфоблоков. Highload-блоки спроектированы под большие таблицы и высокую нагрузку чтения, поэтому в пик они ведут себя предсказуемее.
Перед распродажей проверяют, что тяжёлые справочные данные вынесены корректно, по ним есть индексы, а выборки кэшируются. Это особенно важно для B2B, где к каталогу цепляются цены по группам, остатки по складам и характеристики — всё то, что в пик запрашивается массово.
Инфраструктура и веб-кластер
Когда софт оптимизирован, упираются в железо. Здесь два пути, и выбор между ними делают по результатам нагрузочного теста, а не «на всякий случай».
- Вертикальное масштабирование. Более мощный сервер: больше CPU и памяти, быстрый диск. Проще и часто достаточно.
- Веб-кластер. Несколько веб-нод за балансировщиком, репликация базы, общий кэш и сессии. Нужен, когда пик заведомо превышает один сервер.
Веб-кластер 1С-Битрикс поддерживает распределение нагрузки, но требует правильной настройки общего кэша, сессий и синхронизации. Это серьёзная работа, которую делают заранее и обязательно тестируют. Про надёжное окружение и запас по ресурсам — материал про хостинг и инфраструктуру на BitrixVM.
Обмен с 1С и агенты в пик
Одна из самых частых причин падения в час пик — тяжёлый обмен с 1С, запущенный не вовремя. Полная выгрузка каталога или большая пачка заказов конкурирует за ресурсы с покупателями именно тогда, когда их максимум.
- Переведите обмен в щадящий режим. Реже, меньшими порциями, в непиковые окна.
- Обновляйте критичное точечно. Остатки — прицельно, а не полной переиндексацией каталога.
- Накапливайте заказы. Выгрузка в 1С пачками в спокойные часы, а не по каждому заказу в пик.
- Ревизуйте агентов. Переведите агенты «на хите» на cron, тяжёлые задачи отложите на ночь, лишние отключите.
Стабильность самой учётной части — тоже часть подготовки: если 1С не справляется с выгрузкой, это бьёт по сайту. Эту зону закрывает автоматизация продаж и склада на 1С.
Защита корзины и оформления заказа
Оформление заказа — самое ценное и самое уязвимое место. Под всплеском трафика здесь возникают дубли, зависшие заказы и потерянные оплаты. Задача — сделать оформление идемпотентным и устойчивым.
- Идемпотентность. Повторный клик или ретрай не создаёт второй заказ — защита по токену оформления.
- Внешние вызовы не блокируют. Обмен с CRM и уведомления выносятся в очередь, а не держат оформление.
- Понятные ошибки оплаты. Сбой платёжного шлюза не «вешает» заказ, а даёт клиенту повторить попытку.
- Блокировки остатков. Корректная работа с остатком при одновременных заказах одного товара.
Тема надёжности оформления и оплаты настолько важна, что заслуживает отдельного разбора — как защититься от дублей и потерь при всплеске, мы разбираем в материалах про безопасность внешних вызовов, например про REST, вебхуки и безопасность.
Нагрузочное тестирование
Всё, что описано выше, проверяется одним способом — нагрузочным тестом. Без него вы не знаете реальный предел системы и лишь надеетесь на запас. Тест на реалистичном сценарии показывает, при какой нагрузке система деградирует и что именно падает первым.
Хороший тест воспроизводит поведение живых покупателей: просмотр каталога, применение фильтра, добавление в корзину, авторизация и оформление заказа — в пропорциях, близких к реальным. Нагрузку поднимают ступенями до предела, фиксируют, где начинается деградация, устраняют узкое место и прогоняют снова. Один прогон — не тест: важна итеративность, «нашли — починили — перепроверили».
План на день распродажи
Даже подготовленная система требует плана на сам день. Импровизация в пик стоит дорого.
- Дежурство. Разработчик и админ на связи, роли и контакты заранее распределены.
- Мониторинг в реальном времени. Дашборды по нагрузке, ошибкам, времени ответа и оформлениям.
- Заморозка изменений. Никаких релизов и правок в день пика без крайней необходимости.
- План отката. Что отключить в первую очередь, если система начинает захлёбываться (тяжёлые блоки, обмен, лишние функции).
- Резервные копии. Свежий бэкап перед стартом распродажи.
Безопасный процесс выкатки и отката помогает и здесь — как его выстроить, в материале про CI/CD и деплой в Битрикс.
Частые ошибки
- Готовятся за пару дней. Узкие места вскрываются под живым трафиком, когда менять что-то поздно.
- Надеются только на композит. Витрина летает, а оформление и база ложатся первыми.
- Файловый кэш вместо Memcached/Redis. Под пиком файловый кэш становится тормозом, а не ускорителем.
- Полный обмен с 1С в час пик. Выгрузка конкурирует с покупателями за ресурсы.
- Агенты «на хите». Фоновые задачи стартуют при запросе и тормозят обычные страницы.
- Оформление без идемпотентности. Всплеск даёт дубли, зависшие заказы и потерянные оплаты.
- Нет нагрузочного теста. Реальный предел системы неизвестен, узкие места — сюрприз в худший момент.
Чек-лист готовности
- Метрики собраны. Известны тяжёлые страницы, узкие места и ожидаемый пик.
- Композит включён и проверен. Витрина отдаётся из кэша, динамика догружается корректно.
- Кэш в быстром хранилище. Memcached/Redis, разумные TTL, контролируемая инвалидация.
- База оптимизирована. Медленные запросы устранены, индексы на месте, таблицы почищены.
- Инфраструктура масштабирована. Ресурсов хватает по результатам теста; при необходимости — веб-кластер.
- Обмен и агенты усмирены. Обмен с 1С в щадящем режиме, агенты на cron и вне пика.
- Оформление защищено. Идемпотентность, очередь для внешних вызовов, обработка ошибок оплаты.
- Нагрузочный тест пройден. Прогон на реалистичном сценарии, узкие места устранены и перепроверены.
- План на день готов. Дежурство, мониторинг, заморозка, откат, свежий бэкап.
Вывод
Магазин на 1С-Битрикс выдерживает распродажу не благодаря «мощному серверу», а благодаря подготовке: измеренным узким местам, включённому композиту, кэшу в быстром хранилище, оптимизированной базе, усмирённому обмену с 1С и защищённому оформлению заказа. Каждая из этих мер закрывает конкретную причину падения, и все вместе они дают запас прочности.
Главное правило — готовиться заранее и проверять нагрузочным тестом, а не надеждой. Дайте себе 4–6 недель, найдите предел системы, устраните узкие места и прогоните всё повторно. Тогда чёрная пятница станет лучшим днём года по выручке, а не по инцидентам. А фундамент устойчивости — здоровый обмен и учёт — держится на автоматизации на 1С.
