Операційна аналітика

1) Що таке операційна аналітика і навіщо вона потрібна

Операційна аналітика (Ops Analytics) - це системна збірка сигналів зі спостережуваності (метрики/логи/трейси), ITSM (інциденти/проблеми/зміни), CI/CD (релізи/конфіги), провайдерів (PSP/KYC/CDN/Cloud), FinOps (витрати) і бізнес-SLI (успіх платежів, реєстрації), перетворена в єдині вітрини і дашборди для прийняття рішень.

• знизити MTTD/MTTR за рахунок раннього виявлення і коректної атрибуції причин;
• тримати SLO і бюджет помилок під контролем;
• пов'язувати зміни → імпакт (релізи/конфіги → SLI/SLO/скарги/витрати);
• давати self-service аналітику командам і менеджменту.

2) Джерела і канонічний шар даних

Телеметрія: метрики (SLI/ресурси), логи (семплінг/редакція PII), трейси (trace_id/span_id, реліз-теги).
ITSM/Incident модулі: SEV, таймстампи T0/Detected/Ack/Declared/Mitigated/Recovered, RCA/CAPA.
CI/CD & Config: версії, коміти, канарика/blue-green, флаг-стейт, цільові конфіги.
Провайдери: статуси/SLA, затримки, коди помилок, ваги маршрутів.
FinOps: вартість за тегами/акаунтами/тенантами, $/одиницю (1k опер.) .
DataOps: свіжість вітрин, DQ-помилки, lineage.

Ключовий принцип - єдина кореляція через ідентифікатори: `service`, `region`, `tenant`, `release_id`, `change_id`, `incident_id`, `provider`, `trace_id`.

3) Єдина модель даних (спрощений каркас)

dim_service(service_id, owner, tier, slo_targets…)
dim_time(ts, date, hour, tz)
dim_region(region_id, country, cloud)
dim_provider(provider_id, type, sla)
fact_sli(ts, service_id, region_id, tenant, metric, value, target, window)
fact_incident(incident_id, service_id, sev, t0, t_detected, t_ack, t_declared, t_mitigated, t_recovered, root_cause, trigger_id, burn_minutes)
fact_change(change_id, type(code    config    infra), service_id, region_id, started_at, finished_at, canary_pct, outcome(ok    rollback), annotations)
fact_cost(ts, service_id, region_id, tenant, cost_total, cost_per_1k)
fact_provider(ts, provider_id, region_id, metric(latency    error    status), value)
fact_dq(ts, dataset, freshness_min, dq_errors)

4) SLI/SLO та бізнес-метрики

Бізнес-SLI: `payment_success_ratio`, `signup_completion`, `deposit_latency`.
Тех-SLI: `availability`, `http_p95`, `error_rate`, `queue_depth`.
SLO-шар: цілі + burn-rate (коротке/довге вікно), автоматичні анотації порушень.
Нормалізація: показники на 1k успішних операцій/користувачів/трафік.

5) Кореляції та атрибуція причин

Релізи/конфіги ↔ SLI/SLO: анотації на графах; причинно-наслідкові звіти (частка інцидентів, пов'язаних зі змінами; MTTR change-інцидентів).
Провайдери ↔ бізнес-SLI: ваги маршрутів vs latency/помилки, внесок кожного провайдера в промах SLO.
Ємність/ресурси ↔ затримки: перегрів пулів → зростання p95 → вплив на конверсію.

6) Аномалії та прогнозування

Аномалія-детект: сезонність + перцентильні пороги + change-пошукові фічі (до/після релізу).
Прогноз: тижневі/сезонні патерни навантаження, прогноз burn-out бюджету помилок, предикція витрат ($/од.) .
Гардрейли: алерти тільки при кворумі джерел (synthetic + RUM + бізнес-SLI).

7) Вітрини і дашборди (референс)

