Планування потужностей

1) Що таке планування потужностей і навіщо воно потрібне

Планування потужностей (capacity planning) - це систематичний процес оцінки і забезпечення ресурсів, необхідних для досягнення цільових SLO при мінімальній вартості. Мова не тільки про CPU/пам'яті, але і про пропускну здатність мереж, зберігання, БД/кешах, чергах/шині подій, зовнішніх провайдерах (платежі/КУС/антифрод), а також людських ресурсах (on-call, підтримка).

• Виконувати SLO/SLAs навіть в піках і деградаціях.
• Мінімізувати TCO і простий капіталу (overprovisioning).
• Скоротити ризик інцидентів від вичерпання ресурсів (saturation → р99/помилки).
• Забезпечити передбачуваність релізів і кампаній (маркетинг, турніри, топ-матчі).

2) Вхідні дані та джерела істини

Спостережуваність: RPS/конкаррентність, p50/p95/p99, error-rate, saturation (CPU, mem, disk IOPS, мережеві pps/mbps), довжини черг, rate лімітів.
Бізнес-події: календарі кампаній, сезонність (вечори/вихідні/мега-івенти), регіони/юрисдикції.
Техдолг/фічі: roadmap релізів, архітектурні зміни (наприклад, шифрування, нове логування).
Провайдери: квоти і throughput платіжних/КУС/поштових/антифрод сервісів.
Інциденти минулого: де вузьке місце (БД, кеш, L7-балансувальник, шина, CDN, диск).

3) Базові поняття та формули

Headroom - запас по ємності: 'headroom = (макс _ стійкий _ RPS − фактичний _ RPS )/макс _ стійкий _ RPS'.
Цільове значення в піку 20-40% (для критичних потоків).
Saturation - відношення зайнятого ресурсу до доступного (CPU%, пам'ять/GC, з'єднання, file descriptors, IOPS, глибина черги).
Throughput стійкий - швидкість, при якій p99 і error-rate виконують SLO тривало (не разовий сплеск).
Capacity Unit (CU) - нормована одиниця потужності для сервісу (наприклад, X RPS на один pod vCPU = 1, RAM = 2 GiB).
Системний ліміт - max без деградації: `N_pods × CU`. Важливо враховувати shared залежності (БД/кеш/шина).

4) Модель попиту: прогнозування

Статистичні ряди: тижнева/добова сезонність, свята, спортивні фінали, регіональні піки.
Когорти: по країнах, платіжних провайдерах, пристроях, VIP-сегментах.
Подієві дельти: вплив кампаній/гармат/релізів/SEO.
«Що якщо» (scenario planning): + 50% до трафіку в 19:00–22:00; випадання провайдера A → перерозподіл на B (+ 30% до латентності).
Real-time коригування: nowcasting за лід-метриками (пожвавлення сесій, черга на матч, кошики).

5) Модель пропозиції: де «ламається» ланцюжок

Конвеєр запиту: Edge/CDN → L7-балансувальник → додаток → кеш → БД → зовнішні API → черга/шина → обробники/ETL.

• Ємність (CU/інстанс), масштабованість (горизонт ./вертик.) , межі (коннекти, pps, IOPS), запізнювання.
• Політики відмови (rate limit, circuit breaker, деградація).
• SLO локальні та їх внесок у e2e-SLO.

6) Запас і бюджет помилок

Прив'язуємо headroom до error budget: менше бюджету → більше запасу.
Для критичних потоків (оплата/верифікація) - headroom вище, для другорядних - нижче.
Холодні/теплі резерви: активовані при піку/аварії.

7) Масштабування: тактика

HPA (за метриками навантаження): RPS, latency, довжина черги, призначені для користувача SLIs (better than CPU%).
VPA: коригування ресурсів подам (акуратніше з stateful і p99 GC).
KEDA/адаптери: масштабування за зовнішніми джерелами (Kafka lag, Redis list length, CloudQueue depth).
Warm pools/прогрів: заздалегідь підняті інстанси, щоб уникнути холодного старту.
Підхід «Load-as-Code»: політики автоскейлу/лімітів/таймаутів/ретраїв версіонуються і проходять review.

8) Черги, backpressure і управління хвостом

Мета - не допустити лавиноподібного росту p99.
Обмежуємо паралелізм і розмір черги, вводимо тимчасові вікна та ідемпотентність.
Hedging/Retry-budget: обмежувати загальний бюджет часу користувача і системи.
Graceful degradation: відключення другорядних фіч при перевантаженні.

9) БД, кеші та сховище

БД: ліміт конектів, журналювання/FSync, індекси, план запитів, replica lag, hot-keys/таблиці, max TPS для транзакцій.
Кеші: hit-ratio за сегментами, «шторм промахів» при релізі/інвалідції, розподіл ключів.
Сторадж: IOPS/throughput, затримки, компресія, TTL, очищення старих партій/снапшотів.
Схема міграцій: expand→migrate→contract без зупиняючих блокувань.

10) Потоки подій і ETL

Kafka/шина: пропускна здатність партій, lag, ISR, compaction, ліміти продюсерів/консьюмерів.
ETL/батчі: вікна запуску, бюджети часу виконання, вплив на прод-сторану (throttle I/O).
Ідемпотентність і exactly-once-like для критичних флоу (платежі/баланси).

11) Мережа і периметр

