Стратегія performance-тестування: від вимог до звіту

З чого ви почнете перф-тестування нового сервісу?

Не з інструмента, а з питання «що ми взагалі міряємо і з чим порівнюватимемо результат». Поки немає відповіді, будь-яке число з прогону нема куди прикласти: воно не проходить і не провалюється, його просто хтось оцінює на око. Тому перші кроки — зʼясувати, хто вважатиме прогін вдалим, які саме користувацькі операції критичні для бізнесу, які метрики під них збиратимемо і яке значення вважаємо прийнятним. Далі — де міряємо і на яких даних, бо стенд і дані визначають достовірність усього результату. Інструмент вибирається останнім, бо він наслідок профілю й метрик, а не їх причина. Слабка відповідь на співбесіді починається з «підняв би JMeter і подивився» — це відповідь про скрипт, а не про тестування.

Що входить у план перф-тесту?

Практично план зводиться до шести рішень, які мають бути ухвалені до того, як хтось напише перший рядок скрипта. Цілі — заради чого прогін і хто підписується під його результатом. Scope — які транзакції граємо і які метрики збираємо. Профіль навантаження — скільки й чого подаємо системі. Середовище — де саме міряємо, з якою конфігурацією й на яких даних. Критерії приймання — за яким числом ухвалюється вердикт. Ризики — якого сценарію відмови ми боїмося (пік, витік памʼяті під довгим навантаженням, деградація під стресом), бо саме він диктує вид тесту. Сильний кандидат назве середовище й профіль окремими рішеннями, а не сховає їх під словом «сценарії»: помилка в будь-якому з них псує всі числа, і жодна кількість віртуальних користувачів цього не виправить.

Хто задає цілі перф-тесту і які цілі бувають?

Цілі приходять від стейкхолдерів, а не вигадуються тестувальником: замовник визначає, що вважати досягненням, у якій термінології про це говорити і за яким критерієм закривати роботу. Цілі корисно розводити на дві групи. Користувацькі — про задоволеність людини й бізнес-результат: чи не втрачаємо конверсію, чи не чекає користувач на оформленні. Технічні — про експлуатацію: як система масштабується, за яких умов починає деградувати, скільки лишається запасу по ресурсах. Розмову зі стейкхолдером зазвичай відкривають трьома питаннями: які операції граємо в тесті і який час відповіді для них очікується; які системні метрики знімаємо і які значення для них нормальні; наскільки краще має бути порівняно з попереднім циклом. Якщо на ці три питання ніхто в команді відповісти не може — це і є перша знахідка прогону, ще до прогону.

Чому «зберемо всі метрики, а потім розберемось» — погана стратегія?

Кожна метрика — це не безкоштовний рядок у звіті, а зобовʼязання: її треба стабільно збирати, зберігати й пояснювати з прогону в прогін. Надлишковий набір дає два побічні ефекти одразу: аналіз тоне в шумі, бо на сотні графіків завжди знайдеться щось червоне, і сам збір починає впливати на продуктивність застосунку, який ми міряємо. Тому завдання — не «максимум», а досяжний мінімум, який реально підпирає цілі тесту. Канон називає приклад підходу — GQM (Goal-Question-Metric): спочатку формулюємо ціль, потім питання, відповідь на яке доведе її досягнення, і лише під це питання добираємо метрику. Межу методу канон називає одразу: GQM пасує процесу перф-тестування не завжди, бо частина метрик описує здоровʼя системи й прямо з цілями не повʼязана.

На чому стоять критерії приймання перф-тесту?

