Texnologiya və infrastruktur → Bulud arxitekturası və SLA
Bulud arxitekturası və SLA
1) Niyə SLA və onları necə idarə etmək olar
SLA (Service Level Agreement) - biznes/tərəfdaşlara xidmətin mövcudluğu, sürəti və düzgünlüyü barədə xarici vəd.
SLO (Service Level Objective) - komandalar üçün daxili hədəf səviyyələri.
SLI (Service Level Indicator) - ölçülə bilən metriklər, onların əsasında SLO qiymətləndirilir.
iGaming/fintech üçün sərt zirvə pəncərələri (turnirlər, canlı bahislər, hesabat dövrləri, «maaş» günləri), PSP/KYC provayderlərindən və coğrafiyadan güclü asılılıq xarakterikdir. SLA bu davranışı nəzərə almalıdır və memarlıq yalnız orta deyil, həm də üzlük zəmanəti təmin etməlidir.
2) Əsas terminologiya
Mövcudluq (Availability) - interval üçün uğurlu sorğuların payı.
Gizli - əsas əməliyyatlar üçün P50/P95/P99.
Səhv - dəqiq müəyyən edin (5xx, zaman, iş səhvləri?).
RTO (Recovery Time Objective) - bərpa üçün nə qədər vaxt icazə verilir.
RPO (Recovery Point Objective) - qəza zamanı nə qədər məlumat itirilə bilər.
Error Budget - 1 − SLO, dəyişikliklər və insidentlər üçün «ehtiyat».
3) SLA altında bulud arxitekturası çərçivəsi
3. 1 Çoxzonluq (Multi-AZ)
Status replikasiyası (DB, cache, növbə) minimum 2-3 AZ.
Soyuq/isti stendbay, avtomatik failover.
per-AZ sağlamlıq çekləri ilə yerli balanslaşdırıcılar (L4/L7).
3. 2 Multiregion
Aktiv-aktiv: aşağı RTO/RPO, daha mürəkkəb konsistentlik və dəyəri.
Aktiv-passiv (hot/warm): daha ucuz, RTO daha böyük, lakin daha asan məlumat nəzarət.
Coğrafi marşrut (GeoDNS/Anycast), «blast radius» izolyasiyası.
3. 3 Anbarlar və məlumatlar
Tranzaksiya DB: regionda sinxron replikasiya, regionlararası asinxron.
Cache: cross-regional replikalar, «local reads + async warmup» rejimi.
Obyekt saxlama: version, həyat dövrləri, cross-region replication.
Növbələr/axın: güzgü klasterləri/çox regional axınlar.
3. 4 Kontur izolyasiyası
Kritik xidmətlərin (payments/wallet) və «ağır» analitik vəzifələrin ayrılması.
Rate-limits/quotas kontur arasında hesabatlar «yemək» prod.
4) Yüksək mövcudluq nümunələri
Bulkhead & Pool Isolation - birləşmə və resurs hovuzları izolyasiya.
Circuit Breaker + Timeouts - xarici inteqrasiyanın asılmasına qarşı qorunma.
Idempotency - sorğuları ikiqat silinmədən təkrarlayırıq.
Graceful Degradation - deqradasiya zamanı nefundamental fiçləri (avatarklar, genişlənmiş filtrlər) söndürürük.
Backpressure - gələn axını idarə edin, «üfüqə qədər» növbələrə yol verməyin.
Chaos/Failure Injection - etibarlılıq hipotezlərini yoxlamaq üçün planlaşdırılan «uğursuzluqlar».
5) DR strategiyaları (Disaster Recovery)
Seçim: ödənişlər/cüzdan - minimum Hot Standby; məzmun/kataloq - Warm; hesabatlar - aydın pəncərələri ilə Backup & Restore.
6) SLI/SLO haqqında: düzgün ölçmək üçün necə
6. Səviyyələrə görə 1 SLI
Müştəri SLI: end-to-end (şlyuz və xarici provayderlər daxil olmaqla).
Servis SLI: «təmiz» gizlilik/xidmət səhvləri.
Biznes SLI: CR (qeydiyyat → depozit), T2W (time-to-wallet), PSP-decline rate.
6. 2 SLO nümunələri
Core API mövcudluğu: ≥ 99. 30 gün ərzində 95%.
Payout başlanğıc gecikməsi: P95 ≤ 350 ms, P99 ≤ 700 ms.
PSP vebhuk çatdırılması: ≥ 99. 9% 60 saniyə ərzində (retralar ilə).
Data Freshness Hesabatlar: ≤ 10 min 95% vaxt lag.
6. 3 Error Budget Policy
Büdcənin 50% -i dəyişikliklərə (buraxılışlar/təcrübələr), 50% -i insidentlərə aiddir.
Büdcə yanma → friz fich, yalnız sabitləşmə.
7) Performans və miqyas
SLO yönümlü siqnallarla HPA/VPA (yalnız CPU deyil, həm də növbə/gecikmə).
Cədvəllər və tarixi zirvələr əsasında əvvəlcədən skeylinq.
Warm pools/turnirlər əvvəl DB/PSP üçün ön isitmə bağlantıları.
Caching və edge - xüsusilə oyun kataloqları və statik assets üçün RTT azaltmaq.
8) Şəbəkə təbəqəsi və qlobal trafik
Anycast/GeoDNS latentliyi minimuma endirmək və qəzaları lokallaşdırmaq üçün.
Failover siyasətləri: bölgənin sağlamlıq testləri, eşiklər, TTL ilə «stickiness».
mTLS/WAF/Rate Limit kənarında, bot trafikinə qarşı qorunma.
allow-list və SLA-aware retrains PSP/KYC üçün egress-nəzarət.
9) Məlumatlar və uyğunluq
Uyğunluq səviyyəsinin seçimi: ciddi (payments) vs eventual (kataloq/reytinqlər).
CQRS kritik komandaları oxu və şaquli boşaltmaq üçün.
Outbox/Inbox «rəvan» hadisə çatdırılması üçün.
Downtime olmadan miqrasiya: expand-migrate-contract, MAJOR dəyişiklikləri zamanı ikiqat qeyd.
10) SLA altında müşahidə (Observability)
Şlyuz vasitəsilə treys: partnyor/region/API versiyası ilə 'trace _ id' korrelyasiyası.
burn-rate ilə SLO-daşbordları, regionlar və provayderlər üçün «hava».
Simptomlara görə alertlər, proxy simptomlarına görə deyil (CPU deyil, P99/səhvlər).
Synthetics: hədəf ölkələrindən xarici yoxlamalar (TR, BR, EU...).
Audit və hesabat: SLI/SLO-nun ortaq portala ixracı.
11) Təhlükəsizlik və uyğunluq
Şəbəkə seqmentasiyası və gizli idarəetmə (KMS/Vault).
Uçuş/sülh şifrələmə, PAN/PII tokenlaşdırma.
Administrator/operator rolları üzrə giriş siyasəti.
Audit üçün dəyişməz log (WORM) və retenshn.
Tənzimləyici: bölgədə saxlama, hesabatlar, SLA-nın həyata keçirilməsinin sübuta yetirilməsi.
12) FinOps: dəyər sürücüsü kimi SLA
SLO deviasiyasına qiymət qoyun: nə qədər dəyərlidir + 0. 01% mövcudluğu?
Pik pəncərələri profilləşdirin, sabit gücü şişirməyin.
Arxa plan tapşırıqları üçün Right-sizing və «spot harada».
Kontur üçün kvotalar və büdcələr, «pulsuz» deqradasiyaya yol verməyin.
13) Etibarlılıq testi
GameDay/Chaos-sessiyaları: AZ/PSP-nin söndürülməsi, növbələrin gecikməsi, BGP fasilələri.
DR-drill: RTO hədəfləri ilə bölgələrin keçid müntəzəm təlim.
Load & Soak: real bahis/turnir profilləri ilə uzun qaçış.
Replay hadisələri: məşhur fayllar və oynatma skriptləri kitabxanası.
14) SLA prosessor tərəfi
SLO kataloqu: sahibi, formula, metriklər, mənbələr, alertlər.
RFC/ADR vasitəsilə dəyişikliklər: error budget təsir qiymətləndirilməsi.
Postmortemlər: memarlıq və ranbukların təkmilləşdirilməsi, SLO düzəlişləri.
Tərəfdaşlarla ünsiyyət: poçt, status-səhifə, planned maintenance.
15) SLI/SLO/hesabat nümunələri
15. 1 Düsturlar
SLI_availability = (успешные_запросы / все_запросы) 100%
SLI_latency_P99 = перцентиль_99(латентность_запроса)
SLI_webhook_D+60 = доля вебхуков, доставленных ≤ 60 сек15. 2 Core API üçün SLO dəsti nümunəsi
Mövcudluq (30 gün): 99. 95%
P95 nöqtəsi '/v2/payouts/create ': ≤ 350 ms
5xx səhvləri (1 saat sürüşmə): <0. 3%
Webhook delivery ≤ 60 сек (P99): ≥ 99. 9%
Cüzdan üçün RPO: ≤ 60 san, RTO ≤ 5 dəq
15. 3 SLA hesabatı (sıxma)
Tamamlandı: 99. 97% (SLO 99. 95%) +
Pozuntular: PSP-taymautlar səbəbindən BR bölgəsi üzrə 2 epizod (cəmi 8 dəq).
Tədbirlər: smart-routing uğursuzluq kodları əlavə edilib, PSP-B-yə varm pool bağlantıları artırılıb
16) Giriş çek siyahısı
1. Kritik istifadəçi yolları və müvafiq SLI-lər müəyyən edilmişdir.
2. SLO 30/90 gün + error budget policy.
3. Multi-zonallıq və RTO/RPO məqsədləri ilə DR planı, müntəzəm qazma.
4. Geo-hədəf Synthetics, per-region/per-PSP daşbordları.
5. Dayanıqlılıq nümunələri: circuit breaker, backpressure, idempotency.
6. Deqradasiya siyasəti və feature flags üçün off phics.
7. FinOps: kontur büdcələri, pik proqnozu, warm pools.
8. Təhlükəsizlik: seqmentasiya, şifrələmə, audit.
9. Tərəfdaşlar üçün SLA sənədləşdirilməsi, kommunikasiya prosesi.
10. Retrospektivlər və hər 1-2 rübdə SLO-ya yenidən baxılması.
17) Anti-nümunələr
Ölçülebilir SLI və şəffaf sayma metodologiyası olmadan SLA vəd edin.
Şlyuz/provayderlərə məhəl qoymadan «xidmət girişində» mövcudluğu hesab edin.
P99 quyruqlarına məhəl qoymadan yalnız orta gecikməyə arxalanın.
DR «kağız», real təlim yoxdur.
Limitsiz «əbədi» resurslar: bir hesabat prod.
Bir/DB klasterində prod və ağır analitikanı qarışdırın.
18) Yekun
SLA altında bulud arxitekturası - texniki nümunələrin (multi-AZ/region, izolyasiya, pozulmaya davamlı məlumatlar), proseslərin (SLO, error budget, DR-drili) və iqtisadiyyatın (FinOps) birləşməsidir. Özünüzə proqnozlaşdırılan uğursuzluqlar hüququ verin: uğursuzluğa dözümlülüyü sınaqdan keçirin, üzlükləri ölçün, «partlayış radiusunu» məhdudlaşdırın və açıq şəkildə əlaqə saxlayın. Sonra SLA-nın vədləri marketinq deyil, idarə olunan mühəndislik təcrübəsi olacaq.