KPI інфраструктури та аптайм

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

KPI інфраструктури перетворюють «почуття» про стабільність у вимірювані цілі, керують ризиком і фокусом робіт. Правильні метрики пов'язують технічні SLI з бізнес-результатами (конверсія, Time-to-Wallet, LTV) і дозволяють планувати розвиток, навантаження і частку інновацій vs надійності.

Базові поняття: SLI, SLO, SLA і бюджет помилок

SLI (Service Level Indicator) - вимірюваний показник якості: частка успішних запитів, p95 latency, аптайм за інтервал.
SLO (Service Level Objective) - мета по SLI (наприклад, "успіх ≥ 99. 9% за 30 днів").
SLA (Agreement) - зовнішня обіцянка з неустойками/кредитами. Завжди похідне від SLO, але не дорівнює йому.
Бюджет помилок ='1 − SLO'. Це максимально допустима частка «неуспіху» за вікно вимірювання. Використовується для прийняття рішень про ризикові релізи та експерименти.

• SLO доступності 99. 95% за 30 днів → бюджет помилок 0. 05% ≈ 21. 6 хвилин «неуспіху» в календарному місяці.

Чотири «золотих» сигналу і додаткові

1. Латентність (p50/p90/p95/p99, tail важливіше середнього).
2. Помилки (5xx/timeout/бізнес-помилки).
3. Трафік/пропускна (RPS/QPS, MBps).
4. Насичення (CPU/RAM/IO/FD/підключення/GC/квоти).
Додатково: холодний старт, черги/беклог, час деплоя, SLO-комплаєнс.

Модель SLI для різних типів сервісів

HTTP/API

Доступність: '(успішні 2xx/3xx − логічні помилки )/( всі запити)'

Латентність: 'p95'для успішних запитів; мета по «гарячих» маршрутах.
Якість: частка запитів з'audience/scope'коректними (без authZ-помилок).

Черги/асинхрон

Час обробки повідомлення: p95 end-to-end ≤ N сек.
Backlog: медіана <X, хвіст p99 <Y.
Помилка доставки: ≤ Z ppm.

БД/кеш

Латентність операцій: p95 get/put/commit.
Насичення: connection pool usage, hit-ratio кэша.
Помилки: timeouts, deadlocks, eviction storms.

CDN/статик

Hit Ratio: ≥ цільового рівня; деградація → зростання навантаження на origin.
Доступність POP: Anycast-розкладка, відмови компенсуються сусідами.

Платежі (бізнес-SLI)

Time-to-Wallet p95, успішність депозиту/виведення%, rate відмов PSP.

Розрахунок доступності та «аптайма»

Доступність сервісу ='успішні запити/всі запити'( переважно, а не «хвилини аптайма»).
Альтернатива для інфраструктурних вузлів: 'час в стані «зелений »/час вікна'.
Календарне вікно: 28-31 день, ковзне вікно: останні 30/90 днів.
Робочі години/критичні вікна: для backoffice може вважатися аптайм за графіком (наприклад, 08:00–22:00 місцевого часу).

• 'Availability (A) ≈ Av (B) × Av (C) × Av (A'B, C)'- важливо закладати SLO на кордонах.

Приклад SLO-набору (зразок)

API Gateway: доступність ≥ 99. 95 %/30д; p95 latency ≤ 120 мс; помилка ≤ 0. 2%.
Checkout/Payments: успіх депозиту ≥ 98. 5 %/30д; Time-to-Wallet p95 ≤ 90 с; PSP-timeouts ≤ 0. 3%.
База даних: p95 read ≤ 10 мс; p95 write ≤ 25 мс; replica lag p95 ≤ 150 мс.
Кеш: hit ratio ≥ 85%; eviction storms = 0/30д.
Виплати: p95 обробка ≤ 5 хв; фрод-фолс-позитиви ≤ 0. 3%.

Бюджет помилок і управління змінами

Якщо бюджет помилок вичерпаний на 50% + раніше середини вікна - вводиться «заморожування» фіч/релізів, фокус на стабілізації.
Якщо бюджет витрачається повільно - можна прискорювати експерименти/канарки.
Споживання бюджету пов'язуйте з конкретними релізами/інцидентами через'release _ id'.

Алертінг: як не «дзвонити вночі» даремно

Алерти тільки по SLO-деградації і життєво важливим симптомам, а не по кожній метриці.
Multi-window, multi-burn rate: коротке вікно (5-15 хв) + довге (1-6 год).
Приклад: «Burn rate 14 × за 5 хв І 6 × за 1 годину» → сторінка on-call.
Тихий годинник для не-P1 сигналів; маршрутизація відповідальності (ownership).

Дашборди та практики візуалізації

SLO-панель: комплаєнс по сервісах, залишився бюджет, карти залежностей.
Latency-панель: p50/p90/p95/p99, розкладання по маршрутах/тенантам/країнам/ASN.
Error-панель: коди/причини, кореляція з релізами/фічфлагами.
Capacity-панель: зріз CPU/RAM/IO/нетворк/FD/коннекти, тренди і прогнози.
Бізнес-панель: конверсія, Time-to-Wallet, депозити/висновки, вплив захистів (WAF/антибот).

Інциденти, MTTR і постмортеми

• MTTD (виявлення), MTTA (аккепт), MTTR/MTTC (відновлення/стримування),% інцидентів без RCA вчасно.
• Плейбуки: хто ескалує, як включити фічфлаги/блоки, як відкотити реліз, комунікація з бізнесом.
• Постмортем (blameless): факти, лінія часу, першопричини (тих/процеси), дії: негайні/довготривалі, тести регресії, вплив на SLO.

