Əməliyyatlar və İdarəetmə → Əməliyyat infrastrukturunun miqyası

Əməliyyat infrastrukturunun genişləndirilməsi

1) Nə üçün və nəyi «miqyaslı» hesab etmək

Ölçmə platformanın SLO itkisi olmadan və nəzarət olunan maya dəyəri ilə bant genişliyini (RPS/TPS, konnektlər, IOPS, throughput) və məlumat həcmini artırmaq üçün sistem qabiliyyətidir. iGaming/fintech üçün bu birbaşa pul haqqındadır: depozitlərin/bahislərin konvertasiyası, canlı oyunlar və hesablaşmalar.

• X yük artımı və mövsümi zirvələrdə SLO saxlayın.
• Proqnozlaşdırıla bilən miqyas vaxtını təmin edin (minutes, not hours).
• İqtisadiyyatı saxla: cost/RPS, cost/əməliyyat, cost/1k hadisələr.

2) Ölçülə bilən platformanın prinsipləri

1. Horizontal-ilk: kiçik bölünməsi, stateless-services; dövlət - məlumat klasterlərində.
2. Back-pressure və növbələr: sıçrayışların hamarlanması, «fırtınalardan» qorunma.
3. Bütün qatlarda caching: client/edge/service/DB.
4. İdempotentlik və təkrarlanabilirlik: təhlükəsiz retralar, outbox, dedup.
5. Məhdudiyyətlərlə asılılıq: taymaut, breyker, bulkhead-izolyasiya, rate-limits.
6. Tutum siqnalları ilə müşahidə: headroom, p95/p99, lag, konnektlər, kvotalar.
7. HPA/VPA/Cluster Autoscaler + stop şərtləri.
8. Multi-region by design: müstəqil blast zonaları, lokal məlumatlar, davamlı fayloverlər.

3) Capacity planning: necə «hesablamaq lazımdır»

Model girişləri: hədəf pik TPS, trafik profili (saatlıq), «kritik yollar», cash-hit əmsalları, orta payloadlar, SLO və provayder limitləri.

• RPS → CPU/pod: 'pod = RPS p99_time/effektiv _ CPU _ pod' (30-50% ehtiyatı ilə).
• Növbələr: 'minimum _ sürət _ konsumer ≥ pik _ sürət _ prodüser 1. 2`.
• DB konnektləri: 'max _ conns = aktiv _ hovuzlar _ orta _ pool _ size 1. 3`.
• Cache: ölçüsü = «N dəqiqə üçün isti working-set» + 20-30% ehtiyat.
• Egress/CDN: pik egress = pik sorğular orta cavab ölçüsü (kompres nəzərə).

Headroom: Hədəf 20-40% pik (laylar üzrə). Aşağıda 15% → trigger «capacity uplift».

4) Təbəqələr və ölçü nümunələri

4. 1 Edge / CDN / WAF

Kənarda caching (TTL + SWR), geo-balans, sıxılma, HTTP/2/3.
Rate-limits IP/JWT/key perimetri, sıçrama qorunması.
broker/pub/sub kanalları vasitəsilə hadisələrin (jackpotlar, canlı xəbərdarlıqlar) fan-out.

4. 2 API-şlyuz/Backend-for-Frontend

Statles-pod üfüqi miqyaslı, dedicated hovuzlar downstream.
İş metrləri üzrə HPA: RPS, p99, work hovuzunda növbə - yalnız CPU deyil.

4. 3 Asinxron növbələr/axın (Kafka/Rabbit/Pulsar)

Partiyalar və konsumerlərə görə miqyas; skew qarşısını almaq (açarları və paylanması).
Lag-alertlər + avto-miqyaslı konsumerlər; DLQ və retry-topics.
Retention SLA reconcilation və replay altında.

4. 4 Caches (Redis/Memcached)

Klaster rejimləri, replikalar, eviction-policies (LFU), multiget, pipeline.
Hot-key və fon vəzifələrinin bölünməsi, müştəri limitləri və max-memory policy.

4. 5 Verilənlər bazası

Read-replications və routing oxu, connection pooling.
Bölgə/tenant/açar diapazonuna görə şardlama.
CQRS: yazılar - master/lider, oxu - replika.
İşlərin indeksləşdirilməsi və betch yazılması (outbox → stream → sink).
Arxivləşdirmə və isti/soyuq məlumatlar (tiering).

4. 6 Fayl/obyekt anbarları

Multi-axın, multipart-download, CDN-ön, asenxron transformasiya.
Provayder kvotaları, «quyruqların» təmizlənməsi və büdcə egress.

4. 7 Provayderlər (PSP/KYC/Studios)

Çox satıcı və kvota marşrutu/SLO/dəyəri.
Hər bir provayder üçün circuit breaker + rate-limit, retray növbəsi, «grace-rejimləri».

5) Avto-miqyaslı və qard-relslər

