SLA, SLO і KPI надійності

1) Терміни та відмінності

SLI (Service Level Indicator) - вимірюваний індикатор якості (наприклад, частка успішних запитів, p95 латентності).
SLO (Service Level Objective) - цільове значення SLI за вікно часу (наприклад, "успішність ≥ 99. 9% за 28 днів").
Помилка бюджету (Error Budget) - допустима частка невиконання SLO: `1 − SLO`.
SLA (Service Level Agreement) - контрактні зобов'язання зі штрафами/кредитами (зовнішні).
KPI надійності - операційні метрики процесу (MTTD/MTTA/MTTR/MTBF,% автоматичних мітігейтів, покриття алертами тощо).

💡 Правило: SLA ≤ SLO; зовнішній контракт не повинен бути суворішим внутрішньої мети сервісу.

2) Як вибирати SLI (на базі Golden Signals)

1. Latency - p95/p99 для ключових ендпоінтів.
2. Traffic - RPS/RPM/потік повідомлень.
3. Errors - частка 5хх/бізнес-помилок (наприклад, платіжні «decline з вини PSP» виключати).
4. Saturation - насичення ресурсів (CPU/RAM/IO/lag).

Критерії хорошого SLI:

Корелює з досвідом користувача (user-perceived).
Технічно доступний і стабільний у вимірюванні.
Контролюємо (можливі дії для поліпшення).
Низька вартість збору.

3) Формули і приклади

3. 1 Доступність (availability)


Availability = Успешные запросы / Все запросы
Error Budget (за период) = 1 − SLO

Приклад: SLO 99. 9% за 30 днів → бюджет помилок = 0. 1%, що еквівалентно 43 хв 12 сек недоступності.

3. 2 Латентність

SLO по латентності формулюємо як частку запитів, що вкладаються в поріг:


Latency SLI = доля запросов с duration ≤ T
SLO пример: 99% запросов ≤ 300 мс (rolling 28d)

3. 3 Платежі (бізнес-рівень)


Payment Success SLI = (успешные проводки — внешние отказы PSP) / все попытки

💡 Виключаємо «decline по карті клієнта» з відмов сервісу; включаємо тільки провини платформи.

4) Помилковий бюджет і burn-rate

Помилка бюджету - ваш «паливний бак» для інновацій (релізи, експерименти).

Burn-rate - швидкість споживання бюджету:

швидкий канал (детект за ~ 1 год),
повільний канал (тренд за ~ 6-12 год/24 год).

Порогові ідеї:

Якщо burn-rate> 14. 4 за 1 годину - SEV-1 (з'їмо денний бюджет за ~ 100 хв).
Якщо burn-rate> 6 за 6 годин - SEV-2 (швидка деградація).

5) Алертинг по SLO (multi-window, multi-burn)

Індикатор помилок: частка 5xx або порушень латентності.

Приклади PromQL (узагальнені):

promql
Доля ошибок за 5 минут sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

Быстрый burn (1m окно)
(
sum(rate(http_requests_total{status=~"5.."}[1m])) /
sum(rate(http_requests_total[1m]))
) / (1 - SLO) > 14.4

Медленный burn (30m окно)
(
sum(rate(http_requests_total{status=~"5.."}[30m])) /
sum(rate(http_requests_total[30m]))
) / (1 - SLO) > 2

Для SLO по латентності використовуйте процентильні гістограми:

promql p95 latency histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

6) Приклади SLI/SLO по доменах

6. 1 API-шлюз/Edge

SLI-Errors: частка відповідей 5xx <0. 1% (28d).
SLI-Latency: p95 ≤ 250 мс (день).
SLO: Availability ≥ 99. 95% (квартал).

6. 2 Платежі

SLI-Success: оплат успішних (виключаючи клієнтські відмови) ≥ 99. 8% (28d).
SLI-Latency: авторизація ≤ 2 секунди для 99% (день).
SLO: Time-to-Wallet p95 ≤ 3 хв (24h).

6. 3 Бази даних (PostgreSQL)

SLI-Lag: реплікаційний лаг p95 ≤ 1 сек (день).
SLI-Errors: частка помилок запитів ≤ 0. 05% (28d).
SLO: доступність кластера ≥ 99. 95%.

6. 4 Черги/Стрімінг (Kafka)

SLI-Lag: споживчий лаг p95 ≤ N повідомлень (година).
SLI-Durability: підтвердження запису ≥ 99. 99% (28d).
SLO: доступність брокерів ≥ 99. 9%.

7) KPI процесу надійності

MTTD (Mean Time To Detect)

MTTA (… To Acknowledge)

MTTR (… To Restore)

MTBF (… Between Failures)

% інцидентів з автоматичною мітигацією

Покриття SLO/алертами топ-шляхів трафіку (цільове ≥ 95%)

Частка релізів з канарним етапом

Споживання помилкового бюджету за командами/фічами

8) Як ставити SLO реалістично

1. Виміряйте поточну базову надійність (3-4 тижні).
2. Визначте «чутливі» користувацькі шляхи (логін, депозит, гра).
3. Врахуйте вартість кожного девіації (час, гроші, репутація).
4. Виберіть амбітну, але досяжну мету (поліпшення на 10-30% до базової).
5. Переглядайте щокварталу.

