Operatsiyalar va Boshqaruv → Operatsion infratuzilmani ko’paytirish

Operatsion infratuzilmani ko’paytirish

1) Nima uchun va nimani «masshtablash» deb hisoblash kerak

Masshtablash - bu platformaning o’tkazish qobiliyatini (RPS/TPS, konnektlar, IOPS, throughput) va ma’lumotlar hajmini SLO yo’qotmasdan va nazorat qilinadigan tannarxga ega bo’lgan tizimli qobiliyatidir. iGaming/fintech uchun bu to’g’ridan-to’g’ri pul haqida: depozitlar/stavkalar konvertatsiyasi, live-o’yinlar va hisob-kitoblar.

• SLOni yuklamaning X baravar o’sishi va mavsumiy cho’qqilarda ushlab turish.
• Taxminiy kattalashtirish vaqtini (minutes, not hours) taʼminlash.
• Iqtisodiyotni saqlash: cost/RPS, cost/tranzaksiya, cost/1k hodisalar.

2) Kengaytiriladigan platforma prinsiplari

1. Gorizontal-birinchi: kichik, stateless-servislarga bo’lish; holat - ma’lumotlar klasterlarida.
2. Back-pressure va navbatlar: portlashlarni tekislash, «bo’ronlar» dan himoya qilish.
3. Hamma qatlamlarda kesh qilish: client/edge/service/DB.
4. Idempotentlik va takrorlanuvchanlik: xavfsiz retralar, outbox, dedup.
5. Cheklovlar bilan bog’liqlik: taymautlar, breykerlar, bulkhead-izolyatsiya, rate-limits.
6. Signallar bo’yicha kuzatish qobiliyati: headroom, p95/p99, lag, konnektlar, kvotalar.
7. HPA/VPA/Cluster Autoscaler + to’xtash shartlari.
8. Multi-region by design: mustaqil blast zonalar, lokal maʼlumotlar, barqaror fayloverlar.

3) Capacity planning: «qancha hisoblash kerak»

Model kirishlari: maqsadli eng yuqori TPS, trafik profili (soatbay), «kritik yo’llar», kesh-xit koeffitsiyentlari, o’rtacha payload’lar, SLO va provayderlar limitlari.

• RPS → CPU/pod:’pod = RPS p99_time/samarali _ CPU _ pod’(30-50% zaxirali).
• Navbatlar:’minimal _ tezlik _ konsumerlar ≥ eng yuqori _ tezlik _ prodyuserlar 1. 2`.
• DB konnektlari:’max _ conns = aktiv _ polar _ servislar oʻrta _ pool _ size 1. 3`.
• Kesh: hajmi = «N daqiqa uchun issiq working-set» + 20-30% zaxira.
• Egress/CDN: so’rovlarning cho’qqisi egress = so’rovlarning cho’qqisi javobning o’rtacha o’lchami (kompresssiyani hisobga olish).

Headroom: maqsad 20-40% choʻqqida (qatlamlar boʻyicha). Quyidagi 15% → trigger «capacity uplift».

4) Ko’paytirish qatlamlari va patternlari

4. 1 Edge / CDN / WAF

Chetda keshlash (TTL + SWR), geo-balans, siqish, HTTP/2/3.
Rate-limits IP/JWT/kaliti bo’yicha perimetrda, portlashlardan himoya qilish.
Brokerlar/pub/sub kanallari orqali fan-aut hodisalar (jekpotlar, live-ogohlantirishlar).

4. 2 API-shlyuz/Backend-for-Frontend

Statles-poda bo’yicha gorizontal masshtablash, daunstrimlarga dedicated pullar.
Biznes-metrlar bo’yicha HPA: RPS, p99, vork-pulda navbat - nafaqat CPU.

4. 3 Asinxron navbatlar/striming (Kafka/Rabbit/Pulsar)

Partiyalar va konsumerlar bo’yicha ko’lami; skew (kalitlar va taqsimlash) dan qochish.
Lag-alertlar + konsumerlarni avto-masshtablash; DLQ va retry-topiklar.
Retention SLA rekonsilatsiya va replay ostida.

4. 4 Keshlar (Redis/Memcached)

Klaster rejimlari, replikalar, eviction-siyosatlar (LFU), multiget, pipeline.
Hot-key’lar va fon vazifalarini ajratish, mijozlar limitlari va max-memory policy.

4. 5 Ma’lumotlar bazasi

