Как спланировать нагрузочное тестирование перед ожидаемым пиком трафика (например, распродажей) и какие метрики использовать как критерии готовности?

Короткий ответ

Нагрузочное тестирование должно моделировать ожидаемый пиковый профиль трафика (не просто "побольше запросов"), включать плавное нарастание и удержание пика, а критериями готовности служат не просто "держит RPS", а latency по перцентилям, доля ошибок и поведение при частичном отказе зависимостей под той же нагрузкой.

Как это работает подробнее

сначала оценивают ожидаемый пик (на основе прошлых данных + множителя роста из capacity planning), воспроизводят реалистичный микс запросов (не только GET главной страницы, а реальное распределение эндпоинтов — поиск, добавление в корзину, оплата), и постепенно увеличивают нагрузку, наблюдая за поведением системы, а не только фиксируя "максимальный RPS до падения".

Пример / кейс

Ожидаемое поведение: если во время теста p99 latency превышает 800 мс уже при 3000 RPS, это сигнал, что система не готова к заявленному пику 5000 RPS, и нужны доработки (масштабирование, оптимизация запросов) до реальной распродажи, а не во время неё.

Пример кода

example.txtКопировать

Критерии готовности к распродаже:
- Удержание 5000 RPS в течение 30 минут
- p99 latency на /checkout < 800 мс
- Доля 5xx < 0.1%
- При имитации деградации платёжного провайдера (задержка +2с) — graceful degradation без полного отказа

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

• Практический подход. Тест проводят в среде, максимально близкой к продовой (та же конфигурация ресурсов, те же лимиты БД), заранее предупреждают зависимые команды/внешние сервисы (платёжный провайдер может ограничивать тестовый трафик), и фиксируют несколько критериев готовности: p99 latency ниже целевого порога, доля ошибок ниже установленного значения, отсутствие деградации при удержании пика в течение нужного времени (не только в момент всплеска).

Подводные камни

• Частые ошибки. Тестировать только "максимальный RPS до отказа" без привязки к SLO, из-за чего неясно, достаточно ли этого для реального пика; тестировать в среде, отличающейся от прода по ресурсам или конфигурации кэшей; не тестировать деградацию внешних зависимостей под нагрузкой (например, что будет, если платёжный провайдер начнёт отвечать медленнее под общим пиком).