Operatsiyalar va Boshqaruv → Metrik va SLA auditi

Metrik va SLA auditi

1) Nima uchun bu zarur?

Agar ko’rsatkichlar noto’g’ri bo’lsa, qarorlar noto’g’ri bo’ladi, SLA «qog’ozda» buziladi yoki aksincha muammolarni yashiradi. Metrik va SLA auditi foydalanuvchilar va hamkorlar oldidagi va’dalarning taqqoslanishi, ishonchliligi va huquqiy himoyalanganligini kafolatlaydi.

• Yagona «haqiqat manbai» (SSOT) va takrorlanadigan hisob-kitoblarni ta’minlash.
• Dashbordlar/hisobotlar/billing o’rtasidagi tafovutlarni kamaytirish.
• SLAni bajarish va tekshirish (evidence-based).
• O’lchovlardagi tanazzullarni aniqlash servislardagi kabi erta.

2) Javobgarlikning asosiy tushunchalari va chegaralari

Metrik (metrika): o’lchanadigan miqdor (RPS, p95, CR, GGR, Success Rate).
KPI/OKR: Metriklar bogʻlangan maqsadlar.
SLO: xizmatning maqsadli sifati (masalan, "p99 ≤ 400 ms 99. 9% vaqt").
SLA: tashqi va’da; yuridik ahamiyatga ega bo’lgan, SLOga asoslangan.
OLA: jamoalar/sotuvchilar oʻrtasidagi ichki kelishuv, SLAni qoʻllab-quvvatlaydi.
SSOT: maʼlumotlari hisobotlar uchun etalon hisoblanadigan tizim/ombor.

3) Metriklarning taksonomiyasi (qatlamlari)

1. Infratuzilma: CPU/Memory/IO/Net, pod/tugunlar, HPA/VPA.
2. Platforma: navbatlar/oqimlar (lag, throughput), BD/keshlar (konnektlar, hit), API (p95/p99, 5xx).
3. Biznes oqimlari: depozitlar/xulosalar, stavkalar, o’yinlarni boshlash, avtorizatsiya, KYC.
4. Mahsulot/marketing: konversiyalar, ARPPU/LTV, kampaniyalar.
5. Jarayon sifati: MTTA/MTTR, Change Failure Rate, chek varaqlarini qamrab olish.

Qoida: har bir metrika qatlamga, egasiga va formulaga ega bo’lishi kerak.

4) Ma’lumotlar manbalari va «haqiqat»

Telemetriya onlayn: Prometheus/OTel, logi (ELK/ClickHouse), trastirovka.
Voqealar va buxgalteriya: Kafka/Outbox, DWH/data-mart (BigQuery/ClickHouse).
Qo’l artefaktlari: postmortemlar, tiketlar, hodisalar reyestrlari.
Tashqi reyestrlar: provayderlarning hisobotlari (PSP/KYC/studiyalar), billing.

Mojaroni hal qilish: «onlayn vs DWH» tafovutlarida ustuvorlik reglamenti amal qiladi (masalan, SLA uchun - manbali trassaga ega DWH agregatlari).

5) Metrik audit jarayoni (boshqaruv konturi)

1. Inventarizatsiya: metrik/SLO/SLA katalogi (nomi, egasi, qatlami, formulasi, manbai, hisoblash chastotasi).
2. Formulalarni verifikatsiya qilish: SQL/sanoat so’rovlarini aniqlash bilan solishtirish (hisob-kitoblarning unit-testlari).
3. Samplash va qayta tekshirish: voqealar/log satrlarini tanlash va qoʻlda solishtirish.
4. Konturlarni taqqoslash: onlayn dashbordlar va DWH hisobotlarini taqqoslash.
5. Oʻzgarishlarni nazorat qilish: sxemalar/mantiqni chiqarishda formulalar revyusi.
6. SLA auditi: yig’ilishlar va istisnolarning to’g "riligini tekshirish (planned maintenance, fors-major).
7. Hisobot va yaxshilanishlar: aniqlangan tafovutlar va muddatlar bilan fikslar ro’yxati.

6) Aniqliklar va formulalar (namunalar)

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

• SSOTda oynaning yagona aniqlanishi (rolling 5m/1h) va agregatsiya (HDR/TDigest) qayd etiladi.

