Operatsiyalar va Boshqaruv → Hodisalarning oldini olish

Hodisalarning oldini olish

1) Nima uchun bu zarur?

Hodisaga eng yaxshi munosabat - uning yo’qligi. iGaming/fintech uchun ishlamay qolishning har bir daqiqasi - yo’qotilgan stavkalar/depozitlar, provayderlardan olinadigan jarimalar, obro "-e’tibor xavfi. Tizimli profilaktika Change Failure Rate ni kamaytiradi, SLOni barqarorlashtiradi va yong’inlarni o’chirish uchun emas, balki rivojlanish uchun vaqt ajratadi.

• Tanqidiy yo’llarda sodir bo’lgan hodisalar ehtimolini minimallashtirish (depozit, stavka, o’yinni boshlash, chiqish).
• SLO va hamyonga urilgunga qadar tanazzulni ushlash.
• Rad etish radiusini cheklash va tiklashni tezlashtirish.

2) Profilaktikaning bazaviy prinsiplari

1. SLO-first va error budget: Agar SLOni buzib, byudjetni yoqib yuborish xavfi bo’lsa, o’zgarishlar chiqarilmaydi.
2. Defence in depth: himoyalash qatlamlari - maʼlumot sxemalari va konfiguratsiyalaridan tortib tarmoq siyosati va ficheflaglargacha.
3. Design for failure: breykerlar, taymautlar, jitter retraalari, idempotentlik, degradatsiyalar.
4. Small & reversible changes: kichik inkrementlar + tez qaytish (feature flags/kanareyka).
5. Observability by design: har bir muhim qadam va aloqa uchun metriklar/loglar/treyslar.

3) Tavakkalchiliklar va tanqidiy yo’llar xaritasi

Payments, Bets, Games, KYC, Promotions, Jackpots, Content domenlari bo’yicha «og’riq xaritasi» tuzing.

• Biznes-metrika (konvertatsiya, GGR, o’rtacha chek).
• Texnik SLO (latency p95/p99, uptime, success rate).
• Qaramliklar (ichki/tashqi), limitlar/kvotalar.
• «Safe mode» (oʻchirish/soddalashtirish).
• Egasining Runbook.

4) Guardrails (himoya to’siqlari)

Taymautlar va breykerlar: chaqiruvchi servisning ichki taymautlari summasidan qisqaroq; breyker xato/yashirin ko’payganda ochiladi.
Bulkhead-izolyatsiya: alohida birikmalar/vorkerlar hovuzlari.
Rate limit & backpressure: qor ko’chkisi va retraj bo’ronlardan himoya qilish.
Buzilish ficheflaglari: «minimal rejim» - oson javoblar, kesh-replaylar, og’ir fichlarni o’chirish.
Multi-vendor va faylover: muqobil PSP/KYC, yo’nalishlarni o’zgartirish.
Fich va limitlarni xavfsiz oʻzgartirish uchun moslamalar/linyerlar/siyosatlarni validatsiya qilish.

5) O’zgarishlarni boshqarish (Change Management)

Pre-release gates: testlar, xavfsizlik, CDC (consumer-driven contracts), sxemalarning mosligi.
Kanar relizi + avtogeytlar: 1% → 10% → 100%; p99/error rate/yonish byudjeti o’sganda avto-to’xtash.
Feature flags: deploysiz xatti-harakatlarni tezda qaytarish/oʻzgartirish.
Release calendar: Biz provayderlarda eng yuqori sport/turnir va maintenance oynalaridan qochamiz.
Post-deploy checks: avto smok, «oldin/keyin» metriklarini chegaralar bilan taqqoslash.

6) Test sinovi preventiv chora sifatida

