VC LABКейсыКейс: performance-платформа

Performance-платформа: нагрузочное тестирование до того, как нагрузка стала проблемой

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

Исходная ситуация

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

  • Нет профиля нагрузки — неизвестно, какие запросы и в какой пропорции идут в пик.
  • Нет порогов — непонятно, что считать «выдержала».
  • Узкие места известны по ощущениям, а не по измерениям.
  • Внешние интеграции с лимитами запросов, которые в пик могут исчерпаться.

Что сделали

  1. Сняли профиль нагрузки с реальных логов за прошлую кампанию: какие запросы, в какой пропорции, с какими пиками по часам.
  2. Зафиксировали с владельцем продукта целевые пороги: p95 времени ответа для интерфейсных запросов и для пересчёта отчётов, допустимую долю ошибок на целевой нагрузке.
  3. Собрали сценарии пика в k6: интерфейс, API, сбор данных из кабинетов и пересчёт — с учётом лимитов внешних интеграций.
  4. Прогоняли ступенями с мониторингом базы, очередей и внешних вызовов, повышая нагрузку до нарушения порогов.
  5. Отдали отчёт с точкой насыщения, узкими местами, ранжированными по стоимости исправления, и воспроизводимыми сценариями.
Инструменты: k6 для сценариев, Postman для API-коллекции, мониторинг базы и очередей на стороне заказчика, Jira для дефектов.

Результат

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

Что оказалось важным

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

Частые вопросы

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

Расскажите о задаче

Ответим в течение одного рабочего дня, оценку пришлём за 1–2 дня. Бесплатно.

Обновлено: 2026-10-02