Вимоги до продуктивності: NFR, SLA, SLO, SLI

Що таке вимога до продуктивності і чому «має працювати швидко» нею не є?

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

Які три підхарактеристики має продуктивність і навіщо їх розводити?

Продуктивність (performance efficiency) у моделі якості ISO 25010 — не синонім швидкості, а парасолька над трьома різними обіцянками. Часова поведінка (time behavior) — вкластися в заданий час відповіді за заданих умов; це найпоширеніша ціль перф-тесту. Утилізація ресурсів (resource utilization) — скільки процесора, памʼяті, зʼєднань система на це витрачає; її досліджують, коли доступність ресурсів визнали ризиком. Ємність (capacity) — до яких меж за користувачами або обсягами даних система взагалі лишається робочою. Розводити їх треба тому, що вимога, написана тільки про час, дві інші не закриває: сервіс, який тримає 200 мс на майже вичерпаному процесорі, за такою вимогою вважається справним — хоча витримати навіть невеликий приріст трафіку йому вже нічим. І окремо варто памʼятати, що ємність та здатність масштабуватися (scalability) — різні поняття: перше про сьогоднішню межу, друге про можливість цю межу підняти.

Чим відрізняються SLI, SLO і SLA?

Це три різні артефакти, які плутають, бо всі три звучать як «доступність 99,9%». SLI (service level indicator) — індикатор рівня сервісу, тобто ретельно означена кількісна міра одного аспекту сервісу; фізично це метрика, наприклад затримка запиту. SLO (service level objective) — ціль рівня сервісу, тобто конкретне значення або діапазон на цьому індикаторі; фізично це число на метриці. SLA (service level agreement) — угода з користувачами, яка додає до цілей наслідки їх виконання чи невиконання; фізично це контракт. Природна форма запису цілі — SLI ≤ ціль або двостороння нижня межа ≤ SLI ≤ верхня межа. Для тестувальника ця ієрархія має пряме застосування: SLA — джерело чисел для критеріїв приймання, а дотримання SLA (або частота порушень) саме по собі стає метрикою прогону.

Як одним питанням відрізнити SLO від SLA?

Питання звучить так: «а що станеться, якщо ціль не виконано?» Якщо на боці постачальника нічого не станеться — це SLO, хоч би скільки разів документ називався угодою. Якщо є заздалегідь описаний наслідок — знижка або штраф — це вже SLA. Фінансові наслідки впізнати найлегше, але вони не єдині: у Google Search публічної SLA немає взагалі («ми не підписували контракт із усім світом»), а наслідки недоступності цілком матеріальні — репутація й рекламні гроші. У побуті команд слово «SLA» вживають майже завжди неправильно, тому на співбесіді очікують саме цього критерію розрізнення, а не переказу абревіатур.

Які метрики зазвичай стають SLI і скільки їх брати?

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

Замовник каже «має працювати швидко». Ваші наступні кроки?

Спершу зʼясувати, про що саме йдеться: яка транзакція, а не який ендпоінт — «оформити замовлення» і «POST /orders» це різні речі. Далі поставити шість питань, які перетворюють фразу на поле анкети: що міряємо, яким зрізом розподілу, з яким граничним значенням, за якого навантаження, у якій точці виміру й з яким вікном агрегації. Відповіді складаються у твердження, яке читається вголос без другого тлумачення: 95 оформлень зі 100 укладаються в 500 мс на профілі пікового вечора, час знімається на бекенді, число рахується за хвилинним вікном. Слабка відповідь на співбесіді зупиняється на «попрошу конкретне число» — бо число без умов чинності ту саму суперечку відтворює, лише на пізнішій стадії. Корисно памʼятати й про порядок: критерії продуктивності мають потрапити до критеріїв приймання на старті проєкту, а не за тиждень до релізу.

Чому вимогу пишуть на перцентиль, а не на середнє?