Критерій приймання (acceptance criteria) не вигадується під час прогону — він спирається на три речі одночасно: загальні цілі цього тесту, зафіксовані угоди про рівень сервісу (SLA) і базові значення попередніх вимірів. Без третьої ноги критерій легко стає або недосяжним, або нікчемно мʼяким, бо ніхто не знає, від чого відштовхуватися. Машинної форми критерій набуває в порозі (threshold): це записана умова на агрегат — скажімо, «90-й перцентиль оформлення менший за 2 с» або «частка помилок нижча за 0,5%», — яку інструмент наприкінці прогону зводить до true чи false. Саме поріг перетворює число на вердикт: не виконалася умова — прогін вважається провальним і повертає ненульовий код виходу, тобто зупиняє пайплайн без участі людини. Формулювати критерій варто в тій самій формі, у якій потім писатимете результат: «95% операцій оформлення швидші за 2 с» перевіряється й доповідається однаково.

Що таке базовий вимір і звідки він береться?

Базовий вимір (performance baseline) — зафіксований набір метрик, з яким порівнюють наступні прогони, щоб показати конкретне поліпшення або довести, що критерії приймання виконані. Головна деталь, яку регулярно пропускають: це не «зняти дашборд із проду». Baseline часто доводиться створювати спеціально — на підготовленому стенді, з керованим набором даних, за потреби знеособлених із бази. Причина проста: цінність базового виміру не в тому, що він «справжній», а в тому, що його можна повторити. Знімок із проду повторити не можна, бо там щодня інший трафік, інші дані й інший склад релізів. Без такої точки відліку фраза «стало гірше» не має доказу, і суперечка з розробкою зводиться до вражень.

Чим чек відрізняється від порога і звідки беруться «вічнозелені» прогони?

Чек (check) — це перевірка окремої відповіді: статус той, тіло не порожнє, поле на місці. Поріг — це умова на агрегат за весь прогін, і тільки він виносить вердикт. Пастка в тому, що невдалі чеки самі по собі прогін не валять: вони лише накопичують частку невдач у звіті, а тест завершується успішно. Так зʼявляється «вічнозелений» прогін: у логах є 12% помилок і p95 удвічі гірший за минулий тиждень, а пайплайн зелений, бо на ці метрики ніхто не поставив поріг. Практичне правило: якщо метрика важлива настільки, що ви подивитеся на неї в звіті, під неї має бути поріг; якщо порога немає — це графік для аналізу, а не гейт. І перевіряти це варто навмисно: зламайте умову свідомо й переконайтеся, що прогін справді почервонів.

Як будують операційний профіль і з ким його узгоджують?

Операційний профіль (operational profile) — це фактичний або передбачений патерн використання системи, і збирається він із даних, а не з уяви команди. Джерел зазвичай три: розмови чи воркшопи зі стейкхолдерами, дані про використання схожих продуктів і спостереження за тим, як люди реально виконують конкретні задачі. На практиці до цього додається четверте, найдешевше — власні аналітика й моніторинг: типові патерни трафіку вже лежать у ваших дашбордах. Будувати профіль варто згори вниз: спершу грубий і широкий, деталізувати лише там, де від деталі залежить висновок. І головне правило безпеки — узгодити профіль із ключовими стейкхолдерами до того, як із нього зроблять профіль навантаження: це єдиний дешевий момент, коли можна почути «а ви не врахували нічну вивантажку», і не отримати наприкінці спринта висновок «ми міряли не те». Окремо варто памʼятати, що навантаження не завжди створює людина: пакетні обробки й інтеграції теж мають свій профіль.

Що таке достовірність перф-середовища і що робити, коли стенд не дотягує до проду?

Достовірність середовища (test environment fidelity) — це міра того, наскільки стенд відтворює прод. Вимога тут має дві половини, і друга важливіша за першу: наблизити середовище до продакшену настільки, наскільки дозволяють гроші й час, а якщо цього замало — чітко описати, чим саме воно відрізняється і як ви переноситимете результати на прод. Тобто «prod-like» — це назване й кероване розходження, а не рівність. Найбільше на результат впливають дані, конфігурація заліза й ПЗ та конфігурація мережі, причому дані стоять першими: обсяг і структура таблиць можуть змінити картину сильніше, ніж кількість ядер, і передбачити цей вплив до прогону майже неможливо. До основного прогону стенд варто прогнати контрольованим набором тестів і переконатися, що і сам він, і моніторинг поводяться як задумано, — інакше ви ризикуєте описати проблеми середовища як проблеми продукту. І чесна межа: прод не відтворюється в принципі, бо він не герметичний — темп деплоїв постійно вносить у нього живі зміни, тож саме продове середовище не є представницьким навіть для якоїсь однієї версії бінарника.

