Середовище, генератори навантаження і достовірність

Що таке достовірність тестового середовища (test environment fidelity)?

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

Які частини середовища найважливіші і чому дані стоять першими?

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

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

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

А якщо просто зробити стенд точною копією продакшену?

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

На тестових машинах менше памʼяті, ніж на проді. Що з цим робити?

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

Що ви робите зі стендом до старту прогону?

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

Де має стояти сама машина-генератор?

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

Ви навантажили кластер із шести вузлів, а завантажений виявився один. Що сталося?

Найімовірніше — кеш DNS. JMeter із коробки покладається на DNS-кеш віртуальної машини Java, тому імʼя хоста перетворюється на адресу один раз, і далі всі віртуальні користувачі йдуть туди ж, скільки б вузлів не стояло за балансувальником. Окремий елемент керування цим кешем існує рівно для випадку, коли застосунок розгорнутий на кількох серверах за балансувальниками — включно з CDN. Симптом упізнаваний: у звіті пропускна здатність уперлася в стелю значно раніше за очікування, а моніторинг кластера показує один розжарений вузол і пʼять сплячих. Це не відмова системи й не її межа ємності — це помилка конфігурації прогону, і висновок про ємність кластера з такого прогону робити не можна.

Навіщо потрібна підміна IP-адрес віртуальних користувачів?

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

Які пороги здоровʼя генератора ви тримаєте в голові?

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

Як довести, що вузьким місцем був генератор, а не система?

Трьома незалежними доказами. Перший — ресурси самої машини навантаження за той самий інтервал: якщо процесор стояв під стелею, інструмент зазнавав обмежень тротлінгу (throttling), і метрики результату показують значно більший час відповіді, ніж є насправді, — картина виглядає як деградація сервісу, хоча сервіс ні до чого. Другий — розкладка помилок за походженням: socket: too many open files означає, що на генераторі скінчилися дескриптори файлів і система цих запитів навіть не бачила; read: connection reset by peer — зʼєднання розірвала цільова сторона; context deadline exceeded — запит дійшов, а вчасної відповіді не було. Третій — сам факт того, що машини генерації моніторяться нарівні з системою: канон вимагає цього прямо, щоб не отримати прогін, у якому навантаження просто не трималося через повільний генератор. І ресурсом тут вважається не лише процесор із памʼяттю: дескриптори файлів та межа кількості задач — такі самі ресурси, у яких є своя утилізація й свої характерні помилки.

Чому кажуть, що швидший сервер навантажує генератор сильніше?

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

Інструмент вимірювання сам зʼїдає ресурси. Де це трапляється найчастіше?

Класика — спостерігати за прогоном через графічний інтерфейс. Більшість елементів Listener у JMeter зберігає копію кожного семпла, який показує, тож відкрите дерево результатів під час тесту перетворює прогін на вимір власного інтерфейсу. Канонічні настанови радять протилежне: запуск у режимі командного рядка, мінімум елементів Listener і асертів, CSV замість XML для результатів, дані для рандомізації підготовлені файлом заздалегідь. У k6 те саме приходить з іншого боку: тіло відповіді за замовчуванням потрапляє в памʼять, а кожен унікальний URL створює окремий обʼєкт часового ряду — тому прогін по адресах із випадковими ідентифікаторами роздуває споживання памʼяті без жодної користі для звіту. Спільний висновок: усе, що інструмент робить «для зручності перегляду», оплачується з ресурсів тієї самої машини, чиї межі ви щойно домовилися не переходити.

Один і той самий сценарій на одній і тій самій машині дав інші цифри. Що перевірити першим?

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

Ви ганяєте сценарій, що тягне статику. Що насправді міряє така пропускна здатність?

Частково — edge-вузол CDN (Content Delivery Network), а не вашу систему. CDN — це мережа проміжних серверів ближче до користувачів, яка кешує відповіді й тим самим знімає частину запитів із власних серверів організації; спільні керовані кеші такого типу — reverse proxy, CDN, service worker із Cache API — ставить сама команда сервісу, щоб зняти частину роботи з origin. Для перф-тесту це означає, що частина вашого трафіку до системи просто не доїжджає, а числа пропускної здатності описують чужу інфраструктуру. Окрема деталь: спільним кешам термін свіжості задають директивою s-maxage, тож поведінка edge-вузла може відрізнятися від того, що бачить браузер. Практичне правило перед прогоном — знати, яка частка запитів сценарію завершується на edge-вузлі, і або свідомо винести статику зі сценарію, або описати її внесок у звіті.

