Актуально на травень 2026. Автор: інженер з продуктивності та SRE, 9+ років досвіду.
Коли сервери не сплять: коротка історія з піку
19:03. Реклама з ефіру зайшла в ціль. Трафік різко зріс у 4 рази. На графіках — зелений ліс зростаючих RPS. За дві хвилини каса стала повільною. Люди тиснуть «Оплатити», але відповідь йде 2–3 секунди. Через 10 хвилин частина сесій падає. Корінь проблеми виявився простим: холодний кеш, невдалий прогрів, і черга на платежі без бекофа. Цей кейс навчив команду: готувати сценарії саме під пік, а не «середній день».
Висновок простий. Пік — це окрема подія. Вона має власний профіль навантаження, свої вузькі місця та окремий план експерименту. Далі — як зробити так, щоб у ваш найгарячіший вечір все працювало швидко і стабільно.
Пік — це не лише трафік. Це кеш, черги, бази, мережа
Коли на сайт іде вал користувачів, «ламаються» не тільки веб-сторінки. Пливуть кеш-хітрейт, затримки в чергах, з’єднання до БД, квоти зовнішніх API. Ланцюг довгий: балансувальник → CDN → бекенд → БД → черги → зовнішні сервіси. Будь-який слабкий вузол вдарить по всій системі.
Розумійте пік як повну подорож подій. Аналізуйте його за реальними патернами (сплески, довгі плато, стрибки з ретраями). Добре описує типові хвилі та захист від DDoS розбір у блозі Cloudflare — подивіться практичні графіки і поради щодо пікових вікон: аналіз пікового трафіку.
Також не забувайте про UX-метрики у фронтенді. Core Web Vitals напряму впливають на конверсію в пік (важливо, коли бекенд швидкий, але браузер «важкий»). Офіційні орієнтири тут: Core Web Vitals.
Що міряти перш за все: бізнес-SLO поверх сирих RPS
Ключ — зв’язати технічні числа з бізнес-ціллю. Не лише «RPS і CPU», а «відсоток успішних оплат», «час видачі пошуку», «частка кинутих кошиків». Для піку це і є SLO. Наприклад: «99,5% оплат до 800 мс», «помилки в чекауті ≤0,5%», «p95 пошуку ≤300 мс». Технічні метрики (RPS, p95/p99, кеш-хітрейт, лаг черги) стають інструментом для захисту SLO.
Як формулювати SLO і не загубитись у термінах — дивіться «книгу SRE» від Google: Service Level Objectives. Вона дає рамку, як тримати баланс між швидкістю і надійністю.
Антикаталог помилок пікового дня
- Stampede на пошук. Рекламний меседж змістив попит з «чекауту» на «пошук»; кеш не встиг, індекс став вузьким місцем.
- Черга платежів без бекофа. Ретраї без джітеру добили шлюз, помилки пішли «ялинкою».
- Кеш-хітрейт впав після релізу. Один заголовок cache-control зламав едж-кеш. Трафік злетів на бекенд уpeak.
- Таймаути коротші за P95. Через занадто малі таймаути — лавина ретраїв і подвійний тиск.
- Пул конекшнів до БД забитий. Сервіс масштабували у 3×, пул — ні. Контеншен і висока латентність.
Як запобігти черговим колапсам? Перегляньте шаблон 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 |
Мікросценарії під різні вертикалі
E‑commerce
- Серії швидких пошуків за брендом після пуша та TV-реклами.
- Каскадний перегляд карток: галерея → відгуки → розмірна сітка.
- Комплектні кошики: кілька доставок, купони, подарункові пакування.
Квитки та івенти
- Флеш-бронювання в перші 2–3 хвилини після старту продажу.
- Колізії місць при перегляді плану залу.
- Пік повернень за годину до дедлайну.
Банкінг/фінтех
- Серії дрібних P2P-переказів у прайм.
- Валідація KYC/AML пакетами під обмежені квоти.
- Виплати на картки з різними платіжними мережами.
Гемблінг
- Старт живих столів у прайм із різкою зміною бітрейту.
- Піковий чат під час великих турнірів.
- Сплески депозитів/виплат під бонусні вікна.
Редакційна примітка. Патерни трафіку у вечірні години відчутно різняться за країнами та провайдерами. Для ринку Данії є корисні зрізи трафіку та платіжних шляхів у незалежних оглядах. Див. Danske Casinoer i Danmark — це допоможе підібрати реалістичні сценарії під ваш тайм-зонний «прайм» без здогадок.
Інструменти: міксуємо JMeter, k6, Gatling, Locust
Немає одного «срібного» інструменту. Під протокольні тести підійде JMeter (див. посібник Apache JMeter). Для сценаріїв на JS з гарною телеметрією — k6 (документація k6). Для Scala-стеків і високої пропускної — Gatling (довідник Gatling). Для простих Python-сценаріїв з розподілом ролей — Locust (документація Locust).
Ключ — пов’язати генератор навантаження з APM/трасуванням і метриками інфраструктури. Тоді ви бачите, де саме гальмує: код, БД, мережа чи зовнішній API. Знімайте трейси для повільних транзакцій, інакше втратите деталі.
Дані для тестів: синтетика чи слепки з продакшену
Готуйте суміш. Візьміть анонімізований слепок подій (воронки, SKU, тарифи, часті помилки) та домішайте синтетичні «хвости» (рідкі запити, дивні фільтри). Пам’ятайте: розподіл запитів важливіший за «красиві числа» RPS.
Особливо стежте за приватними даними. Анонімізуйте чи псевдонімізуйте. Базові принципи пояснено тут: псевдонімізація згідно з GDPR.
План експерименту: прогрів → «сходинки» → плато → стрес → відновлення
- Прогрів (10–30 хв). Наповніть кеші, встановіть стабільний GC, прогрійте пули.
- Сходинки. Піднімайте навантаження порціями (наприклад, +10 RPS кожні 3–5 хв).
- Плато. Тримайте стабільний рівень 20–40 хв. Міряйте p95/p99, помилки, saturation.
- Стрес. Короткий ривок 1,5–2×, щоби побачити «край» системи без ризику.
- Відновлення. Зніміть навантаження і перевірте, як швидко черги та кеші повертаються у норму.
Додайте краплю хаосу: вимкніть один із зовнішніх API, збільште латентність мережі на 200 мс, зсуньте таймаути. Надихніться кейсами з Netflix Tech Blog — там добре показано, як вони підходять до chaos engineering.
Спостережуваність, яка рятує у пік
Тримайте «золоті сигнали»: латентність, помилки, пропускна здатність, насичення. Плюс бізнес-метрики зверху. Один дашборд — одна історія: що зараз болить і що робити. Придивіться до пояснень і прикладів у керівництві з чотирьох «золотих сигналів».
Архітектурні важелі під пік
- Edge/CDN кеш: кешуйте все, що можна; рухайте TTL і ключі кешу обережно.
- Кеш-френдлі рендеринг: менше варіантів сторінок, більше варіантів даних у кеші.
- Rate limiting і backpressure: захистіть бекенд від бурі ретраїв.
- Пули з’єднань: розмір, таймаути, стратегії відмов.
- Фіче-флаги та «деградація на милість»: прибирайте дорогі блоки під навантаженням.
Почати можна з базового тюнінгу веб-сервера. Корисний довідник: налаштування продуктивності NGINX. Про кешування на CDN добре розписано тут: стратегії кешування на рівні CDN.
Як говорити з CFO: скільки коштує хвилина простою в пік
Порахуйте просту модель. X транзакцій за хвилину × середній чек × маржа. Це дає ціну однієї хвилини. Далі — очікувана тривалість збою без підготовки. Покажіть окупність плану тестів і буфера ємності. Для структури думок з фінансового боку корисні принципи з AWS Well‑Architected: Cost Optimization.
Контрольний список перед піковим днем
- Кеші прогріті; ключі та TTL перевірені на прод-лайк середовищі.
- Rate limits узгоджені між фронтом, бекендом і зовнішніми API.
- Таймаути та ретраї з експоненційним бекофом і джітером.
- Пули з’єднань масштабовані пропорційно реплікам.
- Фіче-флаги для швидкої деградації «важких» блоків.
- Резервний платіжний шлюз налаштований і протестований.
- Моніторинг і алерти по бізнес-SLO, не лише по CPU.
- Дашборди «пік-режиму» з Golden Signals і ключовими бізнес-лініями.
- Квоти сторонніх сервісів підтверджені письмово.
- Сертифікати/ключі не протухають у вихідні.
- Runbook інцидентів: хто телефонує, кого будять, як відкотити.
- Бекап конфігів і «червона кнопка» зниження навантаження.
Після бою: постмортем без звинувачень
Зберіть факти: таймлайн, дані з метрик і логів, рішення, що спрацювали. Визначте 2–3 покращення процесу, а не «знайдіть винного». Корисний шаблон для письма: постмортем від Atlassian.
Міфи і правда про навантажувальні тести
- Міф: «Достатньо одного великого тесту раз на рік». Правда: профіль піку змінюється; робіть серії коротких тестів перед кожним великим івентом.
- Міф: «Потрібні тисячі віртуальних користувачів». Правда: важливі реальні патерни, черги і кеш. Кількість — не все.
- Міф: «Середній p50 норм — значить, все ок». Правда: надійність визначає p95/p99 і помилки на бізнес-критичних кроках.
- Міф: «CDN вирішить усе». Правда: некоректні ключі й TTL проб’ють кеш і вб’ють бекенд.
- Міф: «Chaos — це ризиковано перед піком». Правда: маленькі, контрольовані ін’єкції хаосу рятують у реальних збоях.
Міні-гайд по назвах, титулах і даних (для SEO без «переспаму»)
- Title: чітко про пік і сценарії. Наприклад: «Пікове навантаження без паніки: сценарії, SLO і план експериментів».
- Meta description: коротко про профілі, інструменти, чекліст.
- Alt для діаграм: прості й описові (див. нижче приклади).
- Внутрішні посилання: на керівництва з кешування/CDN/observability у вашому блозі.
Посилання на авторитетні джерела, корисні для поглиблення
- Як великі рітейлери готують Black Friday/Cyber Monday: Shopify Engineering.
- Поведінка пікового трафіку та захист на периметрі: Cloudflare Blog.
- Формулювання SLO на практиці: SRE Book: SLO.
- Черги як буфер під пік: Microsoft Learn: Queue-based load leveling.
- Документації інструментів навантаження: JMeter, k6, Gatling, Locust.
- Chaos-підхід у продакшені: Netflix Tech Blog.
- Тюнінг веб-сервера під високе навантаження: NGINX Performance Tuning.
- CDN кешування без болю: Fastly Caching Concepts.
- Вартість надійності: AWS Well‑Architected (Cost).
- Core Web Vitals для фронтенду: web.dev.
- Золоті сигнали спостережуваності: Datadog Monitoring 101.
- Постмортем: Atlassian.
- GDPR і псевдонімізація: gdpr.eu.
FAQ
Чим відрізняється стрес‑тест від тесту пікового плато?
Стрес‑тест шукає межу та «режим відмов». Пікове плато перевіряє, чи витримає система реальний високий рівень упродовж довшого часу без просідання метрик і 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 і великими трансляціями.
