SLO, SLA va ishonchlilik monitoringi

(Bo’lim: Texnologiyalar va infratuzilma)

Qisqacha xulosa

SLO - sifatning ichki maqsadi, SLA - mijoz oldidagi tashqi majburiyat, SLI - sifatni qanday o’lchashimiz. iGaming-da asosiy SLI: API va to’lovlarning mavjudligi, tanqidiy yo’nalishlarning yashirin p95/p99, Time-to-Wallet (TTW), to’lovlarni konvertatsiya qilish, o’yinlarni boshlash, shuningdek navbatlar metrikasi. Ishonchlilikni boshqarish xatolar byudjeti, multi-burn alertlari, aniq reliz geytlari va izohli koʻrgazmali dashbordlar atrofida qurilmoqda.

1) Atamalar va farqlar

SLI (Service Level Indicator) - o’lchanadigan indikator (masalan, vaqt oynasi uchun muvaffaqiyatli so’rovlar ulushi).
SLO (Service Level Objective) - SLI maqsadli qiymati (masalan, "foydalanish imkoniyati 99. 30 kun ichida 9%").
SLA (Service Level Agreement) - kompensatsiyalar bilan kontrakt/majburiyat; haqiqiy SLOlarga asoslanadi, lekin yuridik shartlar va istisnolar oynalarini (planned maintenance, fors-major) o’z ichiga oladi.

Qoida: Avval SLI/SLOni ichkarida barqarorlashtiring va shundan keyingina SLAni tashqariga chiqaring.

2) iGaming uchun SLI ramkasi

TexSLO

Availability: muvaffaqiyatli 2xx/3xx/barcha soʻrovlar.
Latency: p95/p99 (’/deposit’, ’/bet’, ’/game/init’).
Errors: 5xx/taymaut ulushi.
Saturation/Queues: to’lov/tranzaksiya navbatlarining kechikishi.

Biznes-SLI

Payment conversion: `success/attempt`.
TTW p95: Hisobdan chiqarish soʻrovidan boshlab qabul qilishgacha boʻlgan vaqt.
Game start success: oʻyinlar sessiyalari, provayderni ishga tushirish.
KYC/AML flow success: yoʻlni muvaffaqiyatli yakunlash.

• Error Budget = 1 − SLO.
• Masalan: 99 ta SLO. 9 %/30d ⇒ xatolar byudjeti = 0. 1% vaqt ≈ 30 kunlik derazada 43min 12s.

success_ratio = success_requests / all_requests error_ratio  = 1 - success_ratio

SLO harakatlanuvchi oynada (30/7/1 kun) hisoblanadi va dashbordlarda ko’rinadi.

• Byudjetning tez yonishi → freeze relizlar, kanareya turib, barqarorlik ustida ishlayapmiz.
• Budjet zaxirasi → tez-tez o’zgarishlarga yo’l qo’yamiz (nazorat qilinadi).

4) Asosiy oqimlar uchun SLO namunalari

• Availability ≥ 99. 9 %/30d
• Latency p95 `/deposit` ≤ 250 ms / 30д
• Payment conversion ≥ baseline − 0. 3 %/24 soat
• TTW p95 (chiqish) ≤ 3 min/24 soat

• Game init success ≥ 99. 5% / 7д p95 game init ≤ 600 ms / 7д

• Job success ≥ 99 %/7d, lag <5 min (eng yuqori oynalar alohida).

5) O’lchash: formulalar va PromQL (g’oyalar)

promql sum(rate(http_requests_total{status=~"2..    3..",service="payments-api"}[5m]))
/
sum(rate(http_requests_total{service="payments-api"}[5m]))

promql histogram_quantile(0. 95,
sum by (le) (rate(http_request_duration_seconds_bucket{service="payments-api",route="/deposit"}[5m])))

promql histogram_quantile(0. 95,
sum by (le) (rate(ttw_seconds_bucket{flow="withdrawal"}[15m])))

promql sum(rate(payments_success_total[15m])) / sum(rate(payments_attempt_total[15m]))

6) Burn-rate alerta (multi-window)

G’oya: byudjet xarajatlarining joriy tezligini maqbul bilan solishtiramiz.

• Fast burn: 1 soat uchun 14 × byudjet → 5-15 daqiqada peyj.
• Slow burn: 24 soat ichida 6 ta byudjet × → chipta, sabablarni tahlil qilish.

yaml recording rule: job:http:success_ratio — заранее alert: SLOFastBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 14 for: 10m labels: { severity: "page" }

alert: SLOSlowBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 6 for: 1h labels: { severity: "ticket" }

7) «SLO-karta» dashbordlari va operatsion

• Servislar bo’yicha kartochkalar: Availability, p95, Error-rate, Burn-rate, qoldiq Error Budget.
• Filterlar:’env’,’region’,’tenant’,’version’.
• Reliz izohlari: Git SHA, turi (canary/blue-green), oʻtish vaqti.