Стенд удвічі слабший за прод. Можна помножити результат на два?

Ні, і це не «консервативна оцінка», а помилка методу. Продуктивність — нелінійна функція середовища: подвоєння ресурсів не подвоює пропускну здатність, бо в системі є спільні точки (база, черга, пул зʼєднань, блокування), які масштабуються інакше або не масштабуються взагалі. Часто буває навпаки: слабший стенд ловить обмеження, якого на проді немає, або, навпаки, ховає ефект, що виникає лише на великому обсязі даних. Чим далі стенд від продакшену, тим менш надійним стає будь-який прогноз — саме тому вимога до достовірності середовища й формулюється так жорстко. Що можна зробити чесно: назвати різницю явно, показати результат як діапазон із припущеннями і додати у звіт окремим рядком, який висновок ця різниця робить непідтвердженим.

Що таке відтворюваність прогону і що її найчастіше ламає?

Відтворюваність означає, що повтор того самого сценарію на незміненій системі дає статистично однакові результати в межах домовленого допуску. Без цієї властивості весь ітеративний цикл розвалюється: ви не можете сказати, чи змінилася метрика від вашої оптимізації, чи від умов прогону. Ламають її зазвичай не екзотичні речі, а побутові. Перше — дані: якщо сценарій створює або змінює записи, наступний прогін стартує з іншої точки, тож стан треба відкочувати між циклами. Друге — сусіди по стенду: чужий прогін, бекап або нічний ETL на тій самій інфраструктурі. Третє — сам генератор: якщо він уперся в свої ресурси, ви міряєте його, а не систему. Четверте — час: доба, день тижня й фонові процеси самі по собі рухають метрики. Практичний висновок — розкид лікують повторенням прогону, а не розширенням порога: ширший поріг просто перестає ловити регресію.

Навіщо смоук-тест перед довгим прогоном?

Смоук-тест тут — це коротке навантаження на кілька хвилин з мінімальною кількістю користувачів, і його мета не в метриках, а в тому, щоб не витратити три години даремно. Він відповідає на два питання: чи скрипт узагалі робить те, що задумано (правильні ендпоінти, валідна авторизація, коректна параметризація), і чи система нормально почувається під невеликим навантаженням. Ціна помилки без нього велика й тиха: довгий прогін відпрацює, а потім виявиться, що половина запитів усі три години поверталася з 401, і всі красиві перцентилі — це перцентиль помилки. Ще один побічний ефект: смоук дає першу грубу оцінку часу відповіді без конкуренції, з якою потім зручно порівнювати результат під навантаженням.

p90 виріс на 18% проти прогону минулого тижня. Це регресія?

Поки що це різниця, а не регресія — доказу тут ще немає. Час сам по собі є одним із найбільших джерел варіації метрик: прогін у вівторок і прогін у суботу відрізняються фоновим трафіком, наповненістю бази, розкладом бекапів і складом даних. Тому порівняння «до й після» через тиждень тягне за собою великий обсяг шуму, і 18% цілком можуть бути ним. Що перетворює різницю на висновок: повторити обидва прогони й подивитися на розкид, а не на одну пару чисел; звірити ресурси генератора й стенду; перевірити, чи однаковий був набір даних і чи не змінилося середовище. Корисно також не змішувати три задачі, які регулярно злипаються в одну: тримати ліміт проти зафіксованої точки відліку, стежити за напрямком руху метрики протягом кварталу і вирішувати долю конкретного білда. Плутанина між ними призводить до того, що на тренд ставлять поріг, а на гейт дивляться очима.

Прогін показав деградацію на 40%. Що перевіряєте першим?