Пропускна здатність уперлася в стелю, а в розкладці помилок — тисячі 429. Чия це межа?

Це вердикт обмежувача частоти, а не ємність системи. Код 429 означає, що клієнт надіслав забагато запитів за проміжок часу, причому специфікація свідомо не визначає, як саме сервер ідентифікує клієнта й рахує запити: на практиці лічильник ведуть за IP, а там, де є автентифікація, — за обліковим записом чи застосунком; сам ліміт буває як загальний для сервера, так і окремий для конкретного ресурсу. Оскільки всі віртуальні користувачі одного генератора приходять з однієї адреси, без підміни IP ліміт наздоганяє вас раніше, ніж наздогнав би живого користувача, — тобто до системи доїжджає лише частина навантаження, і про її межу такий прогін не каже нічого. Заголовок Retry-After тут не є надійним індикатором: при 429 він необовʼязковий, приходить у двох форматах (HTTP-дата або кількість секунд) і трапляється також при 503 та редиректах, тож «бачу Retry-After — значить ліміт» хибно. Ще один пункт того ж розділу: ризик у редакції OWASP 2023 перейменували на Unrestricted Resource Consumption, змістивши акцент на вичерпання ресурсів, зокрема платних за виклик — лист, SMS, дзвінок. Сценарій, що зачіпає такі операції, коштує реальних грошей, і це предмет погодження прогону, а не технічна дрібниця.

Час відповіді росте, помилки зʼявляються, а системні метрики спокійні. Що це може бути?

Одразу застереження: окремого стандарту чи специфікації під цю тему немає — далі практика команд, а не канон. Дуже характерна картина для периметра — зазвичай це WAF (web application firewall). Синтетичне навантаження погано вдає людей: заголовки в усіх однакові, темп рівний, а тисячі сесій приходять із кількох адрес — периметр цілком здатен розцінити це як атаку й узятися фільтрувати запити, підсовувати додаткові перевірки чи штучно сповільнювати темп. Далі ваш графік чесно описує реакцію периметра, а не поведінку застосунку, і саме тому системні метрики мовчать: до застосунку трафік просто не дійшов. Роблять із цим одне з двох. Або прогін погоджують із власниками периметра й фіксують у плані, чи внесені адреси генераторів до allow-list. Або свідомо ставлять генератор за периметр і прямо пишуть у звіті, що периметр у вимір не входив, — рівно так само, як фіксують будь-яку іншу розбіжність середовища. Обидва шляхи прийнятні; неприйнятно лише не розуміти, у якому з двох станів ви зараз.

Як тестувати систему, яка ходить у платіжний шлюз?

Через віртуалізацію сервісів (service virtualization). Якщо якась частина системи або даних недоступна для перф-тестів, канон вимагає реалізувати обхід — наприклад, стаб (stub), що заміщує й емулює сторонній компонент обробки карткових платежів; для цього існують спеціальні інструменти, і їх використання наполегливо рекомендують, щоб ізолювати систему під тестом. Ключове слово тут — ізолювати: без стаба ви міряєте чужий сервіс разом зі своїм і не можете відповісти, чий саме час відповіді виріс. Але дублер із нульовою затримкою бреше не менше: у Gatling для цього є окрема фіктивна дія — вона вдає звернення до віддаленої системи, і їй задають тривалість, підсумок і оновлення сесії; випадок описано прямо — реальний сервіс у прогоні чіпати не можна, а метрики бізнес-процесу все одно потрібні. Тривалість там ставлять фіксованим числом, обчислюваним виразом або випадковою величиною, а підсумок за потреби роблять невдалим. Правило звідси: стаб мусить віддавати затримку, схожу на реальну, інакше профіль втрачає ту паузу, яка в бойовому середовищі нікуди не дінеться. І останнє — у звіті пишуть, що саме замінено: результат стосується системи з фіктивною залежністю, а не системи цілком.

