Чёрная пятница за месяц: план подготовки сервера по неделям

MAATRIX

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

Неделя 1: разбор прошлогодней нагрузки и план по ресурсам

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

Соберите то, что осталось от прошлого года:

• графики нагрузки CPU, RAM, диска и сети за сам день распродажи и за неделю вокруг него;
• логи веб-сервера — количество запросов в минуту в пиковые часы;
• количество одновременных соединений к базе данных в пике;
• метрики очередей (если есть) — сколько задач копилось и как долго разгребались;
• список того, что тогда падало или тормозило: конкретные эндпоинты, конкретные запросы к БД, конкретные фоновые джобы.

Если исторических данных нет — потому что мониторинг не хранил историю так долго, или проект новый, — ориентируйтесь на пиковую нагрузку обычного дня и закладывайте кратный запас. Для интернет-магазинов Чёрная пятница обычно даёт от 3 до 10 раз больше трафика, чем обычный день, но точный множитель у вас будет свой — зависит от ниши, размера скидок и того, насколько активно проект анонсирует распродажу заранее. Не берите это число как гарантированное — это ориентир для первой прикидки, а не формула.

Дальше — сравнение с текущими лимитами. Если в прошлом году пиковая нагрузка на CPU доходила до 85%, а в этом году трафик ожидается на 50% выше — action item очевиден: либо апгрейд, либо горизонтальное масштабирование, либо оба варианта. Формулы для расчёта конфигурации под нагрузку по каждому ресурсу отдельно разобраны в статье про расчёт конфигурации сервера под нагрузку — тот же подход, только с горизонтом в месяц, а не в год.

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

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

Что купить или зарезервировать заранее

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

Неделя 2: нагрузочное тестирование

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

Порядок действий:

1. Соберите сценарий, похожий на реальный. Не просто «долбим главную страницу» — воспроизведите типичный путь покупателя: главная → каталог → карточка товара → корзина → оформление заказа. Смешанная нагрузка на разные эндпоинты ведёт себя иначе, чем однородная.
2. Выберите инструмент под задачу. Для HTTP-нагрузки подходят k6, Locust, JMeter или Apache Bench для простых прогонов. Важно, чтобы инструмент умел эмулировать нарастающую нагрузку (ramp-up), а не сразу бить максимумом — так поведение системы под градиентом видно лучше, чем под резким шоком.
3. Тестируйте не на проде напрямую в рабочие часы. Идеальный вариант — staging-окружение, максимально похожее на прод по конфигурации. Если staging слабее прода по железу — на нём вы не увидите реальный потолок, только относительную деградацию, что тоже полезно, но не заменяет тест на проде в окно с низким трафиком.
4. Ищите не только точку отказа, но и точку деградации. Сервер может не падать полностью, но давать 2-секундный отклик вместо 200 мс — для покупателя это тоже потеря. Фиксируйте, при какой нагрузке время ответа начинает расти нелинейно.
5. Тестируйте базу данных отдельно. Веб-сервер часто масштабируется горизонтально проще, чем БД. Именно база данных чаще всего оказывается узким местом на распродажах — потому что growing connections и блокировки на популярных товарах бьют по ней сильнее, чем по фронту.

Частая ошибка на этом шаге — гонять нагрузочный тест с ноутбука разработчика в соседней комнате от офиса: интернет-канал и мощность клиентской машины сами становятся узким местом теста, и результат врёт в обе стороны. Тестовый стенд должен быть отдельной машиной с гарантированным каналом, иначе цифры не о вашей системе, а о вашем ноутбуке.

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

Пример вывода нагрузочного теста

Сценарий: 500 → 5000 виртуальных пользователей за 10 минут (ramp-up)
Эндпоинт            | RPS на пике | p95 latency | Ошибки
/                    | 1200        | 180ms       | 0%
/catalog             | 900         | 340ms       | 0.1%
/product/{id}        | 1800        | 420ms       | 0.3%
/cart/add            | 600         | 1100ms      | 2.1%   <- узкое место
/checkout            | 150         | 2400ms      | 5.4%   <- критично

Цифры в примере условные — у вас будут свои, задача таблицы — показать формат: не общее «выдержал/не выдержал», а разбивка по эндпоинтам с ошибками и латентностью.

Регулярная практика нагрузочного тестирования (не только перед распродажами, а раз в полгода как процесс) снимает часть авральности — команда заранее знает потолок системы. Об этом подробнее в статье про нагрузочное тестирование раз в полгода.

Неделя 3: автомасштабирование, резервные мощности и мониторинг

Третья неделя — превращение выводов из тестов в конкретную инфраструктурную защиту.

Автомасштабирование. Если инфраструктура это позволяет (облачные VPS с API, Kubernetes с HPA, группы масштабирования), настройте правила заранее и проверьте их на тесте, а не в день распродажи. Порог для добавления узла должен срабатывать раньше точки деградации, найденной на неделе 2 — если латентность начинает расти при 70% CPU, порог автомасштабирования на 90% уже опоздал. Учитывайте и время на прогрев нового узла: если контейнер поднимается 3 минуты, а трафик скачет за 30 секунд, чисто реактивное масштабирование не спасёт — нужен запас мощности, включённый заранее на пиковые часы.

Резервные мощности вручную. Автомасштабирование не всегда доступно или надёжно на пике — иногда проще заранее увеличить ресурсы сервера (добавить CPU/RAM через панель провайдера, если тариф это позволяет без простоя) на период распродажи, а после снизить обратно. Это менее гибко, чем автомасштабирование, но предсказуемо: не зависит от скорости реакции метрик и API. Для многих проектов на распродажу разумна гибридная модель: заранее увеличенная базовая мощность плюс автомасштабирование сверху для непредсказуемых скачков.

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

Мониторинг и алерты. К началу распродажи мониторинг должен покрывать минимум:

• загрузку CPU, RAM, диска на всех узлах;
• время ответа ключевых эндпоинтов (каталог, карточка товара, корзина, оформление заказа);
• количество ошибок 5xx в разрезе по эндпоинтам;
• состояние очереди подключений к базе данных;
• доступность внешних интеграций — платёжного шлюза, службы доставки, если их отказ блокирует заказ.

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

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

Неделя 4: заморозка изменений и финальные проверки

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

Заморозка изменений (code freeze). Договоритесь с командой о датах: обычно это последние 5-7 дней до старта распродажи и сам день распродажи. В это время в прод идут только критичные фиксы безопасности и исправления багов, найденных на этой же неделе — никаких новых фич, никаких рефакторингов «пока есть время», никаких обновлений зависимостей без крайней необходимости. Чем позже релиз перед пиком, тем меньше времени заметить и откатить проблему на спокойном трафике.

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

Финальный чек-лист перед стартом:

• [ ] Резервные мощности включены или правила автомасштабирования активны и протестированы
• [ ] Мониторинг и алерты работают, дежурные назначены на все окна пиковой нагрузки
• [ ] Бэкапы базы данных и файлового хранилища сделаны непосредственно перед стартом, план восстановления проверен
• [ ] Платёжный шлюз и служба доставки подтвердили готовность к повышенной нагрузке со своей стороны
• [ ] CDN и статика настроены так, чтобы не грузить основной сервер картинками и скриптами
• [ ] Rollback-план готов: как быстро откатить последний релиз, если что-то пойдёт не так
• [ ] Лимиты (rate limiting, защита от ботов) настроены так, чтобы не резать легитимных покупателей на пике
• [ ] Команда знает, кто принимает решение о масштабировании вручную, если автоматика не справляется

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

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

Таблица плана по неделям

Частые вопросы