Перш ніж заводити дефект, треба виключити найдешевшу й найпоширенішу причину — сам вимірювальний контур. Найчастіший винуватець тут генератор навантаження: якщо він упирається в 100% процесора, прогін зазнає тротлінгу, і в звіті зʼявляється час відповіді, значно більший за реальний. Тому машини генерації навантаження моніторять так само уважно, як і систему під тестом — це вимога, а не гарний тон. Далі за списком: мережа між генератором і стендом, стан даних (можливо, попередній прогін залишив по собі мільйон рядків), сусідні активності на стенді, зміна конфігурації середовища. І тільки коли контур чистий і деградація відтворюється, вона стає знахідкою про продукт. Окремо вартий уваги дзеркальний випадок: середній час раптом покращився, бо частина запитів почала швидко відвалюватися з помилкою — це не поліпшення, а симптом перевантаження, і бекенд цілком може задихатися, витрачаючи процесор просто на відмови.

Чим тестування ємності відрізняється від тестування масштабованості?

Тестування ємності (capacity testing) відповідає на питання, скільки користувачів або транзакцій система витримує, продовжуючи виконувати заявлені цілі продуктивності. Друга половина означення важливіша за першу: максимум, при якому система ще вкладається в цільовий час відповіді, і максимум, при якому вона просто не падає, — це два різні числа, і ємністю називають перше. Тестування масштабованості (scalability testing) дивиться вперед: чи здатна система рости під майбутні вимоги, не порушуючи поточних і не відмовляючи. Тобто ємність — про «зараз і на цьому залізі», масштабованість — про «потім і, ймовірно, на іншому». Практична цінність другого не в оцінці «пройдено/провалено», а в експлуатаційному артефакті: коли межі відомі, з них роблять порогові значення для моніторингу проду й попереджають про проблему до того, як вона стане інцидентом.

«Скільки користувачів витримує наша система?» — як відповідати на це питання?

Це питання-пастка, і сильна відповідь починається зі зустрічного питання, а не з числа. Перше уточнення — при якій цілі: «витримує» означає «не падає» чи «тримає час відповіді в межах домовленого»? Друге — які саме користувачі: важкі звіти й прості читання створюють різне навантаження, тож без складу сценарію число не існує. Третє — де саме: результат зі стенда переносити на прод можна лише з названими припущеннями. Готова коректна форма відповіді виглядає приблизно так: на такому середовищі з таким міксом операцій система тримає N одночасних користувачів при p90 меншому за 2 с і частці помилок нижче 0,5%, а далі починається деградація ось за такою ознакою. Ця форма одразу придатна і для звіту, і для порога в CI.

Чому «тримаємо 5000 запитів за секунду» — ненадійна характеристика ємності?

Бо запити нерівні між собою. Різні операції споживають кардинально різні ресурси, а вартість однієї й тієї ж операції може змінюватися від чинників, які ви не контролюєте: нова версія клієнта почала тягнути більше даних, змінився час доби, поповз розмір таблиці. Тому число «запитів за секунду» описує рухому ціль, а рухома ціль — погана метрика: збережеться цифра, зміниться мікс — і система ляже на тому ж таки RPS. Надійніше міряти ємність прямо в доступних ресурсах системи, бо саме вони закінчуються насправді. Практичний наслідок для звіту: якщо ви все ж пишете RPS, поруч обовʼязково має стояти склад навантаження й ціль, при дотриманні якої це число отримане, — інакше воно не переноситься ні на інший мікс, ні на наступний квартал.

Що таке точка перегину і чому у звіті її подають разом із критерієм?

