Привет, Хабр!

Меня зовут Андрей Бирюков. Я — независимый эксперт в области ИТ и ИБ, преподаю в учебных центрах и пишу статьи и книги.

Стенд в тестировании — ключевой элемент, который нужен для проверки работоспособности приложения. А стенд для нагрузочного тестирования — это не просто «железо», на котором запускают JMeter, а сложный комплекс, который должен с максимальной точностью имитировать продуктивную среду, чтобы результаты тестов имели ценность.

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

В статье разбираюсь, как решить эту проблему.

Какие бывают стенды и зачем они нужны

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

Стенд, приближенный к продуктивному (Performance / Pre‑Prod), представляет собой основной инструмент для финальных замеров. Его главная цель — дать ответ на вопрос:

«Выдержит ли система пиковую нагрузку в Чёрную пятницу?»

Например, при тестировании банковского процессинга на стенде разворачивают не только саму АБС, но и эмуляторы внешних систем (например, НСПК с искусственной задержкой ответа 500 мс), чтобы узкие места проявились именно там, где они возникнут в реальности.

На таком стенде критически важно совпадение версий ОС, СУБД и даже точечных настроек с продом.

Изолированный стенд для отладки и CI/CD по сути является той самой «песочницей», которую используют разработчики и инженеры по производительности. Здесь уже не требуется копия всей продуктивной среды.

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

Например, стенд на базе одного сервера с развёрнутым Apache JMeter и тестовой базой, где проверяется деградация времени отклика конкретного API. Такой стенд дешевле, но его результаты нельзя экстраполировать на всю систему.

Наконец, демонстрационные и лабораторные стенды (полигоны) используются для проверки совместимости и предварительной оценки производительности перед закупкой оборудования или миграцией.

Например, демолаборатория на базе российских серверов и СХД позволяет заказчику прогнать нагрузочный тест на VDI или СУБД, чтобы понять, хватит ли мощности, прежде чем подписывать контракт.

Разобравшись с видами стендов, вернусь к стендам для нагрузочного тестирования.

Главные особенности

Стенд для нагрузочного тестирования отличается от функционального или разработческого набором «фишек», без которых тест теряет смысл.

Так, здесь обязательно должен быть генератор нагрузки и необходимые эмуляторы, размещённые в отдельном контуре. И на стенде не должно возникать ситуаций, когда генератор нагрузки «съедает» ресурсы тестируемого приложения.

В идеале это должны быть отдельные машины или даже сеть.

Более того, для сложных систем (банки, телеком) обязательно наличие эмуляторов внешнего окружения. Если вы тестируете оформление заказа, а платежный шлюз отвечает за 2 секунды, вы будете оптимизировать не то место.

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

Но здесь важно понимать, что данные — это половина теста.

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

Для систем «1С» или ERP это означает, что в базе должны быть данные за 1–3 года, чтобы запросы выполнялись так же, как у бухгалтера, который работает в системе с 2022 года.

Если данных мало, СУБД выберет индексный доступ там, где на реальном объёме потребуется скан таблицы, и вы получите ложный оптимизм.

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

Так, если для тестов должны использоваться ФИО, паспорт и другие сведения, подпадающие под требования ФЗ «О персональных данных», то нам необходимо либо защищать их в соответствии с нормативкой, либо заменить эти записи вымышленными данными, которые в реальности никому не принадлежат.

Мониторинг должен быть сквозным, так как нагрузочный стенд неотделим от системы мониторинга (APM, логи, метрики ОС).

Причём мониторить нужно не только «среднюю температуру по больнице», но и ресурсы каждого узла.

К примеру, в тестах «1С» система мониторинга позволяет увидеть, что при росте виртуальных пользователей упирается не CPU, а дисковый ввод‑вывод на сервере СУБД, и вовремя остановить тест, чтобы не ждать восстановления стенда полдня.

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

От цели к конфигурации

Выбор стенда начинается не с вопроса «сколько серверов взять», а с вопроса:

«Какое решение мы хотим принять по итогам теста?»

Начинать нужно с определения бизнес‑целей, так как если цель — подписание акта о том, что внедрённая система соответствует SLA (например, время закрытия месяца не более 4 часов), вам нужен стенд, максимально похожий на прод, с полными данными и реальными сценариями.

Ну а если цель — найти узкое место в новом микросервисе, достаточно изолированного стенда с этим сервисом и его зависимостями.

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

Например, для контакт‑центра профиль нагрузки представляет собой не просто «1000 звонков в час», а соотношение:

• дозвонившихся;

• времени разговора;

• времени после разговора;

• количества одновременных операторов в CRM.

Стенд должен быть спроектирован так, чтобы генерировать именно этот профиль, а не абстрактные HTTP‑запросы.

Масштаб стенда — это отдельная большая тема, так как полная копия продуктива, конечно, очень дорогая.

Для решения этой проблемы часто используют масштабирование, то есть стенд меньше по количеству серверов, но при этом тестируется не «предельная нагрузка на 10 000 пользователей», а удельная производительность (например, сколько транзакций в секунду обрабатывает один узел приложения).

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

В реальных условиях у нас не бывает всё стерильно, поэтому и на стенде необходимо включить «токсичные» факторы:

• включите фоновые задачи (бэкапы, регламентные операции);

• ограничьте сеть, если в продуктивной среде есть сетевые задержки между дата‑центрами.

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

Вывод

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

Также не стоит искусственно усложнять то, что в реальности не требуется (например, увеличивать время ответа внешних сервисов), но и не надо упрощать то, что действительно может создать сложности (к примеру, уменьшать объём обрабатываемых данных).

Тогда собранный вами стенд позволит по‑настоящему эффективно проверить приложение в условиях, максимально приближённых к реальности.

Если хотите развиваться в Performance Testing, важно систематизировать знания и уверенно владеть инструментами диагностики производительности. На курсе «Нагрузочное тестирование» можно углубить практические навыки, научиться находить узкие места и оценивать производительность систем в условиях реальной нагрузки.

А начать можно с бесплатного демо‑урока, который проведет преподаватель курса:

• 17 ноября в 20:00. «Почему тормозит приложение: диагностика в Wireshark». Записаться