Реклама сработала, сайт лёг: как проверить предел системы до пикового трафика

В 19:59 маркетолог обновляет рекламный кабинет. В 20:00 кампания выходит. В 20:03 рабочий чат уже выясняет, почему корзина не открывается, форма не отправляется, а страница акции показывает белый экран. На сайт одновременно пришла вся аудитория. Через три минуты знакомство закончилось.

Нагрузочное тестирование помогает провести эту встречу заранее: воспроизвести ожидаемый поток пользователей, увидеть предел системы и проверить, что после пика она возвращается в нормальное состояние. Сценарий «реклама сработала, сайт лёг» при этом остаётся внутри тестового контура.

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

От маркетолога нужны четыре цифры — дальше работает техническая команда

Фраза «ждём 50 000 посетителей» почти бесполезна для теста без привязки ко времени и действиям. Пятьдесят тысяч человек за неделю и пять тысяч за первые десять минут создают для системы разные задачи. При этом одни читают лендинг, а другие одновременно ищут товар, применяют промокод и переходят к оплате.

На старте маркетолог передаёт четыре вводных: прогноз переходов в первый час и самую плотную минуту, ожидаемую долю людей на каждом шаге воронки, примерную длину сессии и долю мобильного трафика. Источники этих данных — медиаплан и аналитика прошлых запусков. Этого достаточно, чтобы передать задачу технической команде: p95, кэш и конфигурацию серверов дальше разбираем мы.

По этим вводным собираем профиль нагрузки. Допустим, из 100 одновременных пользователей 60 смотрят страницы, 25 работают с поиском и фильтрами, 10 меняют корзину, а 5 оформляют заказ. Пропорции задаёт ожидаемая воронка кампании. Круглая цифра «проверили тысячу пользователей» выглядит солидно на слайде, но не описывает реальную кампанию. Для теста нужен поток с теми же пропорциями и ритмом, которые ожидаются на запуске.

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

Проверять главную страницу — как тестировать магазин по вывеске

Главная страница часто отдаётся через CDN — сеть серверов, которая хранит копии контента ближе к пользователю. Она может открываться быстро, пока поиск ждёт базу данных, корзина получает устаревшие остатки, а форма второй раз пытается передать заявку в систему управления клиентами (CRM).

Поэтому сценарий теста повторяет путь человека. Для интернет-магазина это обычно такая цепочка:

• открыть страницу акции или каталог;

• найти товар через поиск и фильтры;

• открыть карточку и добавить позицию в корзину;

• применить промокод или бонусы;авторизоваться либо оформить заказ без регистрации;

• выбрать доставку и способ оплаты;

• получить подтверждение заказа.

У рекламного лендинга маршрут короче, но заканчивается он дальше кнопки «Отправить»: заявка должна записаться в CRM с корректным источником, а человек — увидеть, что форма принята. Иначе клики не превращаются в заявки для отдела продаж.

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

Среднее время ответа выглядит прилично, пока медленные запросы уже портят продажи

Этот показатель сглаживает хвост медленных запросов. Девять покупателей могут пройти оформление быстро, а десятый несколько секунд смотрит на неподвижную кнопку. Итоговая цифра останется приличной; у десятого покупателя будет своя версия отчёта — короткая и без покупки. Поэтому среднее оставляем для общей картины, а решение принимаем по хвосту медленных запросов.

Для ключевых действий мы смотрим перцентили. p95 показывает время, быстрее которого завершились 95% операций, p99 — 99%. Эти показатели отвечают на практический вопрос: насколько плохо приходится самым терпеливым пользователям во время пика.

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

Кнопка всё ещё недоступна: где теряется время после ответа сервера

После получения данных браузеру ещё нужно собрать страницу и обработать интерфейс. Протокольный тест создаёт основной поток HTTP-запросов, а несколько браузерных сценариев показывают, что видит человек. Для страницы мы фиксируем ориентиры Core Web Vitals: Google относит к хорошим полевым значениям LCP до 2,5 секунды, INP до 200 миллисекунд и CLS до 0,1 у 75% просмотров. Эти метрики описывают загрузку основного контента, отклик интерфейса и визуальную стабильность. До запуска мы проверяем доступные показатели в лабораторных условиях, после — сверяем их с данными реальных посетителей.

Документация Grafana рекомендует сочетать оба слоя: один создаёт масштаб, другой проверяет пользовательский путь. Так мы видим давление на серверную часть и задержку между нажатием кнопки и реакцией интерфейса.

