Я провёл несколько лет в роли Leadа нагрузочного тестирования. И если честно, долгое время это была специализация из разряда “да зачем оно надо, это ваше НТ, купим ещё серваков и железа клевого”. Сейчас всё изменилось. Расскажу почему.

Железо подорожало. И всё подходы перестали работать Ещё пару лет назад в компаниях была простая и рабочая логика: сервис начинает тормозить под нагрузкой, не беда, докидываем железо. CPU не справляется меняем на лучшее! Память кончается, add плашек или буст. Не дорого, быстро и предсказуемо.

Потом серверное железо резко подорожало. Развитие ИИ, санкции, курс $, логистика и всё это потянуло цены вверх. Но не важно почему, важнее что это произошло. И внезапно оказалось, что “докинуть железа” перестало быть дефолтным решением. Бюджеты компаний не резиновые, а проблемы с производительностью никуда не делись.

И вот тут команды начали задавать вопросы, которые раньше не задавали.

Новые вопросы, новые задачи Раньше вопрос звучал так: “Сколько серверов докупить?”

Сейчас он звучит иначе: “А насколько эффективно то, что уже есть?”

Это принципиально другая постановка задачи. И она требует принципиально другой работы.

Конкретно команды начали смотреть на вещи, которые раньше просто игнорировались:

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

Эффективность сборки. Насколько вообще оптимален код под нагрузкой? Где реальные узкие места: в бизнес-логике, в работе с базой, в сериализации, в сети, как настроен балансер и есть ли он? Профилирование под нагрузкой стало не академическим упражнением, а практической необходимостью.

Что бустить, а что не трогать. Это, пожалуй, самый тонкий момент. Не всё, что кажется узким местом, стоит оптимизировать. Иногда агрессивная оптимизация одного компонента создаёт новые проблемы в другом. Или даёт прирост в 2% при риске сломать стабильность. Грамотный специалист по производительности умеет отличить реальный прирост и спрогнозировать его.

Почему специалистов мало За несколько лет в этой роли удалось донести простую вещь: нагрузочное тестирование — это не про запустить в JMeter коллекции из Postman и посмотреть что упадёт)

Это инженерная работа на стыке нескольких дисциплин одновременно.

Нужно понимать как работает сеть. Как устроена база данных и почему один и тот же запрос под нагрузкой ведёт себя иначе чем в покое. Как читать профайлер и отличать реальную проблему от шума. Как устроена очередь потоков в JVM. Как интерпретировать графики из Grafana и не делать неправильных выводов.

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

Это не быстро обучаемая специализация. От джуна или запускатора тестов пользы будет мало.

Отдельный привет финтеху Есть один паттерн, который я наблюдал в финтех-командах достаточно часто, чтобы считать его не случайностью.

Выглядит это примерно так. Команда НТ показывает результаты: система выдерживает X запросов в секунду. Через квартал уже X+3-4%. Ещё через квартал ещё плюс 2-4%. Красивые графики, положительная динамика, все довольны.

Только вот полная картина по системе почему-то не показывается никогда. Не потому что данных нет. А потому что если показать всё сразу — следующий квартал будет не таким убедительным. А убедительный следующий квартал — это бюджет, headcount и в целом ощущение собственной необходимости.

Иногда в этой схеме участвует только НТ. Иногда к ней подключается разработка, иногда аналитики. Получается такой негласный “производительностный” договор: мы показываем прирост, вы не задаёте лишних вопросов, все выглядят молодцами.

Зелёный статус есть. Апрув получен. Все свободны.

Но если вы Head of QA или CTO и ваша команда НТ квартал за кварталом показывает стабильный прирост без единого неудобного результата — это повод задать пару вопросов. Например: “А покажите полную картину по системе целиком?” или привлечь кого-то со стороны.

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

При этом рынок предложения практически не изменился. Специалистов было мало и остаётся мало.

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

Сейчас ситуация другая, но экспертиза в короткий срок не вырастает.

Что это значит на практике Если перед вами стоит задача, как выстроить работу с производительностью в команде — несколько наблюдений из практики.

Во-первых, нагрузочное тестирование эффективнее всего работает не как разовая проверка перед релизом, а как часть процесса. Регрессия по производительности на CI = простой способ не узнавать о деградации от пользователей. Подумайте в этом направлении)

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

В-третьих, метрики важнее ощущений. “Кажется стало быстрее” — не результат. Конкретные цифры до и после, воспроизводимый стенд, понятная методология — вот что позволяет принимать осознанные решения о том, что оптимизировать дальше.

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

Специалистов по-прежнему мало. Спрос растёт. Если вы думаете о том, куда развиваться в QA — это одна из немногих специализаций, где рынок пока не перегрет.