Продуктивність, насичення і деградація

Headroom: цільовий запас ресурсів (наприклад, CPU <70% p95, RAM <75% p95).
Hot paths: профілювання критичних маршрутів;'p99'важливіше середнього.
Degradation modes: кеш-тільки, read-only, drop-шліфування неважливих запитів, «обмеження ставок «/квоти.

Формули та приклади розрахунків

1) Доступність за запитами

availability = (total_requests - error_requests) / total_requests

де'error _ requests'= 5xx + timeouts + бізнес-помилки (налаштовується).

2) Бюджет помилок (хвилини)

error_budget_minutes = window_minutes (1 - SLO)

Приклад: 30 днів (43 200 хв), SLO 99. 95% → 21. 6 хв.

3) Burn rate

burn_rate = observed_error_ratio / (1 - SLO)

Якщо SLO 99. 9% (бюджет 0. 1%), а помилка 1% → burn_rate = 10 ×.

4) Складова доступність

A_total ≈ A_gw × A_auth × A_db × A_psp

Невеликі падіння мультиплікативно б'ють по загальному A.

Політики вимірювання та винятків

Позапланові вікна (інциденти) - враховуються.
Планові вікна обслуговування - враховуються тільки якщо SLA так прописаний; для SLO часто не віднімаються (або позначаються окремо як'planned _ downtime').
Синтетика vs реальні користувачі: корисно мати обидва канали (RUM + синтетичні перевірки).

Приклади артефактів

KQL/PromQL (ідеї)

promql sum(rate(http_requests_total{status=~"5..    timeout"}[5m]))
/
sum(rate(http_requests_total[5m]))

promql histogram_quantile(0. 95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, route))

promql
(
sum(rate(errors_total[5m])) / sum(rate(requests_total[5m]))
) / (1 - 0. 999)

SQL (бізнес-SLI по платежах)

sql
SELECT date_trunc('minute', finished_at) AS ts,
100. 0 sum((status='SUCCESS')::int)::float / count() AS payment_success_pct,
percentile_cont(0. 95) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (finished_at - started_at))) AS ttw_p95_sec
FROM payments
WHERE finished_at > now() - interval '30 days'
GROUP BY 1 ORDER BY 1;

Управління залежностями та каскадами

Контракти SLO між командами: gateway↔auth↔wallet↔PSP.
Degradation policies: при падінні залежності сервіс переходить у «спрощений режим».
Feature flags: відключення не-критичних функцій, «сірий випуск» для зниження хвостів latency.

Capacity Planning і прогнози

Щомес. прогноз RPS/MBps щодо трендів і подій (турніри, матчі, акції).
Load testing по «золотих шляхах», окремі тести для PSP/виплат.
Запас в піку: цільовий коефіцієнт 1. 3×–2. 0 × від очікуваного навантаження.

Чек-лист впровадження SLO/KPI

1. Визначити критичні призначені для користувача шляхи і домовитися про SLI «з точки зору клієнта».
2. Вибрати цілі SLO і вікно (30/90 днів); порахувати бюджет помилок.
3. Вбудувати збір метрик в шлюзи/сервіси, нормалізувати коди/причини.
4. Налаштувати burn-rate алерти (коротке + довге вікно), маршрутизацію і on-call.
5. Візуалізувати SLO-комплаєнс, пов'язувати з релізами/фічфлагами.
6. Завести політику «бюджет проти змін» і процес заморозки.
7. Ретроспективи і RCA по кожному перевищенню, тести регресії.
8. Щоквартально ревізувати SLO по фактичному використанню бюджету і бізнес-цілям.

Типові помилки

Вимірюють «аптайм по пінгу», ігноруючи помилки додатків.
SLO виставлені «про запас» (99. 999%), але недосяжні і нічого не вирішують.
Алерти за низькорівневими метриками замість призначених для користувача симптомів.
Немає карти залежностей → незрозуміло, де горить.
Немає зв'язку SLO з релізами → незрозуміло, хто «з'їв» бюджет.
Ігнор хвостів p99 → хороші середні, але поганий UX VIP-користувачів.

Специфіка для iGaming/фінтех

Піки за розкладом: матчі/івенти/акції - заздалегідь підвищувати capacity, прогрівати кеш/CDN, включати особливі профілі лімітів.
Бізнес-SLI: Time-to-Wallet, успішність депозиту/виведення, «швидкість виплати» p95; в корені дашбордів.
PSP/партнери: окремі SLO/дашборди по провайдерам, автоматичне перемикання маршрутів.
Антибот/антифрод: не повинно виїдати бюджет помилок - відокремлюйте «правомірні блоки» від «технічних помилок».
Регуляторика: зберігання журналів, відтворюваність розрахунків SLO/SLA, звіти по інцидентах.

FAQ

Чи потрібно віднімати планові роботи з SLO?
Зазвичай ні: SLO відображає пережитий користувачем досвід. Для SLA можна обумовити винятки.

Чому p95, а не середнє?
Середнє маскує хвости; UX визначають хвости (p95/p99).

Чи можна один SLO на весь продукт?
Потрібно дерево SLO: агрегатний по продукту і дочірні по критичних шляхах/компонентах.

Підсумок

Сильна система KPI інфраструктури - це призначені для користувача SLI, реалістичні SLO, бюджет помилок як важіль управління змінами, розумний алертинг і дисципліна інцидентів і RCA. Зв'яжіть технічні показники з бізнес-метриками, автоматизуйте збір і візуалізацію - і інфраструктура стане передбачуваною, а аптайм підконтрольним навіть в пікових сценаріях.