До распродажи осталось время: какие изменения в инфраструктуре действительно успеют сработать 

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

Разберем, что реально успеть в зависимости от горизонта планирования.

Один день, который мог стоить миллиона

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

Нагрузочное тестирование дало неожиданные результаты:

· система стабильно работала только до 60 RPS;

· при 85 RPS начиналась заметная деградация;

· до прогнозируемых 200 RPS система просто не дотягивала.

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

Что именно пошло не так и как это исправили

Детальный анализ показал три проблемы, которые накапливались постепенно и в обычном режиме никак не проявлялись.

Избыточное логирование

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

Что сделали: отключили debug-логи.

Результат: производительность выросла на 30–40%.

Неподходящая конфигурация процессора

Для проектов на 1С-Битрикс критически важна частота ядер, а не их количество. Используемая конфигурация (8 ядер по 2,3 ГГц) не соответствовала характеру нагрузки.

Что сделали: перешли на конфигурацию с 4 ядрами по 3 ГГц.

Результат: Один день, который мог стоить миллиона

Бэкапы в рабочее время

Резервное копирование запускалось в 10 утра — в часы максимальной активности пользователей. Это приводило к блокировкам таблиц и дополнительной нагрузке на базу данных.

Что сделали: перенесли бэкапы на ночное время и настроили снятие копий с реплики, а не с мастера.

Результат: проблема блокировок исчезла, база перестала «проседать» в пиковые часы.

Если осталось 2–3 дня

За такой срок невозможно перестроить архитектуру, но можно добавить запас прочности.

1. Вертикальное масштабирование

Добавить ресурсы:

 • увеличить CPU,

 • расширить объем оперативной памяти.

Это не решает архитектурных ограничений, но снижает риск упора в ресурсы в пиковые часы.

2. Отключить debug-логи

Избыточное логирование существенно нагружает диск и процессор.

В пике это может отнимать до 30–40% производительности.

Отключение debug-режима — одна из самых быстрых и эффективных мер.

3. Настроить ротацию логов

Если ротация отсутствует, диск может быстро заполниться.

Это приведет к деградации или остановке сервисов.

4. Проверить лимиты в Nginx

Важно убедиться, что:

 • корректно настроены лимиты соединений,

 • заданы адекватные таймауты,

 • нет искусственных ограничений, которые проявятся в пике.

5. Подключить CDN

Кэширование статики снижает нагрузку на веб-слой и канал связи.

Это позволяет перераспределить ресурсы в пользу динамических операций — каталога и оформления заказа.

Итог:

За 2–3 дня можно увеличить устойчивость, но не изменить архитектуру.

Если осталось 2–3 недели

Этот срок позволяет внести более системные изменения.

1. Вынести базу данных на отдельный сервер

Это снижает конкуренцию за ресурсы между веб-слоем и СУБД.

2. Добавить реплику базы

Мастер обслуживает запись, реплика — операции чтения.

Это снижает нагрузку на основной узел.

3. Масштабировать веб-слой

Добавление дополнительных серверов приложения позволяет распределить пользовательский трафик.

4. Настроить лимитеры и защиту от штормов

Rate limiting и ограничения на уровне веб-сервера и балансировщика помогают защитить backend от резких всплесков нагрузки.

Итог:

За несколько недель можно значительно усилить систему и подготовить её к росту трафика.

Если до пикового сезона 3–6 месяцев

Это уже стратегический горизонт.

Возможные задачи:

 • Пересборка архитектуры.

 • Глубокая оптимизация кода.

 • Переписывание тяжелых запросов.

 • Переработка логики работы с базой.

Такие изменения требуют времени, тестирования и планирования, но именно они формируют долгосрочную устойчивость.

Важное замечание

Инфраструктура — это не проект «накануне распродажи».

Подготовка должна быть регулярной.

Пиковые события лишь показывают ограничения, которые накапливались постепенно.