L4/L7 балансувальники: connection limits, syn backlog, TLS offload, session reuse.
CDN/Edge: пропускна, кеш-політика для зниження origin-навантаження.
Внутрішньомережеві ліміти: pps/mbps в VPC/підмережі, egress-вартість (FinOps).

12) Мультирегіон, DR і юрисдикції

Стратегії: active-active (GSLB/Anycast), active-passive (гарячий/теплий/холодний DR).
N + 1 за регіонами: витримати втрату AZ/регіону при збереженні SLO core-потоків.
Юридична локалізація: розділення трафіку/даних по країнах, різні ліміти і SLO на провайдерів.
Тести DR: регулярні game-days з реальним перенесенням навантаження.

13) Зовнішні провайдери: квоти та маршрути

Платежі/KYC/антифрод/пошта/SMS: квоти TPS, burst, денні ліміти.
Мульти-провайдер: маршрутизація по латентності/успіху, SLO per провайдер, авто-фейловер.
Контракти SLA: відповідність e2e-SLO, канали ескалації, статус-вебхуки.

14) FinOps: вартість та ефективність

TCO: compute + storage + network egress + ліцензії/провайдери + чергування.
Unit Economics: вартість 1k запитів/1 депозитної операції/1 KYC.
Оптимізація: right-sizing, spot/префіксні знижки, кеш-хитрейт, дедуп логів/трасувань, холодні рівні зберігання.
Перенесення навантаження в часі: не критичні батчі в «нічні» вікна і дешеві регіони.

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

• Поточне навантаження vs стійкий throughput по ланках.
• Headroom по сервісах і регіонах; прогноз на 24/72 години.
• KPI FinOps: $/1k запитів, $/депозит.

• Топ-вузькі місця (p99, saturation, lag), запас по DR.

• Успішність/латентність і ліміти провайдерів; частка трафіку за маршрутами.

• План апгрейдів/індексів/оптимізацій, очікувана економія/зростання ємності.

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

RACI: Платформна (інфра/кластера/балансувальники), БД/Дані (індекси, реплікації), Сервісні команди (профілювання/кеш), SRE (SLO, альберти), Sec/Compliance (крипто/журнали), Фінанси (бюджет).
Ритм: щотижневі capacity-review (дорожня карта, прогноз, ризики), щомісячні FinOps-зведення, щоквартальні DR-тести.
Change Management: великі кампанії/релізи проходять capacity-gate (чек-лист нижче).

17) Чек-лист випуску та кампаній (capacity-gate)

• Прогноз навантаження на пік і «+ x% аварійний хвіст».
• Доступний headroom для core-потоків (платежі/КУС/логін).
• Провайдерам підтверджені квоти; альтернативні маршрути активні.
• HPA/KEDA пороги і warm-pool налаштовані.
• Черги/ліміти і деградації перевірені (плейбуки готові).
• Канарські частки і авто-відкат включені.
• Дашборди/алерти (burn-rate, saturation, p99) перевірені.
• План DR і контакти ескалацій актуальні.

18) Анти-патерни

«CPU <70% - все добре»: ігнорування меж залежностей (коннекти БД, IOPS, черги).
Централізований «чорний ящик» без метрик per-ланка - неможливо зрозуміти, де ліміт.
Відсутність кеш-стратегії - промахи при релізі вбивають origin.
Хардкод лімітів ретраїв без бюджетів - шторм запитів.
«Один провайдер платежів» - точка відмови на піку.
Ігнорування теплих резервів - холодний старт як причина інцидентів.
Немає періодичних DR-тестів - план не працює, коли він потрібен.

19) Міні-калькуляції (приклад)

Сервіс X: стійко 350 RPS на pod (vCPU = 1, RAM = 2 GiB). Мета - 5 000 RPS, headroom 25%.
Потрібна потужність ='5000/0. 75 = 6667 RPS`.
Подов ='ceil (6667/350) = 20'. Плюс warm-pool 15% → ще 3 pod.
БД: ліміт 12k TPS, поточний кредит 9k TPS, прогноз пік 10. 5k TPS → запас 1. 5k (14%). Потрібно: індекси/шардинг/репліки або кешування для зниження до 8. 5k.
Провайдер A (KYC): квота 120 rps, пік 95 rps, кампанія + 40% → 133 rps> квоти → маршрутизація 70% A/30% B.

20) Шаблон впровадження capacity planning

1. Описати e2e-шлях і вузькі місця.
2. Ввести CU і виміряти стійкий throughput кожного шару.
3. Налаштувати метрики saturation і p99 на всіх ланках.
4. Сформувати календар подій/кампаній/релізів.
5. Побудувати прогноз по когортах і сценарії «що якщо».
6. Закріпити headroom per-потік і per-регіон (прив'язка до error budget).
7. Налаштувати HPA/VPA/KEDA + warm-pools, ліміти/ретраї/черги.
8. Перевірити провайдерські квоти, включити мульти-маршрути.
9. Зібрати дашборди і щотижневий ритм capacity-review.
10. Щоквартально - DR-навчання і перегляд моделі.

21) Підсумок

Планування потужностей - це керована зв'язка прогнозів, архітектурних обмежень і вартості, а не «додати CPU». Коли кожен шар e2e-шляху має виміряну ємність, а headroom і стратегії деградації пов'язані з SLO і error budget, то пікові навантаження, кампанії і аварії перестають бути сюрпризом. Такий підхід знижує ризик інцидентів, стабілізує бізнес-метрики і оптимізує витрати.