Анти-патерни:

Відразу «п'ять дев'яток» без обґрунтування.
SLO за метриками, не видимими користувачеві (наприклад, CPU без зв'язку з UX).
Занадто багато SLO → розпилення фокусу.

9) Звітність по SLO і бюджетам

Стандартний звіт (щотижня/щомісяця):

Виконання по кожному SLO: факт vs мета, тренди, confidence.
Зведення споживання помилок: скільки бюджету «спалено», ніж, ким (реліз/інцидент).
Топ-п'ять причин деградацій, CAPA-план і статус завдань.
Вплив на бізнес: конверсія, ND, утримання, LTV.

10) Зв'язок з релізною політикою

Бюджет помилок <50% → вільні релізи.
50-80% → «обережний режим»: тільки low-risk/канарські викладки.

💡 80% → заморожування релізів, фокус на стабілізації і боргу.

11) SLA (договірні) - шаблони пунктів

Зобов'язання доступності: наприклад, 99. 9 %/місяць.
Винятки (Force Majeure): DDoS поза розумного контролю, провайдери третіх сторін.
Вікно вимірювання та зона відповідальності: джерела метрик, метод розрахунку.
Кредити/штрафи: таблиця рівнів (наприклад, недоступність 60-120 хв → кредит X%).
Процедури ескалації та повідомлень: терміни, канали.
Дані та приватність: маскування, зберігання, Legal Hold.
План робіт із запобігання повторів (CAPA) у разі порушення.

💡 Зовнішній SLA повинен посилатися на конкретні, що перевіряються SLI і методику розрахунку.

12) Інструменти вимірювання

Пасивні метрики: Prometheus/Mimir/Thanos, експортери.
Логи: Loki/ELK для підрахунку успіхів/помилок на рівні бізнесу.
Синтетика: активні проби (логін/депозит/гра) по cron.
Трасування: Tempo/Jaeger для «вузьких місць» p99.
Оплата/фінанси: джерела ground truth для платіжного SLI.

13) Приклади запитів (шаблони)

Частка успішних API-запитів (виключаючи 4xx як клієнтські):

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

SLO-картка:

yaml slo:
name: "API Availability"
window: "28d"
target: 0.999 sli: "1 - 5xx%"
owner: "Platform SRE"
alerting:
fast_burn: {window: "1h", factor: 14.4}
slow_burn: {window: "6h", factor: 6}

Платіжний успіх (по бізнес-подіям в логах/стрімі):


success_rate = (count_over_time({app="payments"}     = "status=success"[5m]))
/ (count_over_time({app="payments"}     ~ "status=(success    fail)"[5m]))

💡 Уточніть фільтри, щоб виключати «decline по клієнту».

14) ФінОпс і надійність

Cost per 9: вартість додавання «дев'ятки» зростає експоненціально.
Крива вигод: оптимум там, де приріст виручки/зниження втрат ≥ вартість додаткових «9».
Портфель SLO: різні рівні для різних шляхів (критичні платежі «дорожче», звітність «дешевше»).

15) Якість SLO/алертів - чек-лист

SLI корелює з UX і бізнес-метриками.
Вікно і агрегування узгоджені (rolling 28d/квартал).
Алерти multi-window, без флапінгу, з рольовою маршрутизацією.
Документація: власник, формула, джерела, runbook.
Демо-панель SLO з помилковим бюджетом і burn-індикаторами.
Регулярний перегляд цілей (щоквартально).
Тести синтетики за ключовими сценаріями.

16) План впровадження (4 ітерації)

1. Тиждень 1: інвентаризація призначених для користувача шляхів, чернетки SLI, базові дашборди.
2. Тиждень 2: формалізація SLO, розрахунок бюджетів, алерти (fast/slow burn).
3. Тиждень 3: інтеграція з процесом інцидентів/релізів, freeze-правила.
4. Тиждень 4 +: договірні SLA, квартальні рев'ю, фінопс-модель «cost per 9».

17) Міні-FAQ

Чи потрібно мати один SLO на сервіс?
Краще 2-3 ключових (успіх + латентність) замість десятків другорядних.

Що робити, якщо бюджет вичерпано?
Заморожування релізів, фокус на стабілізації і CAPA, зняття експериментальних фіч.

Як уникнути конфлікту між швидкістю релізів і надійністю?
Плануйте релізи «по бюджету», впроваджуйте канарські викладки і feature-flags.

Підсумок

Надійність управляється не набором розрізнених метрик, а системою: SLI → SLO → помилка бюджету → burn-алертинг → процес інцидентів → CAPA → SLA. Стандартизуйте визначення, джерела даних і звітність, прив'яжіть цілі до користувацького досвіду і економіці, і регулярно переглядайте рівень «дев'яток» в залежності від реального ROI.

SLA, SLO і KPI надійності

MTTD (Mean Time To Detect)

MTTR (… To Restore)

% інцидентів з автоматичною мітигацією

Частка релізів з канарним етапом

Підсумок

Зв’яжіться з нами

Швидкий зв’язок

Відео скоро буде оновлено

Зараз ми дуже завантажені проєктами