Операції та Управління → Аудит метрик і SLA

Аудит метрик і SLA

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

Якщо метрики неправильні - рішення будуть неправильними, SLA будуть порушуватися «на папері» або навпаки приховувати проблеми. Аудит метрик і SLA гарантує порівнянність, достовірність і юридичну захищеність обіцянок перед користувачами і партнерами.

• Забезпечити єдине «джерело правди» (SSOT) і відтворювані розрахунки.
• Знизити розбіжності між дашбордами/звітами/білінгом.
• Зробити SLA здійсненними і перевіряються (evidence-based).
• Виявляти деградації у вимірах так само рано, як і в сервісах.

2) Базові поняття та межі відповідальності

Metric (метрика): вимірювана величина (RPS, p95, CR, GGR, Success Rate).
KPI/OKR: цілі, до яких метрики прив'язані.
SLO: цільова якість сервісу (наприклад, "p99 ≤ 400 мс 99. 9% часу").
SLA: зовнішня обіцянка; юридично значуще, засноване на SLO.
OLA: внутрішня угода між командами/вендорами, підтримує SLA.
SSOT: система/сховище, чиї дані вважаються еталонними для звітів.

3) Таксономія метрик (шари)

1. Інфраструктура: CPU/Memory/IO/Net, поди/вузли, HPA/VPA.
2. Платформа: черги/стріми (lag, throughput), БД/кеші (коннекти, hit), API (p95/p99, 5xx).
3. Бізнес-потоки: депозити/висновки, ставки, запуск ігор, авторизація, KYC.
4. Продукт/маркетинг: конверсії, ARPPU/LTV, кампанії.
5. Якість процесів: MTTA/MTTR, Change Failure Rate, покриття чек-листів.

Правило: кожна метрика повинна мати шар, власника і формулу.

4) Джерела даних та «істина»

Телеєметрія онлайн: Prometheus/OTel, логи (ELK/ClickHouse), трасування.
Події та бухгалтерія: Kafka/Outbox, DWH/дата-марти (BigQuery/ClickHouse).
Ручні артефакти: постмортеми, тікети, реєстри інцидентів.
Зовнішні реєстри: звіти провайдерів (PSP/KYC/студії), білінг.

Вирішення конфлікту: при розбіжностях «онлайн vs DWH» діє регламент пріоритету (наприклад, для SLA - агрегати з DWH з джерельною трасованістю).

5) Процес аудиту метрик (контур управління)

1. Інвентаризація: каталог метрик/SLO/SLA (назва, власник, шар, формула, джерело, частота розрахунку).
2. Верифікація формул: звірка SQL/пром-запитів з визначенням (unit-тести розрахунків).
3. Семплювання та повторні перевірки: вибірки рядків подій/логів і ручна звірка.
4. Зіставлення контурів: порівняння онлайн-дашбордів і DWH-звітів.
5. Контроль змін: рев'ю формул при релізах схем/логіки.
6. Аудит SLA: перевірка коректності збірок і винятків (planned maintenance, форс-мажор).
7. Звіт і поліпшення: список виявлених розбіжностей і фіксів з дедлайнами.

6) Визначення та формули (зразки)

• `success = requests - (5xx + timeouts + circuit_open)`
• `success_rate = success / requests`

• в SSOT фіксується єдине визначення вікна (rolling 5m/1h) і агрегації (HDR/TDigest).

• 'SLO _ availability _ month = (час _ роботи - допустимі _ винятки )/загальний _ час'

