Я задаю нагрузочный сценарий языком рабочего дня, а не количеством запросов в секунду

Я задаю нагрузочный сценарий языком рабочего дня, а не числом запросов в секунду. Цифра полезна команде, но сама по себе не объясняет, что бизнес считает нормальной работой. Десять запросов могут быть пустыми просмотрами. А один запрос может закрывать месяц, отправлять зарплату или подтверждать заказ.

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

Нагрузка начинается с вопроса «что происходит в этот день?»

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

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

Соберите один сценарий до конца

Для начала достаточно взять критичную операцию и описать её человеческим языком. Кто её запускает? Какие данные нужны? Какие внешние системы отвечают? Какой результат должен появиться? Через сколько времени человек начнёт искать обходной путь?

Например: в последний рабочий день месяца 40 сотрудников в течение часа проводят документы, а руководитель должен видеть итоговый отчёт до встречи. Здесь важно не только количество действий. Нужно проверить блокировки, фоновые расчёты, очереди, отчёт и поведение при повторной отправке.

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

Что должно быть в нагрузочном сценарии

• Время и повод. Не «высокая нагрузка», а закрытие периода, акция, утреннее открытие смены или выгрузка для партнёра.
• Роли и действия. Какие люди делают что именно, а не просто сколько у системы пользователей.
• Порог терпимости. Когда задержка неприятна, а когда она срывает операцию или обязательство.
• Зависимости. Какие базы, сервисы, очереди, внешние API и фоновые задачи участвуют.
• План деградации. Что можно отложить, показать позже или выполнить вручную, если часть контура замедлилась.

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

Почему тест на стенде может обмануть

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

Это не повод бесконечно копировать production. Смысл тестовой среды — безопасно проверить именно рискованный сценарий. В статье о тестовой среде есть простой критерий: на ней должны проверяться изменения, которые опасно впервые увидеть в рабочем дне.

Не путайте быстродействие и надёжность

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

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

Как превратить сценарий в работу команды

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

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

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