Unit/contract/integration: OpenAPI/AsyncAPI, CDC vs provayder/moq.
Load & stress: praym taym uchun trafik profillari; konnektlar/IOPS/kvotalar limitlari bo’yicha testlar.
Soak/long-haul: resurslar oqishi, soat/kun ufqida kechikishlar ko’payishi.
Chaos/game-days: brokerning qulashi/PSP/KYC, mintaqaning uzilishi, «sekin provayder».
Disaster Recovery Drills: hududlarni o’zgartirish va ma’lumotlar bazasini tiklash bo’yicha muntazam mashg’ulotlar.

7) Tanazzullarni erta aniqlash

Capacity-alerts: headroom, lag navbatlar, BD konnektlari, eviction keshlarda.
SLO-burn-rate: budjetni «yoqish» xavfli tezligida signal.
Moslashuvchan chegaralar: mavsumiylik/yolg’onlarni kamaytirish uchun sutkalik shablonlar.
Tarkibiy alertlar: «lag ↑ + HPA at max + open circuit» ⇒ yuqori xavf.
Vendor health: har bir provayder uchun kvotalar/taymautlar/xatolar + qo’ng’iroqlar qiymati.

8) Tashqi provayderlar bilan ishlash

OLA/SLA SLO: kelishuvlarni maqsadlarimizga bogʻlash.
Playbooks feylover: PSP-X PSP-Y yo’nalishlari, tokenlar keshi, grace-depozit rejimlari.
Sandboxlar va kontraktlar: har bir major o’zgarishidan oldin test flolari.
Provayderlar oynalari: dashbordlardagi izohlar va avtomatik suppress-qoidalar.

9) Ma’lumotlar, konfiguratsiyalar va sirlar

Oʻzgartirish siyosati: ikki juft koʻzning code-review, sxemalarning validatsiyasi/JSON/YAML.
Sirlar: KMS/Secrets Manager, rotatsiya, atrof-muhit/rollarga bo’linish.
Bayroqlar/limitlar: audit va darhol qaytish bilan API orqali o’zgartirish.
Migratsiyalar: «ikki qadam» (expand → migrate → contract), umumiy teskari moslik.

10) O’qitish va jamoalarning tayyorgarligi

On-call treninglar: hodisalar simulyatsiyasi, Shadow-navbatchilik, markazlashtirilgan runbook’lar.
Yagona aloqa formatlari: status/hendover/hodisa-yangiliklar shablonlari.
Xavfsiz madaniyat: ayblovsiz postmortem, mexanik sabablar va preventiv harakatlar.

11) Profilaktika dashbordlari (minimal)

Risk & Readiness: SLO/budjet, qatlamlar bo’yicha headroom, «eng zaif aloqalar».
Change Safety: kanareykalar, konkurslar, «relizdan keyingi» alertlar, avtogeytlarning CTR foizi.
Vendor Panel: p95/error/kvotalar/har bir provayder uchun qiymat, vendor sapporti javob berish vaqti.
Chaos/DR Readiness: mashqlar chastotasi, mintaqani o’zgartirish vaqti, tiklanish muvaffaqiyati.
Config/SecOps: bayroqlar/limitlar/sirlarni oʻzgartirish, anomaliyalar.

12) Preventiv alertlar namunalari

ALERT SLOBurnRateHigh
IF slo_error_budget_burnrate{name="payments_api"} > 4 FOR 10m
LABELS {severity="critical", team="payments"}

ALERT PostDeployRegression
IF (api_p99_ms{service="bets"} > baseline_1d 1. 3) AND (release_window="canary")
FOR 10m
LABELS {severity="warning", team="bets"}

ALERT ProviderQuotaNearLimit
IF usage_quota_ratio{provider="psp_x"} > 0. 9 FOR 5m
LABELS {severity="warning", team="integrations"}

ALERT QueueLagAtRisk
IF (kafka_consumer_lag{topic="ledger"} > 5e6 AND rate(kafka_consumer_lag[5m]) > 5e4)
AND (hpa_desired == hpa_max)
FOR 10m
LABELS {severity="critical", team="streaming"}

