Навантажувальне тестування k6: де ламається прод
Прод ламається не там, де закінчуються ресурси, а там, де закінчується черга. Пул з'єднань до бази вибирається першим, запити стають в очікування, і сервіс, який на графіках CPU виглядає спокійним, починає віддавати таймаути.
Далі спрацьовує каскад: клієнт повторює запит, повтори добивають пул, деградація сервісу прискорюється — і відновлення займає вже не хвилини, а години.
Навантажувальне тестування k6 показує ці точки відмови під навантаженням до того, як їх знайде пікове навантаження в бою. Сценарії описуються кодом: профіль ramp-up, плато, різкий стрибок, поведінка при відмові частини вузлів.
Метрики — час відповіді за перцентилями, частка помилок, пропускна здатність — знімаються за кожним кроком, а пороги задаються як умова проходження прогону, а не як побажання.
Вузьке місце інфраструктури рідко буває одне. Це може бути вичерпання пулу з'єднань, невірний таймаут на зовнішньому виклику, відсутність обмеження на паралелізм, кеш, який не прогрівається після перезапуску, або балансувальник, що втрачає сесії при масштабуванні.
Окремо кожен вузол тримає навантаження, разом вони дають відмову на піку — і побачити це можна тільки на сценарному прогоні з реалістичним профілем трафіку.
Розбираємо, як це закривається: які сценарії пишемо під ваш профіль, де ставимо пороги і що робимо зі знайденими точками відмови до виходу в прод.
Що дає сценарний прогін перед релізом
Сценарний прогін до релізу перетворює здогадки про поведінку сервісу на вимірювання. Замість питання «чи витримає прод пік» команда отримує профіль навантаження, відтворюваний покроково: скільки одночасних користувачів, який сценарій, де точка насичення.
Гіпотези щодо ємності перевіряються за хвилини замість днів очікування реального трафіку, і кожна правка конфігурації одразу видна в цифрах — час відгуку, частка помилок, споживання ресурсів на кожному вузлі.
Передбачуваність під навантаженням — це коли поведінка системи на піку відома заздалегідь. Сценарний прогін показує, за якої кількості одночасних сесій зростає час відгуку, де починають накопичуватися черги і який вузол здається першим.
Ці дані лягають в основу порогів і правил автомасштабування: система реагує на зростання раніше, ніж користувач помічає уповільнення.
Окремий ефект — усунений клас відмов. Помилки, які проявляються лише за конкурентних запитів — гонки за спільний ресурс, вичерпання пулу з'єднань, деградація кешу під промахами — на низькому трафіку невидимі й спливають у найневдаліший момент. Прогін витягує їх до релізу, коли ціна виправлення мінімальна, а не в розпал пікового навантаження.
Стійкість сервісу стає властивістю, яку можна перевірити, а не надією. Команда знає запас за ємністю, бачить, як поводиться система за відмови окремого вузла, і розуміє, які сценарії деградації допустимі.
Це змінює розмову про реліз: замість «напевно, витримає» — конкретні пороги, за яких система залишається в нормі, і зрозумілий план дій у разі їх перевищення.
Профілі навантаження: постійний, ступінчастий, піковий
Профіль навантаження — це не «скільки запитів за секунду подати», а форма кривої в часі. Один і той самий сервіс витримує постійне навантаження і складається на піковому: пул з'єднань, кеш і черги поводяться по-різному залежно від того, як швидко зростає інтенсивність.
Постійний профіль тримає рівну інтенсивність і відповідає на питання «який запас за пропускною здатністю є зараз». Ступінчастий піднімає навантаження кроками з витримкою на кожному ступені — так знаходиться точка, де час відгуку йде вгору, а частка помилок перестає бути нульовою.
Піковий імітує різкий сплеск: розпродаж, розсилка, відкриття реєстрації — перевіряємо, чи переживе система стрибок і як швидко повернеться в норму після нього.
| Профіль | Коли підходить | Обмеження |
|---|---|---|
| Постійний | Базова лінія, регрес між релізами, пошук запасу | Не показує поведінку на зростанні та деградацію під чергами |
| Ступінчастий | Пошук граничної точки та запасу до відмови | Тривалий прогін; результат залежить від тривалості ступеня |
| Піковий | Сплески трафіку, перевірка авто-масштабування та відновлення | Не дає криву деградації, лише факт «витримав/упав» |
На практиці профілі комбінують в одному сценарії: ступінчастий вивід на робочу інтенсивність, витримка на постійній, потім піковий сплеск і спостереження за відновленням.
Обмеження будь-якого профілю — стенд: якщо середовище слабше за продуктивне або дані не схожі на бойові, цифри описують стенд, а не систему. Тому перед прогоном фіксуємо склад середовища, обсяг даних і точки заміру, а результати порівнюємо лише між зіставними конфігураціями.
Як ми впроваджуємо навантажувальне тестування k6
Впровадження починається не зі встановлення інструмента, а з аудиту архітектури: які сервіси приймають трафік, де спільний кеш і база, які залежності зовнішні. Без цієї карти сценарії б'ють по випадкових точках, а результати не сходяться з реальністю.
На виході — перелік критичних шляхів і цільові показники: скільки одночасних користувачів тримаємо, який час відгуку вважаємо нормою, при якому навантаженні починається деградація.
Далі вибудовуємо маршрут так, щоб кожен етап давав перевірюваний артефакт, а не звіт «загалом усе працює».
- Аудит архітектури та точок відмови. Розбираємо схему сервісів, черги, ліміти та зовнішні інтеграції. Фіксуємо, що саме тестуємо і які показники знімаємо.
- Цільові показники навантаження. Узгоджуємо профіль: піковий трафік, тривалість, поведінку при відмовах. Це база для критеріїв приймання, а не абстрактне «має витримати».
- Налаштування сценаріїв. Описуємо користувацькі шляхи у вигляді сценаріїв з різними профілями навантаження — плавне зростання, сходинки, різкий пік. Параметри виносимо в конфігурацію, щоб змінювати їх без правки коду.
- Підготовка оточення та даних. Розгортаємо стенд, наближений до продуктива, готуємо тестові дані та ізоляцію від реальних користувачів. Інакше заміри показують не потужність системи, а її поведінку на порожній базі.
- Прогін і перевірка результатів. Знімаємо метрики за часом відгуку, часткою помилок і пропускною здатністю, зіставляємо з цільовими. Знаходимо вузькі місця — повільні запити, нестачу ресурсів, неправильні налаштування.
- Усунення та повторний прогін. Після правок повторюємо ті самі сценарії та порівнюємо з попередніми замірами. Так видно, що саме дало ефект, а що ні.
- Передача команді. Віддаємо сценарії, конфігурації, регламент запуску та розбір результатів. Ваші інженери далі ганяють перевірки самі — перед релізами та після змін.
Такий маршрут перетворює навантажувальне тестування з разової акції на регулярну перевірку. Команда отримує не разовий звіт, а відтворюваний набір сценаріїв і зрозумілі пороги, за якими система починає деградувати.
Сценарії, пороги та звіти: що залишається у вас
Навантажувальне тестування через k6 дає результат лише тоді, коли сценарії, пороги та середовище описані так, що команда може повторити прогін без автора. Тому передаємо не разовий запуск, а комплект артефактів, за яким навантажувальні перевірки живуть далі самостійно.
- Сценарії навантаження — файли з профілями: розгін, плато, пік, спад і сценарій «сходинки» для пошуку точки деградації. Кожен профіль прив'язаний до реального користувацького шляху, а не до абстрактного запиту.
- Порогові значення — критерії приймання в самих сценаріях: частка помилок, час відповіді на перцентилях, пропускна здатність. Прогін падає автоматично, якщо система вийшла за межі — без ручного розбору графіків.
- Схема середовища — карта стенда: які сервіси, залежності та заглушки задіяні, де вузькі місця за ресурсами, чим середовище відрізняється від продуктивного. Без неї цифри прогону нема чим пояснити.
- Регламент прогонів — коли і що запускаємо: перед релізом, за розкладом, після змін у конфігурації. Із зазначенням, хто дивиться результат і які пороги блокують викатку.
- Звіт із навантаження — розбір результатів: де пройшли пороги, де вперлися в межу, що стало причиною, які зміни пропонуються. З графіками та висновком, а не сирим логом.
- Інструкція із запуску — як підняти середовище, прогнати сценарій і зняти метрики, включно з типовими помилками та способами їх усунути.
- План розвитку — які сценарії додати наступними: сезонні піки, відмовостійкість, тривале навантаження на витривалість.
Такий комплект закриває головний ризик навантажувальних перевірок — коли тест є, а повторити його й зрозуміти результат може лише одна людина. Опишіть вашу систему та цілі — повернемося з оцінкою та планом робіт.
Кейс: як сервіс перестав падати під піком
Що було до
Сервіс — особистий кабінет з оплатою та історією замовлень — стабільно працював на середньому трафіку та передбачувано лягав у момент розпродажів.
Симптоми повторювалися: час відгуку на оформлення замовлення зростав з 400 мс до 6-8 секунд, частка помилок 5xx піднімалася до 12-15%, частина кошиків губилася на етапі підтвердження оплати.
Інженери виправляли те, що бачили в логах, але без відтворюваного профілю навантаження кожне виправлення було здогадкою — ефект від нього ніхто не міг виміряти.
Що змінили
Зібрали сценарій на k6, який повторював реальну поведінку: вхід, каталог, додавання в кошик, оплата — з різними частками та паузами між кроками.
Прогнали серію прогонів зі зростанням віртуальних користувачів до триразового піку та зняли метрики по кожній ділянці шляху, а не лише по сервісу загалом.
Так знайшлися два вузькі місця: синхронний виклик платіжного шлюзу всередині запиту оформлення та пул з'єднань до бази, який упирався в стелю задовго до піку.
Винесли підтвердження оплати в асинхронну обробку, розширили пул з'єднань і додали кеш на читання каталогу. Після кожного виправлення проганяли той самий сценарій — порівняння йшло за одними й тими самими метриками, тому регрес було видно одразу, а не через тиждень на проді.
Що стало
| Метрика | До | Після |
|---|---|---|
| Час відгуку на піку | 6-8 с | 700-900 мс |
| Частка помилок 5xx | 12-15% | нижче 0,3% |
| Втрачені замовлення | поодинокі на піку | не зафіксовані |
| Поведінка при 3× навантаженні | деградація до відмови | працює без зростання помилок |
Сценарій залишився в репозиторії та запускається перед кожним великим релізом — команда бачить, як зміна впливає на стійкість під піком, до викату в прод.
Схожий розбір навантаження ми робили для сервісу доставки на k6: там після перенесення важких операцій із запиту час відгуку на піку впав з 5 секунд до 600 мс, а частка помилок — з 9% до часток відсотка.
Чим сценарний прогін відрізняється від моніторингу
Моніторинг відповідає на питання «що відбувається зараз»: він знімає метрики з працюючого сервісу і показує, що затримки зросли, черга накопичується, а частка помилок поповзла вгору.
Але він не говорить, за якого навантаження це почалося і що саме стало причиною — спостереження фіксує симптом, а не межу, за якою система ламається.
Сценарний прогін влаштований інакше: ми самі задаємо профіль навантаження і перевіряємо гіпотезу — чи витримає сервіс пік, як поводитиметься під тривалим тиском, де почне деградувати.
Ключова відмінність — кероване навантаження. У спостереженні за сервісом трафік створюють реальні користувачі, і ми не керуємо ні його обсягом, ні складом.
У сценарному прогоні ми описуємо поведінку віртуальних користувачів: скільки їх, які запити вони надсилають, з якою частотою і в якій послідовності.
Це перетворює перевірку з пасивної на активну — ми не чекаємо, поки щось впаде, а самі створюємо умови, у яких слабке місце проявиться.
Ще різниця у відтворюваності. Моніторинг показує зріз живої системи, де на результат впливають десятки випадкових факторів.
Сценарний прогін повторюваний: той самий профіль дає зіставні цифри до і після змін, тому можна довести, що оптимізація спрацювала, а не збіглася із затишшям у трафіку.
На практиці ці підходи не замінюють, а доповнюють один одного. Моніторинг тримає постійний контроль і ловить аномалії в реальному часі, а навантажувальний прогін відповідає на питання «чи витримаємо ми зростання» до того, як це зростання станеться.
Ми будуємо сценарії так, щоб вони били по найбільш навантажених шляхах — вхід у систему, оформлення замовлення, звернення до зовнішніх сервісів, — і на виході дають не графік заради графіка, а конкретну межу: скільки одночасних користувачів сервіс тримає з прийнятним часом відгуку і за якого навантаження починаються відмови.
Питання, які ставлять перед стартом
Перед стартом майже завжди виринають три теми: чи не зачепить навантаження бойовий контур, як розділити середовища і що робити з уже написаними сценаріями. Нижче — короткі відповіді, які знімають ці сумніви до початку робіт.
Чи можна ганяти навантаження на проді й не завалити сервіс?
Так, якщо прогін обмежений за навантаженням і за часом. Ми задаємо стелю віртуальних користувачів і швидкість їхнього приросту, ставимо пороги на час відповіді та частку помилок — при їхньому пробої прогін зупиняється сам, а не добиває систему.
Додатково обмежуємо прогін вікном низького трафіку, розводимо генератор навантаження і цільовий контур за ресурсами, а трафік позначаємо, щоб він не потрапляв у продуктову аналітику та білінг. Якщо ризик усе одно неприйнятний — переносимо прогін на копію бойового контуру зіставними даними.
Як розділяються середовища, щоб тести не заважали одне одному й розробці?
Сценарії та конфігурації живуть у репозиторії й запускаються з ізольованого контуру: окремі генератори навантаження, свої ліміти та мережеві правила. Це означає, що прогін не конкурує за ресурси з робочими задачами й не залежить від того, що хтось у цей момент деплоїть. Результати складаються окремо від продуктових метрик, тому заміри залишаються відтворюваними.
У нас уже є сценарії на іншому інструменті — їх доведеться переписувати?
Не обов'язково. Спершу розбираємо те, що є: які сценарії покривають реальні шляхи користувача, де дублі, а де прогалини. Частина логіки переноситься майже без змін, частина переписується під k6 — зазвичай це профілі навантаження та перевірки відповідей.
Якщо сценарії описують те, що вже не відповідає продукту, чесно скажемо про це, а не перенесемо застаріле як є.
Що буде з доступами та даними, які ви отримаєте?
Доступи видаються під конкретні задачі й відкликаються по завершенні робіт; для прогонів використовуємо тестові облікові записи та знеособлені дані, де це можливо. Усі зміни в конфігураціях і сценаріях проходять через репозиторій — видно, хто і що змінював.
За підсумком у вас залишається робоча обв'язка й документація, а не чорна скринька, що залежить від нас.
Якщо якийсь із цих пунктів у вас вирішено інакше — скажіть, як улаштовано зараз: підлаштуємо схему прогонів під ваші обмеження, а не навпаки.
Обговоримо ваше завдання і повернемося з планом
Щоб повернутися з оцінкою та планом, нам потрібен контекст щодо вашої системи: що тестуємо, які сценарії критичні та який результат вважаєте успішним. Опишіть завдання у вільній формі — далі ми поставимо уточнювальні запитання та запропонуємо схему робіт.
- Що це за система і як вона влаштована. Сервіс, API, вебзастосунок або зв'язка сервісів; де проходить межа навантаження і які зовнішні залежності задіяні.
- Ключові сценарії. Які користувацькі шляхи найважливіші: вхід і авторизація, пошук, оформлення замовлення, вивантаження звітів — те, що не можна обвалити.
- Цільові показники. Очікувана кількість одночасних користувачів, пікові періоди, допустимий час відгуку та поріг, після якого вважаємо, що система деградувала.
- Поточна інфраструктура. Де розгорнуто середовище, чи є окремий стенд під навантаження чи тестуємо на проді, які обмеження щодо доступів.
- Що вже пробували. Попередні заміри, відомі вузькі місця, інциденти під час пікових навантажень — це прискорює діагностику.
- Обмеження та строки. Коли потрібен результат, чи є вікна, у які навантаження запускати не можна, хто з боку замовника приймає роботу.
За цими вступними ми готуємо сценарії на k6, розгортаємо стенд, знімаємо метрики та знаходимо межу, за якою система починає втрачати запити.
У відповідь ви отримуєте оцінку строків, план робіт за етапами та перелік того, що увійде в результат: скрипти, звіти з метриками, список вузьких місць і рекомендації щодо їх усунення.
Опишіть завдання — повернемося з оцінкою та планом, обговоримо наступний крок і порядок робіт.
