ოპერაციები და მენეჯმენტი - აუდიტი მეტრიკი და SLA

აუდიტი მეტრიკი და SLA

1) რატომ არის ეს აუცილებელი?

თუ მეტრიკები არასწორია - გადაწყვეტილებები არასწორი იქნება, SLA დაირღვევა „ქაღალდზე“ ან პირიქით, მალავს პრობლემებს. მეტრიკისა და SLA აუდიტი უზრუნველყოფს მომხმარებლებისა და პარტნიორების წინაშე დაპირებების შედარებას, საიმედოობას და იურიდიულ დაცვას.

• უზრუნველყოს ერთი „სიმართლის წყარო“ (SSOT) და რეპროდუქციული გათვლები.
• შეამცირეთ განსხვავებები დაშბორდებს/ანგარიშებს/ბილინგს შორის.
• გახადეთ SLA შესრულებული და დამოწმებული (evidence-based).
• გაზომვებში დეგრადაციის დადგენა ისეთივე ნაადრევია, როგორც სერვისებში.

2) პასუხისმგებლობის ძირითადი ცნებები და საზღვრები

მეტრიკი (მეტრიკა): გაზომილი მნიშვნელობა (RPS, p95, CR, GGR, Success Rate).
KPI/OKR: მიზნები, რომლებთანაც მეტრიკა უკავშირდება.
SLO: მომსახურების მიზნობრივი ხარისხი (მაგალითად, "p99-400 ms 99. დროის 9%").
SLA: გარე დაპირება; იურიდიულად მნიშვნელოვანი, SLO- ს საფუძველზე.
OLA: გუნდებს/გამყიდველებს შორის შიდა ხელშეკრულება, მხარს უჭერს SLA.
SSOT: სისტემა/საცავი, რომლის მონაცემები ითვლება მოხსენების საცნობარო.

3) მეტრიკის ტაქსონომია (ფენები)

1. ინფრასტრუქტურა: CPU/Memory/IO/Net, პოდები/კვანძები, HPA/VPA.
2. პლატფორმა: ხაზები/ნაკადები (lag, throughput), BD/ქეში (კონექტორები, ჰიტი), API (p95/p99, 5xx).
3. ბიზნეს ნაკადები: ანაბრები/დასკვნები, განაკვეთები, თამაშების დაწყება, ავტორიზაცია, KYC.
4. პროდუქტი/მარკეტინგი: კონვერტაცია, ARPPU/LTV, კამპანიები.
5. პროცესის ხარისხი: MTTA/MTTR, Change Failure Rate, ჩეკების ფურცლების საფარი.

წესი: თითოეულ მეტრს უნდა ჰქონდეს ფენა, მფლობელი და ფორმულა.

4) მონაცემთა წყაროები და „ჭეშმარიტება“

ონლაინ ტელემეტრია: Prometheus/OTel, logs (ELK/ClickHouse), ტრეკები.
მოვლენები და აღრიცხვა: Kafka/Outbox, DWH/მონაცემთა მარტი (BigQuery/ClickHouse).
სახელმძღვანელო ნიმუშები: პოსტმორტემები, თიკეტები, ინციდენტების რეესტრები.
გარე რეესტრები: პროვაიდერების მოხსენებები (PSP/KYC/სტუდია), ბილინგი.

კონფლიქტის მოგვარება: „ონლაინ vs DWH“ - ს შეუსაბამობებთან ერთად, არსებობს პრიორიტეტული რეგულაციები (მაგალითად, SLA- სთვის - DWH- ის დანაყოფები წყაროების ტრეკერის სიმძლავრით).

5) მეტრიკის აუდიტის პროცესი (საკონტროლო წრე)

1. ინვენტარიზაცია: მეტრიკის/SLO/SLA კატალოგი (სახელი, მფლობელი, ფენა, ფორმულა, წყარო, გაანგარიშების სიხშირე).
2. ფორმულების გადამოწმება: SQL/prom მოთხოვნების შერჩევა განმარტებით (გამოთვლების unit ტესტები).
3. სიმულაცია და გადამოწმება: მოვლენების/ლოგოების სტრიქონების ნიმუში და სახელმძღვანელო კრეკი.
4. კონტურების შედარება: ონლაინ დაშბორდების შედარება და DWH მოხსენებები.
5. ცვლილებების კონტროლი: ფორმულების გადახრა სქემების/ლოგიკის გამოშვებისას.
6. SLA აუდიტი: შეკრების სისწორისა და გამონაკლისების შემოწმება (planned maintenance, Forse Major).
7. ანგარიში და გაუმჯობესება: ნაპოვნი განსხვავებებისა და ფიქსების სია ვადაზე.

6) განმარტებები და ფორმულები (ნიმუშები)

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

• SSOT აღნიშნავს ფანჯრის (rolling 5m/1h) და აგრეგაციის (HDR/TDigest) ერთ განმარტებას.

• 'SLO _ availability _ month = (დრო _ სამუშაო - დასაშვები _ გამონაკლისი )/ზოგადი _ დრო'

