Нагрузочное тестирование: как заранее узнать, что система не выдержит

Под общим названием живут пять разных проверок, и они отвечают на разные вопросы.

Есть несколько моментов, когда тест окупается почти гарантированно.

Перед сезонным пиком. Распродажа, старт продаж билетов, приём заявок в конкретную дату, отчётный период в корпоративной системе.

Перед крупной рекламной кампанией. Особенно если планируется телевизионная или наружная реклама: там трафик приходит всплеском, а не ровным потоком.

После смены архитектуры. Переезд на новую базу, разделение монолита, смена хостинга или контура — поведение под нагрузкой меняется непредсказуемо.

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

После инцидента. Чтобы убедиться, что исправление действительно помогло, а не просто совпало с падением трафика.

Главный документ теста и то, что отличает осмысленную проверку от «постучим по сайту».

Считается он из реальных данных аналитики. Берём пиковый день за последний год, смотрим распределение по часам, вычисляем количество запросов в секунду в самый плотный час. Затем закладываем запас: обычно двух-трёхкратный к прошлогоднему пику, если бизнес растёт, или под конкретный план кампании.

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

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

Результат теста ровно настолько достоверен, насколько стенд похож на прод.

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

Данные. Объём базы влияет на всё: запрос, мгновенный на десяти тысячах записей, на десяти миллионах уходит в секунды. Нужны обезличенные данные сопоставимого объёма, а не пустая тестовая база.

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

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

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

Ошибка большинства прогонов: смотрят только на клиентские метрики. Тест говорит «медленно», а причина остаётся неизвестной.

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

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

Ваша система может быть готова, а пик всё равно провалится — из-за того, что от вас не зависит.

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

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

Выбор инструмента — далеко не главное решение в проекте, но пара практических соображений есть.

Для веб-сервисов чаще всего берут k6, JMeter, Gatling или Locust; в российских командах распространён Яндекс.Танк с Pandora. Сценарии описываются кодом, поэтому живут в репозитории рядом с проектом и переживают смену команды.

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

Мониторинг во время теста важнее самого инструмента: без графиков со стороны системы вы получите только внешние цифры и никаких причин.

Хороший отчёт отвечает не «выдержали или нет», а на четыре вопроса.

Какой запас есть сегодня. Целевой RPS профиля против фактически достигнутого до начала деградации.

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

Как система ведёт себя за пределом. Плавная деградация с ростом времени ответа — приемлемо; каскадный отказ с потерей данных — критично.

Что делать. Список исправлений, отсортированный по соотношению эффекта и стоимости: обычно два-три изменения дают кратный прирост, а остальное — тонкая настройка.

Отдельно фиксируется, при каких условиях результат действителен: конфигурация стенда, объём данных, версия кода. Через полгода и три релиза цифры становятся историей, а не гарантией.

Ситуация, в которой к нам приходят чаще всего: распродажа послезавтра, а полноценный цикл занимает недели. Что можно успеть.

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

Отключить необязательное на время пика. Персональные блоки, тяжёлые счётчики, живой пересчёт остатков на каждый показ, рекомендации в реальном времени. Функциональность вернётся через два дня, выручка — нет.

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

Поставить очередь и лимиты. Оформление заказа принимается в очередь и обрабатывается асинхронно, на входе — ограничение одновременных запросов, чтобы система деградировала предсказуемо, а не падала.

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

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

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

Рабочая схема — два уровня. Короткий прогон в конвейере сборки на каждый релиз: один-два ключевых сценария, несколько минут, сравнение с прошлым результатом и предупреждение при ухудшении больше заданного порога. И полный прогон по расписанию — раз в квартал и перед сезоном.

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

Объём работ определяют количество сценариев, состояние стенда и то, нужно ли потом исправлять найденное.

По нашим работам: аудит кода и архитектуры с разбором производительности — от 200 до 600 тыс. ₽, DevOps-работы отдельной услугой (стенд, мониторинг, конвейер) — от 200 тыс. ₽, доработка системы под нагрузку в составе проекта — от 1,7 млн ₽, разработка высоконагруженного продукта — от 5 млн ₽. Точная цифра зависит от сценариев и глубины разбора: оценка проекта бесплатная.

Прикинуть бюджет можно заранее — бесплатный калькулятор оценки собирает вилку по составу работ за несколько минут.

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

Стенд не похож на прод. Другая конфигурация, пустая база, отключённые фоновые задания — результат не переносится.

Мониторинг не включили. Есть график времени ответа и ничего изнутри системы: узкое место остаётся гипотезой.

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

Проверили только идеальный путь. Реальный пик — это ещё и отвалившийся платёжный шлюз, и повторные попытки пользователей, и одновременная выгрузка в учётную систему.

Первое — достать цифры прошлого пика: максимум запросов в секунду, распределение по сценариям, что тогда сломалось. Если данных нет, начать нужно с мониторинга, а не с теста.

Второе — определить цель: какой трафик нужно выдержать и с каким временем ответа. Формулировка «должно работать быстро» не проверяется; «p95 не выше 500 мс при 300 запросах в секунду» проверяется.

Третье — оценить состояние стенда. Часто именно подготовка среды и обезличенных данных занимает больше времени, чем сам прогон, и это стоит знать заранее.