Прогнозування навантаження та ризиків

1) Навіщо це потрібно

• планування ємності (capacity planning) та бюджетування;
• налаштування SLO/SLI, бюджетів помилок і політик алертингу;
• вибору стратегії релізів (canary, blue-green, dark launch);
• управління ризиками: запобігання деградацій, черг, дропу транзакцій, SLA-штрафів.

2) Основні поняття

Навантаження (Load): інтенсивність вхідних подій/операцій (RPS, TPS, events/sec), а також споживання CPU/RAM/IO/NET.
Ємність (Capacity): стійко досяжна продуктивність при заданих SLO і вартості.
Ризик: ймовірність × вплив небажаної події (SLA-провал, інцидент, перевитрата).
Ранні індикатори: метрики, що ростуть до інциденту (latency p95/p99, queue depth, GC pauses, error rate, saturation).
Запас міцності (Headroom): відношення доступної ємності до поточного навантаження.

3) Джерела даних і метрики

Джерела: логи та метрики (Prometheus/OTel), трасування, бізнес-івенти (Kafka), CDN/WAF/ALB логи, марктех-дані (кампанії), календарі подій, білінг/кістки (FinOps), фічефлаги/релізи, черги (Kafka/Rabbit), БД/кеші.

• Трафік: RPS/TPS, активні користувачі (DAU/MAU), сесії, конверсія кроків.
• Продуктивність: latency p50/p95/p99, throughput, ошибки (4xx/5xx), timeouts, retries.
• Ресурси: CPU/LoadAvg, RAM/GC, disk IOps/lat, network bw, connection pool usage.
• Черги: backlog, lag, consumer lag, time-in-queue.
• БД: QPS, lock waits, slow queries, replication lag.
• Кеші: hit ratio, eviction rate, hot keys.
• Бізнес-рівень: депозити/ставки за хвилину, платіжні відмови, KYC/AML черга.
• Надійність: SLI/SLO, error budget burn rate (1h/6h/24h).

4) Базові моделі прогнозування

1. Детерміновані та календарні: регресія за відомими драйверами (дата/час, матчі, турніри, маркет-пули, гео, акційні пуши).
2. Статистичні: сезонність/тренд (ARIMA/ETS), регресія зі святами, Prophet-подібні підходи.
3. ML/енсембли: градієнтний бустинг/Random Forest/XGBoost/LightGBM; додаємо фічі: погода, курс валют, новини спорту, конкуруючі івенти.
4. Змішані: статистика для базової сезонності + ML для екзогенних факторів (кампанії, релізи).
5. Квоти/квантилі: прогноз не тільки середнього, але і p90/p95 для планування headroom.

Виходи моделі: прогноз RPS/TPS і розподілу латентності/помилок на горизонтах T + 1h/T + 24h/T + 7d/T + 30d з довірчими інтервалами.

5) Черги та межі: міні-теорія

Закон Літтла: L = λ × W (середня кількість в системі = інтенсивність × середній час).
Вузькі місця: БД/кеш/шина/пул з'єднань/ліміти API провайдерів.
Saturation: при завантаженні> 70-80% латентність зростає нелінійно.
Backpressure: захист споживачів від перевантаження (ліміти, черги, shed-політики, деградація фіч).

6) Планування ємності (Capacity Planning)

Метод «від SLO»: необхідна p99-латентність і допустимий error rate → який throughput витримується при headroom N%.
Метод «від сценаріїв»: «Матч ЛЧ», «Чорна п'ятниця», «Масштабний турнір» → верхні квантилі трафіку + відмова одного AZ/вузла.
Метод «cost-aware»: вибираємо конфігурації по $/RPS, враховуючи знижки, резервування, spot/підписки, autoscaling.

Артефакти: Capacity Model per сервіс, ліміти і квоти (API, БД, черги), таблиця «вузьке місце → дія» (шардування, кешування, репліка, CQRS, async).

7) Управління ризиками

Реєстр ризиків: ідентифікатор, опис, ймовірність, вплив (фінанси/SLA/регуляторика), власники, плани профілактики/реакції.
Категорії: навантажувальні (перевантаження), інфраструктурні (AZ/region fail), залежностей (платіжні провайдери), релізні (регрес), продуктові (кампанія злетіла сильніше очікувань), комплаєнс (ліміти/регулятор).
Матриця: Heatmap (Low/Medium/High × Impact).
KRI (Key Risk Indicators): глибина черг, зростання p99, падіння hit-ratio, burn rate> 2 ×, помилки провайдерів.

8) Раннє попередження та алертинг

