Почему API стоит тестировать до релиза, а не после инцидента
API обычно ломается не в момент первого deploy, а в момент первого настоящего пика. В staging редко есть те же таймауты upstream-сервисов, та же конкуренция за пул соединений и тот же профиль клиентов, что в production. Поэтому авторизованное нагрузочное тестирование перед релизом полезно не как «галочка QA», а как способ обнаружить хрупкие места до того, как их обнаружат реальные пользователи или партнёрские интеграции.
Особенно это важно для auth, checkout, поиска, webhook-обработчиков и публичных API, которые запускаются вместе с маркетинговой кампанией или новой мобильной версией. Красивый smoke-тест говорит лишь о том, что маршрут в целом жив. Настоящий stress test показывает, где начинают расти p95 и p99, сколько ошибок появляется при очередях, и выдерживает ли приложение рост одновременных сессий без цепной деградации.
Если вам нужен англоязычный аналог этой статьи, он находится в Stress test API before launch. Для терминов и метрик также полезно прочитать Конкурентные соединения vs RPS и EN-версию Concurrent connections vs RPS, чтобы одинаково понимать язык теста внутри команды.
Какие сценарии включать в прогон
Главная ошибка перед релизом API состоит в попытке «нагрузить всё сразу». На практике лучше выбрать 1–3 критичных сценария и построить прогон вокруг них. Для B2B API это может быть выдача токена, чтение основного ресурса и запись события. Для e-commerce API это, как правило, корзина, расчёт стоимости и подтверждение заказа. Для внутреннего сервиса важнее всего endpoint, через который проходит наибольшая доля реального трафика или самая дорогая бизнес-операция.
Сценарий должен быть достаточно реалистичным, чтобы нагружать именно тот компонент, в котором вы сомневаетесь. Если гипотеза связана с базой, кэшем или приложением, нужен L7-путь с реальными маршрутами и заголовками, а не абстрактный поток случайных запросов. Если же опасение связано с сетевым периметром, полезно отдельно свериться с L4 и L7 нагрузочным тестированием, чтобы не перепутать слой проблемы и слой инструмента.
Сразу определите, какие зависимости входят в scope. Платёжный провайдер, сторонний KYC, антифрод или email gateway могут стать самой хрупкой частью релиза. Иногда правильное решение состоит не в том, чтобы нагружать сторонний сервис, а в том, чтобы эмулировать его ответ и проверить, как ваше API ведёт себя при росте числа запросов внутри разрешённого тестового окна.
Как моделировать нагрузку без самообмана
До запуска теста нужно решить, что именно вы измеряете: рост одновременных соединений, пропускную способность в запросах в секунду, устойчивость при длительном прогоне или поведение на коротком пике. От ответа зависит форма ramp-up. Для большинства API разумно стартовать с небольшого уровня concurrents, зафиксировать baseline, затем повышать нагрузку ступенями. Такой подход помогает увидеть точку, где приложение ещё работает, но уже заметно деградирует.
Слишком резкий выход на максимум плана портит результат: вы видите только факт аварии, но не понимаете, где начался путь к ней. Намного полезнее привязать ступени к гипотезе. Например, первая ступень подтверждает обычный дневной пик, вторая имитирует маркетинговый всплеск, третья проверяет запас прочности. Именно поэтому страницы тарифов вроде /pricing стоит читать не как каталог «мощности», а как набор лимитов под конкретную задачу: длительность, concurrents, доступ к API и удобство управления прогоном.
Независимо от объёма трафика тест должен оставаться авторизованным и управляемым. Перед прогоном подтвердите право на цель, согласуйте окно и перечень хостов, а также убедитесь, что правила /legal и внутренний процесс компании допускают именно такой вид проверки. Это не формальность: согласованный scope защищает команду так же, как и сам сервис.
Что наблюдать во время теста и когда останавливать
Во время прогона мало смотреть только на график RPS из панели нагрузки. Для API по-настоящему важны несколько групп метрик: latency по перцентилям, доля 4xx и 5xx, состояние connection pool, загрузка CPU, очереди воркеров, file descriptors, лимиты базы данных и поведение rate limit. Если часть запросов начинает отваливаться, важно понять, происходит ли это из-за защиты, из-за приложения или из-за зависимого сервиса за ним.
Критерии остановки должны быть оговорены заранее. Например: p95 выше установленного SLA дольше N минут, error rate превышает допустимый порог, очередь не разгружается на плато, или сервис начинает вредить смежным системам. Без заранее определённого abort тест легко превращается в спор прямо в момент деградации. Хорошая практика состоит в том, чтобы назначить отдельного человека, который следит за мониторингом и может вовремя нажать stop.
После остановки дайте системе остыть и посмотрите, насколько быстро она возвращается к норме. Липкая очередь, длительный recovery, медленный возврат connection pool или затянувшийся autoscaling часто важнее, чем сама пиковая точка. Если вы готовите новый API к запуску, именно такие постэффекты часто объясняют, почему ночью всё прошло «нормально», а утром сервис всё равно ушёл в инцидент.
Как превратить результаты в безопасный релиз
Правильный итог теста не сводится к формуле «выдержало» или «не выдержало». Нужен короткий отчёт с исходной гипотезой, параметрами прогона, точкой деградации, первой ломающейся зависимостью и решением: оптимизировать приложение, увеличить пул, поправить кэш, изменить лимиты или пересобрать rollout-план. Когда findings сформулированы чётко, нагрузочный тест становится частью инженерного процесса, а не разовым экспериментом.
Если ресурс выдержал целевой уровень с запасом, это тоже результат. Он позволяет релизить спокойнее, точнее выбирать план и не покупать лишнюю ёмкость без необходимости. Если же bottleneck найден, устраняйте его и повторяйте проверку на том же сценарии, чтобы сравнение было честным. Для команд, которым нужен готовый рабочий контур, разумно зарегистрировать отдельный аккаунт в /register и запускать только в подтверждённых окнах на verified targets.
В этом смысле хороший stress test API перед релизом не «доказывает силу», а уменьшает неопределённость. Он показывает, насколько дорого вам обойдётся всплеск трафика, где закладывать буфер и какие компоненты нужно усилить до того, как пользователи наткнутся на проблему первыми.