Точкою перегину (knee point) називають місце, де крива навантаження ламається: пропускна здатність перестає рости, а час відповіді починає стрімко зростати. Проблема в тому, що поняття прийшло з математики, і для кривої навантаження усталеного означення в нього немає, а критикують його щонайменше з 1940-х за конкретну ваду: положення перегину залежить від обраних масштабів осей. Розтягнули шкалу — і «перегин» переїхав, хоча дані ті самі. Тому в звіті точку називають разом із критерієм, за яким вона визначена: наприклад, «навантаження, після якого p90 перевищує 2 с» або «точка, де приріст навантаження на 10% не додає пропускної здатності». Тоді число можна перевірити й відтворити, а не лише подивитися на нього. Окреме питання — що система робить за цією точкою: керована деградація (graceful degradation) означає віддавати спрощені або менш точні відповіді, які дешевші в обчисленні, і переходити на помилки лише при екстремальному перевантаженні.

Як розподілити результати одного прогону між адресатами?

Одні й ті самі дані розкладаються на три адреси, і плутати їх — найшвидший спосіб зробити звіт, який ніхто не прочитає. Час відповіді — це турбота користувача, тож він іде в розмову про продукт і досвід. Пропускна здатність — турбота бізнесу: скільки замовлень за годину система здатна обробити в пік. Утилізація й насичення ресурсів — турбота інженерів: де закінчиться запас і що доведеться масштабувати. Вимога до звіту при цьому одна для всіх: результат має бути зрозумілим і легко зіставним з очікуваннями, які стейкхолдери озвучили на старті, — тому корисно писати його в тій самій формі, у якій формулювалися цілі. З інженерами додатково допомагає ціль рівня сервісу (service level objective, SLO), оприлюднена для всіх: спільне очікування помітно зменшує кількість безпідставних скарг на кшталт «сервіс якийсь повільний», бо без явно названої цілі кожен виробляє власне уявлення про норму. А бюджет помилок (error budget) робить розмову з розробкою відтворюваною: замість суперечки «швидше постачати проти надійніше працювати» зʼявляється число, з яким обидві сторони погодилися заздалегідь.

Як сформулювати залишковий ризик і коли зупинятись?

Фраза «клієнти іноді ще можуть довго чекати на оформленні» не є результатом: вона не показує ні того, наскільки ризик знизився, ні того, скільки його лишилося. Замість неї потрібна частка користувачів і поріг: «приблизно 3% операцій оформлення довші за 4 с проти 11% до оптимізації». Це та сама форма, у якій ставилася ціль, тому бізнес може ухвалити рішення, а не перепитувати. Звідси й вимога до чисел у звіті: середнє ховає довгий хвіст — більшість запитів може бути швидкою, а найгірші в рази повільнішими, — тож поруч мають стояти щонайменше медіана й високий перцентиль. Тепер про зупинку. Нуль ризику недосяжний у принципі, тому ціль — не «жодних проблем на проді», а названий залишковий рівень, з яким власник продукту згоден жити. Економіка це підтверджує: 100% майже ніколи не є правильною ціллю, бо вартість наступного кроку зростає нелінійно, а користувач із власним не дуже надійним телефоном і мережею просто не помітить різниці між дуже високими рівнями. Готовий механізм зупинки дає бюджет помилок: доки він не вичерпаний — релізи їдуть, вичерпався — релізи тимчасово ставлять на паузу й вкладаються в стійкість. І дві поради з боку самих цілей: краще почати з мʼякшої цілі й затягувати її поступово, ніж узяти надто сувору й потім публічно послаблювати; а самих цілей має бути якнайменше. Найгірший критерій зупинки — «спринт закінчився»: із нього не видно ні досягнутого рівня, ні обсягу неперевіреного.

Три кейси, які проходять маршрут цілком: перетворення розмитої заявки «подивись, чи витримаємо» на шість рішень із числами, налаштування гейта в прогоні так, щоб зелений результат щось означав, і складання звіту, який читають дві різні аудиторії й після якого можна зупинитися. Скрізь — що дивитися і чому.

Кейс 1. «Подивись, чи витримаємо Чорну пʼятницю» — розкладка заявки на шість рішень

Заявка приходить одним реченням і в такому вигляді не тестується: у ній немає ні цілі, ні складу навантаження, ні критерію успіху. Перш ніж відкривати інструмент, її треба розкласти на шість відповідей — і кожна здобувається питанням до конкретної людини, а не здогадом.

