ოპერაციული ანალიტიკა

1) რა არის ოპერაციული ანალიტიკა და რატომ არის ეს საჭირო

ოპერაციული ანალიტიკა (Ops Analytics) არის სისტემის სიგნალის შეკრება დაკვირვებისგან (მეტრიკა/ლოგები/ტრეისი), ITSM (ინციდენტები/პრობლემები/ცვლილებები), CI/CD (გამოშვებები/კონფიგურაციები), პროვაიდერები (PSP/KYC/Cloud), FinOps (ხარჯები) და ბიზნეს SLI (გადახდის წარმატება, რეგისტრაცია), გადაიქცა ერთ ფანჯარაში და დაშბორდებად გადაწყვეტილების მისაღებად.

• შეამცირეთ MTTD/MTTR მიზეზების ადრეული გამოვლენისა და სწორი ატრიბუტის გამო;
• შეინარჩუნეთ SLO და შეცდომების ბიუჯეტი კონტროლის ქვეშ;
• დაუკავშირეთ ცვლილებები გავლენაში (გამოშვებები/კონფიგურაცია, SLI/SLO/საჩივრები/ხარჯები);
• მისცეს ელექტრონული სერვისის ანალიზს გუნდებსა და მენეჯმენტს.

2) წყაროები და კანონიკური მონაცემთა ფენა

ტელემეტრია: მეტრიკა (SLI/რესურსები), ლოგოები (ნიმუშები/PII გამოცემა), ტრეისი (trace _ id/spank _ id, გამოცემა-ჭდეები).
ITSM/Incident მოდულები: SEV, T0/Detected/Ack/Declared/Mitigated/Recovered, RCA/CAPA.
CI/CD & Config: ვერსიები, კომიქსები, კანარიკა/ცისფერი-მწვანე, დროშის სახელმწიფო, მიზნობრივი კონფიგურაცია.
პროვაიდერები: სტატუსები/SLA, შეფერხებები, შეცდომების კოდები, მარშრუტების წონა.
FinOps: ღირებულება ტეგების/ანგარიშების/ტენანტების მიხედვით, $/ერთეული (1k ოპერები.) .
DataOps: ფანჯრის სიახლე, DQ შეცდომები, ხაზები.

ძირითადი პრინციპია ერთიანი კორელაცია იდენტიფიკატორების საშუალებით: 'სერვისის', '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-change-spikes (გამოშვების შემდეგ).
პროგნოზი: ყოველკვირეული/სეზონური დატვირთვის ნიმუშები, შეცდომების ბიუჯეტის პროგნოზი, ხარჯების პროგნოზი ($/ერთეული) .
გარდრეილები: ალერტები მხოლოდ წყაროების კვორუმში (სინთეტიკური + RUM + ბიზნეს SLI).

7) ვიტრინები და დაშბორდები (რეფერენდუმი)

1. აღმასრულებელი 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, logs/egress, ხარჯების ანომალიები, რეკომენდაციები (ნიმუშები, შენახვა).
6. DataOps: ფანჯრის სიახლე, DQ შეცდომები, SLA piplines, უკანა პლანზე წარმატება.

8) მონაცემთა ხარისხი და მთავრობის

ღონისძიების კონტრაქტები: მკაფიო სქემები ინციდენტების/გამოშვებისთვის/SLI (სავალდებულო ველები, ერთიანი დროის ზონები).
DQ გამშვები: სისრულე, კლავიშების უნიკალურობა, დროის თანმიმდევრულობა (t0-detectected-ack...).
ხაზოვანი: დაშბორდიდან წყარომდე.
PII/საიდუმლოებები: რედაქტირება/შენიღბვა პოლიტიკის შესახებ; evidence WORM.
SLA სიახლე: Ops ფანჯრები 5 წუთიანი შეფერხებაა.

9) სიმწიფის მეტრიკა

Coverage: კრიტიკული სერვისების% ფანჯრებში და SLO ბორდებში (მიზანი 95%).
Freshness: ვიჯეტების წილი სიახლის 5 წუთის განმავლობაში (მიზანი 95%).
Actionability: Dashboard- დან მოქმედების გადასვლის% (playbook/SOP/ticet) - 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. მოქმედება: playbuk/SOP, გამოშვების კარიბჭე, fich დროშა, პროვაიდერის შეცვლა.
4. Evidence და AAR/RCA: დრო, გრაფიკა, ბმულები გამოშვებებზე/ლოგებზე/ტრეისებზე.
5. CAPA და სასურსათო გადაწყვეტილებები: პრიორიტეტი burn წუთებში და -impact.

