GH GambleHub

Əməliyyat və İdarəetmə → Hadisələrin qarşısının alınması

Hadisələrin qarşısının alınması

1) Niyə lazımdır

Hadisəyə ən yaxşı reaksiya onun olmamasıdır. iGaming/fintech üçün hər dəqiqə fasilə - itirilmiş dərəcələr/depozitlər, provayderlərdən cərimələr, reputasiya riskləri. Sistemli profilaktika Change Failure Rate-ni azaldır, SLO-nu sabitləşdirir və yanğınsöndürmə deyil, inkişaf üçün komandaların vaxtını azad edir.

Məqsədlər:
  • Kritik yollarda insident ehtimalını minimuma endirin (depozit, bahis, oyunun başlaması, nəticə).
  • SLO və cüzdan vurulmadan əvvəl deqradasiyanı tutun.
  • Uğursuzluq radiusunu (blast radius) məhdudlaşdırın və bərpanı sürətləndirin.

2) Profilaktikanın əsas prinsipləri

1. SLO-first və error budget: SLO-nu vurmaq və büdcəni yandırmaq riski varsa, dəyişikliklər buraxılmır.
2. Defence in depth: qorunma qatları - verilənlər sxemləri və konfiqurasiya şəbəkə siyasətləri və fitness.
3. Design for failure: breakers, taymauts, jitter retrains, idempotent, deqradasiya.
4. Small & reversible changes: kiçik artımlar + sürətli geri dönüş (feature flags/kanarya).
5. Observability by design: Hər kritik addım və əlaqə üçün metrik/log/treys.

3) Risklər və kritik yollar xəritəsi

Payments, Bets, Games, KYC, Promosyonlar, Jackpots, Content domenləri ilə «ağrı xəritəsi» tərtib edin.

Hər yol üçün qeyd edirik:
  • Biznes metrikası (dönüşüm, GGR, orta çek).
  • Texniki SLO (latency p95/p99, uptime, success rate).
  • Asılılıqlar (daxili/xarici), limitlər/kvotalar.
  • «Safe mode» davranış (biz/asanlaşdırmaq).
  • Runbook sahibi.

4) Guardrails (qoruyucu maneələr)

Taymaut və breykerlər: çağırıcı xidmətin daxili taymaut məbləğindən qısadır; breyker artan səhvlər/gecikmə ilə açılır.
Bulkhead-izolyasiya: ayrı-ayrı bağlantı hovuzları/iş yerləri.
Rate limit & backpressure: uçqunlar və retray fırtınalardan qorunma.
Deqradasiya xüsusiyyətləri: «minimal rejim» - yüngül cavablar, cash-replaylar, ağır fiqurların söndürülməsi.
Multi-satıcı və feylover: alternativ PSP/KYC, marşrutları keçid.
Konfiqurasiya validasiyası: sxemlər/linerlər/siyasətlər təhlükəsiz fiş və limitləri dəyişdirmək üçün.

5) Dəyişikliklərin idarə edilməsi (Change Management)

Pre-release gates: testlər, təhlükəsizlik, CDC (consumer-driven contracts), sxemlərin uyğunluğu.
Kanarya buraxılışı + avtoqeytlər: 1% → 10% → 100%; p99/error rate/yanma büdcəsi artdıqda avtomatik stop.
Feature flags: ani geri/deploi olmadan davranış keçid.
Release calendar: İdman/turnirin pik pəncərələrindən və provayderlərdən maintenance.
Post-deploy checks: avto smoks, «əvvəl/sonra» metriklərinin eşiklərlə müqayisəsi.

6) Qabaqlayıcı tədbir kimi test

Unit/contract/integration: OpenAPI/AsyncAPI, CDC və provayder/moq müqavilələri.
Yük və stress: prime-time üçün trafik profilləri; / IOPS/kvota limitləri testləri.
Soak/long-haul: resurs sızması, saat/gün üfüqündə gecikmələrin artması.
Chaos/game-days: broker/PSP/KYC düşməsi, bölgə qırılması, «yavaş provayder».
Disaster Recovery Drills: Bölgələri dəyişdirmək və BD-ni bərpa etmək üçün müntəzəm məşq.

7) Deqradasiyanın erkən aşkarlanması

Capacity-alerts: headroom, lag növbələri, DB konnektləri, eviction caches.
SLO-burn-rate: büdcənin təhlükəli «yandırma» sürəti ilə siqnal.
Adaptiv eşiklər: mövsümlük/gündəlik saxta azaltmaq üçün şablonlar.
Kompozit alertlər: «lag ↑ + HPA at max + open circuit» ⇒ yüksək risk.
Vendor health: hər bir provayder üçün kvotalar/vaxt/səhvlər + zəng dəyəri.

8) Xarici provayderlərlə iş

OLA/SLA, SLO: Məqsədlərimizlə bağlı razılaşmalar.
Playbooks Feylover: PSP-X PSP-Y marşrutları, tokenlərin cache, grace-depozit rejimləri.
Sandboxlar və müqavilələr: hər əsas dəyişiklik əvvəl test flow.
Provayderlərin pəncərələri: dashboard şərhləri və avtomatik suppress qaydaları.

9) Məlumatlar, konfiqrlər və sirlər

