Актуально на травень 2026. Автор: інженер з продуктивності та SRE, 9+ років досвіду.
19:03. Реклама з ефіру зайшла в ціль. Трафік різко зріс у 4 рази. На графіках — зелений ліс зростаючих RPS. За дві хвилини каса стала повільною. Люди тиснуть «Оплатити», але відповідь йде 2–3 секунди. Через 10 хвилин частина сесій падає. Корінь проблеми виявився простим: холодний кеш, невдалий прогрів, і черга на платежі без бекофа. Цей кейс навчив команду: готувати сценарії саме під пік, а не «середній день».
Висновок простий. Пік — це окрема подія. Вона має власний профіль навантаження, свої вузькі місця та окремий план експерименту. Далі — як зробити так, щоб у ваш найгарячіший вечір все працювало швидко і стабільно.
Коли на сайт іде вал користувачів, «ламаються» не тільки веб-сторінки. Пливуть кеш-хітрейт, затримки в чергах, з’єднання до БД, квоти зовнішніх API. Ланцюг довгий: балансувальник → CDN → бекенд → БД → черги → зовнішні сервіси. Будь-який слабкий вузол вдарить по всій системі.
Розумійте пік як повну подорож подій. Аналізуйте його за реальними патернами (сплески, довгі плато, стрибки з ретраями). Добре описує типові хвилі та захист від DDoS розбір у блозі Cloudflare — подивіться практичні графіки і поради щодо пікових вікон: аналіз пікового трафіку.
Також не забувайте про UX-метрики у фронтенді. Core Web Vitals напряму впливають на конверсію в пік (важливо, коли бекенд швидкий, але браузер «важкий»). Офіційні орієнтири тут: Core Web Vitals.
Ключ — зв’язати технічні числа з бізнес-ціллю. Не лише «RPS і CPU», а «відсоток успішних оплат», «час видачі пошуку», «частка кинутих кошиків». Для піку це і є SLO. Наприклад: «99,5% оплат до 800 мс», «помилки в чекауті ≤0,5%», «p95 пошуку ≤300 мс». Технічні метрики (RPS, p95/p99, кеш-хітрейт, лаг черги) стають інструментом для захисту SLO.
Як формулювати SLO і не загубитись у термінах — дивіться «книгу SRE» від Google: Service Level Objectives. Вона дає рамку, як тримати баланс між швидкістю і надійністю.
Як запобігти черговим колапсам? Перегляньте шаблон Queue-based load leveling. Це базова, але дуже дієва ідея для згладжування валів подій.
Таблиця нижче — стартовий набір. Візьміть 3–5 критичних сценаріїв, підставте свої метрики та пороги. Не женіться за десятками кейсів: краще глибше, але по суті. Запускайте сценарії окремо і разом, щоб бачити перетоки навантаження.
| Масовий пошук товарів після пуш-кампанії | 10→50 RPS за 10 хв; плато 30 хв; стрес 2× на 5 хв | Кеш, пошук, БД | p95 ≤ 300 мс; miss ≤ 20%; CPU ≤ 70% | 99% < 500 мс; помилки ≤ 0,3% | k6, Grafana/Prometheus | Синтетика з реальним розподілом запитів | Агресивніший edge-кеш; спрощений результат пошуку |
| Перегляд картки товару з варіаціями | 15→80 RPS стрибком; плато 20 хв | CDN, кеш API, мікросервіси атрибутів | Cache hit ≥ 85%; p99 ≤ 600 мс | 99% < 400 мс | Gatling, APM | Слепок популярних SKU (аноніміз.) | Edge-кеш HTML; відкласти пов’язані блоки |
| Checkout з оплатою карткою | 5→20 RPS; плато 20 хв; стабільний шум ретраїв | API платежів, черга, база замовлень | Помилки ≤ 0,5%; p99 ≤ 800 мс; лаг черги | 99,5% успіху; SLA платіжного шлюзу | JMeter, APM/трейсинг | Псевдонімізований слепок транзакцій | Exponential backoff; альтернативний шлюз |
| Старт розпродажу квитків | 3× за 2 хв; далі «сходинки» кожні 5 хв | Локи місць, транзакції, черги | p95 ≤ 500 мс; конфлікти локів; saturation | 99% броней без конфліктів | Locust, Redis моніторинг | Синтетика + «гарячі» події | Пул місць; м’яка деградація UI під навантаженням |
| Банківський переказ із підтвердженням | Плавний ріст 1→10 RPS; довге плато | Сервіси AML/KYC, зовнішні API, таймаути | Timeout rate; p95 ≤ 900 мс; черги | 99,9% без помилок; SLA зовнішніх API | k6 + Chaos (фліп таймаутів) | Анонімні кейси + синтетика помилок | Кеш рішень KYC; режим «обмеженої функції» |
| Живі ігри у прайм-тайм (гемблінг) | Стрибок 3× за 2 хв; шум у чаті | Стрім, чат, платежі, кеш профілів | Jitter ≤ 150 мс; drop ≤ 0,2%; p95 транзакцій | Uptime 99,9%; відмова ≤ 0,1% | Gatling + трасування | Синтетика + патерни реальних вечорів | Адаптивна якість відео; пріоритизація транзакцій |
| Масовий логін з MFA | Пік 50 RPS на 5 хв; далі плато 15 хв | Сесійне сховище, SMS/e-mail шлюзи | p95 OTP ≤ 2 с; помилки ≤ 0,5% | 99% видача OTP до 2 с | JMeter + ліміти зовнішніх шлюзів | Синтетика + rate limits | Кеш дотичних даних; резервний канал OTP |
Редакційна примітка. Патерни трафіку у вечірні години відчутно різняться за країнами та провайдерами. Для ринку Данії є корисні зрізи трафіку та платіжних шляхів у незалежних оглядах. Див. Danske Casinoer i Danmark — це допоможе підібрати реалістичні сценарії під ваш тайм-зонний «прайм» без здогадок.
Немає одного «срібного» інструменту. Під протокольні тести підійде JMeter (див. посібник Apache JMeter). Для сценаріїв на JS з гарною телеметрією — k6 (документація k6). Для Scala-стеків і високої пропускної — Gatling (довідник Gatling). Для простих Python-сценаріїв з розподілом ролей — Locust (документація Locust).
Ключ — пов’язати генератор навантаження з APM/трасуванням і метриками інфраструктури. Тоді ви бачите, де саме гальмує: код, БД, мережа чи зовнішній API. Знімайте трейси для повільних транзакцій, інакше втратите деталі.
Готуйте суміш. Візьміть анонімізований слепок подій (воронки, SKU, тарифи, часті помилки) та домішайте синтетичні «хвости» (рідкі запити, дивні фільтри). Пам’ятайте: розподіл запитів важливіший за «красиві числа» RPS.
Особливо стежте за приватними даними. Анонімізуйте чи псевдонімізуйте. Базові принципи пояснено тут: псевдонімізація згідно з GDPR.
Додайте краплю хаосу: вимкніть один із зовнішніх API, збільште латентність мережі на 200 мс, зсуньте таймаути. Надихніться кейсами з Netflix Tech Blog — там добре показано, як вони підходять до chaos engineering.
Тримайте «золоті сигнали»: латентність, помилки, пропускна здатність, насичення. Плюс бізнес-метрики зверху. Один дашборд — одна історія: що зараз болить і що робити. Придивіться до пояснень і прикладів у керівництві з чотирьох «золотих сигналів».
Почати можна з базового тюнінгу веб-сервера. Корисний довідник: налаштування продуктивності NGINX. Про кешування на CDN добре розписано тут: стратегії кешування на рівні CDN.
Порахуйте просту модель. X транзакцій за хвилину × середній чек × маржа. Це дає ціну однієї хвилини. Далі — очікувана тривалість збою без підготовки. Покажіть окупність плану тестів і буфера ємності. Для структури думок з фінансового боку корисні принципи з AWS Well‑Architected: Cost Optimization.
Зберіть факти: таймлайн, дані з метрик і логів, рішення, що спрацювали. Визначте 2–3 покращення процесу, а не «знайдіть винного». Корисний шаблон для письма: постмортем від Atlassian.
Чим відрізняється стрес‑тест від тесту пікового плато?
Стрес‑тест шукає межу та «режим відмов». Пікове плато перевіряє, чи витримає система реальний високий рівень упродовж довшого часу без просідання метрик і SLO.
Скільки триває прогрів перед піком?
Залежить від кешів і бекграунд-задач. Часто 10–30 хв вистачає. Дивіться на стабілізацію p95 і GC-пауз, а також на прогрів кешів до цільового hit-rate.
Як узгодити бізнес-SLO з технічними метриками?
Прив’язуйте «золоті сигнали» (латентність, помилки, пропуск, насичення) до бізнес-подій (оплати, пошук, бронювання). Встановіть бюджети помилок і пороги p95/p99 для кожного кроку воронки.
Як ми збирали підходи: відпрацьовані сценарії з прод‑інцидентів за останні роки, контрольовані тести у препроді з реальними розподілами подій, кореляція трейсерів і метрик, перевірка відновлення після стресу. В інструментах — JMeter/k6/Gatling/Locust, APM і системи трасування.
Автор: інженер з продуктивності та SRE. 9+ років у e‑commerce, фінтех і гемблінгу. Сертифікації: AWS (Architect Associate), GCP (Associate Cloud Engineer). Працював з піковими івентами на десятках сервісів, включно з BFCM і великими трансляціями.