Тому що середнє змішує в одне число дві різні сукупності — швидку більшість і повільний хвіст — і показує щось середнє між ними, чого не переживає жоден реальний користувач. Перцентиль натомість фіксує ранг спостереження: 95-й перцентиль — значення, нижче якого лежать 95% вимірів, медіана — те саме для половини. Тому вимога, записана на середнє, спокійно пропускає прогін, де кожен двадцятий користувач чекає секунди. Якщо для продукту важлива форма кривої, а не одна точка, канон радить писати кілька цілей одразу — скажімо, 90% швидше за 1 мс, 99% швидше за 10 мс, 99,9% швидше за 100 мс. А для різних класів навантаження цілі просто різні: інтерактивному клієнту важлива затримка, пакетній обробці — пропускна здатність.

Вимога звучить «p(95)<500 мс». Чого їй бракує, щоб стати перевірною?

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

Що таке транзакція як одиниця виміру часу відповіді?

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

Вимог до продуктивності немає взагалі. Звідки їх узяти?

Числа задають стейкхолдери — вони ж визначають термінологію і те, за яким критерієм ціль вважається досягнутою; завдання QA — цей процес організувати, а не вигадати числа за них. Корисно одразу розділяти цілі користувацькі (задоволеність, бізнес-показники) і технічні (де починається деградація, як система масштабується): вони перевіряються по-різному. Рухатися варто від того, що важливо користувачам, назад до індикаторів, а не від переліку метрик, які вміє віддавати моніторинг. Робочий каркас — GQM: спершу цілі, потім питання, відповіді на які покажуть, що цілей досягнуто, і лише потім метрики; межу методу канон називає сам — не кожна метрика виводиться з цілі, деякі показують стан системи й до цілей не привʼязані. Окрема заборона, про яку часто забувають: не виводьте ціль із поточної продуктивності — узявши сьогоднішні 300 мс без рефлексії, ви законсервуєте систему, яку вже зараз тримають героїчними зусиллями. Планку задають не конкуренти, а найкращі сервіси, якими користувач користується щодня.

Що таке профіль навантаження і чому він частина вимоги, а не її контекст?

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

Як коректно сформулювати вимогу до ємності?

Вимога до ємності відповідає на питання «скільки користувачів або транзакцій ми тримаємо», але сама по собі ця цифра не визначена, поки до неї не додано обмовку «і при цьому все ще виконуємо заявлені цілі продуктивності». Різниця не косметична: межа, за якою процес просто не падає, і межа, за якою він ще вкладається в обіцяні півсекунди, — це два різні числа, і зазвичай друге істотно менше. Тому формулювання виглядає так: «система обслуговує 5 000 одночасних користувачів профілю checkout-peak, утримуючи p(95) транзакції оформлення нижче 500 мс і частку помилок нижче 1%». Саме така форма робить ємність вимірюваною й перевірною, а не риторичною. Побічно вона ж закриває типову підміну на демонстраціях, коли «ми витримали 10 тисяч» означає лише «процес не впав».

Що таке поріг (threshold) і чому поріг — це не SLO?

Поріг — це умова над метрикою прогону, яку ранер обчислює в true або false і на основі якої оголошує тест пройденим чи проваленим. Форма проста: спосіб агрегації, оператор, значення — avg < 200, count >= 500, p(90) < 300; доступні агрегації залежать від типу метрики (для Trend це avg, min, max, med і p(N), для Rate — rate). Вердикт віддається кодом виходу: усі пороги виконано — нуль, провалено хоч один — ненульовий, а за потреби прогін можна ще й обірвати на першому провалі. Призначення порогу — кодифікувати SLO мовою, яку розуміє інструмент, тобто це зліпок цілі на час тесту. Але тотожності немає: SLO живе на проді й міряється тижнями чи місяцями на реальному трафіку, а поріг рахується за короткою вибіркою на меншому стенді, тому його значення часто беруть суворішим. Плутати їх небезпечно в обидва боки: зелений прогін не доводить виконання SLO, а провалений поріг не означає, що SLO порушено.

Прогін зелений. Чи означає це, що вимогу виконано?

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

Вимога «сторінка відкривається за 2 секунди». Перевіримо навантажувальним прогоном?

