Почему e-commerce пик нельзя проверять общими тестами
Трафик Чёрной пятницы отличается от обычного дня не только объёмом, но и формой поведения пользователей. Люди быстрее переходят между страницами, чаще обновляют каталог, массово пытаются применить купоны, запускают проверку наличия и доходят до checkout почти одновременно. Если протестировать только главную страницу или только кэшируемые GET-запросы, можно получить очень оптимистичную картину, которая никак не отражает реальную нагрузку на корзину, оплату и внутренние API.
Для магазина опасен не сам факт всплеска, а сочетание нескольких узких мест. Один компонент может успешно кэшироваться на edge, в то время как другой делает дорогие обращения к базе. Третий зависит от внешнего платёжного сервиса, который сам по себе не падает, но резко увеличивает latency. Поэтому stress test перед Чёрной пятницей должен быть ближе к репетиции бизнес-потока, чем к абстрактному «прогону трафика».
Если удобнее читать английскую пару, используйте Stress test website before Black Friday. Для сценариев за CDN отдельно пригодится статья Нагрузочное тестирование за Cloudflare CDN, потому что именно различие между edge и origin часто вводит команды в заблуждение на пиковых распродажах.
Разделяйте каталог, поиск и checkout на отдельные прогоны
Хорошая подготовка начинается с разбиения сайта на пользовательские потоки. Каталог и карточки товара обычно сильно выигрывают от CDN и кэша. Поиск, фильтры, рекомендации и личный кабинет уже нагружают приложение заметно сильнее. Checkout и подтверждение оплаты часто вообще живут в собственной категории риска, потому что задействуют запись в базу, инвентарь, антифрод и внешние платёжные интеграции.
Из-за этого один «усреднённый» тест вреден: он смешивает лёгкие и тяжёлые операции в такой пропорции, которую потом невозможно интерпретировать. Намного полезнее прогнать как минимум три сценария отдельно: browsing, search/cart и checkout. Тогда вы увидите, какой именно этап срывается первым, и сможете исправлять его адресно. Внутренние ссылки между тестами тоже станут понятнее: если checkout падает при умеренном уровне RPS, смотрите concurrency, очереди и внешние зависимости, а не только суммарный трафик.
Если магазин имеет мобильное приложение и веб одновременно, подумайте о различии поведения клиентов. Мобильный трафик часто чаще повторяет запросы к API, а веб-поток может сильнее нагружать CDN и статические ресурсы. Смешивать их в один шаблон стоит только после того, как каждый путь проверен отдельно.
Кэш, CDN и origin: где прячется реальная слабость
На распродажах команды часто радуются хорошему поведению CDN и недооценивают то, что происходит за ним. Edge может отдавать каталог идеально, пока origin медленно деградирует на miss-path, API и админских операциях. Если не смотреть на оба слоя одновременно, то тест создаёт ложную уверенность: снаружи всё быстро, а внутри уже формируется очередь, которая позже ударит по оплате и личному кабинету.
Поэтому отдельная гипотеза должна звучать так: что мы проверяем, edge или origin? Если нужно понять эффективность кэша и rate limiting, один сценарий строится вокруг cache hit. Если надо оценить приложение и базу, второй сценарий должен сознательно включать некэшируемые пути. Подробный разбор такого подхода есть в нагрузочном тестировании за Cloudflare CDN, а также в EN-статье Stress testing behind Cloudflare CDN.
Не забывайте и про административные или полу-приватные маршруты, которые кэш не прикрывает. В периоды пиков они часто становятся неожиданным bottleneck, потому что о них вспоминают только после запуска кампании, когда времени на аккуратную диагностику уже нет.
Abort-критерии и координация с бизнесом и провайдерами
У теста перед Чёрной пятницей должен быть не только технический, но и операционный владелец. Нужно заранее решить, какие показатели считаются красной зоной: рост p95 checkout, доля неуспешных оплат, перегрев очередей, saturation базы, агрессивные срабатывания WAF, потеря доступности админки или проблемы у провайдера. Когда эти правила оговорены заранее, прогон проходит спокойно даже при частичной деградации.
Окно теста лучше согласовать не только внутри engineering, но и с хостером, CDN, security и командой поддержки. Иначе автоматические алерты будут восприняты как реальная авария, а кто-то из дежурных начнёт экстренно менять конфигурацию прямо во время упражнения. Такая импровизация уничтожает результат теста. Ровно поэтому важно соблюдать правила /legal и использовать только авторизованные цели и известные временные окна.
Если у вас ещё нет отдельного контура для контролируемых запусков, зарегистрируйте его через /register и заранее сопоставьте форму теста с возможностями плана на /pricing. В контексте e-commerce удобство stop и воспроизводимость сценария часто важнее максимального теоретического уровня нагрузки.
Что считать успешной подготовкой после прогона
Успех не обязательно означает, что сайт идеально выдержал пик с первого раза. Успехом можно считать и честно найденный предел, если после теста команда поняла, что нужно исправить: расширить кэш, вынести тяжёлые вычисления, оптимизировать индекс, ослабить избыточные WAF-правила, разнести очереди или пересмотреть checkout-path. Плохо не найти проблему, а не зафиксировать её заранее.
После каждого прогона соберите короткий отчёт для бизнеса и инженерии: что моделировали, на каком уровне началась деградация, какая зависимость провалилась первой и как это влияет на фактическую готовность к распродаже. Это помогает руководству принимать решения об объёме акции, а инженерам не спорить о приоритетах. Если изменения внесены, повторите тот же сценарий ещё раз, иначе вы не поймёте, действительно ли исправление помогло.
В идеале стресс-тест перед Чёрной пятницей становится не однодневной паникой, а частью календаря подготовки. Тогда сезонный пик перестаёт быть лотереей и превращается в управляемое инженерное событие с понятным запасом прочности.