13) Oldini olish chek-varaqasi (har kuni/cho’qqilardan oldin)

• Cho’qqilarning dolzarb taqvimi (o’yinlar, turnirlar, kampaniyalar, provayderlar oynalari).
• API/DB/keshlar/navbatlar bo’yicha Headroom, HPA/VPA tayyorligi, keshlarni isitish.
• Provayderlarning holati (kvotalar, limitlar, 24 soatlik degradatsiyalar), feylover sozlangan.
• Kanar geytlari yoqilgan, qaytish ficheflaglari egalari uchun mavjud.
• SLO/Capacity alertlari faol, suppression rejalashtirilgan ishlarga belgilangan.
• Runbook’va yangilangan, on-call tasdiqlangan, eskalatsiya kanallari ishlamoqda.

14) Anti-patternlar (nimadan qochish kerak)

Kanareyka va bayroqsiz «Katta tungi relizlar».
Barcha downstrimlar uchun umumiy oqim hovuzlari (head-of-line blocking).
Noidempotent operatsiyalar va tor o’rinlar taymautlari uchun retrajlar.
Alertlarda gisterezis yo’qligi → eshik bo’ylab kesish.
Vendorning SDKsiga ko’r-ko’rona ishonch kuzatilmasdan va vaqtni boshqarmasdan.
Steyj/sandbox va CDCsiz «Prodda qilamiz».

15) KPI profilaktika

Change Failure Rate (maqsad ≤ 10-15% yoki maqsadli).
Pre-Incident Detect Rate: degradatsiya bosqichida oldini olingan hodisalar ulushi.
Mean Time Between Incidents (MTBI) и MTTR.
Coverage himoyasi: bayroqlar/breykerlar/taymautlar/kanareykali muhim yo’llar%.
Chaos/DR cadence: mashqlarning chastotasi va muvaffaqiyati.
Vendor readiness: zaxira provayderga oʻtishning oʻrtacha vaqti.

16) Tez boshlash (30 kun)

1-hafta: muhim yo’llar xaritasi, SLO va egalari; SLO-burn-alertlar va capacity-alertlarni o’z ichiga oladi.
2-hafta: kanareyka geytlari + ficheflaglar; bazaviy chaos-ssenariylar (provayder/navbat).
3-hafta: «Change Safety» va «Vendor Panel» dashbordlari, feylover-pleybuklar.
4-hafta: DR-mashqlar (qisman), retrospektiv va choraklik hardening’a rejasi.

17) Shablonlar (parchalar)

canary_policy:
guardrails:
- metric: api_p99_ms threshold: 1. 3 baseline_1d window: 10m action: pause_and_rollback
- metric: error_rate threshold: 2 baseline_1d window: 5m action: pause max_step: 10%
step_interval: 15m required_annotations: [release_notes, feature_flags, runbook_link]

safe_mode:
payments:
- freeze_heavy_providers
- enable_cached_token_flow
- route_to_psp_y_if(psp_x_error_rate > 5%)
games:
- limit_broadcasts
- reduce_lobby_heavy_widgets bets:
- raise_risk_score_threshold
- cache_odds_snapshot

18) FAQ

Q: Resurslar kam bo’lsa, birinchi navbatda nimani amalga oshirish kerak?
A: kritik yo’llardagi SLO-burn-alertlar, kanareya geytlari va qaytish ficheflaglari; so’ngra - xavflar xaritasi va provayderlar feyloveri.

Q: Profilaktika «ishlayotganini» qanday tushunish mumkin?
A: Change Failure Rate kamayadi, oldini olingan hodisalar ulushi ortadi, MTTR va alertlar shovqini pasayadi, «tungi» peyjlar soni kamayadi.

Q: Muntazam chaos-mashqlar kerakmi?
A: Ha. Mashq qilmasdan, feylover va DR deyarli har doim qog’ozdagidan uzoqroq va og’riqli bo’ladi.