Ні — протокольний інструмент виміряє іншу величину. У JMeter це видно вже на трьох окремих лічильниках: Elapsed time доводить відлік до останнього байта відповіді, Latency зупиняється на першому, а Connect Time, у який входить і рукостискання TLS, сам собою з Latency не віднімається. Головне ж інше: такий прогін не виконує клієнтський JavaScript і не враховує час рендерингу, тобто все, що відбувається з моменту, коли байти вже прийшли, а користувач ще дивиться на порожній екран. Тому вимогу «сторінка відкривається за 2 секунди» треба або переписати на серверну метрику з чесною точкою виміру, або міряти клієнтськими інструментами. Відповідь рівня сеньйора додає: розрив між серверним часом і тим, що бачить користувач, — не похибка, а окремий предмет вимірювання, і замовчувати його у звіті означає обіцяти те, чого не перевіряли.

Чи можна жити без абсолютних цілей, звіряючи кожен реліз лише з попереднім?

Так, порівняльна форма — повноцінна третя форма вимоги, і питання «яких поліпшень ви очікуєте проти попередніх циклів» стоїть у каноні серед питань до стейкхолдерів. Точкою відліку працює базовий вимір (performance baseline) — зафіксований набір метрик, з яким порівнюють поточні. Ключова деталь, яку часто проґавлюють: baseline створюють спеціально, за потреби на знеособлених даних, — його не «беруть із проду», і саме тому його можна відтворити. Умова чинності жорстка: звіряти між собою дозволено тільки прогони, у яких не змінилися ні залізо стенда, ні набір даних; переїхали на іншу інфраструктуру — стара точка відліку більше нічого не доводить. І варто розрізняти три різні цілі регулярних прогонів: звірка з базовим виміром, спостереження за трендом у часі й виловлювання регресії конкретного релізу — на pass/fail схоже тільки третє. Перед довгим прогоном варто витратити хвилину на перф-смоук на кількох користувачах, інакше ризикуєте порівняти baseline із результатом зламаного скрипта.

Що таке бюджет помилок і навіщо він тестувальнику?

Бюджет помилок (error budget) — це заздалегідь погоджена міра того, наскільки ненадійним сервісу дозволено бути за період; арифметично він є доповненням цілі до сотні. Механіка складається з чотирьох кроків: продуктовий менеджмент фіксує SLO на квартал, фактичний показник міряє нейтральна сторона — система моніторингу, різниця між ними і є залишок бюджету, і поки залишок додатний, нові релізи викочують. Приклад арифметики: ціль «успішно обслужити 99,999% запитів за квартал» дає бюджет 0,001%, тож інцидент, який зʼїв 0,0002% очікуваних запитів, витратив пʼяту частину квартального бюджету. Сенс механізму — не в обліку, а в тому, що він дає розробці й експлуатації спільний вимірюваний стимул: одні відповідають за темп постачання, інші за надійність, а бюджет робить із цього конфлікту число, про яке можна домовитися. Для QA висновок прямий: коли ціль записана через затримку, повільна відповідь витрачає бюджет нарівні з недоступністю, а вичерпаний бюджет — заздалегідь погоджена підстава пригальмувати релізи, а не привід для чергової дискусії.

Чому ціль «100% успішних запитів» вважають шкідливою?

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

Три поди віддали свої p(95). Чи можна усереднити їх, щоб отримати загальний p(95)?

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

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

Кейс 1. Зі стендапу до перевірної вимоги

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

Результат розмови вкладається в структуру, яку далі читає і людина, і ранер:

type PerformanceRequirement = {
  transaction: string;    // "checkout: від кліку Оплатити до сторінки підтвердження"
  aggregation: string;    // "p(95)"
  operator: '<' | '<=';
  value: number;          // 500
  unit: 'ms' | 'ratio';
  load: string;           // "профіль checkout-peak, 200 запитів/с, будній вечір"
  measuredAt: string;     // "бекенд, час до останнього байта відповіді"
  window: string;         // "усереднення за 1 хвилину"
  errorPolicy: string;    // "часи рахуються лише для успішних транзакцій"
};

Прочитане вголос, це звучить так: 95 оформлень зі 100 укладаються в 500 мс на профілі checkout-peak, час знімається на бекенді, число рахується за хвилинним вікном, а невдалі транзакції у вибірку часу не потрапляють і покриваються окремою ціллю на частку помилок.

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