11) შეკითხვის მაგალითები (იდეა)

11. 1 გამოშვების გავლენა SLO- ზე (24ch)

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 აღმასრულებელი ანგარიშის ბარათი (სექციები)

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: Fick- ის ხელახალი გამოყენება (კანარიკა, სეზონურობა, პროვაიდერი სიგნალები).
Semantic Layer/Metric Store: მეტრიკის ერთიანი განმარტებები (SLO, MTTR...).
Access Control: RBAC/ABAC, row-level უსაფრთხოება ტენანტებისთვის/რეგიონებისთვის.
Catalog/Lineage: ძებნა, აღწერილობა, დამოკიდებულება, მფლობელები.

14) ჩეკის ფურცლები

14. 1 ოპერაციული ანალიტიკის დაწყება

• დამტკიცებულია SLI/SLO, SEV, მიზეზები, change ტიპები.
• მოვლენების სქემები და ერთიანი ტაიმსონები.
• ტელემეტრიული კონექტორები, ITSM, CI/CD, პროვაიდერები, ბილინგი.
• ვიტრინები: SLI/SLO, Incidents, Changes, Providers, FinOps.
• საგანგებო/SRE/Change/Providers dashbords ხელმისაწვდომია.
• კვორუმის ალერტები და მხარდაჭერა მომსახურების ფანჯრებზე.

14. 2 ყოველკვირეული Ops მიმოხილვა

• SEV ტენდენციები, MTTR/MTTD, SLO გამოტოვება, მშრალი წუთი.
• Change Impact და CFR, დაბრუნების სტატუსი.
• პროვაიდერის ინციდენტები და რეაქციის დრო.
• FinOps: $/ed., ლოგოების ანომალიები/egress.
• CAPA სტატუსი, შეფერხებები, პრიორიტეტები.

15) ანტი შაბლონები

„გრაფიკის კედელი“ მოქმედებებზე გადასვლის გარეშე.
ბრძანებებს შორის მეტრიკის სხვადასხვა განმარტება (არ არსებობს სემანტიკური ფენა).
გამოშვების/ფანჯრების პრეზენტაციების არარსებობა მიზეზების სუსტი ატრიბუტია.
საშუალო ორიენტაცია p95/p99 ნაცვლად.
მოცულობის ნორმალიზაცია არ არსებობს - დიდი სერვისები „უარესად გამოიყურება“.
PII ლოგოებში/ფანჯრებში, რეცენზიების დარღვევა.
მონაცემები „დამონტაჟებულია“ (> 5-10 წუთი რეალურ დროში ვიჯეტებისთვის).

16) განხორციელების გზის რუკა (4-8 კვირა)

1. ნვე. 1: შეთანხმებები მეტრიკის ლექსიკონზე, მოვლენების სქემებზე, იდიალურ კორელაციებზე; კავშირი SLI/SLO და ITSM.
2. ნვე. 2: Incidents/Changes/Providers ფანჯრები, გამოშვების სურათები; აღმასრულებელი და SRE დაშბორდები.
3. ნვე. 3: FinOps ფენა ($/ერთეული) , კავშირი SLI- სთან; ანომალია-დეტაჟი კვორუმთან.
4. ნვე. 4: semantic layer/metric store, კატალოგი და ხაზები.
5. ნვე. 5-6: დატვირთვის/ხარჯების პროგნოზი, პროვაიდერების მოხსენებები, CAPA ვიტრინა.
6. ნვე. 7-8: გაშუქება - 95% Tier-0/1, SLA სიახლე 5 წუთი, რეგულარული Ops მიმოხილვები.

17) შედეგი

ოპერაციული ანალიტიკა არის გადაწყვეტილების მიღების მანქანა: მეტრიკის ერთიანი განმარტებები, ახალი ფანჯრების ფანჯრები, მიზეზების სწორი ატრიბუტი და პირდაპირი გადასვლები playbooks და SOP. ასეთ სისტემაში გუნდი სწრაფად აღმოაჩენს და განმარტავს გადახრებს, ზუსტად აფასებს გამოშვებებისა და პროვაიდერების გავლენას, აკონტროლებს ხარჯებს და სისტემურად ამცირებს რისკს - ხოლო მომხმარებლები იღებენ სტაბილურ მომსახურებას.