Що дивитися і чому:

• Стовпчик «погана відповідь» — це не карикатура, а типовий стан плану. Кожен його рядок проходить рецензію, поки план читають як документ, і жоден не проходить першу ж суперечку про результат: «не гальмує» неможливо ні провалити, ні підтвердити.
• Профіль узгоджують до того, як він стане скриптом. Саме на цьому кроці аналітик каже «а нічна вивантажка в маркетплейс іде о 2:00 і теж тисне на ту саму базу» — і це дешево. Почути те саме після трьох днів прогонів означає викинути результати: ми міряли не те навантаження.
• Різниця стенда з продом іде в план, а не в примітку. Її не треба соромитись — її треба назвати, бо саме вона визначає, які висновки ми маємо право переносити на прод. Формулювання «половина реплік, 30% даних» чесніше й корисніше за «prod-like».
• Метрики поза scope не збираємо навмисно. Спокуса «увімкнемо все, потім розберемось» коштує двічі: аналіз тоне в шумі, а сам збір псує ті самі цифри, заради яких затівався прогін.

Кейс 2. Гейт у прогоні: чому чек не валить тест, а поріг валить

Найтихіша поломка перф-тестування в CI — прогін, який завжди зелений. Причина зазвичай не в тому, що система ідеальна, а в тому, що на метрику не поставлено жодного порога: чеки рахують невдачі, але вердикту не виносять. Ось конфігурація, у якій гейт справді існує.

import http from 'k6/http';
import { check } from 'k6';

export const options = {
  vus: 50,
  duration: '10m',
  thresholds: {
    // кожен рядок нижче — гейт: провал будь-якого валить весь прогін
    http_req_failed: ['rate<0.005'],
    'http_req_duration{name:checkout}': ['p(90)<2000'],
    // ось це перетворює чеки з лічильника на гейт
    checks: ['rate>0.99'],
  },
};

const payload = JSON.stringify({ cartId: 'c-42', paymentMethod: 'card' });

export default function () {
  const res = http.post('https://shop.example.com/api/checkout', payload, {
    headers: { 'Content-Type': 'application/json' },
    tags: { name: 'checkout' },
  });

  // сам по собі check лише веде облік частки невдач
  check(res, {
    'створено замовлення': (r) => r.status === 201,
    'у відповіді є номер замовлення': (r) => r.json('orderId') !== undefined,
  });
}

Схематично підсумок прогону виглядає так — і саме рядок з позначкою провалу дає ненульовий код виходу, на який реагує пайплайн:

checks ............................  98.20%   (поріг rate>0.99 — ПРОВАЛЕНО)
http_req_failed ...................   0.31%   (поріг rate<0.005 — ok)
http_req_duration{name:checkout} ..  p(90)=1.84s  (поріг p(90)<2000 — ok)

Що дивитися і чому:

• Без рядка checks у порогах цей прогін був би зелений. 1,8% невдалих оформлень нікуди б не поділися: вони так само лежали б у звіті, але код виходу був би нульовий, і білд поїхав би далі. Правило просте: якщо на метрику ви подивитеся у звіті, під неї має бути поріг; якщо порога немає — це матеріал для аналізу, а не гейт.
• Поріг ставлять на транзакцію, а не на весь трафік. Загальний p(90) по всіх запитах розмивається легкими викликами каталогу, і повільне оформлення в ньому просто тоне. Тег на запиті (name: checkout) дає окрему метрику, до якої й привʼязується критерій приймання.
• Гейт перевіряють навмисним зламом. Один раз затягніть поріг до свідомо недосяжного значення й переконайтеся, що прогін почервонів, а пайплайн зупинився. Поріг, який жодного разу не спрацював, і поріг, який не працює, зовні виглядають однаково.
• Перед довгим прогоном — коротка розминка. Дві хвилини з кількома користувачами показують, що скрипт узагалі робить те, що задумано. Без цього легко відпрацювати три години й виявити, що всі запити повертали 401, а красиві перцентилі — це перцентиль сторінки помилки.
• Числа порога беруться з домовленості, а не зі стелі. p(90)<2000 тут не тому, що дві секунди звучать добре, а тому, що так сформульована ціль у першому кейсі — критерій приймання, поріг і рядок у звіті мають бути одним і тим самим твердженням.