Dəyişiklik siyasəti: iki cüt gözün code-review, sxemlərin təsdiqi/JSON/YAML.
Secrets: KMS/Secrets Manager, rotasiya, mühit/rollar üzrə bölgü.
Bayraqlar/limitlər: audit və ani geri dönüş ilə API vasitəsilə dəyişiklik.
Miqrasiyalar: «iki addım» (expand → migrate → contract), ümumi əks uyğunluq.

10) Təlim və komanda hazırlığı

On-call təlimləri: hadisələrin simulyasiyaları, Shadow vəzifələri, mərkəzləşdirilmiş runbook.
Vahid kommunikasiya formatları: status/hendover/hadisə-yeniləmə şablonları.
Təhlükəsiz mədəniyyət: ittihamsız postmortem, mexaniki səbəblər və qabaqlayıcı hərəkətlər.

11) Dashbord profilaktikası (minimum)

Risk & Readiness: SLO/büdcə, təbəqələr üzrə headroom, «ən həssas əlaqələr».
Change Safety: Kanaryaların faizi, geri çəkilmələr, «buraxılışdan sonra» alertlər, avtoqeytlərin CTR.
Vendor Panel: p95/error/kvotalar/hər bir provayder üçün qiymət, satıcı sapport cavab vaxt.
Chaos/DR Readiness: məşq tezliyi, bölgə keçid vaxtı, bərpa müvəffəqiyyəti.
Config/SecOps: bayraqların/limitlərin/sirlərin, anomaliyaların dəyişdirilməsi.

12) Profilaktik alertlərin nümunələri


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) Check-list qarşısının alınması (gündəlik/pik əvvəl)

  • Cari zirvə təqvimi (matçlar, turnirlər, kampaniyalar, provayderlərin pəncərələri).
  • API/DB/caches/növbələr, HPA/VPA hazırlıq, cache qızdırmaq üçün Headroom.
  • Provayderlərin vəziyyəti (kvotalar, limitlər, 24 saat ərzində deqradasiya), xüsusi faylover.
  • Kanarya geytləri daxildir, geri qaytarma faylları sahiblərinə təqdim olunur.
  • SLO/Capacity alertləri aktivdir, planlaşdırılan işlərə təyin edilmiş suppression.
  • Runbook 'və yenilənmiş, on-zəng təsdiq, eskalasiya kanalları iş.

14) Anti-nümunələr (nə qarşısını almaq)

Kanarya və bayraqsız «Böyük gecə buraxılışları».
Bütün downstream üçün ümumi akış hovuzları (head-of-line blocking).
Qeyri-idempotent əməliyyatlar və dar yerlərin taymautları üçün retrajlar.
Alertlərdə histerezis olmaması → eşik kəsmə.
SDK satıcıya müşahidə edilmədən və zamana nəzarət etmədən kör inanc.
Steyj/sandbox və CDC olmadan «Prod etmək».

15) KPI profilaktikası

Change Failure Rate (hədəf ≤ 10-15% və ya hədəf).
Pre-Incident Detect Rate: deqradasiya mərhələsində qarşısı alınan insidentlərin payı.
Mean Time Between Incidents (MTBI) и MTTR.
Coverage qorunması: bayraqlar/breykerlər/zaman/kanarya ilə kritik yollar%.
Chaos/DR cadence: təlimlərin tezliyi və müvəffəqiyyəti.
Vendor readiness: ehtiyat provayder keçid orta vaxt.

16) Sürətli başlanğıc (30 gün)

Həftə 1: kritik yolların xəritəsi, SLO və sahibləri; SLO-burn-alertləri və capacity-alertləri daxil edin.
Həftə 2: Kanarya geytləri + Ficheflags; əsas chaos ssenariləri (provayder/növbə).
Həftə 3: «Change Safety» və «Vendor Panel» daşbordları, feylover pleybukları.
Həftə 4: DR təlimi (qismən), retrospektiv və rüblük hardening 'a planı.

17) Şablonlar (fraqmentlər)

Kanarya avtoqeyt siyasəti (şərti-YAML):

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]
Deqradasiya planı (xülasə):

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 azdırsa, ilk növbədə nə tətbiq etmək lazımdır?
A: Kritik yollarda SLO-burn-alertlər, kanarya geytləri və geri dönüş ficheflages; sonra - risklər xəritəsi və provayderlərin feyloveri.

Q: Profilaktikanın «işlədiyini» necə başa düşmək olar?
A: Change Failure Rate azalır, qarşısı alınan hadisələrin nisbəti artır, MTTR və alert səs-küyü düşür, «gecə» peyceklərinin sayı azalır.

Q: müntəzəm chaos təlimləri lazımdır?
A: Bəli. Feylover və DR məşq etmədən demək olar ki, həmişə kağız üzərində göründüyündən daha uzun və ağrılı olur.

Contact

Bizimlə əlaqə

Hər hansı sualınız və ya dəstək ehtiyacınız varsa — bizimlə əlaqə saxlayın.Həmişə köməyə hazırıq!

İnteqrasiyaya başla

Email — məcburidir. Telegram və ya WhatsApp — istəyə bağlıdır.

Adınız istəyə bağlı
Email istəyə bağlı
Mövzu istəyə bağlı
Mesaj istəyə bağlı
Telegram istəyə bağlı
@
Əgər Telegram daxil etsəniz — Email ilə yanaşı orada da cavab verəcəyik.
WhatsApp istəyə bağlı
Format: ölkə kodu + nömrə (məsələn, +994XXXXXXXXX).

Düyməyə basmaqla məlumatların işlənməsinə razılıq vermiş olursunuz.