Как подготовить интернет-магазин к Чёрной пятнице и 11.11: план на 6 недель

Начинайте за шесть недель до 27 ноября 2026 года. Это дата Чёрной пятницы — пятницы после Дня благодарения в США. Порядок такой: замер скорости сайта, нагрузочный тест корзины и оплаты, запас мощности у хостинга, заморозка релизов за неделю до пика и дежурство в сам день. 11 ноября 2026-го, в среду, проходит генеральная репетиция: всё, что не выдержало «11.11», чинят до Чёрной пятницы. Дальше — план по неделям и чек-лист теста. Если своими силами не успеть, эти задачи закрывает поддержка интернет-магазина в пиковые дни.

Короткий ответ: календарь от T−6 недель

Шесть недель — не случайная цифра. За это время можно найти узкое место, поправить код и перепроверить его под нагрузкой. Две недели на такой цикл уже не хватит. Правки на живом каталоге в разгар подготовки — риск сам по себе, и лучше избегать его в последний момент. Первый шаг T−6 — замер: быстрая диагностика скорости страниц каталога и карточки товара покажет, с какой точки вы стартуете.

Таблица 1. План T−6 … T+1

Что падает первым: корзина, оплата, поиск, обмен остатками

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

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

Обмен остатками с 1С или складской системой — отдельная история. Синхронизация раз в час означает, что часть заказов в пик уходит на товар, которого уже нет на складе. Здесь два решения: временно повысить частоту синхронизации на дни пика или включить визуальный резерв товара в корзине на 10–15 минут, чтобы остаток не разошёлся между покупателями одновременно.

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

Нагрузочный тест своими силами: инструменты и сценарии

Нагрузочный тест — не «зайти с трёх вкладок одновременно». Это управляемая симуляция реального трафика с измеримым результатом: время ответа, доля ошибок, поведение под ростом нагрузки. Для этого есть три открытых инструмента. k6 — тесты пишутся на JavaScript, легко встраивается в CI/CD. Apache JMeter — инструмент старше, с графическим интерфейсом и множеством готовых примеров сценариев. Яндекс.Танк — генератор нагрузки от Яндекса, хорошо держит очень высокий RPS. Для среднего интернет-магазина хватит любого из трёх. Разница в основном в удобстве написания сценариев, а не в возможностях самого инструмента.

Целевую нагрузку не выдумывают. Её берут из собственных данных. В Яндекс.Метрике, в отчёте «Посещаемость», смотрят почасовую статистику за прошлый пиковый день — 11.11 или Чёрную пятницу прошлого года. Пиковое число визитов в час делят на 3600 секунд, получают примерное число визитов в секунду и умножают на 2–3: это целевая нагрузка с запасом на рост аудитории.

Если прошлогодних данных нет — магазин запускает первый сезон, — берут обычный дневной максимум и умножают на 4–5. Ориентир на реальный масштаб пика такой: по данным ЮKassa, в 2024 году именно 11 ноября оборот интернет-магазинов вырос на 32% год к году, а число покупок — на 45%, тогда как за трое суток вокруг этой даты прирост был скромнее — 15% и 40% соответственно (данные ЮKassa приводит malls.ru). День пика задаёт нагрузку. Не неделя вокруг него.

Таблица 2. Сценарии нагрузочного теста

Это распределение — ориентир для магазина среднего размера. Для маркетплейса с большим ассортиментом долю каталога и поиска поднимайте. Для монобрендового магазина — наоборот, снижайте.

Сервер и кеш: что проверить у хостинга

За T−4 недели письменно спросите у хостинга три вещи: можно ли временно увеличить лимиты CPU и оперативной памяти на дни пика, есть ли автоматическое масштабирование или расширение делается вручную по заявке, и сколько времени занимает переход на более мощный тариф в разгар распродажи — иногда это часы, а не минуты. Устные ответы не помогут в момент пиковой нагрузки — зафиксируйте их в переписке.

Отдельный узел — CDN (сеть доставки контента) для изображений товаров. Карточки и каталог тянут за собой десятки картинок. При росте посещаемости именно статика создаёт львиную долю нагрузки на сервер. Вынос картинок на CDN снимает эту нагрузку без изменения кода магазина. Если своего CDN ещё нет, это одна из немногих правок T−3, которая почти всегда окупается за один сезон. Когда узкое место сидит глубже, в самом коде каталога и корзины, точечное ускорение страниц каталога и корзины даёт больший эффект, чем наращивание мощности сервера вслепую.

Бывает и так: тест на T−4 показывает, что сервера объективно не хватает с любым разумным запасом. Тогда дело не в отдельной странице — дело в хостинге целиком, и латать симптомы неделя за неделей бессмысленно.

Ещё один рычаг, который редко включают в план подготовки, — временный режим кеширования страниц каталога и карточек товара на дни пика. Когда популярный плагин кеширования (например cache-enabler для WordPress или встроенный кеш композитных страниц в 1С-Битрикс) отдаёт посетителю уже готовую HTML-страницу вместо того, чтобы на каждый запрос заново обращаться к базе данных и собирать страницу из десятков модулей, сервер выдерживает кратно больше одновременных посетителей на том же железе. Плата за это — обновление цены и остатка на кешированной странице происходит с задержкой в минуту-две, и для дней с ограниченным ассортиментом акции это допустимый компромисс.

Платёжный путь и чеки: тест оплаты, лимиты провайдера, онлайн-касса

Проверке подлежит полный платёжный путь целиком: выбор способа оплаты, форма ввода карты или СБП, редирект к провайдеру, возврат на сайт, формирование чека по 54-ФЗ, письмо с чеком покупателю. Каждый узел ломается под нагрузкой отдельно и чаще, чем кажется: провайдер режет запросы по лимиту в минуту, редирект зависает при медленном ответе сайта, а чек не формируется, если очередь задач на сервере переполнена. Порядок подключения провайдеров, лимиты и сравнение по 54-ФЗ разобраны в отдельном материале — подключение оплаты и онлайн-кассы для сайта.

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

Неделя заморозки и день пика: кто дежурит, что мониторить

За неделю до Чёрной пятницы, в T−1, останавливают все релизы. Исключение — критичные фиксы безопасности. Любая правка кода в эту неделю — риск. В обычное время он оправдан, а перед пиком нет: даже мелкое изменение может конфликтовать с только что протестированной конфигурацией. В ту же неделю проверяют резервную копию: восстановление из копии за известное время должно быть проверено заранее, а не в момент, когда что-то уже сломалось. На эту неделю назначают дежурного. У него должен быть доступ к серверу и к панели хостинга, а не только к админке магазина.

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

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

После распродажи: разбор по логам и заказам

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

Фактический пик этого сезона становится новой базой для расчёта целевой нагрузки в следующем году: именно его, а не прошлогоднюю цифру, берут на шаге T−6 через год, деля пиковое число визитов в час на 3600 и умножая на выбранный запас. Если магазин растёт на 20–30% в год, что для активной ниши в Москве и России не редкость, разница между прогнозом по устаревшим данным и фактическим трафиком через год-два способна свести на нет весь запас мощности, заложенный сегодня.