Аналитика нагрузочного тестирования
Проблемы с производительностью обычно проявляются в самый неподходящий момент: когда резко растет нагрузка или система обрабатывает сложные сценарии.
Именно для таких ситуаций существует нагрузочное тестирование. Но сам процесс — это не только запуск тестов. Нужно собрать требования, подготовить инфраструктуру, настроить инструменты и синхронизировать работу команд.
Егор, аналитик в Naumen Contact Center, рассказал, как внутри продукта устроено нагрузочное тестирование и почему «запустить тест» — самая простая часть.
Что такое нагрузочное тестирование?
Нагрузочное тестирование показывает, насколько хорошо система справляется с большим количеством пользователей или объемом данных. В случае контакт‑центра это, например:
- количество одновременно работающих операторов
- нагрузка на входящие и исходящие вызовы
Почему аналитик вообще занимается нагрузочным тестированием?
У каждого аналитика в нашей команде есть свои зоны экспертизы. Я, например, начал погружаться в тему производительности, поэтому нагрузочное тестирование со временем стало частью моей работы.
Моя задача — анализировать требования и описывать, как именно должно проходить нагрузочное тестирование: что проверяем, какие сценарии запускаем и какие параметры считаем важными.
Когда нужно проводить нагрузочное тестирование?
Есть несколько типичных ситуаций, когда без него не обойтись:- Регулярные проверки перед релизом или после обновления серверов.
- Тестирование новых фич — если изменения потенциально могут повлиять на производительность.
- Запросы от клиентов или команды внедрения — когда нужно проверить нагрузку или конфигурацию.
- Внутренние задачи разработки — когда команде нужно проверить свои решения под нагрузкой.
Однако протестировать все невозможно — это требует слишком больших ресурсов. Поэтому мы используем карту нефункциональных требований: проходим по чек-листу и смотрим, могут ли изменения повлиять на производительность системы.
Как принимается решение о проведении тестирования?
Обычно это происходит на встрече по оценке фичи. В обсуждении участвуют тимлиды разработки, архитекторы, тестировщики и другие cпециалисты. Аналитик приносит информацию по изменениям, а дальше команда совместно решает, нужен ли нагрузочный тест.
Как устроен процесс нагрузочного тестирования?
Процесс можно разделить на три этапа:
- Первичная аналитика — собираем требования и определяем цель.
- Детальная аналитика — описываем сценарии, метрики, инфраструктуру.
- Проведение тестов — запускаем тестирование и анализируем результаты.
Почему нагрузочное тестирование требует отдельной инфраструктуры?
Для более-менее реалистичного тестирования недостаточно одного сервера. В нашем случае используются несколько гипервизоров, десятки виртуальных машин, серверы генерации и приема нагрузки, а также инструменты вроде Gatling, JMeter, Grafana и Ansible.
Отдельные компоненты эмулируют работу операторов и клиентов. Например, для проверки нескольких тысяч операторов фактически собирается отдельный контур.
Почему даже короткий тест может занимать полтора часа?
Потому что сам прогон — только часть процесса. До запуска нужно подготовить окружение, очистить старые данные, проверить сервисы, настроить мониторинг и применить параметры. После — собрать артефакты, метрики и результаты. Поэтому тест на 20 минут превращается в полтора часа работы.
Что происходит после тестирования?
После прогона команда анализирует логи, метрики, бизнес-отчеты и дашборды в Grafana. Есть основные метрики, которые проверяются постоянно. Для контакт-центра это, например, скорость установления соединения, скорость открытия экранных форм, переходов между ними и закрытия экранных форм.
Если эти показатели проседают, тест нельзя считать успешно пройденным, даже если сама фича формально работает.
После анализа команда либо фиксирует результаты, либо заводит задачи на доработку сервисов, окружения или инструментов.