Кейс 3. Один прогін — два звіти, і рішення зупинитися

Прогін завершився, цифри є. Далі починається частина, на якій перф-активності провалюються найчастіше: результат треба розповісти двом аудиторіям, які питають про різне, і назвати умову, за якої роботу можна закривати.

Сирі дані одного прогону:

Старт: 2026-05-19 21:00, тривалість 45 хв
Профіль: пік 3× (2400 одночасних користувачів), мікс каталог/картка/кошик/оформлення
Оформлення: median 640 ms, p90 1.84 s, p95 3.10 s
Пропускна здатність: 118 замовлень/хв
Помилки: 0.31%
CPU застосунку 74%, пул зʼєднань до БД 92% у піку

Одні й ті самі числа розкладаються за адресатами:

Що дивитися і чому:

• Залишковий ризик пишеться числом і в тій самій формі, що й ціль. Фраза «клієнти іноді ще можуть почекати на оформленні» не є результатом: вона не показує ні того, наскільки ризик знизився, ні того, скільки його лишилося. «Приблизно 10% довші за 1,84 с проти 27% раніше» — уже підстава для рішення.
• Середнє в цей звіт не потрапляє взагалі. Воно ховає довгий хвіст: більшість запитів швидкі, найгірші — у рази повільніші, і саме вони формують враження про продукт. Мінімальний чесний набір — медіана плюс високий перцентиль.
• Знімок базового тесту фіксують повністю. Коли прогін стартував, на скільки одночасних користувачів цілились, яку пропускну здатність виміряли і що показали ключові знахідки — частка помилок, час відповіді, середня пропускна здатність. Без цього блоку наступний прогін нема з чим порівнювати, і за місяць ніхто не згадає, за яких умов отримано «118 за хвилину».
• Цифра пропускної здатності не переноситься без складу навантаження. «118 замовлень за хвилину» справедливе для цього міксу й цього стенда; зміниться частка важких операцій — зміниться й число, тому мікс стоїть у звіті поруч, а не в додатку.
• Умова зупинки називається явно. Тут вона виглядає так: ціль по p90 виконано, залишковий ризик описано числом, з яким власник продукту згоден жити, а наступна гіпотеза (шардування пулу зʼєднань) — це вже зміна архітектури, тобто задача планування, а не ще один прогін. Порівняйте з формулюванням «більше не встигаємо, спринт закінчився»: із нього не видно ні того, якого рівня ми дійшли, ні того, який обсяг лишився неперевіреним.
• Прогін не закриває ризик до нуля — і не має. Ціль полягає в названому залишковому рівні, а не у відсутності проблем на проді: вартість кожного наступного кроку зростає нелінійно, і в певний момент поліпшення просто перестає бути помітним для користувача.

План до першого прогону

• Можу назвати шість рішень, які мають існувати до відкриття інструмента: цілі, scope (транзакції й метрики), профіль навантаження, середовище, критерії приймання, ризики.
• Знаю, що цілі, термінологію й межу успіху задають стейкхолдери, розводжу цілі користувацькі (задоволеність, бізнес-результат) і технічні (масштабованість, умови деградації), і вмію відкрити розмову трьома питаннями: які операції граємо і з яким очікуваним часом відповіді, які системні метрики знімаємо і з якими значеннями, наскільки краще має бути проти попереднього циклу.
• Розумію, чому набір метрик роблять досяжним мінімумом, а не максимумом (аналіз тоне в шумі, а сам збір псує продуктивність застосунку), і знаю метод добору GQM (Goal-Question-Metric).