• Перше питання — про транзакцію, а не про число. Якщо не домовитися, де операція починається й де закінчується, усі наступні числа будуть про різні речі. Класична розбіжність: продакт має на увазі «від кліку до сторінки подяки», а бекенд міряє один POST із середини флоу.
• «Скільки користувачів мають укластися» — це і є вибір зрізу. Формулювання через частку користувачів зрозуміле нетехнічному стейкхолдеру й напряму перекладається в перцентиль, тоді як питання «яке середнє вас влаштує» веде до числа, за яким ховається довгий хвіст.
• Політика щодо відмов не косметична. Невдалі запити часто повертаються швидше за успішні, бо сервер не виконує роботи; змішавши їх у спільну вибірку, ви отримаєте штучно кращий час саме тоді, коли системі погано.
• Не виводьте ціль із поточних показників. Спокуса записати «як зараз, тільки трохи краще» велика, але так ви фіксуєте те, що вже сьогодні тримається на героїзмі. Орієнтир — чого потребує користувач, і планку йому задають найкращі сервіси, якими він користується щодня.
• Ця ж структура закриває питання «чому вимогу не можна взяти з чужого проєкту». Поля load, measuredAt і window унікальні для вашої системи, тож 200 мс із чужої статті — число без умов чинності.

Кейс 2. k6: зелений прогін, який нічого не перевірив

Вимога з кейсу 1 є, сценарій написано, нічний прогін завершився з кодом 0. Але вимогу порушено. Ось конфігурація, яка до цього призвела:

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

export const options = {
  scenarios: {
    peak: {
      executor: 'constant-arrival-rate',
      rate: 200, timeUnit: '1s', duration: '15m',
      preAllocatedVUs: 100, maxVUs: 400,
    },
  },
  thresholds: {
    http_req_duration: ['p(95)<500'],   // ← цей рядок не діє
    http_req_duration: ['p(95)<2000'],  // ← ключ обʼєкта той самий, лишається тільки він
  },
};

export default function () {
  const res = http.post(
    `${__ENV.BASE_URL}/api/checkout`,
    JSON.stringify({ sku: 'A-1', qty: 1 }),
    { headers: { 'Content-Type': 'application/json' } },
  );
  check(res, {
    'status is 200': (r) => r.status === 200,
    'body has orderId': (r) => r.json('orderId') !== undefined,
  });
}

І підсумок, який побачив ранок:

     ✗ status is 200
      ↳  99% — ✓ 179244 / ✗ 756
     ✗ body has orderId
      ↳  91% — ✓ 163872 / ✗ 16128

     checks.........................: 95.31%  ✓ 343116  ✗ 16884
     http_req_duration..............: avg=186ms  med=120ms  p(90)=410ms  p(95)=980ms
     http_req_failed................: 0.42%   ✓ 756     ✗ 179244

   █ THRESHOLDS
     http_req_duration
     ✓ 'p(95)<2000'  p(95)=980ms

running (15m00.0s), 000/400 VUs, 180000 complete iterations
exit status 0

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

• Дубль ключа зʼїв суворий поріг мовчки. Пороги живуть у звичайному JavaScript-обʼєкті, тож два однакові ключі співіснувати не можуть: лишається останній, а перший зникає без попередження. У блоці THRESHOLDS це видно одразу — умова там рівно одна, і не та, яку писали. Кілька умов на одну метрику задають масивом: http_req_duration: ['p(95)<500', 'p(99)<1500'].
• p(95)=980ms проти вимоги 500 мс — прогін мав бути червоним. Замість вердикту ви отримали число у звіті, яке ніхто не звіряв із вимогою руками. Саме тому «зелений прогін» без переліку виконаних порогів нічого не доводить: перше, що варто прочитати у звіті, — не метрики, а список умов, які взагалі перевірялися.
• Провалений чек не завалив тест. Приблизно кожна одинадцята відповідь приходила без orderId — тобто замовлення не створювалося, а сервер чесно віддавав 200. Але невдалий чек лише накопичує свою частку у rate-метриці й на код виходу не впливає; гейтом він стає лише з порогом на цю метрику — checks: ['rate>0.99'].
• http_req_failed 0,42% нічого не спростовує. Ця метрика бачить транспортні збої й помилкові коди, а не змістовну помилку в тілі відповіді з кодом 200. Без чека на тіло прогін виміряв би швидкість, з якою система віддає порожні замовлення.
• Виправлена конфігурація виглядає так — три метрики трьома окремими ключами, а кілька умов на одну метрику стоять масивом:

