Перформанс начинается с требований

21.10.2025

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

теория

📋

Введение

Большинство перф-тестеров хотя бы раз сталкивались с ситуацией, когда после детального отчёта и аккуратных графиков клиент задаёт один и тот же вопрос:

«Так это хорошо или плохо?»

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

Без чётких критериев команда не знает, куда стремиться, а заказчик не понимает, за что платит. Именно поэтому работа над NFR-ами — это не бюрократия, а ключевой этап построения зрелой инженерной культуры.

Содержание

🧠 Эта статья основана на разговоре и совместных размышлениях с Иваном Зарубиным, Надеждой Тамела и Сергеем Руденко.

🔍 Что такое перформанс-требования и зачем они нужны

Перформанс-требования — это язык общения между инженерами, бизнесом и юзерами. Это набор измеримых характеристик, определяющих, при каких условиях система считается работающей хорошо.

Когда нет критериев, победит тот, кто громче скажет, что всё работает.

NFR-ы:

  • позволяют определить границы «нормальной» работы;
  • создают основу для анализа;
  • фиксируют ожидания бизнеса и юзеров.

Хорошие NFR отвечают не только на вопрос насколько быстро, но и на насколько стабильно и насколько предсказуемо. Без этого легко попасть в иллюзию успеха: приложение летает на QA-энве, но умирает при первых 1000 реальных юзерах.

🧭 Как определить требования: от наблюдений к метрикам

Перформанс начинается не с JMeter, а с понимания бизнеса.

  1. Кто пользователи?
  2. Что они делают?
  3. Какие операции критичны для бизнеса?

Только после этого переходят к цифрам.

Хорошие требования не придумывают, их находят в данных.

📊 Источники для определения NFR:

  • Логи и мониторинг продакшена — реальная статистика по сценариям.
  • Наблюдение за пользователями — как часто и где возникают пиковые нагрузки.
  • Бизнес-контекст — сезонность, часы активности, тип клиентов.
  • Аналитика и опыт экспертов — прогноз для новых систем.

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

У крупных компаний каждые 100 мс задержки — это процент потерь дохода.

NFR не высечены в камне. Это живой документ, который нужно пересматривать, когда продукт растёт, инфраструктура меняется или появляются новые сценарии.

🧩 Кто отвечает за NFR

На зрелых проектах требования формулируются совместно: архитекторы, разработчики, тестирование и бизнес. Но чаще — их пишет перформанс-инженер. Просто потому что больше некому.

«Хочу, чтобы было не хуже» — не требование. Это самоуспокоение.

Хороший инженер не ждёт готовых метрик. Он предлагает их сам: анализирует, формулирует, согласовывает и фиксирует. Так тесты становятся инженерной практикой, а не хаосом.

Иногда NFR рождаются из инцидентов: что-то упало, бизнес потерял деньги и только потом формируется требование «чтобы не повторилось». Зрелые команды действуют наоборот — они формулируют границы заранее.

⚠️ Типичные ошибки

  1. ❌ Хочу быстрее без цифр. Не цель.
  2. ⚖️ Среднее время отклика. Среднее ничего не значит, смотрите перцентили.
  3. 🔍 Без приоритизации. Не все сценарии важны одинаково. Checkout важнее страницы профиля.
  4. 🧱 Игнор архитектуры. Иногда проблема в дизайне, а не в коде.
  5. 🔄 Статичные цифры. Требования должны обновляться вместе с системой.

Плохие NFR хуже, чем их отсутствие.

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

📈 Метрики, на которые стоит смотреть

Перформанс — это не одно число. Это экосистема метрик.

  • Нагрузочные: пользователи, сессии, транзакции/сек.
  • Временные: медиана, 90-й и 95-й персентили, максимумы.
  • Ресурсные: CPU, память, IO, сеть, база.
  • Поведенческие: частота ошибок, время восстановления, GC-паузы, количество таймаутов.

Если всё идеально при 80% нагрузки, вы просто не тестировали достаточно сильно.

Важно не только измерять, но и понимать причинно-следственные связи. Рост CPU может быть следствием неэффективного кэша, а рост задержек в сети — проблемы в балансировщике. Перформанс-инженер должен мыслить системно: искать закономерности, а не отдельные виновные метрики.

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

🔧 Главные челленджи

  1. 📉 Нет данных. Без логов любые оценки субъективны.
  2. 🗣 Разные языки. Девы говорят о TPS, аналитики — о юзерах, бизнес — о прибыли.
  3. 🕒 Позднее подключение. Вспоминают о перформансе за месяц до релиза.
  4. 🧩 Разобщённость. Никто не чувствует ответственности.
  5. 💸 Недооценка перформанса. Пока система не падает, кажется, что всё хорошо, его воспринимают как приятное дополнение.

Перформанс — это инвестиция в будущее. Мы тестируем не сегодня, мы страхуем завтра.

☁️ Прод-лайк энвайрмент

Тесты имеют смысл только в продоподобном окружении.

Тестировать перформанс на QA — как проверять самолёт в гараже: он двигается, но не летает.

Идеальный энвайрмент:

  • то же количество серверов и ядер;
  • идентичные настройки баз и кэшей;
  • одинаковые версии JVM, драйверов и сервисов.

В облаке это стало проще: Terraform, Helm, CloudWatch, Grafana, Prometheus. Главное — наблюдаемость и стабильность.

Тесты должны имитировать реальные сценарии: логин, навигацию, покупки, отчёты. Иначе результат не покажет, как поведёт себя прод.

💼 Инвестиция, а не бюрократия

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

В зрелых командах NFR — это не бумажка, а часть ДНК.

Требования делают тесты полезными. Разработчики знают границы, бизнес — понимает риски, инженеры — видят цель. Это не про отчётность, это про контроль над ростом системы.

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

🧭 Вместо вывода

Перформанс без требований — это полет без приборов. Можно лететь по ощущениям, но рано или поздно наступает туман, и система теряет ориентацию.

Требования — это карта и компас. Без них каждый оптимизирует что-то своё, но никто не движется вперёд.