SLO/SLA та метрики

SLO/SLA та метрики

1) Терміни та ієрархія

SLI (Service Level Indicator) - вимірний показник «як бачить нас користувач»: частка успішних запитів, p95 латентності, свіжість даних, частка успішно оброблених батчів і т.п.
SLO (Service Level Objective) - цільове значення SLI на інтервалі спостереження (28/30/90 днів). Приклад: «99. 9% запитів/pay завершуються ≤ 400 мс".
Error budget — 1 − SLO. При SLO 99. 9% бюджет помилок = 0. 1% часу/запитів.
SLA (Agreement) - юридично значущий рівень обслуговування: включає SLO, вимірювання, виключення, компенсації/штрафи.

2) Принципи проектування

Симптоми> внутрішні метрики. SLI повинні відображати реальний досвід користувача.
Мала кількість ключових SLI. На сервіс - 2-5 основних: успішність, латентність, пропускна здатність/свіжість, коректність.
Охоплення критичних шляхів. Для кожного бізнес-сценарію (checkout, login, webhook, ETL-завантаження) - свій набір SLI/SLO.
Сувора семантика «успіху». Не «код 200», а «користувач отримав відповідь вчасно і результат валіден».
Розділення зовнішніх і внутрішніх SLO. Внутрішні - суворіше; зовнішній SLA ≤ на 1-2 дев'ятах нижче.

3) Каталог SLI (референс)

3. 1 API/онлайн-сервіси

Успішність: `SLI_success = 1 − (5xx + timeout + business_error) / all_requests`

Латентність: p95/p99'http _ server _ duration _ seconds'за маршрутами/методами/орендарями

Пропускна здатність: 'RPS '/ліміти/квоти

Коректність: частка валідних відповідей (сигнатури, схеми, інваріанти)

3. 2 Вебхуки/асинхронні доставки

Доставка: частка подій, підтверджених в T секунд і ≤ N ретраїв

Замовники: частка передплатників без тривалої затримки (пер-тенант)

3. 3 Дані/ETL/DWH

Свіжість (freshness): `now − last_successful_ingest_ts`

Повнота: `ingested_rows / expected_rows`

Коректність: частка записів, що пройшли перевірки якості

Пайплайни: частка джоб завершених до дедлайну

3. 4 Мобільні/клієнтські SDK

Клієнтський успіх: частка сесій без фатальних помилок

Латентність round-trip: p95 від запиту до рендера

Кеш-хіти: частка обслужених з кешу (як симптом перформансу)

4) Формули і приклади цілей