thresholds: {
  http_req_duration: ['p(95)<500', 'p(99)<1500'],  // часова поведінка
  http_req_failed: ['rate<0.01'],                  // частка відмов, не штуки
  checks: ['rate>0.99'],                           // ось що робить чек гейтом
},

• І остання рамка: цей поріг — не SLO. Він рахувався за пʼятнадцять хвилин на стенді, тоді як ціль на проді міряють кварталом на реальному трафіку. Зелений прогін означає «вимогу не порушено на цій вибірці», а не «SLO виконується».

Кейс 3. Нарада: чи гальмувати реліз через регресію p(95)

Реліз викотили в понеділок. p(95) транзакції оформлення виріс з 380 до 620 мс при цілі 500 мс. Розробка каже «двісті мілісекунд — це дрібниця», підтримка каже «люди скаржаться». Замість вражень на стіл кладуть бюджет.

Спершу — скільки взагалі дозволено, залежно від цілі (квартал = 90 днів; праворуч — той самий бюджет у запитах, якщо їх за квартал 100 мільйонів):

Тепер конкретна арифметика цієї команди. SLO сформульовано через затримку: «99% запитів швидші за 500 мс за квартал», тобто бюджет — це 1% запитів, яким дозволено бути повільними. Трафік — близько 550 тисяч запитів на добу, отже ~49,5 млн за квартал і бюджет приблизно 495 тисяч повільних запитів, або в середньому 5,5 тисячі на добу.

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

• Суперечка «двісті мілісекунд — це багато чи мало» отримала числову відповідь. Не «повільніше», а «квартальний бюджет вигорить за 13 днів замість 90» — це вже підстава для рішення, і саме заради таких розмов бюджет заводять. Зверніть увагу й на нелінійність: зростання p(95) у 1,6 раза дало сімнадцятиразову витрату бюджету, бо за поріг 500 мс переїхала ціла ділянка розподілу.
• Перф-регресія їсть той самий бюджет, що й падіння сервісу. Якщо ціль сформульована через затримку, повільна відповідь для бюджету нічим не краща за помилку — обидві потрапляють у «погані» події. Тому питання «це достатньо повільно, щоб гальмувати реліз» перестає бути питанням смаку.
• Реакція не обовʼязково «відкотити». Легальних ходів кілька: відкотити реліз, залишити його й вкластися в стійкість, або свідомо переглянути ціль, якщо команда постійно не вкладається й це визнано прийнятним. Заборонений лише один варіант — мовчки порушувати чинну ціль.
• Різницю з SLA варто проговорити на тій самій нараді. Якщо в контракті з клієнтом наслідків за час відповіді немає, це внутрішня ціль, і рішення ухвалює продукт. Якщо ж наслідок описано — знижка, компенсація, — розмова переходить у площину грошей, і ціна затримки рахується інакше.
• Джерело чисел має бути нейтральним. Фактичний показник беруть із системи моніторингу проду, а не з результатів прогону на стенді: прогін дає ранній сигнал і pass/fail релізу, витрату бюджету рахують на реальному трафіку.

Що обіцяє вимога до продуктивності

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

Звідки беруться числа

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

SLI, SLO, SLA

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

Анатомія перевірної вимоги

• Можу перелічити шість відповідей, без яких вимога лишається побажанням: яка транзакція, який перцентиль, яке граничне число, під яким навантаженням, у якій точці знімають вимір і за яким вікном усереднюють; і памʼятаю, що транзакція — це закінчена операція користувача, під якою може ховатися десяток HTTP-запитів, а не сам запит.
• Можу пояснити, чому ціль пишуть на перцентиль, а не на середнє, і коли одного зрізу мало: щоб описати форму кривої, задають кілька цілей одразу.
• Розумію, чому «сторінка відкривається за 2 секунди» протокольним прогоном не перевіряється (рендеринг і клієнтський JavaScript у вимір не входять), і не плутаю три лічильники JMeter: Elapsed time доводить відлік до останнього байта, Latency зупиняється на першому, а Connect Time разом із рукостисканням TLS сам собою з Latency не віднімається.

Навантаження і ємність

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

Поріг: pass/fail самого прогону

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

Baseline і бюджет помилок

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