1. Executive 28d: SEV-мікс, медіана MTTR/MTTD, SLO adherence, $/одиницю, топ-причини.
2. SRE Ops: SLI/SLO + burn-rate, Page Storm, Actionable %, Change Failure Rate.
3. Change Impact: релізи/конфіги ↔ SLI/SLO/скарги, відкати та їх ефект.
4. Providers: статус-лінії PSP/KYC/CDN, впливу на бізнес-SLI, часи відповідей.
5. FinOps: cost per 1k txn, логи/egress, аномалії витрат, рекомендації (семплінг, зберігання).
6. DataOps: свіжість вітрин, DQ-помилки, SLA пайплайнів, бекфіл-успіх.

8) Якість даних і governance

Контракти подій: чіткі схеми для інцидентів/релізів/SLI (обов'язкові поля, єдині часові пояси).
DQ-чекери: повнота, унікальність ключів, несуперечливість таймлайну (t0≤detected≤ack...).
Лінійдж: від дашборду до джерела (traceable).
PII/секрети: редагування/маскування з політики; WORM для evidence.
SLA свіжості: вітрини Ops ≤ 5 хв затримки.

9) Метрики зрілості операційної аналітики

Coverage: % критичних сервісів у вітринах і SLO-бордах (мета ≥ 95%).
Freshness: частка віджетів зі свіжістю ≤ 5 хв (мета ≥ 95%).
Actionability: % переходів з дашборду до дії (плейбук/SOP/тікет) ≥ 90%.
Detection Coverage: ≥ 85% інцидентів виявляє автоматика.
Attribution Rate: частка інцидентів з підтвердженою причиною і тригером ≥ 90%.
Change Impact Share: частка інцидентів, пов'язаних зі змінами (контролюємо тренд).
Data Quality: DQ-помилки/тиждень → ↓ QoQ.

10) Процес: від даних до дій

1. Збір → очищення → нормалізація → вітрини (ETL/ELT, feature-шар для ML).
2. Виявлення/прогноз → ескалація по матриці (IC/P1/P2/Comms).
3. Дія: плейбук/SOP, реліз-гейт, фіча-прапор, перемикання провайдера.
4. Evidence и AAR/RCA: таймлайн, графіки, посилання на релізи/логи/трейси.
5. CAPA та продуктові рішення: пріоритизація по burn-хвилинах і $ -імпакту.

11) Приклади запитів (ідея)

11. 1 Вплив релізів на SLO (24ч)

sql
SELECT r. change_id,
COUNT(i. incident_id) AS incidents,
SUM(i. burn_minutes) AS burn_total_min,
AVG(CASE WHEN i.root_cause='code' THEN 1 ELSE 0 END) AS code_ratio
FROM fact_change r
LEFT JOIN fact_incident i
ON i.trigger_id = r. change_id
WHERE r. started_at >= NOW() - INTERVAL '24 hours'
GROUP BY 1
ORDER BY burn_total_min DESC;

11. 2 Частка проблем від провайдерів по регіонах

sql
SELECT region_id, provider_id,
SUM(CASE WHEN root_cause='provider' THEN 1 ELSE 0 END) AS prov_inc,
COUNT() AS all_inc,
100. 0SUM(CASE WHEN root_cause='provider' THEN 1 ELSE 0 END)/COUNT() AS pct
FROM fact_incident
WHERE t0 >= DATE_TRUNC('month', NOW())
GROUP BY 1,2
ORDER BY pct DESC;

11. 3 Cost per 1k успішних платежів

sql
SELECT date(ts) d,
SUM(cost_total)/NULLIF(SUM(success_payments)/1000. 0,0) AS cost_per_1k
FROM fact_cost c
JOIN biz_payments b USING (ts, service_id, region_id, tenant)
GROUP BY d ORDER BY d DESC;

12) Шаблони артефактів

12. 1 Схема події інциденту (JSON, фрагмент)