Критерії приймання, чеки й пороги

• Памʼятаю три опори критерію приймання (acceptance criteria): цілі цього прогону, угоди про рівень сервісу (SLA) і базові значення попередніх вимірів.
• Можу пояснити поріг (threshold) як записану умову на агрегат, яку інструмент наприкінці прогону зводить до true чи false, а при невиконанні повертає ненульовий код виходу.
• Знаю різницю між чеком (check) і порогом та природу «вічнозеленого» прогону: метрика червона, пайплайн зелений, бо порога під неї ніхто не поставив.

Профіль і середовище

• Знаю, що операційний профіль (operational profile) будують із даних — розмов зі стейкхолдерами, поведінки схожих продуктів, спостережень за задачами, власних аналітики й моніторингу, — будують згори вниз і рецензують до того, як зроблять із нього профіль навантаження; і що пакетні обробки теж мають свій профіль.
• Можу пояснити достовірність перф-середовища (test environment fidelity) обома половинами, знаю, що серед чинників дані стоять першими, і що стенд валідують контрольованим набором тестів до основного прогону.
• Розумію, чому прод не відтворюється в принципі (він не герметичний через темп деплоїв), тож «prod-like» — це назване розходження, а не рівність, і чому лінійна екстраполяція зі слабшого стенда заборонена: продуктивність нелінійно залежить від середовища.

Цикл і відтворюваність

• Розумію перф-тестування як контур «базовий вимір → прогін → аналіз → оптимізація → повтор», а не як разовий захід перед релізом, і памʼятаю про смоук-тест перед довгим прогоном.
• Знаю, що базовий вимір (performance baseline) часто доводиться створювати спеціально, на керованих і за потреби знеособлених даних, бо його цінність у відтворюваності, а не в «справжності».
• Можу сформулювати вимогу відтворюваності й назвати, що її ламає: незвернені після прогону дані, сторонні активності на стенді та генератор, який зʼїв увесь процесор і через тротлінг завищує час відповіді.
• Розумію, чому час — одне з найбільших джерел варіації метрик, чому розкид лікують повторенням прогону, а не ширшим порогом, і не плутаю три задачі регулярних прогонів: звірку з базовим виміром, спостереження за трендом і перевірку конкретного релізу на регресію.

Ємність і масштабованість

• Знаю означення тестування ємності (capacity testing) з обома половинами й відрізняю його від тестування масштабованості (scalability testing): ємність — про поточну межу, масштабованість — про здатність рости під майбутні вимоги; знайдені межі потім стають порогами моніторингу на проді.
• Розумію, чому «тримаємо N запитів за секунду» — слабка метрика (вартість запиту різна й рухома) і чому ємність надійніше міряти прямо в доступних ресурсах.
• Знаю проблему точки перегину (knee point) — її положення залежить від масштабів осей, тож у звіті вона йде разом із критерієм визначення, — і можу пояснити керовану деградацію (graceful degradation).

Звіт, комунікація і зупинка

• Памʼятаю розкладку метрик за адресатами (час відповіді — користувачеві, пропускна здатність — бізнесу, утилізація — інженерам) і розумію, чому середнє не можна лишати єдиним числом: воно ховає довгий хвіст, тож поруч потрібні щонайменше медіана й високий перцентиль.
• Умію переписати залишковий ризик із фрази в число («X% користувачів повільніше за Y») і можу назвати склад «знімка» базового тесту у звіті: коли прогін стартував, на скільки одночасних користувачів цілились, яку пропускну здатність виміряли, яка вийшла частка помилок і час відповіді.
• Можу пояснити, що дає команді оприлюднена ціль рівня сервісу (service level objective, SLO) і чому бюджет помилок (error budget) знімає протистояння «швидкість постачання проти надійності».
• Знаю зрілі критерії зупинки — названий залишковий рівень ризику або невичерпаний бюджет помилок — і розумію, чому нуль ризику й 100% надійності не є правильними цілями, а «спринт закінчився» не є критерієм узагалі.