Ровный поток, всплеск, стресс и длинная акция ломают сайт по-разному

Один прогон на постоянной нагрузке отвечает только на один вопрос. Перед распродажей полезны четыре режима.

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

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

Стресс-тест увеличивает поток до деградации и помогает найти предел. Мы видим, какой компонент сдаётся первым и по какой метрике приближение к пределу можно заметить заранее. AWS также рекомендует использовать нагрузочные тесты для поиска точки отказа и наблюдаемых признаков её приближения.

На одном из e-commerce-проектов мы использовали k6 и проверяли цепочку от открытия каталога до создания заказа. Первым ограничением стал пул соединений с базой данных: при росте нагрузки p95 увеличился примерно до 2,8 секунды. После оптимизации запроса и настройки пула повторный прогон на том же профиле показал p95 около 700 миллисекунд.

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

В кейсе «Стадикэтс» нагрузка идёт «пилой, а не волной»: дедлайны домашних заданий, пробники и канун экзамена по очереди создают резкие всплески. Задача проекта — обеспечить стабильность, когда ученики одновременно отправляют работы. Учебный календарь здесь становится основой профиля теста. Ровный шаблонный поток скрыл бы важную часть риска.

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

Один заказ, четыре проверки: CRM, защита от дублей, бизнес-события и внешние сервисы

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

Мы проверяем, что отложенные задачи доходят до конца под контролем, а заявка попадает в CRM вместе с источником и контактами. Для оплаты и создания заказа мы используем защиту от дублей: повторный запрос с тем же ключом возвращает прежний результат. Разработчики называют это идемпотентностью; для бизнеса смысл простой: один запрос — один заказ и одна оплата.

Во время теста мы считаем бизнес-события на каждом участке: сколько корзин ушло в оформление, сколько заказов создалось, сколько оплат подтвердилось, сколько записей получила CRM. Разница между соседними цифрами указывает место, где поток начал протекать.

Внешние сервисы мы проверяем отдельно и по договорённости. Платёжный шлюз, 1С, CRM, доставка или сервис рассылок могут иметь собственные лимиты. Для массового прогона мы используем тестовые контуры, заглушки или заранее согласованный объём запросов. Случайный нагрузочный тест чужой системы быстро знакомит со службой безопасности. Подготовить собственный запуск он не помогает.

Тестовая среда должна быть похожа на рабочую там, где больно

Тест на одном сервере с пустой базой плохо предсказывает поведение кластера с миллионом товаров и историей заказов. Полная копия рабочей среды бывает слишком дорогой, поэтому мы добиваемся сходства на участках, которые влияют на результат:

• та же версия приложения и конфигурация сервисов;

• сопоставимые объём и распределение данных;

• такие же база данных, кэш, очереди и правила автоматического масштабирования;

• реальные ограничения CDN, балансировщика, сетевого экрана и защиты от ботов;

• мониторинг на уровне приложения, инфраструктуры и бизнес-событий.

В кейсе 4fresh магазин переезжал с 1С-Битрикс на собственное решение. Вместе с ним мы переносили профили пользователей, историю заказов и тысячи отзывов. Такой объём нельзя честно воспроизвести пустой базой. Поэтому мы готовим среду с совпадающими версиями сервисов и сопоставимым «весом» реальных данных.

Меньший масштаб тестовой среды мы фиксируем в выводах. Мы пересчитываем результат только там, где известна зависимость от ресурсов. Без описания окружения фраза «на тесте всё выдержало» ничего не говорит о готовности к запуску.

Перед большим прогоном мы согласуем время, ответственных и критерии остановки. Мы останавливаем тест при росте числа ошибок, приближении базы к пределу соединений, остановке сокращения очередей или риске для соседних систем. Так мы находим безопасный предел без аварии в рабочем контуре.

Пять ответов, после которых запуску можно дать зелёный свет

Итоговый отчёт должен ответить на пять вопросов:

• Какой поток пользователей и операций система выдерживает с нужным запасом?

• Каковы p95 и доля ошибок на каждом критичном шаге?

• Сходятся ли заказы, оплаты, остатки и заявки между системами?

• Какой компонент ограничивает рост и какая метрика предупредит об этом первой?

• Что команда сделает при превышении прогноза по трафику?

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

Критерий простой: сайт готов к рекламе, когда команда знает его безопасный предел, видит приближение к нему и умеет сохранить заказ при перегрузке. Тогда в 20:03 рабочий чат обсуждает продажи. Белый экран остался на тестовом контуре.

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