json
{
"incident_id": "2025-11-01-042",
"service": "payments-api",
"region": "eu",
"sev": "SEV-1",
"t0": "2025-11-01T12:04:00Z",
"detected": "2025-11-01T12:07:00Z",
"ack": "2025-11-01T12:09:00Z",
"declared": "2025-11-01T12:11:00Z",
"mitigated": "2025-11-01T12:24:00Z",
"recovered": "2025-11-01T12:48:00Z",
"root_cause": "provider",
"trigger_id": "chg-7842",
"burn_minutes": 18
}

12. 2 Каталог метрик (YAML, фрагмент)

yaml metric: biz. payment_success_ratio owner: team-payments type: sli target: 99. 5 windows: ["5m","1h","6h","28d"]
tags: [tier0, region:eu]
pii: false

12. 3 Картка звіту Executive (розділи)

1) SEV mix and MTTR/MTTD trends
2) SLO adherence and burn-out risks
3) Change Impact (CFR)
4) Providers: Degradation and switchover
5) FinOps: $/unit, log anomalies/egress
6) CAPAs: Status and Deadlines

13) Інструменти та архітектурні патерни

Data Lake + DWH: «сирий» шар для телеметрії, вітрини для рішень.
Stream-процесинг: near-real-time SLI/burn-rate, онлайнові фічі для аномалій.
Feature Store: повторне використання фіч (канарика, сезонність, провайдер-сигнали).
Semantic Layer/Metric Store: єдині визначення метрик (SLO, MTTR...).
Access Control: RBAC/ABAC, row-level security для тенантів/регіонів.
Catalog/Lineage: пошук, описи, залежності, власники.

14) Чек-листи

14. 1 Запуск операційної аналітики

• Затверджені словники SLI/SLO, SEV, причини, change-типи.
• Схеми подій і єдині таймзони.
• Конектори телеметрії, ITSM, CI/CD, провайдери, білінг.
• Вітрини: SLI/SLO, Incidents, Changes, Providers, FinOps.
• Executive/SRE/Change/Providers дашборди доступні.
• Налаштовані кворум-алерти і suppression на вікна обслуговування.

14. 2 Щотижневий Ops-огляд

• SEV-тренди, MTTR/MTTD, промахи SLO, burn-хвилини.
• Change Impact і CFR, статус відкатів.
• Провайдерські інциденти і часи реакції.
• FinOps: $/од., аномалії логів/egress.
• CAPA статус, прострочення, пріоритети.

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

«Стіна графіків» без переходу до дій.
Різні визначення метрик у команд (немає семантичного шару).
Відсутність анотацій релізів/вікон - слабка атрибуція причин.
Орієнтація на середні замість p95/p99.
Немає нормалізації на обсяг - великі сервіси «здаються гіршими».
PII в логах/вітринах, порушення ретенцій.
Дані «застоюються» (> 5-10 хв для real-time віджетів).

16) Дорожня карта впровадження (4-8 тижнів)

1. Нед. 1: домовленості щодо словника метрик, схем подій, id-кореляції; підключення SLI/SLO і ITSM.
2. Нед. 2: вітрини Incidents/Changes/Providers, анотації релізів; Executive & SRE дашборди.
3. Нед. 3: FinOps-шар ($/од.) , зв'язка з SLI; аномалія-детект з кворумом.
4. Нед. 4: self-service (semantic layer/metric store), каталог і lineage.
5. Нед. 5–6: прогноз навантаження/витрат, звіти провайдерам, CAPA-вітрина.
6. Нед. 7–8: охоплення ≥95% Tier-0/1, SLA свіжості ≤5 хв, регулярні Ops-огляди.

17) Підсумок

Операційна аналітика - це машина прийняття рішень: єдині визначення метрик, свіжі вітрини, коректна атрибуція причин і прямі переходи до плейбуків і SOP. У такій системі команда швидко виявляє і пояснює відхилення, точно оцінює вплив релізів і провайдерів, управляє витратами і системно знижує ризик - а користувачі отримують стабільний сервіс.