Найпідступніший випадок — залежність, яка не падає, а мовчить. Що з нею робити?

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

Чи можна ганяти навантаження на проді?

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

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

Кейс 1. Паспорт стенда: перетворюємо число на перевірюваний факт

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

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

• Колонка «куди зміщує» важливіша за колонку «прод». Канон вимагає не рівності середовищ, а розуміння відмінностей і того, як результат проєктується на бойове середовище. Рядок без напрямку зміщення — це визнання «ми не думали», а не документація.
• Питання «помножимо на три, бо вузлів утричі більше?» має одну правильну відповідь — ні. Продуктивність нелінійно залежить від середовища, і саме тут це видно предметно: три рядки таблиці тягнуть результат угору, два — вниз, а один взагалі не має знака. Множник, який мав би все це підсумувати, не існує.
• Рядок про дані стоїть першим не з ввічливості. Обсяг і структура здатні змінити результат кардинально, а передбачити цей вплив до реального прогону не виходить — тобто саме цей рядок і робить решту таблиці приблизною.
• Рядок про heap Java — той, який забувають. Зменшений стенд потребує іншої конфігурації ПЗ, а не тих самих параметрів на слабшому залізі; підігнали heap — зобовʼязані про це написати, бо профіль збирача сміття тепер інший, ніж на проді.
• Правильна форма відповіді менеджеру. Не «прод витримає N», а «на стенді межа була N при такому міксі й такій базі; на проді очікуємо іншу, і щоб її знати, треба зміряти на середовищі, ближчому за трьома рядками таблиці». Далі — розмова про бюджет, а не про арифметику.

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

import { test, expect } from '@playwright/test';

test.describe('передпольотна перевірка стенда', () => {
  test('білд, дані й моніторинг відповідають паспорту прогону', async ({ request }) => {
    const build = await (await request.get('/api/version')).json();
    expect(build.commit, 'на стенді не той білд, який збиралися міряти')
      .toBe(process.env.EXPECTED_COMMIT);

    // обсяг даних — перший рядок паспорта, тож перевіряємо порядок, а не точне число
    const stats = await (await request.get('/api/internal/stats')).json();
    expect(stats.orders).toBeGreaterThan(1_000_000);

    // моніторинг має збирати метрики ДО старту, а не «розберемося потім»
    const metrics = await (await request.get('/metrics')).text();
    expect(metrics).toContain('http_server_requests_seconds');
  });
});

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

Кейс 2. Стеля пропускної здатності: хто насправді поставив межу

Звіт нічного прогону виглядає як знайдена межа системи. Насправді таких «меж» у прогоні буває три, і всі вони не про систему.

Прогін 02:10–02:50, ramping 0 → 2000 VU, сценарій catalog+checkout

  throughput ......... 848–852 rps упродовж 26 хвилин (розкид менше 0.5%)
  http_req_failed .... 11.4%
  p(95) .............. 3.9s

  Розкладка помилок:
    HTTP 429 ................................. 6 940
    read: connection reset by peer .............. 512
    socket: too many open files ................... 0

  Машина-генератор:
    CPU ..... 41%   RAM ..... 55%   NIC ..... 180 Mbit/s з 1 Gbit/s

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

• Спершу знімаємо підозру з генератора — і тут вона знімається. Процесор має запас, памʼять далеко від девʼяноста відсотків, мережа не в поличці, дескрипторних помилок нема. Якби процесор стояв під стелею, розмова була б інша: при 100% процесора тест зазнає обмежень тротлінгу, і метрики покажуть значно більший час відповіді, ніж є насправді. Порядок дій незмінний — генератор виключають першим, а не останнім.
• Висновок робить розкладка помилок, а не форма кривої. «Так рівно система не поводиться» — здогад, а не доказ: сама по собі стабільна лінія нікого не називає. Тому поруч із графіком завжди кладуть перелік помилок за походженням — саме він показує, хто зупинив запити.
• Майже сім тисяч 429 називають винуватця. Обмеження частоти рахує клієнта за IP, а всі віртуальні користувачі одного генератора приходять з однієї адреси — тобто ліміт спрацював на «одному клієнті» з нереальною поведінкою, а не на тисячі різних. Без підміни IP цей прогін узагалі не міг дійти до межі системи.