Early-warning SLIs: зростання p95, зменшення кеш-хітів, зростання tail latency, зростання retry/timeout, збільшення consumer lag.
Burn-rate алерти по бюджету помилок: швидкі (1h) і повільні (6-24h) вікна.
Порогові та аномалія-базовані алерти: базові пороги + моделі аномалій (IQR, STL, потокові детектори).
Агрегація сигналів: кореляція подій релізів/фічефлагів/кампаній з деградаціями.

9) Сценарний аналіз і «what-if»

«Якщо приріст трафіку + 60% за 10 хвилин?»

«Якщо CDN/WAF ріже 5% легітимного трафіку?»

«Якщо платіжний провайдер втрачає 30% авторизацій?»

Для кожного сценарію: очікувані метрики, вузькі місця, кроки деградації (toggle off не-критичних фіч), ручний/авто-скейл, перемикання провайдерів.

10) Тестування та верифікація прогнозів

Навантажувальні тести: синтетичний трафік (k6/JMeter/Locust), профілі «реальний мікс».
Game Days/Chaos: відключення AZ, деградація БД, вичерпання пулу.
Shadow/Dark: трафік «в тінь» нового шляху без впливу на прод.
Ретроспектива точності: MAPE/SMAPE/RMSE + post-mortem "де помилилися? ”.

11) Процеси і ролі

• Responsible: SRE/Platform/DS-аналітики.
• Accountable: Head of Ops/SRE.
• Consulted: Dev Leads, Marketing, Finance (FinOps).
• Informed: Support/Compliance/Business.
• Каденс: щотижневі апдейти прогнозів, щомісячний перегляд SLO/Capacity, передівентні вар-руми.

12) Інструменти та стек

Дані: Kafka, ClickHouse/BigQuery, Lake/DWH, dbt.
Моніторинг: Prometheus, Grafana, Tempo/Jaeger, Loki/ELK, OTel.
ML/Прогнози: Airflow/Argo, feature store, моделі ARIMA/ETS/GBM, сервіс прогнозів (gRPC/REST).
Тести: k6/JMeter/Locust, Fault-injection/Chaos Mesh.
Управління: Feature Flags, Autoscaling (HPA/KEDA), Policy-as-Code.
FinOps: cost explorer, showback/chargeback, $/RPS дашборди.

13) Практична методика впровадження (roadmap)

1. Інвентаризація метрик і залежностей → карта критичних шляхів (депозит, ставка, висновок).
2. SLO/SLI і бюджети помилок → цільові p95/p99, error-rates, burn-алерти.
3. Збір і очищення даних → єдиний шар подій/метрик, дедуплікація, запізнення.
4. Базовий прогноз сезонності → денні/тижневі патерни, свята/матчі.
5. Розширення драйверами → маркет-кампанії, релізи, гео, платіжні вікна.
6. Capacity-моделі по сервісах → headroom, ліміти, вузькі місця, план оптимізацій.
7. Сценарні «what-if» і таблиця деградацій (kill-switches, read-only, grace).
8. Верифікація через тести/тіні → коригування моделей і порогів.
9. Операційна рутина → щотижневі прогнози, попередні рев'ю, пост-івентні ретро.
10. Автоматизація → автоскейл за прогнозом, автопереключення провайдерів, авто-фічефлаги.

14) Антипатерни

Прогноз «тільки по середньому» без хвостів p95/p99.
Ігнор черг і пулів - проблеми спливають в пік.
«Вручну на око» без валідації і метрик точності.
Немає зв'язку з витратами → надмірне масштабування.
Відсутність плану деградації і фічефлагів.

15) Дашборди та звітність

Exec-дашборд: прогноз RPS/TPS (p50/p90/p95), headroom, ризик-теплокарта, burn-rate.
Тех-дашборд: p95/p99 latency по сервісах, черги/lag, hit-ratio, пул з'єднань, БД/кеш, ліміти зовнішніх API.
Фінансовий: $/RPS, прогноз витрат, ефект оптимізацій.
Точність прогнозів: фактичне vs прогноз, помилка по періодах/гео/каналах.

16) Шаблони артефактів

Risk Register: ID, ризик, ймовірність/вплив, власник, KRI, план превенції, план реакції.
Capacity Sheet: сервіс, поточний throughput, ліміт, вузьке місце, headroom, необхідне розширення, ЕТА/вартість.
What-If Cards: сценарій, вхідні фактори, очікувані метрики, дії, критерій завершення.
Playbook Degrade: список фіч для відключення, рівні QoS, маршрути в кеш/статик, ліміти retry/timeout.

17) Ключові KPI функції

Виконання SLO (% періодів в цілі), час реакції на ранні індикатори, точність прогнозів (MAPE/SMAPE), кількість інцидентів через перевантаження, частка автоматичних масштабувань, економія $/RPS без деградації SLO.

Підсумок

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