• `SLA_month = 99. UTC ფანჯრის გასწვრივ აფთიაქის 90%, დაგეგმილი ფანჯრების გამოკლებით (T-48 შეტყობინება), რომლებიც დადასტურებულია სატრანზიტო ოპერატორებში (დოკუმენტები). '

7) მონაცემთა ხარისხი: შემოწმებები და ალერტები

• Полнота (completeness): `received_events / expected_events ≥ 0. 99`.
• დროული (დროული): დატვირთვის ლაქი N წუთი.
• უნიკალურობა: კლავიშებზე დუბლირების გარეშე (იდუმალი-კეი).
• თანმიმდევრულობა: თანხები/ვალუტა/ნიშნები.
• ხაზოვანი (მონოტონიზმი): მრიცხველები არ „ბრუნდებიან“.

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) ერთი კონკრეტული API.
6. ანგარიში: ანგარიში თვის/კვარტლის შესახებ: ფაქტი, გადახრები, კომპენსაცია (თუ გამოიყენება), მაკორექტირებელი ზომები.

9) გამოთვლების რეპროდუქციის შემოწმება

ფორმულების ვერსია: Git საცავი SQL/PromQL/სპეციფიკაციებით.
მეტრიკის ერთეულის ტესტები: სინთეზურ მონაცემებზე (edge შემთხვევები: გამოტოვება, დუბლირება, თარიღების საზღვრები).
მონაცემთა ხაზები: დაშბორდიდან საწყის ცხრილებამდე და მოვლენებამდე.
Snaphots: მონაცემების გაყინვა შეწყვეტაზე, ისე რომ კალმის გათვლები შედარებულია.

10) საკონტროლო ნიმუშები

ყოველდღიურად: 10-20 მოვლენა საკვანძო ნაკადებზე (ანაბარი/განაკვეთი/KUS) - DWH ტრეკების სახელმძღვანელო შეკრება.
ყოველკვირეულად: 1% ნიმუში აგრეგატებისთვის „ონლაინ 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/fintech სპეციფიკა

მოთხოვნის მწვერვალები: მეტრიკებმა უნდა გაუძლოს ასაფეთქებელ დატვირთვებს (აგრეგაციები არ „იჭრება“).
პროვაიდერები: SLA დამოკიდებულია OLA გამყიდველებზე - შეინახეთ მათი მოხსენებები, ინციდენტების სტატუსები და კვოტები.
ღირებულება: 'cost _ per _ 1k _ calls' და „წარმატების ღირებულება“ სავალდებულო პანელები არიან.
ანტიფროდი/რისკი: მგრძნობელობა შეფერხებების მიმართ და მეტრიკის „ცრუ მოქმედება“.

14) დაშბორდის აუდიტი (მინიმალური ნაკრები)

Metrics Health: completeness/timeliness/duplicates, ingest-lag, ошибки ETL.
SLO/SLA Evidence: გამოთვლილი SLO, ფაქტობრივი SLA, გამონაკლისი, ინციდენტების/აქტების ბმულები.
ონლაინ DWH Compare: p95/p99/Success Rate, გადახრები და ტენდენციები.
Vendor SLA: აფთიაქი/კვოტები/დრო/დრო/ღირებულება პროვაიდერების კონტექსტში.
Release Impact: მეტრიკის რეგრესია fick- ის გადაღების/ჩართვის შემდეგ.

15) აუდიტის სია (ოპერაციული)

• მეტრული/SLO/SLA კატალოგი მფლობელებითა და ფორმულებით აქტუალურია.
• SSOT განისაზღვრება თითოეული ანგარიში/პანელისთვის.
• Unit ტესტები არის მწვანე ფორმულები, დაფიქსირებულია გამოთვლების რაციონი.
• Alerta მონაცემთა ხარისხის შესახებ აქტიურია (completeness/timeluness/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 (დრო დეგრადაციის გარეშე/ETL).
Time-to-Fix Formula (შეცდომის აღმოფხვრის დრო ფორმულაში).
SLA Dispute Rate (პარტნიორებთან სადავო შემთხვევების სიხშირე).
Coverage SLO/SLA (კრიტიკული ბილიკების პროპორცია ოფიციალურად აღწერილი SLO/SLA).

19) როლები და პასუხისმგებლობა

მეტრიკის/მომსახურების მფლობელი: ფორმულა, წყარო, დაშბორდი, ალერტები.
Observability/SRE: SSOT/პლატფორმა, ფორმულების ტესტები, მონაცემთა ხარისხის ალერტები.
Data/BI: DWH, რეპორტების რეპროდუქცია, ხაზოვანი.
იურისტები/პარტნიორი მენეჯერები: 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) და სრული ხაზით; ონლაინ პანელები - ოპერაციული კონტროლისთვის, არა იურიდიული აქტებისთვის.

Q: როგორ გავუმკლავდეთ „ორ p99“ - ს?
A: დაფიქსირება ფანჯარა/აგრეგაციის მეთოდი მეტრიკის კატალოგში, პანელების მიგრაცია, დრიფტის ალერტის დამატება.

Q: როგორ გავითვალისწინოთ დაგეგმილი სამუშაოები?
A: შეინარჩუნეთ გამონაკლისების კალენდარი და ავტომატურად ამოიღეთ ისინი SLA- დან ხელშეკრულების წესების შესაბამისად; შეინახეთ დამადასტურებელი ნივთები.