Моніторинг SLA і SLO

1) Терміни і ролі

SLA (Service Level Agreement) - зовнішнє договірне зобов'язання перед клієнтом (штрафні застереження, кредити).
SLO (Service Level Objective) - цільовий внутрішній рівень сервісу, що підтримує виконання SLA.
SLI (Service Level Indicator) - вимірюваний індикатор, на основі якого оцінюються SLO/SLA.
Error Budget - допустима частка «недоступності/помилок» за період: `Budget = 1 − SLO`.
Scope: вимірюється очима користувача (end-to-end). У мікросервісах - і на рівні компонента, і наскрізного шляху.

2) Вибір SLI: що саме вимірювати

Критерій - кореляція з користувацьким досвідом і бізнес-цінністю.

• Доступність: частка успішних запитів.'SLI = успішні/всі'.
• Латентність: частка запитів швидше порогу T.'SLI = P (latency ≤ T)'.
• Якість: частка коректних відповідей (без 5хх/функц. помилок).
• Актуальність даних: затримка реплікації/ETL ≤ X хвилин.
• Результативність бізнес-процесу: частка успішних платежів/реєстрацій.

Анти-патерни: вважати тільки 200-ки як «успіх», ігноруючи бізнес-помилки; вимірювати в тестовій мережі замість користувацької.

3) Формули і вікна спостереження

• `Availability = (OK_requests / All_requests) × 100%`.

• 'P95 ≤ T'→ краще формулювати як частку: 'SLI =% запитів ≤ T'.
• Приклад: «99% запитів пошуку ≤ 300 мс за 28 днів».
• Ковзне вікно: 28 або 30 днів (баланс чутливості і стабільності). Для інцидентів - доп. вікна: 1 год, 6 год, 24 год.

4) Error Budget і управління швидкістю змін

Розрахунок: при'SLO = 99. 9%'бюджет ='0. 1%'помилок/недоступності за період.

• Бюджет> 50%: релізи та експерименти за планом.
• Бюджет 10-50%: тільки низькоризикові релізи, посилення канарок.
• Бюджет <10%: заморожування релізів, коренева причина, поліпшення надійності.
• Зв'язок з прогресивними релізами: canary/feature-flags «їдять» бюджет дозовано, з авто-відкатом при деградації.

5) Алерт-політики: від порогів до burn rate

Чому не «даупал SLO - підніми алерт»: занадто пізно. Потрібна проактивність.

• 'BR = (спостережувана помилка за коротке вікно/допустима помилка за це вікно)'.
• Якщо «BR> 1» - бюджет витрачається швидше норми.

• Швидкий алерт (шум чутливий, ловить катастрофи): вікно 5-10 хв, поріг BR 14-20 ×.
• Повільний алерт (ловить повзучі деградації): вікно 1-6 год, поріг BR 2-4 ×.
• Умови комбінувати: спрацював швидкий або повільний - пейджинг on-call.
• Рівні: пейджер для користувацьких SLO, тікети/повідомлення для сірих деградацій внутрішніх SLI.

6) Спостережуваність і джерела істини

Логи - діагностика причин.
Метрики - числові SLI (успіх/помилка, перцентилі латентності, частки, лічильники).
Трейси - наскрізні шляхи, локалізація «гарячих» сегментів.
Синтетика - активні проби з периферії (region-aware).
Реальні події - RUM/телеметрія клієнтів, бізнес-метрики (конверсія, успішні платежі).

Вимоги: єдина картина в дашбордах релізів та інцидентів, анотації «версія/канарка/прапор».

7) Проектування SLO: покроковий шаблон

1. Опишіть критичний шлях (наприклад, «депозит карткою»).
2. Визначте SLI: успіх/помилка, поріг латентності, повнота.
3. Узгодьте SLO: ціль на 28 днів + виключення (заплановані вікна).
4. Зв'яжіть з SLA: юридичне зобов'язання ≦ фактичний SLO.
5. Призначте власника (service owner), RACI і канал алертів.
6. Визначте алерт-політики (двовіконні BR) і авто-відкати.
7. Впроваджуйте звітність: щотижневі огляди бюджету, пост-інцидентні рев'ю.
8. Переглядайте SLO щоквартально (зміна навантаження/архітектури).