• HPA: метрики `rps_per_pod`, `queue_depth`, `p99_latency`; `targetAverageValue`.
• VPA: resurslar üzrə tövsiyələr; zirvədən kənarda yeniləmək.
• Cluster Autoscaler: prioritetləri olan nod qrup profilləri (spot + on-demand).
• PodDisruptionBudget/TopologySpreadConstraints: zonalar üzrə vahid.
• LimitRange/ResourceQuota: «sərxoş» deploes qarşı müdafiə.

apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler spec:
scaleTargetRef: {apiVersion: apps/v1, kind: Deployment, name: api-gw}
minReplicas: 8 maxReplicas: 200 metrics:
- type: Pods pods:
metric:
name: rps_per_pod target:
type: AverageValue averageValue: "120"
- type: Pods pods:
metric:
name: p99_latency_ms target:
type: AverageValue averageValue: "280"
behavior:
scaleUp:
stabilizationWindowSeconds: 90 scaleDown:
stabilizationWindowSeconds: 300

• «Pause & Rollback», əgər kanareyk p99> 1. 3 × baseline 10 dəqiqə.
• «Freeze scale-down» prime-time, yalnız scale-up.
• «Stop retries» -də 'open _ circuit = 1' dar yerlərə.

6) Multi-region: aktiv/aktiv və aktiv/passiv

Blast-təcrid olunmuş regionlar: müstəqil klasterlər, yerli sirlər/kvotalar.
Qlobal marşrutlaşdırma: latency-/geo-based, health-probes, əl override.

• İsti - yerli + eventual replikasiya (axınlar).
• Kritik əməliyyatlar - domenlə razılaşdırılmış (ledger/balans).
• Failover playbook: addım-addım mənbə dəyişikliyi, TTL, cache qızdırılması.
• Məşq Qaydaları (DR): RTO/RPO məqsədləri ilə rüblük məşq.

7) Şəbəkə və xidmət nümunələri

Service Mesh: mTLS, retry/breaker, outlier detection, per-downstream limitləri.
eBPF/Observability L4/L7, bağlantı limitləri, head-of-line qorunması.
S2S üçün daxili API şlyuzları, ümumi rate-limit və audit.
VPC/blast zona alt şəbəkələri, NAT/Egress nəzarət, satıcılarla peering.

8) Performans: testlər və sübut

Prime time + worst-case profilinə yük və stress.
Soak (uzun müddətli) - yaddaş/deskriptor sızması, latency artımı.
Chaos/game-days: broker/provayder/zonanın düşməsi, «yavaş provayder».
CI perf-reqressiya: istinad ssenariləri və avtomatik geytlər dəsti.

9) Data və saxlama: böyümə strategiyaları

"Tavan 'a şaquli böyümə → üfüqi/çardaq.
Oxu → replikalar/cache; → batch/asinxron/jurnal qeydləri.
Sxemlərin miqrasiyası: qlobal bloklar olmadan expand → migrate → contract.
Arxivləşdirmə: soyuq hissələr ucuz saxlama + on-demand yenidən hidrasiya.
Axtarış: fərdi indekslər (OpenSearch/Solr) əlavə yeniləmələr paylayıcı ilə.

10) Provayderlərin və kvotaların idarə edilməsi

Kvota kartı (TPS, pəncərələr, xərclər); alertlər 'usage _ ratio> 0. 9`.
Qiymət/keyfiyyətə görə routing (smart routing).
OLA, SLO müqavilələri və kvotaların artırılması prosesi.
Alternativlər hovuzu və «isti» keçid.

11) Müşahidə və miqyaslı siqnallar

• Capacity headroom по слоям; `queue_lag/backlog growth`; `kafka ISR`; `db connections`/`repl lag`; `redis evictions`; `open_circuit`/`retry_rate`; `quota_usage`.
• Business Metrics: success rate/depozit dönüşüm, oyunun başlanğıc vaxtı.
• Dəyəri: cost/RPS, cost/1k calls.

• Capacity Overview (headroom, top risklər, burn-rate SLO).
• Stream & Queue Panel (lag/backlog, consumer saturation).
• DB & Cache (p99, konnektlər, hit/evictions).
• Providers & Quotas (TPS, timeouts, dəyəri, keçid).
• Change Safety (buraxılışdan əvvəl/sonra, kanareyka, avtoqeytlər).

ALERT HeadroomLowAPI
IF capacity_headroom{layer="api"} < 0. 15 FOR 10m

ALERT KafkaBacklogAtRisk
IF (consumer_lag > 5e6 AND rate(consumer_lag[5m]) > 5e4) AND (hpa_desired == hpa_max) FOR 10m

ALERT DBConnectionsNearMax
IF active_conns / max_conns > 0. 85 FOR 5m

ALERT ProviderQuota90
IF usage_quota_ratio > 0. 9 FOR 5m