• `SLI_req_avail = 1 − (failed_requests / total_requests)`
• `SLO_req_avail = 99. 95%'на 30 днів → error budget = 0. 05% запитів.

• `uptime = (obs_window − downtime) / obs_window`

• ' SLO _ latency = p95 (route = »/pay») ≤ 400 ms'на 7-денних зрізах, з виключенням кеш-прогрівів (1%)

• ' SLO _ freshness (dataset =» orders») ≤ 10 min'p99 за 24 години.

5) Error budget і управління змінами

Бюджет (B): `B = 1 − SLO`.
Витрати бюджету (burn): відношення фактичних помилок до допустимих.

• Перевитрата (burn> 1) → фічфриз, фокус на надійність.
• При burn rate> X в короткому вікні - інцидент і крап. заходи.
• Планування: частка спринту на надійність корелює з burn за минулий період.

6) Алертінг: burn rate і багатовіконні правила

Ідея: ловимо швидкі витоки і повільний дрейф.

• Критичний: «2% бюджету за 1 годину» (швидка пожежа).
• Попередження: «5% бюджету за 6 годин» (повзуча деградація).

• Коротке вікно (хвилина-година) для швидких інцидентів.
• Довге вікно (6-24 години) для трендів.
• Латентність: алерт по p99> порогу ≥5 хв, з придушенням флапінгу і зв'язок з екземпларами трас.

error_ratio_5m = errors[5m] / requests[5m]
error_ratio_1h = errors[1h] / requests[1h]
burn_5m     = error_ratio_5m / error_budget_fraction burn_1h     = error_ratio_1h / error_budget_fraction alert_critical if burn_1h > 14 and burn_5m > 14 alert_warning  if burn_6h > 6 and burn_30m > 6

7) Багатоарендність (multi-tenant) і сегментація

SLI/SLO рахуються за орендарями/планами/регіонами, інакше медіана «замаже» провали.
Мінімальне число подій для статистичної значущості (guard-rails).
SLA може відрізнятися за тарифами (наприклад, "Pro 99. 9%, Free 99. 5%»).

8) Зв'язок зі спостережуваністю і трасуваннями

Метрики SLI - з гістограм/лічильників з exemplars → перехід в «погані» трейси.
Логи - джерело причин: таймаути, коди бізнес-помилок, ліміти.
Для даних - зв'язка з lineage: «яка джоба затримала метрику свіжості».

9) Контракти та SLA

• Визначення SLI/методу вимірювання/вікна.
• Винятки (планові роботи, форс-мажор).
• Процедура інцидентів і комунікацій (статус-сторінка, RFO/RCA).
• Компенсації (service credits) і порядок запиту.
• Юрисдикція, період дії, умови перегляду.

• Ніколи не обіцяйте публічно SLO суворіше, ніж дозволяє архітектура та операційні практики.
• Відокремлюйте внутрішні SLO і зовнішні SLA.

10) Вартість і пріоритизація

Ціна дев'яток зростає не лінійно. «99. 9% → 99. 99%" = інший клас архітектури (N + 1, мультизону, актив-актив).
Ставте SLO на найбільш цінні призначені для користувача дії.
Контролюйте вартість телеметрії: downsampling, квоти, репліка та зберігання за класами.

11) Процедури та звітність

Щотижневі звіти: виконання SLO по сервісах/орендарях, витрата бюджету, топ-причини, плани поліпшень.
Постінцидентні RCA: пов'язуємо зі шматками бюджету; ставимо завдання на усунення корінних причин.
Фічфріз: критерії включення/зняття.

12) Шаблони (для швидкого старту)

12. 1 Картка SLO (приклад)

Service: Checkout API
SLI:
success: 1 - (5xx+timeouts+biz_failures)/all latency_p95: p95(http_server_duration_seconds{route="/pay"})
SLO:
success: 99. 95% / 30d latency_p95: ≤ 400ms / 7d
Windows:
primary: 30d rolling secondary: 7d rolling
Burn Alerts:
critical: use 1h/5m > 14 warning: use 6h/30m > 6
Owner: Team Checkout
Tenancy: per-tenant (≥ 1k req/day threshold)
Dashboards: RED + trace exemplars

12. 2 Таблиця «зрілості SLO»

13) Приклади правил (фрагменти)

promql
Error rate (5xx + timeout) for the sum (rate (http_requests_total{route="/pay",code=~"5. route.    599"}[5m]))
/ sum(rate(http_requests_total{route="/pay"}[5m]))

p99 histogram_quantile latency (0. 99, sum(rate(http_server_duration_seconds_bucket{route="/pay"}[5m])) by (le))

promql error_budget_fraction = 0. 001 for 99. 9%
(err_rate_5m / 0. 001 > 14) and (err_rate_1h / 0. 001 > 14) # critical
(err_rate_30m / 0. 001 > 6) and (err_rate_6h / 0. 001 > 6)  # warning

promql
Data order lag (minutes)
(max(time()) - max(last_ingest_ts_seconds{dataset="orders"})) / 60

14) SLO для даних і ML (особливості)

Наскрізні SLO даних: свіжість p99, повнота p99, час «перепроробки» після збою.
Контракти даних: очікувані схеми, обсяги, дедлайни; порушення → інцидент даних.
ML: SLO на латентність інференса, SLA на доступність фіч-стора, моніторинг дрейфу (якість моделі - окрема тема, поза SLA).

15) Інтеграція з безпекою та приватністю

Логи SLI без PII/секретів; токенізація/маскування.
Аудит змін SLO/SLA та публікацій звітів у незмінних журналах.
Для регуляторних шляхів (платежі/PII) - окремі, більш суворі SLO.

16) Чек-листи

Перед запуском сервісу/фічі

• Визначено SLI «успіх/латентність/пропускна здатність/свіжість».
• Задані SLO і вікна; розраховано бюджет помилок.
• Налаштовані burn-rate алерти (коротке + довге).
• Дашборди RED + exemplars → траси; рунібуки інцидентів.
• Багатоарендні розрізи і пороги значущості.
• Процедура фічфризу і звітності.

Експлуатація

• Щотижневий звіт по SLO/burn, плани hardening.
• Переоцінка SLO при зміні архітектури/навантаження.
• Періодичні «інциденти-навчання» та оновлення рунібуків.
• Контроль вартості телеметрії та кількості SLI.

17) Runbook’и

Runbook: швидке зростання p99/pay

1. Алерт р99> поріг → відкрити дашборд → перейти по exemplar в трейс.
2. Знайти вузький CLIENT/SERVER-спан, порівняти регіони/версії.
3. Увімкнути деградацію (кеш/ліміт/фолбек), повідомити команду залежності.
4. Після стабілізації - RCA, завдання оптимізації, оновлення SLO-вимірів.

Runbook: витрата бюджету> 50% за тиждень

1. Заморозити фічі, підняти пріоритет надійності.
2. Кластеризація помилок: за маршрутами/орендарями/залежностями.
3. Викотити виправлення → підтвердити відновлення тренда.
4. Ретроспектива та коригування алертів/порогів.

18) FAQ

В: Скільки SLO потрібно?
ПРО: Мінімум на критичні призначені для користувача сценарії: успіх + латентність. Все інше - за потребою.

В: Що краще - доступність за часом або за запитами?
ПРО: За запитами - більш призначена для користувача метрика. За часом зручно для мережевих компонентів/інфри.

В: Чому p95, а не середнє?
ПРО: Середнє приховує хвіст; користувач відчуває p95/p99.

В: Як не «закрутити гайки» занадто сильно?
ПРО: Почніть з реалістичних цілей (історичні дані), потім посилюйте в міру зрілості.

• "Спостережуваність: логи, метрики, трасування"
• «Розподілені трасування»
• «Аудит і незмінні журнали»
• «Гарантії доставки вебхуків»
• «Шифрування In Transit/At Rest»
• «Походження даних (Lineage)»