8) Приклади SLO (шаблони)

• Доступність: `≥ 99. 95%'( 28д, виключаючи оголошені вікна ≤ 30 хв/міс).
• Латентність: «≥ 99%» відповідей «≤ 400 мс».
• Успіх бізнес-операцій: `≥ 98. 5%'успішних авторизацій (fraud-фільтри враховані).

• Латентність: «≥ 99%» запитів «≤ 300 мс».
• Актуальність кешу: «≤ 5 хв» відставання в 99% випадків.

• Доставка: `≥ 99. 9%'протягом'≤ 60 с'( end-to-end, з ретраями).
• Втрата: `≤ 0. 01%'повідомлень (ідемпотентність/дедуплікація включені).

9) Мульти-регіон і мульти-тенант

SLO «по когортах»: країна, платіжний провайдер, VIP-сегмент, пристрій.
Локальні SLO на краю: метрики з найближчих до користувача точок (edge/PoP).
Агрегування: загальний SLO не повинен приховувати провали по важливих когортах.
Перемикання провайдерів: автоматичні fallback-маршрути на рівні SLO-гейтів.

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

Релізний дашборд: версія, канарка (% трафіку), SLI (успіх/латентність), BR, анотації прапорів.
Операційний дашборд: burn-down бюджету по днях, топ-інциденти, MTTR, проблемні когорти.
Щотижневі звіти: залишок бюджету, тренди BR, технічний борг (вузькі місця), план поліпшень.

11) Процеси: інциденти, RCA і поліпшення

Інцидент-менеджмент: алерт → оцінка BR → масштаб канарок/прапорів → відкат/фікс.
RCA (коренева причина): факти/таймлайн/гіпотези/виправлення/перевірка ефекту по SLI.
Витягнуті уроки: некаральні пост-мортеми, обов'язкові action items з власниками і термінами.
Замикання циклу: зміни в тестах, фіча-прапорах, лімітах, кешах, ретраях, квотах.

12) Комплаєнс і аудит

SLO/SLI як артефакти контролю (policy-as-code, незмінні логи).
Прив'язка до вимог (наприклад, доступність платіжних операцій).
Докази: протоколи алертів, звіти по бюджету, журнали релізів/відкатів.

13) Часті помилки і як їх уникнути

“99. 99% або смерть": недосяжні цілі → постійний алерт-шум. Вибирати реалістичні SLO.
Глобальні середні приховують локальні провали → вводити когорти.
Метрики не e2e: високі SLO при фактичній деградації на клієнті → додавати RUM/синтетику.
Алерти по одному порогу → переходити на двовіконні burn rate.
Немає зв'язку зі змінами → релізи не анотовані, немає авто-відкату.

14) Міні-чек-лист впровадження

• Описані критичні шляхи та їх SLI/SLO.
• Задано вікно спостереження і виключення.
• Налаштовані двовіконні BR-алерти (швидкі і повільні).
• Дашборди релізів і операцій з анотаціями версій/прапорів.
• Політика error budget впливає на релізи.
• Регулярні огляди бюджету і пост-інцидентні RCA.
• Документація та власники показників.

15) Приклад розрахунку (конкретика)

SLO доступності API: 99. 9% за 28 днів → бюджет = 0. 1%.
За 7 днів накопичилося 0. 06% помилок → витрачено 60% тижневого бюджету.
На короткому вікні 15 хв спостерігається 2% помилок. Допустимо на цьому вікні: `0. 1% × (15 хв/40320 хв) ≈ 0. 000037%`.
Burn Rate ≫ 1 (десятки ×) → спрацьовує швидкий пейджер, канарка відкочується до 1%, включається фіча-прапор «degrade-payments-UX», запускається RCA.

16) Підсумок

Моніторинг SLA/SLO - це не тільки цифри в звіті, а механізм управління ризиком змін і якістю сервісу. Правильні SLI, реалістичні SLO, управління error budget, двовіконні burn-rate алерти і e2e-спостережуваність перетворюють метрики в робочі рішення: швидше випускати цінність і тримати користувацький досвід передбачуваним.