12) FinOps: sərfəli ölçmək

Effektivlik əmsalları: cost/RPS, cost/depozit, cost/1k hadisələr.
Right-sizing: VPA/tövsiyələr, «over-provisioned» hesabatları.
Qeyri-kritik üçün Spot/Preemptible; Reserved/Committed əsas yük üçün.
Egress-büdcə və caching, CDN/edge-offload.
Logların dəyərinə görə toplanması və arxivləşdirilməsi (hot vs cold).
Xəbərdarlıq kvotaları (soft-cap) və genişləndirilməsi üçün avto-biletlər.

13) Proseslər və insanlar

Change Management: kanaryalar, fitness, reqressiya dayanacaqları.
Hazırlıq hadisəsi: runbook 'i «harada tutum əlavə etmək», «bölgəni necə dəyişdirmək olar».
Zirvələrin planlaşdırılması: matçların/turnirlərin/kampaniyaların təqvimi və provayderlərin pəncərələri.
Müntəzəm game-days və DR-təlimlər.
Sahiblik matrisi: Kim «düyməni sıxa bilər» faylover/artan kvota.

14) Giriş yoxlama vərəqləri

• Kritik yollar və limitlər xəritəsi (laylar üzrə), headroom məqsədi ≥ 30%.
• HPA biznes metrik + Cluster Autoscaler; PDB/SpreadConstraints.
• Qaynar yollarda növbələr, idempotency-keys, outbox.
• Cashes: hit hədəfləri ≥ 90%, evictions siyasəti, əsas indekslər.
• DB: read-replications, pool konnektlər, charding planı.
• Provayderlər: multi-satıcı, kvotalar, breykerlər/retralar.
• Dashboard «Capacity/Stream/DB/Providers», 11.
• Kanarya və avtoheytlər «buraxılışdan əvvəl/sonra».
• DR playbook və bir qismən feylover təlim.

• Qızdırma cache, ön skail HPA/ASG, warm-standby replica.
• Smart-routing daxil provayder kvotaların artırılması.
• Kritik olmayan alertlər üçün gecə rejimində sıxışdırıcıların daxil edilməsi.
• «safe mode» fitzeflagı dərhal işə salınmağa hazırdır.

15) Anti-nümunələr

Şaquli upgrade üfüqi əvəzinə «dik».
Bütün alt axınlarda ümumi axın/əlaqə hovuzu (head-of-line).
Dar yerlərin taymautlarında retrajlar, jitter → fırtına yoxdur.
Alert və scale siyasətlərində histerezis yoxdur → «kəsmə».
Charding və məlumat lokalizasiyası olmadan vahid qlobal DB.
Zaman/retraut/müşahidə nəzarət olmadan SDK satıcı kor inam.
DR təlimlərinin olmaması: feylover «yalnız kağız üzərində».

16) KPI miqyaslı

Zirvədə SLO-riayət (p95/p99, success rate).
Headroom prime time layları üzrə.
MTTS (Mean Time To Scale) - əlavə resursların görünməsinə qədər.
Backlog/Lag Resolution Time - zirvədən sonra növbələrin çökmə vaxtı.
Aktiv artım dövrü üçün Change Failure Rate.
Cost/RPS və cache/CDN/edge-offload qənaət.
DR Readiness: Məşqlərdə RTO/RPO.

17) «Sürətli» şablon nümunələri

partitions(topic="bets") = ceil(peak_msgs_per_sec / target_msgs_per_partition)
consumers = min(partitions, max_pods); rebalance_on: skew > 1. 5x scale_up_if: lag > 5e5 && rate(lag[5m]) > 5e4

max_connections = poolers pool_size 1. 3 read_routing: primary (write), replicas (read majority)
shard_key: tenant_id or region_id

maxmemory-policy: allkeys-lfu cluster-replicas: 1 evict-alert: rate(evictions[5m]) > 0 && used_mem/limit > 0. 8

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

18) FAQ

Q: İlk nə ölçmək lazımdır?
A: Dashboard məlumatlarına görə dar yerlər: növbələr/caches/DB oxu. İsti yollar (depozit/bahis/oyunun başlaması) prioritetdir.

Q: Avtomatik miqyasın «daha da pisləşdiyini» necə başa düşmək olar?
A: Korrelyasiyaya baxın: scale-up ↑ və p99/səhvlər yaxşılaşmır - bəlkə də siz «problemi genişləndirirsiniz» (dar axın/kvota). Breakers/deqradasiya daxil edin.

Q: Həmişə ikinci bir provayder lazımdır?
A: Kritik yollar üçün - bəli. Əks halda, ən azı sadələşdirilmiş ssenari və cache ilə «safe mode».

Q: Active-active или active-passive?
A: RTO tələbləri aşağı və bir çox regional oyunçular varsa - active-active. Əks təqdirdə, işlənmiş bir feylover ilə active-passive ilə başlayın.