• Stable vs canary.
• PSP/o’yin provayderlari bo’yicha kesim.
• exemplars (trace_id) va bogʻlangan loglarga oʻtish.
• Queue lag va saturation (USE-metrika).

8) SLO-jarayonlar: geytlar, freeze, eskalatsiyalar

CDdagi Gates: kanareyka promousheniga faqat SLO-proksi (availability, p95, conv) bajarilganda ruxsat beriladi.
Freeze: fast-burn yoki nol budjet qoldig’ida - qayta tiklangunga qadar relizlarni to’xtatish.
Eskalatsiyalar: SEV-matritsasi (SEV1 to’lovlar/depozitlar, SEV2 o’yinlar, SEV3 bekofis).
RCA: ayblovlarsiz tahlil qilish, test/limit/fizeflaglarni yangilash.

9) Data/ML-SLO (tavsiya beruvchilar uchun/LLM)

Latency: p95 javob modeli ≤ 300 ms (yoki tokens/s ≥ N).
Quality proxy: valid javoblar/past toksiklik ulushi, share of helpful.
Freshness: fich/maʼlumot yoshi ≤ X soat.
Cost per 1k events: budjetdagi xarajatlar.
SLO-geytlar modellarning relizlariga (A/V/kanar rollout) integratsiyalashadi.

10) SLO negizida SLAni loyihalash

SLA asosi sifatida konservativ SLOlarni tanlang.
Istisnolarni aniqlang (rejali ishlar, tashqi bog’liq provayderlar, hodisalar reglamenti).
Qoidabuzarliklar darajasi bo’yicha kompensatsiyalar (kredit/chegirma), hisobot va verifikatsiya mexanizmlarini kiriting.

11) Tez-tez xatolar va anti-patternlar

SLO yo’q, faqat «uptime 100%» haqiqiy emas, demotivatsiya qiladi va xavflarni yashiradi.
Burn-rate o’rniga «har bir metrika» bo’yicha alertlar - alert-fetig va ignor.
SLO uchun metrik/loglarda PII aralashmasi - komplayens xavfi.
Kardinallik yorliq kabi portlaydi.
Relizlarning izohlari yo’qligi - degradatsiyalarni o’zgarishlar bilan bog’lash qiyin.
Xatolar uchun shaffof bo’lmagan byudjet - buyruq qachon xavf ostida qolishni tushunmaydi.
SLO biznes bilan bog’liq emas - «yashil» texnometriklar, «qizil» daromad.

12) Joriy etish chek-varaqasi

1. Bazaviy SLI (Availability, p95/p99, Error-rate, TTW, Conversion) ni tasdiqlang.
2. 30/7/1 kunlik oynalarda SLO’ni o’rnating va Error Budget hisoblang.
3. recording rules va burn-rate alerta (fast/slow) qoʻshing.
4. Relizlar izohlari va canary/stable taqqoslamalari bilan SLO kartasini yarating.
5. CDga geytlarni kiriting: SLO-oksiz - promoushensiz.
6. Freze va SEV eskalatsiya matritsasini kiriting.
7. SLOni biznes-metriklar (conv, TTW) va to’lov yo’nalishlari bilan bog’lang.
8. Data/ML uchun latency/quality/freshness-SLO ni aniqlang.
9. Muntazam RCA va SLO/chegaralarni qayta ko’rib chiqish (har chorakda).
10. SLO barqarorlashgandan keyingina SLAni hujjatlashtiring.

13) «Tayyor» maqsadlar misollari (start sifatida)

Umumiy API: Availability 99. 9 %/30d; p95 ≤ 250 ms/30d; Error-rate ≤ 0. 3 %/30d.
Payments: Conversion ≥ baseline − 0. 3 %/24 soat; TTW p95 ≤ 3 min/24 soat.
Games init: Success ≥ 99. 5 %/7d; p95 ≤ 600 ms/7d.
Backoffice jobs: Success ≥ 99%/7д; lag ≤ 5 min/7d.
LLM/Reco: tokens/s ≥ N, toxicity viol. ≤ 0. 5 %/7d, freshness ≤ 6 soat.

Yakunlar

SLO/SLA yondashuvi ishonchlilikni «kechagidan yaxshiroq» o’lchanadigan fanga aylantiradi: shaffof SLI, tushunarli xato byudjeti, yonish tezligi uchun alertlar, tushunarli dashbordlar va relizlarga kiritilgan sifat geytalari. Bunday kontur iGaming platformasiga oldindan aytib bo’ladigan p95/p99, barqaror to’lovlar va TTW, ya’ni eng yaxshi daromad va eng issiq soatlarda kamroq hodisalar beradi.