Перевірка займає один запит — і одразу видно, чий це вердикт:

curl -s -o /dev/null -D - "https://stage.example.com/api/catalog?page=2"

HTTP/1.1 429 Too Many Requests
Retry-After: 30
X-Cache: MISS

• 429 тут — вердикт обмежувача, а не системи. Специфікація свідомо не описує, як сервер ідентифікує клієнта й веде рахунок: одні лічать за IP, інші за автентифікованим користувачем чи застосунком, і ліміт буває як загальний для сервера, так і окремий для ресурсу. Тому «підняли ліміт на 30%» без розмови з власником сервісу — вгадування.
• Retry-After не є доказом ліміту. При 429 він необовʼязковий, приходить у двох форматах (кількість секунд або HTTP-дата) і трапляється також при 503 і при редиректах. Читати треба код, а заголовок брати лише як підказку про паузу.
• X-Cache у відповіді — друга межа того самого прогону. Частина сценарію завершується на edge-вузлі CDN: він віддає статику з кешу й знімає ці запити з власних серверів організації. Значить, пропускна здатність у звіті частково описує чужу інфраструктуру, а MISS на цьому конкретному запиті означає, що саме він до системи таки дійшов. Назви й формат таких діагностичних заголовків залежать від провайдера (X-Cache, CF-Cache-Status тощо), тож звірятися треба з його докою, а не з памʼяттю. Перед прогоном треба знати частку HIT — інакше незрозуміло, яку систему ви зміряли.
• Третій кандидат на «межу» не видно в жодному заголовку — і канону під ним немає. Далі практика команд, а не стандарт: якщо системні метрики спокійні, а помилки й затримки ростуть, підозра переходить на периметр — WAF цілком може прочитати рівний синтетичний трафік з кількох адрес як атаку й почати притримувати темп. Перевіряється це не в консолі, а розмовою: чи внесені адреси генераторів до allow-list і чи стоїть генератор перед периметром узагалі.

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

Кейс 3. Стаб платіжного шлюзу: два способи підробити вимір

Сценарій оформлення замовлення ходить у зовнішній платіжний шлюз. Ганяти навантаження в чужий бойовий сервіс не можна, тож ставимо стаб (stub) — і саме тут роблять дві протилежні помилки.

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

• Мета стаба — ізоляція, а не швидкість. Канон називає практику віртуалізацією сервісів і рекомендує її саме для того, щоб відокремити систему під тестом від зовнішніх компонентів. Прискорення профілю — побічний ефект, і він шкідливий: інструменти дозволяють виставити тривалість фіксованим числом, обчислюваним виразом або випадковою величиною, а підсумок зробити невдалим саме тому, що дублер має бути схожим на оригінал, а не зручним.
• Другий рядок таблиці — найпоширеніша помилка. Стаб на 1 мс прибирає з тесту головне, що дає зовнішня залежність: зайняті ресурси, які чекають. У проді сотні потоків стоятимуть на очікуванні платежу, а ваш звіт про це не знає нічого.
• Четвертий рядок — рівень сеньйора. Канон SRE вимагає перевіряти саме мовчазну залежність: некритичний бекенд, який ніколи не відповідає, здатен тримати ресурси й сповільнювати критичні шляхи, а фронтенд при цьому не має права ані сипати відмовами всім підряд, ані виїдати власні ресурси, ані відповідати з надзвичайно довгою затримкою.

Мовчазну залежність зручно відтворити на рівні браузерного тесту — прямо перевіряємо, що інтерфейс не помирає разом із чужим сервісом:

import { test, expect } from '@playwright/test';