O’qish nusxalari va routing, connection pooling.
Mintaqa/tenant/kalitlar diapazoni boʻyicha shardlash.
CQRS: yozuv - master/lider, oʻqish - replika.
Indekslash va betch yozish mashqlari (outbox → stream → sink).
Arxivlash va issiq/sovuq ma’lumotlar (tiering).

4. 6 Fayl/obyekt saqlovchilari

Ko’p oqimli, multipart yuklash, CDN-front, asinxron transformatsiyalar.
Provayder kvotalari, «dumlarini» tozalash va egress budjeti.

4. 7 Provayderlar (PSP/KYC/studiyalar)

Kvotalar/SLO/qiymati bo’yicha multi-vendor va marshrutlash.
Har bir provayderga Circuit breaker + rate-limit, retraylar navbati, «grace-rejimlar».

5) Avto-masshtablash va gard-reylar

• HPA: метрики `rps_per_pod`, `queue_depth`, `p99_latency`; `targetAverageValue`.
• VPA: resurslar bo’yicha tavsiyalar; choʻqqidan tashqarida yangilash.
• Cluster Autoscaler: nod-guruh profillari (spot + on-demand).
• PodDisruptionBudget/TopologySpreadConstraints: zonalar boʻyicha bir tekislik.
• LimitRange/ResourceQuota: «mast» deplolardan himoya qilish.

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», agar kanareykada p99> 1. 3 × bazeline 10 daqiqa.
• «Freeze scale-down» praym-taymda, faqat scale-up.
• ’open _ circuit = 1’ dagi’Stop retries’tor joylarga.

6) Multi-region: aktiv/aktiv va aktiv/passiv

Blast-izolyatsiya qilingan hududlar: mustaqil klasterlar, mahalliy sirlar/kvotalar.
Global routing: latency-/geo-based, health-probes, qoʻlda override.

• Issiq - lokal + eventual replikatsiya (oqim).
• Kritik tranzaksiyalar - domen bo’yicha kelishilgan (ledger/balanslar).
• Faylover pleybuklar: manbani bosqichma-bosqich almashtirish, TTL, keshni isitish.
• Mashqlar reglamenti (DR): RTO/RPO maqsadli choraklik mashqlar.

7) Tarmoq va servis patternlari

Service Mesh: mTLS, retry/breaker, outlier detection, per-downstream limitlari.
eBPF/Observability L4/L7, ulanish limitlari, head-of-line himoyasi.
S2S uchun ichki API-shlyuzlar, umumiy rate-limit va audit.
VPC/blast-zonalar bo’yicha kichik tarmoqlar, NAT/Egress nazorati, vendorlar bilan peering.

8) Unumdorlik: testlar va dalillar

Praym taym + worst-case profiliga yuklash & stress.
Soak (uzoq vaqt) - xotira/deskriptor oqishi, latency o’sishi.
Chaos/game-days: broker/provayder/zonaning qulashi, «sekin provayder».
CIdagi perf regressiyalari: etalon stsenariylari va avtomatik geytlar to’plami.

9) Ma’lumotlar va omborlar: o’sish strategiyalari

«Shift» gacha vertikal o’sish → gorizontal/sharding.
Oʻqish → replika/kesh; → batchi/asinxron/jurnal yozuvlari.
Sxemalarni koʻchirish: expand → migrate → contract, global blokirovkasiz.
Arxivlash: sovuq partiyalar arzon omborxonada + on-demand re-gidratsiya.
Qidirish: alohida indekslar (OpenSearch/Solr).

10) Provayderlar va kvotalarni boshqarish