• `SLA_month = 99. 90% аптайма по вікну UTC, виключаючи планові вікна (T-48 повідомлення), доказові аварії у транзитних операторів (документи). '

7) Якість даних: перевірки та алерти

• Повнота (completeness): `received_events / expected_events ≥ 0. 99`.
• Своєчасність (timeliness): лаг завантаження ≤ N хвилин.
• Унікальність (uniqueness): без дублів за ключами (idempotency-key).
• Узгодженість (consistency): суми/валюта/знаки.
• Лінійність (monotonicity): лічильники не «відкочуються».

ALERT MetricsIngestionLagHigh
IF dwh_ingest_lag_minutes > 15 FOR 10m

ALERT EventsCompletenessDrop
IF (events_received / events_expected) < 0. 99 FOR 15m

ALERT DuplicateEventsSpike
IF rate(events_duplicates_total[10m]) > baseline_7d 2

8) Аудит SLA/OLA: Методика

1. Зберіть календар винятків: планові вікна, узгоджені деградації, акти вендорів.
2. Розрахунок аптайма: по єдиній часовій зоні, з опорою на SSOT.
3. Звірка з інцидентами: таймлайн, квитки, постмортеми.
4. Атрибуція: власні збої, провайдер, транзит, DDoS, регламентні роботи.
5. Периметр SLA: користувацький досвід (E2E) vs один конкретний API.
6. Звітність: звіт за місяцем/кварталом: факт, відхилення, компенсації (якщо застосовно), коригувальні заходи.

9) Перевірка відтворюваності розрахунків

Версіонування формул: Git-репозиторій з SQL/PromQL/док-специфікаціями.
Юніт-тести метрик: на synthetic даних (edge-кейси: пропуски, дублі, межі дат).
Data lineage: від дашборду назад до вихідних таблиць і подій.
Снапшоти: заморожування даних на відсічку, щоб пере-розрахунки були порівнянні.

10) Контрольні вибірки (sampling)

Щодня: 10-20 подій за ключовими потоками (депозит/ставка/КУС) - ручна звірка трасування ↔ DWH.
Щотижня: 1% семпл для порівняння «онлайн vs DWH» за агрегатами.
Щомісяця: набір інцидентів з SLA-ефектом - детальна реконструкція.

Date/Window: 2025-10-01.. 2025-10-07
Metric: SLO_api_p99
Source A: Prometheus (rolling 5m)
Source B: DWH snapshot (1h buckets)
Deviation: + 6. 2% (A above B)
Reason: different aggregation windows
Action: align window in both contours to 5m/rolling
Term/Owner: 2025-11-10/squad-observability

11) Аудит дашбордів та сповіщень

Єдиний словник метрик: глосарій прямо на дашборді.
Анотації релізів/івентів: щоб бачити причину відхилень.
Порівняння «до/після релізу»: автоматичні панелі регресій.
Дублі/розбіжності: виявлення «двох різних p99» - правка формул/вікон.
Доступність панелей: права, резерв, контроль посилань/версій.

12) Управління змінами в метриках

RFC-процес: зміна формули/вікна/джерела - через RFC з оцінкою впливу на SLA/звіти.
Міграція «expand → migrate → contract»: тимчасово ведемо обидві версії, порівнюємо, потім вимикаємо стару.
Комунікації: заздалегідь повідомляти продукт/бізнес про зрушення значень «за новою методикою».

13) Специфіки iGaming/фінтех

Піки попиту: метрики повинні витримувати вибухові навантаження (агрегації не «залипають»).
Провайдери: SLA залежить від OLA вендорів → зберігати їх звіти, статуси інцидентів і квоти.
Вартість: 'cost _ per _ 1k _ calls'і «вартість успіху» - обов'язкові панелі.
Антифрод/ризик: чутливість до затримок і «помилкових спрацьовувань» метрик.

14) Дашборди аудиту (мінімальний набір)

Metrics Health: completeness/timeliness/duplicates, ingest-lag, ошибки ETL.
SLO/SLA Evidence: обчислений SLO, фактичний SLA, винятки, посилання на інциденти/акти.
Online vs DWH Compare: p95/p99/Success Rate, відхилення і тренди.
Vendor SLA: аптайм/квоти/тайм-аути/вартість в розрізі провайдерів.
Release Impact: регресії метрик після викладок/включення фіч.

15) Чек-лист аудиту (операційний)

• Каталог метрик/SLO/SLA з власниками і формулами актуальний.
• SSOT визначений для кожного звіту/панелі.
• Юніт-тести формул зелені, пайплайни розрахунків задокументовані.

Алерти на якість даних активні (completeness/timeliness/duplicates).

• «Online vs DWH» розбіжності ≤ допустимого порогу (наприклад, ≤2%).
• Узгоджені винятки SLA задокументовані і додані до звіту.
• Проведено контрольні вибірки та оформлено акти.
• Всі зміни формул пройшли RFC і міграцію.

16) Приклади (фрагменти)

api_p99_ms:release:ratio =
(api_latency_p99_ms{release="after"} / api_latency_p99_ms{release="before"})

sql
SELECT event_date,
COUNT() AS received,
SUM(expected_count) AS expected,
COUNT()::decimal / NULLIF(SUM(expected_count),0) AS completeness
FROM events
JOIN expected_events USING (event_date, event_type)
WHERE event_type IN ('deposit','bet_placed','kyc_completed')
AND event_date BETWEEN:from AND:to
GROUP BY 1;

ALERT DwhVsOnlineDrift
IF abs(dwh_kpis{metric="api_p99"} - online_kpis{metric="api_p99"}) > 0. 02 online_kpis
FOR 30m
LABELS {severity="warning", team="observability"}

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

Дві різні формули «однієї» метрики на різних панелях.
Зміна метрики без міграції та повідомлення - «скачки» в OKR/SLA.
Звіти в локальному Excel як «істина» (невідтворювано).
Змішування часових поясів і календарів в SLA-розрахунках.
Винятки SLA не фіксуються документально.
Немає алертів на якість вимірювань.

18) KPI зрілості вимірювань

Drift Rate Online↔DWH (мета ≤2%).
Metrics Health Uptime (час без деградацій ingest/ETL).
Time-to-Fix Formula (час усунення помилки у формулі).
SLA Dispute Rate (частота спірних кейсів з партнерами).
Coverage SLO/SLA (частка критичних шляхів з формально описаними SLO/SLA).

19) Ролі та відповідальність

Власник метрики/сервісу: формула, джерело, дашборд, алерти.
Observability/SRE: SSOT/платформа, тести формул, алерти якості даних.
Data/BI: DWH, відтворюваність звітів, lineage.
Юристи/партнер-менеджери: SLA-домовленості та винятки.
Інцидент-менеджер: атрибуція і зв'язка інцидентів з SLA.

20) Швидкий старт (30 днів)

Тиждень 1: інвентаризація метрик/SLO/SLA та власників; призначити SSOT.
Тиждень 2: включити алерти якості даних і панель «Online vs DWH».
Тиждень 3: провести контрольні вибірки, вирівняти віконність p95/p99.
Тиждень 4: формалізувати RFC-процес для формул, підготувати щомісячний SLA-звіт з додатками.

21) FAQ

Q: Що вважати SSOT для SLA?
A: Сховище з відтворюваними розрахунками (DWH) і повним lineage; онлайн-панелі - для оперативного контролю, не для юридичних актів.

Q: Як боротися з «двома p99»?
A: Зафіксувати вікно/метод агрегації в каталозі метрик, мігрувати панелі, додати алерт на дрейф.

Q: Як враховувати планові роботи?
A: Вести календар винятків і автоматично віднімати їх з SLA за правилами договору; зберігати підтверджуючі артефакти.