test('інтерфейс переживає платіжний шлюз, який не відповідає', async ({ page }) => {
  // залежність не падає, а мовчить: запит іде і не повертається ніколи
  await page.route('**/api/payments/**', async () => {
    await new Promise(() => {}); // навмисно без resolve
  });

  await page.goto('/checkout');
  await page.getByTestId('place-order').click();

  // критичний шлях лишається живим: користувач бачить стан, а не завислий екран
  await expect(page.getByTestId('payment-pending')).toBeVisible({ timeout: 15_000 });
  await expect(page.getByTestId('order-summary')).toBeVisible();

  // і застосунок сам обриває очікування, а не тримає його вічно
  await expect(page.getByTestId('payment-timeout-notice')).toBeVisible({ timeout: 45_000 });
});

• Тест перевіряє не платіжку, а поведінку системи навколо неї. Зелений результат означає, що застосунок має власний таймаут і деградує керовано; червоний — що одна мовчазна залежність здатна вичерпати ресурси на критичному шляху. Це знахідка, якої звичайний навантажувальний прогін із добрим стабом не дає ніколи.
• Той самий сценарій має сенс і на протокольному рівні. У перф-прогоні мовчазну залежність тримають частку часу (наприклад, останні десять хвилин довгого тесту) і дивляться на пул зʼєднань та кількість активних потоків, а не на час відповіді — саме там проявляється утримання ресурсів.
• І фінальний рядок у звіті. Замінивши шлюз дублером, ви перестали міряти систему цілком: результат стосується конфігурації з фіктивною залежністю. Це така сама відмінність середовища, як менша база чи слабше залізо, і місце їй — у паспорті стенда з кейсу 1.

Достовірність середовища

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

Чому коефіцієнт заборонений

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

Генератор — теж система під навантаженням

• Тримаю в голові пороги здоровʼя генератора: щонайменше 20% простою процесора, памʼять не вище 90%, мережевий інтерфейс не в поличці, своп вимкнено.
• Знаю, що робить тротлінг генератора зі звітом — завищує час відповіді проти справжнього, — і тому ресурси машини навантаження дивлюся раніше за метрики системи.
• Розводжу помилки за походженням: too many open files — межа генератора, connection reset by peer — зʼєднання розірвала система, context deadline exceeded — система не відповіла вчасно; і памʼятаю, що дескриптори файлів та межа кількості задач — такі самі ресурси зі своєю утилізацією.
• Можу пояснити контрінтуїтивне: швидший сервер навантажує генератор сильніше, а невдало підібрана кількість потоків веде до Coordinated Omission із хибними або неточними результатами.
• Знаю, чим інструмент зʼїдає власні ресурси (елементи Listener у JMeter тримають копію кожного показаного семпла; у k6 тіло відповіді за замовчуванням лежить у памʼяті, а на кожну унікальну адресу заводиться окремий часовий ряд) і чому підняті ліміти ОС зникають після перезапуску, а ulimit живе лише в поточній сесії оболонки.

Що стоїть між генератором і системою

• Можу пояснити, чому CDN робить частину виміру чужою: edge-вузол віддає відповідь із кешу, тож пропускна здатність частково описує його, а спільним кешам термін свіжості задає s-maxage.
• Знаю, що 429 у розкладці помилок — межа обмежувача, а не системи, і що специфікація свідомо не визначає спосіб рахунку (за IP або за автентифікованим користувачем); памʼятаю, що Retry-After при 429 необовʼязковий і трапляється також при 503 та редиректах.
• Знаю дві конфігураційні пастки маршруту: без підміни IP балансувальник і обмежувач бачать одного клієнта замість тисячі, а кеш DNS віртуальної машини Java відправляє весь трафік на один вузол кластера.
• Можу назвати WAF як чинник спотворення (синтетичний трафік читається як атака, системні метрики при цьому спокійні) і два законні виходи: узгоджений allow-list адрес або свідоме рішення стати за периметр із записом про це у звіті — памʼятаю, що канону під цю тему немає, це практика команд. Окремо тримаю в голові ціну прогону: у редакції OWASP 2023 ризик названо Unrestricted Resource Consumption, тож сценарій, що чіпає операції з оплатою за виклик (надісланий лист, SMS, дзвінок), узгоджують заздалегідь.

Стаби й зовнішні залежності

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

Прод

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