Kvota xaritasi (TPS, derazalar, qiymat); alerty’usage _ ratio> 0. 9`.
Qiymati/sifati bo’yicha routing (smart routing).
va kvotalarni oshirish jarayoni.
Muqobil pullar va «issiq» almashtirish.

11) Kuzatish va ko’paytirish signallari

• Capacity headroom по слоям; `queue_lag/backlog growth`; `kafka ISR`; `db connections`/`repl lag`; `redis evictions`; `open_circuit`/`retry_rate`; `quota_usage`.
• Biznes-metrika: success rate/depozit konvertatsiyasi, o’yinni boshlash vaqti.
• Qiymati: cost/RPS, cost/1k calls.

• Capacity Overview (headroom, top-risklar, burn-rate SLO).
• Stream & Queue Panel (lag/backlog, consumer saturation).
• DB & Cache (p99, konnektlar, hit/evictions).
• Providers & Quotas (TPS, timeouts, qiymat, almashtirish).
• Change Safety (relizdan oldin/keyin, kanareyka, avtogeytlar).

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: ko’paytirish foydali

Samaradorlik koeffitsiyentlari: cost/RPS, cost/depozit, cost/1k hodisalar.
Right-sizing: VPA/tavsiyalar, «over-provisioned» bo’yicha hisobotlar.
Tanqidsiz uchun Spot/Preemptible; Asosiy yuk uchun Reserved/Committed.
Egress-budjet va keshlash, CDN/edge-ofload.
Loglarni qiymatiga koʻra yigʻish va arxivlash (hot vs cold).
Ogohlantirish kvotalari (soft-cap) va kengayish uchun avto-chiptalar.

13) Jarayonlar va odamlar

Change Management: kanareykalar, ficheflaglar, regressiyalarni toʻxtatish.
Hodisaga tayyorlik: runbook’i «sig’imni qayerda qo’shish kerak», «mintaqani qanday almashtirish kerak».
Cho’qqilarni rejalashtirish: o’yinlar/turnirlar/kampaniyalar taqvimi va provayderlar oynalari.
Muntazam game-days va DR-mashqlar.
Egalik matritsasi: kim feyloverga «tugmani bosishi »/kvotalarni oshirishi mumkin.

14) Joriy etish chek-varaqalari

• Kritik yo’llar va limitlar xaritasi (qatlamlar bo’yicha), headroom maqsadi ≥ 30%.
• Biznes-metriklar bo’yicha HPA + Cluster Autoscaler; PDB/SpreadConstraints.
• Issiq yo’llarda navbatlar, idempotency-keys, outbox.
• Keshlar: hit-maqsadlar ≥ 90%, evictions siyosati, asosiy indekslar.
• DB: o’qish nusxalari, konnektlar hovuzi, sharding rejasi.
• Provayderlar: multi-vendor, kvotalar, breykerlar/retralar.
• «Capacity/Stream/DB/Providers» dashbordlari, § 11 dagi alertlar.
• Kanareyka va avtogeytlar «chiqarilishdan oldin/keyin».
• DR-pleybuk va bitta qisman feylover trening.

• Keshni isitish, HPA/ASG pre-skeyl, warm-standby replikasi.
• Provayderlar kvotalarini oshirish, smart-routing.
• Nekritik alertlar uchun night-mode bosimini yoqish.
• «safe mode» ficheflagini ishga tushirishga tayyor.

15) Anti-patternlar

Gorizontal o’rniga vertikal «to’g’ridan-to’g’ri» yangilash.
Barcha daunstrimlar uchun umumiy oqim/ulanish puli (head-of-line).
Tor joylardagi taymautlarda retralar, jitter yo’qligi → bo’ron.
Alert va scale siyosatida gisterezis yo’q → «kesish».
Sharding va ma’lumotlarni mahalliylashtirmasdan yagona global MA.
Vendorning SDKsiga ko’r-ko’rona ishonish vaqtni/retraut/kuzatishni nazorat qilmasdan.
DR mashqlari yo’qligi: feylover «faqat qog’ozda».

16) Masshtablanish KPI

Eng yuqori cho’qqida SLO (p95/p99, success rate).
Praym taymdagi qatlamlar boʻyicha headroom.
MTTS (Mean Time To Scale) - qo’shimcha resurslar paydo bo’lgunga qadar.
Backlog/Lag Resolution Time - eng yuqori pog’onadan so’ng navbatlar qulagan vaqt.
Change Failure Rate - faol oʻsish davri.
Cost/RPS va cash/CDN/edge-ofloaddan tejash.
DR Readiness: Mashqlarda RTO/RPO.

17) «Tez» shablon namunalari

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: Birinchi bo’lib nimani ko’paytirish kerak?
A: Dashbord ma’lumotlari bo’yicha tor joylar: navbatlar/kesh/DB o’qish. Issiq yo’llar (depozit/stavka/o’yinni boshlash) - ustuvor vazifa.

Q: Avto-masshtablash «yomonlashtirishini» qanday tushunish mumkin?
A: Korrelyatsiyaga qarang: scale-up ↑ va p99/xatolar yaxshilanmaydi - ehtimol siz «muammoni ko’paytirasiz». Breykerlar/degradatsiyani yoqing.

Q: Har doim ikkinchi provayder kerakmi?
A: Tanqidiy yo’llar uchun - ha. Aks holda, hech bo’lmaganda soddalashtirilgan skript va kesh bilan «safe mode».

Q: Active-active или active-passive?
A: Agar RTO talablari past bo’lsa va mintaqaviy o’yinchilar ko’p bo’lsa - active-active. Aks holda, ishlatilgan feylover bilan active-passive bilan boshlang.