Нагрузочное тестирование перед запуском: что проверить

Как проверить продукт под нагрузкой: рабочие сценарии, профиль трафика, пороги, очереди и отчёт. Что спросить у команды до запуска и рекламы.

Автор: Арнак Меликян, CTO, 404gen.

В презентации написано: «система выдерживает тысячу пользователей». За этой фразой могут скрываться одновременно открытые страницы, редкое чтение кэшированного каталога или интенсивное создание заказов. Для бизнеса это совершенно разные условия. До запуска нужно узнать, какая работа была проверена и какое качество считалось приемлемым.

Материал предназначен владельцу продукта и руководителю проекта, которым нужно подготовить и принять нагрузочную проверку. Разбираем модель трафика, критерии, окружение и выводы. Общее устройство автоматических проверок описано в статье про unit, E2E и CI/CD. Здесь внимание сосредоточено на поведении системы под нагрузкой перед запуском.

Сначала сформулируйте деловой вопрос

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

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

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

Почему число пользователей не равно числу операций

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

Учебный пример: посетители каталога изучают товар дольше, чем менеджеры сохраняют короткие изменения в очереди обращений. Одинаковое число открытых сессий создаст разную нагрузку. Для предварительного расчёта можно связать ожидаемую частоту действий со средней стоимостью маршрута, но предположения затем проверяются измерением. Это модель для подготовки, не подтверждённый показатель продукта.

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

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

Профиль нагрузки состоит из рабочих маршрутов

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

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

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

Разные испытания проверяют разные риски

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

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

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

Пороги согласуют до просмотра графиков

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

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

В документации k6 по thresholds показано задание условий по измеряемым показателям и результату прогона. Такой механизм помогает автоматически проверять согласованный порог. Само значение выбирают по требованиям продукта; копирование чужого примера не создаёт обоснованного обязательства для вашей системы.

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

Окружение определяет применимость результата

Испытание на рабочем ноутбуке и на целевом контуре отвечает на разные вопросы. Запишите ресурсы приложения, базы, очереди, сетевые ограничения и версии компонентов. Сохраните настройки, влияющие на результат. Если стенд меньше будущего, выводы формулируют с учётом различий, а не умножают итоговую мощность на отношение процессоров без проверки.

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

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

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

Внешние системы требуют отдельной модели ожидания

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

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

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

Очередь может сгладить пик, но не убрать работу

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

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

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

Контролируемое ухудшение лучше неопределённого состояния

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

В главе Google SRE об обработке перегрузки обсуждаются ограничение нагрузки и поведение системы при нехватке ресурсов. Для приёмки важно проверить не только пик, но и понятный отказ, сохранность состояния и восстановление после него. Наличие автоматического масштабирования не отменяет ограничений базы и зависимостей.

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

Какие измерения нужны во время испытания

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

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

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

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

Ошибки, из-за которых отчёт выглядит лучше продукта

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

Ещё одна ошибка состоит в проверке только сетевого успеха. Сервер может вернуть HTML страницы входа, пустой список вместо ожидаемого объекта или сообщение о недоступности с кодом 200. Включите проверки содержимого и результата. Отдельно считайте успешные ответы и правильно завершённые бизнес-действия, чтобы не подменять одно другим.

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

Что должно находиться в отчёте

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

Вывод описывает границу готовности. Например, ожидаемый профиль пройден при согласованном качестве, длительная обработка требует исправления, отдельная зависимость имитировалась и нуждается в проверке. Такие формулировки помогают выбрать действие. Итог «всё хорошо» не раскрывает, какие риски команда действительно проверила и какие оставила предположением.

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

Исправление подтверждается повторным сценарием

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

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

Результаты переходят в эксплуатационные наблюдения. Если испытание выявило значимую очередь или зависимость, для неё нужны понятные сигналы и ответственный. Цель состоит в том, чтобы команда распознала приближение известной границы в реальной работе. Сам факт существования отчёта не сообщает о проблеме дежурному сотруднику.

Серверная мощность и удобство страницы измеряются отдельно

Быстрый API не гарантирует, что пользователь быстро увидит и сможет использовать страницу. На восприятие влияют сеть, изображения, исполнение JavaScript, устройство и стабильность интерфейса. Поэтому нагрузочная проверка сервера дополняется проверкой реального пользовательского пути. Эти измерения отвечают на связанные, но разные вопросы.

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

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

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

Сколько виртуальных пользователей нужно для проверки?

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

Можно ли проверять сразу на рабочем сайте?

Такое испытание требует отдельного согласования границ, участников и последствий. Обычно подготовку и основные эксперименты проводят в управляемом контуре. Важно исключить реальные списания, рассылки и нежелательные изменения данных. Если часть проверки выполняется на рабочей системе, нужны понятные условия остановки и наблюдение за влиянием на настоящих пользователей.

Достаточно ли среднего времени ответа?

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

Почему система выдержала тест, но замедлилась после рекламы?

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

Нужно ли нагружать все внешние сервисы?

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

Что подготовить для оценки испытания?

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

Как подготовить проверку перед запуском

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

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

Источники и границы разбора

Технические источники проверены 15 октября 2026 года. Документация продуктов используется для объяснения конкретных механизмов; выбор платформы требует отдельной оценки. Учебные ситуации не описывают достигнутые результаты клиентов 404gen.

• Grafana k6: виды нагрузочных испытаний
• Grafana k6: пороги и критерии
• Google SRE: обработка перегрузки