Операциялық талдау
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/құпиялар: саясат бойынша редакциялау/бүркемелеу; evidence үшін WORM.
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, ML үшін feature-қабат).
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, ретенциялардың бұзылуы.
Деректер «тұрып қалады» (real-time виджеттер үшін> 5-10 мин).
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-қа тікелей ауысулар. Мұндай жүйеде команда ауытқуларды тез анықтайды және түсіндіреді, релиздер мен провайдерлердің әсерін дәл бағалайды, шығындарды басқарады және тәуекелді жүйелі түрде төмендетеді - ал пайдаланушылар тұрақты сервис алады.