7 мая 2026 г.·5 мин чтения

Load testing на собеседовании системного аналитика

Проверь себя · 1/3разбор после ответа
Таблицы orders_2024 и orders_2025 имеют одинаковую структуру. Некоторые заказы случайно попали в обе таблицы. Чем будут отличаться результаты SELECT * FROM orders_2024 UNION SELECT * FROM orders_2025 и того же запроса с UNION ALL?

Содержание:

Виды нагрузочного тестирования

Нагрузочное тестирование — это не один тест, а семейство разных проверок, и на собесе системного аналитика первым делом смотрят, различаете ли вы их. Каждый вид отвечает на свой вопрос о поведении системы.

  • Load test (нагрузочный). Прогоняем ожидаемый рабочий трафик и проверяем, что система держит его в рамках SLA. Базовый вопрос: «выдерживаем ли мы обычную нагрузку».
  • Stress test (стресс). Даём нагрузку выше проектной ёмкости, чтобы увидеть, как именно система деградирует и падает — плавно или обвально, и восстанавливается ли после. Вопрос: «где наш предел и что происходит за ним».
  • Spike test (пиковый). Резкий всплеск трафика за короткое время — распродажа, рассылка, вирусный пост. Проверяем, переживёт ли система внезапный скачок и успеет ли автоскейлинг.
  • Soak / endurance test (на выносливость). Держим нагрузку часами или сутками. Именно так вылезают утечки памяти, исчерпание пула соединений и другие проблемы, которые не видны за пять минут.
  • Volume test (объёмный). Проверяем поведение на больших объёмах данных — распухшие таблицы, длинные очереди, — когда деградирует не трафик, а сам размер данных.

Инструменты

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

  • k6. Современный инструмент, сценарии пишутся на JavaScript, запускается из CLI и легко встраивается в CI/CD. Хорош для инженерного подхода «нагрузка как код».
import http from 'k6/http';

// каждый виртуальный пользователь дёргает endpoint заказов
export default function () {
  http.get('https://example.com/api/orders');
}
  • JMeter. Ветеран с графическим интерфейсом, очень функциональный, много протоколов и плагинов. Тяжеловат и менее удобен для версионирования сценариев, зато закрывает почти любой кейс.
  • Locust. Сценарии на Python, умеет распределённый запуск с нескольких машин. Удобен, когда команда пишет на Python и нужна гибкая логика поведения пользователей.
  • Gatling. На Scala, высокая производительность и хорошие отчёты. Один генератор нагрузки выдаёт много запросов.
  • Yandex.Tank. Российский инструмент с движком Pandora, распространённый в РФ-компаниях. Часто всплывает на собесах именно как локальная альтернатива.
  • Vegeta. Простой инструмент на Go для быстрой проверки постоянной нагрузки на HTTP-endpoint без сложных сценариев.

Сценарии нагрузки

Хороший нагрузочный тест воспроизводит реальное поведение пользователей, а не равномерно долбит один endpoint. Это ключевая мысль, которую проверяют на собесе.

  • Реалистичное распределение. Нагрузка неравномерна: большинство пользователей просто смотрят, и лишь малая доля доходит до оплаты. Тест должен повторять эти пропорции, иначе вы нагружаете не то, что нагружено на проде.
80% — просмотр каталога и карточек
15% — добавление в корзину
 4% — оформление заказа
 1% — административные действия
  • Ramp up (постепенный рост). Плавно повышаем нагрузку, чтобы найти точку, где система начинает деградировать. Так определяют реальную ёмкость и порог, за которым растут задержки и ошибки.
  • Sustained (удержание пика). Держим пиковую нагрузку долго, чтобы поймать утечки памяти и исчерпание ресурсов, которые не видны на коротком прогоне.
  • Mixed (смешанный). Разные типы пользователей работают одновременно — просмотр, покупки, фоновые задачи, — чтобы проверить систему в условиях, близких к боевым.
Готовишься к собесу системного аналитика?
827 вопросов: REST, UML, OAuth, ERD, требования. Тренируйся в Telegram
Тренировать SA в Telegram

Метрики

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

  • Throughput (пропускная способность). Сколько запросов в секунду система реально обрабатывает. Главный показатель ёмкости.
  • Latency (задержка). Время ответа, обязательно по перцентилям — p50, p95, p99, — а не среднее. Среднее прячет проблемы хвоста.
  • Error rate (доля ошибок). Процент упавших запросов. Рост доли ошибок под нагрузкой — сигнал, что система прошла свой предел.
  • Saturation (насыщение ресурсов). Загрузка CPU, памяти, сети, диска. Показывает, какой ресурс упрётся в потолок первым, — обычно именно он и есть узкое место.
  • Tail latency (хвостовые задержки). p99 говорит о худших запросах больше, чем среднее: даже при отличном mean несчастливый 1% пользователей может ловить секундные ответы. SLA обычно живёт именно в хвосте.

Цель всего упражнения — подтвердить, что система держит SLA под ожидаемой нагрузкой с запасом (headroom), а не работает на пределе, где любой всплеск её обрушит.

Связанные темы

FAQ

Чем стресс-тест отличается от нагрузочного?

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

Почему задержку меряют по перцентилям, а не по среднему?

Среднее прячет хвост распределения. При хорошем среднем несчастливые 1% запросов (p99) могут отвечать за секунды — и именно они формируют негативный опыт и нарушают SLA. Поэтому смотрят p95 и p99, а не mean.

Зачем нужен soak-тест, если нагрузочный уже прошёл?

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

Как выбрать реалистичный сценарий нагрузки?

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

Это официальная информация?

Нет. Статья основана на документации инструментов нагрузочного тестирования и индустриальных практиках. Конкретный выбор инструмента и сценариев зависит от системы и требований команды.

Тренируйте системный анализ — откройте тренажёр с 1500+ вопросами для собесов.

Ещё по теме