• ’SLO _ availability _ month = (ish vaqti _ ruxsat etilgan _ istisnolar )/umumiy _ vaqt’

• `SLA_month = 99. 90% aptaym UTC oynasi bo’yicha, rejali derazalar (T-48 xabarnoma), tranzit operatorlarida isbotlanadigan avariyalar (hujjatlar) bundan mustasno. "

7) Ma’lumotlar sifati: tekshirishlar va alertlar

• Полнота (completeness): `received_events / expected_events ≥ 0. 99`.
• O’z vaqtida (timeliness): ortish vaqti ≤ N daqiqa.
• Uniqueness: (idempotency-key).
• Muvofiqlik (consistency): summalar/valyuta/belgilar.
• Chiziqlilik (monotonicity): hisoblagichlar «orqaga qaytmaydi».

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 auditi: metodika

1. Reja oynalari, kelishilgan tanazzullar, vendor dalolatnomalari kabi istisnolar taqvimini yigʻing.
2. Aptaym hisob-kitobi: SSOTga tayanib, yagona vaqt zonasi bo’yicha.
3. Hodisalar bilan solishtirish: taymline, chiptalar, postmortemlar.
4. Atributsiya: o’z uzilishlari, provayder, tranzit, DDoS, reglament ishlari.
5. SLA perimetri: foydalanuvchi tajribasi (E2E) vs bitta aniq API.
6. Hisobot: oy/chorak bo’yicha hisobot: fakt, rad etish, kompensatsiya (agar qo’llanilsa), tuzatish choralari.

9) Hisob-kitoblarning takrorlanuvchanligini tekshirish

Formulalar versiyasi: SQL/PromQL/doc spetsifikatsiyali Git-repozitoriy.
Unit-testlar metrik: synthetic ma’lumotlarga (edge-keyslar: o’tkazgichlar, dubllar, sana chegaralari).
Data lineage: dashborddan boshlangʻich jadvallar va hodisalarga qaytish.
Snapshotlar: qayta hisob-kitoblarni taqqoslash uchun maʼlumotlarni kesish uchun muzlatish.

10) Nazorat namunalari (sampling)

Har kuni: asosiy oqimlar bo’yicha 10-20 tadbir (depozit/stavka/KS) - DWH trassasini qo’lda solishtirish.
Haftalik: agregatlar bo’yicha «onlayn vs DWH» ni solishtirish uchun 1% sampl.
Oylik: SLA effekti bilan bog’liq hodisalar to’plami - batafsil rekonstruksiya.

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) Dashbordlar va xabarnomalar auditi

Metriklarning yagona lug’ati: glasariy to’g’ridan-to’g’ri dashbordda.
Relizlar/hodisalar izohlari: rad etish sababini koʻrish uchun.
«Relizdan oldin/keyin» taqqoslash: avtomatik regressiya panellari.
Dubli/tafovutlar: «ikki xil p99» ni aniqlash - formula/oynalarni tuzatish.
Panellardan foydalanish imkoniyati: huquqlar, zaxira, havolalar/versiyalarni boshqarish.

12) Metriklardagi o’zgarishlarni boshqarish

RFC jarayoni: formulani/oynani/manbani o’zgartirish - RFC orqali SLA/hisobotlarga ta’sirini baholash.
Migratsiya «expand → migrate → contract»: vaqtincha ikkala versiyani olib boramiz, taqqoslaymiz, keyin eskisini oʻchiramiz.
Kommunikatsiyalar: mahsulot/biznesni «yangi metodika bo’yicha» qiymatlarning o’zgarishi haqida oldindan xabardor qilish.

13) iGaming/fintech xususiyatlari

Talab cho’qqilari: metriklar portlovchi yuklarga bardosh berishi kerak (agregatsiyalar «yopishmaydi»).
Provayderlar: SLA OLA vendorlariga bog’liq → ularning hisobotlari, hodisalar holati va kvotalarini saqlash.
Qiymati:’cost _ per _ 1k _ calls’va’muvaffaqiyat qiymati’- majburiy panellar.
Antifrod/xavf: kechikish va metriklarning «yolg’on ishlashiga» sezgirlik.

14) Audit dashbordlari (minimal to’plam)

Metrics Health: completeness/timeliness/duplicates, ingest-lag, ошибки ETL.
SLO/SLA Evidence: hisoblab chiqilgan SLO, haqiqiy SLA, istisnolar, hodisalar/harakatlarga havolalar.
Online vs DWH Compare: p95/p99/Success Rate, chetlanishlar va trendlar.
Vendor SLA: aptaym/kvotalar/taym-autlar/provayderlar kesimidagi qiymat.

Release Impact: metriklarning regressiyasi

15) Audit chek-varaqasi (operatsion)

• Metrik/SLO/SLA katalogi egalari va formulalari bilan dolzarbdir.
• SSOT har bir hisobot/panel uchun belgilangan.
• Formula unit testlari yashil, hisob-kitoblar payplaynlari hujjatlashtirilgan.
• Ma’lumotlar sifati uchun alertlar faol (completeness/timeliness/duplicates).
• «Online vs DWH» ≤ ruxsat etilgan chegaradagi tafovutlar (masalan, ≤ 2%).
• SLAning kelishilgan istisnolari hujjatlashtirilgan va hisobotga ilova qilingan.
• Nazorat namunalari o’tkazildi va dalolatnomalar rasmiylashtirildi.
• Formuladagi barcha o’zgarishlar RFC va migratsiyadan o’tdi.

16) Misollar (parchalar)

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) Anti-patternlar

Turli panellarda «bir» metrikaning ikki xil formulasi.
Ko’chib o’tmasdan metrikani o’zgartirish - OKR/SLA da «sakrash».
Mahalliy Excel hisobotlari «haqiqat» sifatida (qayta tiklanmaydi).
SLA hisob-kitoblarida vaqt zonalari va taqvimlarni aralashtirish.
SLA istisnolari hujjatlar bilan qayd etilmaydi.
O’lchash sifati uchun hech qanday xavf yo’q.

18) O’lchashlar yetukligining KPI

Drift Rate Online, DWH (maqsad ≤ 2%).
Metrics Health Uptime (ingest/ETL degradatsiyasiz vaqt).
Time-to-Fix Formula (formuladagi xatoni bartaraf etish vaqti).
SLA Dispute Rate (sheriklar bilan bahsli holatlar chastotasi).
Coverage SLO/SLA (SLO/SLA rasmiy tavsiflangan tanqidiy yo’llar ulushi).

19) Rollar va javobgarlik

Metrika/servis egasi: formula, manba, dashbord, alertlar.
Observability/SRE: SSOT/platforma, formula testlari, ma’lumotlar sifati alertlari.
Data/BI: DWH, hisobotlarning takrorlanuvchanligi, lineage.
Advokatlar/hamkor menejerlar: SLA-kelishuvlar va istisnolar.
Hodisa boshqaruvchisi: SLA bilan hodisalarni atributlash va bogʻlash.

20) Tezkor boshlash (30 kun)

1-hafta: metrik/SLO/SLA va egalarini inventarizatsiya qilish; SSOTni tayinlash.
2-hafta: Ma’lumotlar sifati alertlari va «Online vs DWH» panelini yoqish.
3 hafta: nazorat namunalarini o’tkazish, p95/p99 oynasini tekislash.
4-hafta: formulalar uchun RFC jarayonini rasmiylashtirish, ilovalar bilan oylik SLA hisobotini tayyorlash.

21) FAQ

Q: SLA uchun SSOTni nima deb hisoblash kerak?
A: Qayta tiklanadigan hisob-kitoblar (DWH) va to’liq lineage bo’lgan ombor; onlayn-panellar - tezkor nazorat uchun, yuridik hujjatlar uchun emas.

Q: «Ikkita p99» bilan qanday kurashish mumkin?
A: Metriklar katalogida oynani/agregatsiya usulini tuzatish, panellarni ko’chirish, dreyfga alert qo’shish.

Q: Rejali ishlarni qanday hisobga olish kerak?
A: Istisnolar kalendarini yuritish va ularni shartnoma qoidalari bo’yicha SLAdan avtomatik ravishda chegirib tashlash; tasdiqlovchi artefaktlarni saqlash.