Quvvatlarni rejalashtirish

1) Quvvatlarni rejalashtirish nima va nima uchun zarur

Quvvatlarni rejalashtirish (capacity planning) - bu maqsadli SLOga minimal narxda erishish uchun zarur bo’lgan resurslarni baholash va ta’minlashning tizimli jarayonidir. Gap nafaqat CPU/xotira, balki tarmoqlarning o’tkazish qobiliyati, saqlash, DB/keshlar, voqealar navbatlari/shinalari, tashqi provayderlar (to’lovlar/KS/antifrod), shuningdek, inson resurslari (on-call, qo’llab-quvvatlash) haqida bormoqda.

• Hatto choʻqqilar va degradatsiyalarda ham SLO/SLAlarni bajarish.
• TCO va oddiy kapitalni minimallashtirish (overprovisioning).
• Resurslarning tugashidan hodisalar xavfini kamaytirish (saturation → p99/xato).
• Relizlar va kampaniyalarning (marketing, turnirlar, top-o’yinlar) bashorat qilinishini ta’minlash.

2) Kirish ma’lumotlari va haqiqat manbalari

Kuzatilganlik: RPS/konkarrentlik, p50/p95/p99, error-rate, saturation (CPU, mem, disk IOPS, tarmoq pps/mbps), navbat uzunliklari, rate limitlari.
Biznes-tadbirlar: kampaniya taqvimlari, mavsumiylik (kechki/dam olish/mega-tadbirlar), hududlar/yurisdiksiyalar.
Texdolg/fich: relizlar roadmap, arxitektura oʻzgarishlari (masalan, shifrlash, yangi loging).
Provayderlar: kvotalar va to’lov/KTS/pochta/antifrod xizmatlarining throughput.
O’tmishdagi noxush hodisalar: qayerda tor joy (DB, kesh, L7-balanschi, shina, CDN, disk).

3) Bazaviy tushunchalar va formulalar

Headroom - sig’imi bo’yicha zaxira:’headroom = (maks _ barqaror _ RPS − haqiqiy _ RPS )/maks _ barqaror _ RPS’.
Eng yuqori 20-40% maqsadli qiymati (kritik oqimlar uchun).
Saturation - band qilingan resursning mavjud resursga nisbati (CPU%, xotira/GC, ulanishlar, file descriptors, IOPS, navbat chuqurligi).
Throughput barqaror - p99 va error-rate SLOni uzoq vaqt davomida bajaradigan tezlik.
Capacity Unit (CU) - servis uchun me’yorlangan quvvat birligi (masalan, X RPS bir pod vCPU = 1, RAM = 2 GiB).
Tizim limiti - degradatsiyasiz max:’N _ pods × CU’. Shared qaramligini (BD/kesh/shina) hisobga olish muhimdir.

4) Talab modeli: prognozlashtirish

Statistik qatorlar: haftalik/sutkalik mavsumiylik, bayramlar, sport finallari, mintaqaviy cho’qqilar.
Kogortlar: mamlakatlar, to’lov provayderlari, qurilmalar, VIP-segmentlar bo’yicha.
Hodisa deltalari: kampaniyalar/mo’ynalar/relizlar/SEO ta’siri.
«Nima bo’lsa» (scenario planning): 19: 00-22: 00 da trafikka + 50%; provayderning A → ga tushishi B ga qayta taqsimlanishi (maxfiylikka + 30%).
Real-time tuzatishlar: lid-metriklar bo’yicha nowcasting (sessiyalarni jonlantirish, o’yin uchun navbat, savatlar).

5) Taklif modeli: zanjir «sinadi»

So’rov konveyeri: Edge/CDN → L7-balanslovchi → ilova → kesh → DB → tashqi API → navbat/shina → ishlov beruvchilar/ETL.

• Sig’imi (CU/instans), kattaligi (gorizont/vertikal) , chegaralar (konnektlar, pps, IOPS), kechikishlar.
• Rad etish siyosati (rate limit, circuit breaker, degradatsiya).
• SLO mahalliy va ularning e2e-SLO hissasi.

6) Xatolar zaxirasi va budjeti

Headroomni error budgetga bogʻlaymiz: byudjetdan kichik → zaxiradan katta.
Tanqidiy oqimlar uchun (to’lov/verifikatsiya) - headroom yuqorida, ikkinchi darajali oqimlar uchun - pastda.
Sovuq/issiq zaxiralar: avariya/cho’qqida faollashtiriladigan.

7) Ko’paytirish: taktika

HPA (yuk ko’rsatkichlari bo’yicha): RPS, latency, navbat uzunligi, foydalanuvchi SLIs (better than CPU%).
VPA: resurslarni tuzatish (stateful va p99 GC bilan ehtiyotkorlik bilan).
KEDA/adapterlar: tashqi manbalar boʻyicha masshtablash (Kafka lag, Redis list length, CloudQueue depth).
Warm pools/isitish: sovuq boshlashdan qochish uchun oldindan koʻtarilgan instantsiyalar.
«Load-as-Code» yondashuvi: avtoskeyl/limit/taymaut/retraj siyosati versiya qilinadi va review’dan o’tadi.

8) Navbatlar, backpressure va dumni boshqarish

Maqsad p99 ko’chkilarning ko’payishiga yo’l qo’ymaslikdir.
Parallellik va navbat oʻlchamini cheklaymiz, vaqtinchalik oynalar va idempotentlikni kiritamiz.
Hedging/Retry-budget: foydalanuvchi va tizimning umumiy vaqtini cheklash.
Graceful degradation: ortiqcha yuklashda ikkinchi darajali fazalarni oʻchirish.

9) DQ, keshi va ombor

DQ: konnektlar limiti, jurnallash/FSync, indekslar, so’rovlar rejasi, replica lag, hot-keys/jadvallar, tranzaksiyalar uchun max TPS.
Keshi: segmentlar bo’yicha hit-ratio, reliz/nogironlik paytida «o’tkazib yuborish bo’roni», kalitlarni taqsimlash.
Storaj: IOPS/throughput, kechikishlar, siqish, TTL, eski partiyalar/snapshotlarni tozalash.
Migratsiya sxemasi: expand → migrate → contract to’xtatuvchi bloklarsiz.

10) Voqealar oqimi va ETL

Kafka/shina: partiyalarning o’tkazish qobiliyati, lag, ISR, compaction, prodyuserlar/konsumerlar limitlari.
ETL/batchi: ishga tushirish oynalari, bajarish vaqtining byudjetlari, prod-storanga ta’siri (throttle I/O).
Tanqidiy floular uchun idempotentlik va exactly-once-like (to’lovlar/balanslar).

11) Tarmoq va perimetr

L4/L7 balanschilar: connection limits, syn backlog, TLS offload, session reuse.
CDN/Edge: origin yukini kamaytirish uchun oʻtish, kesh siyosati.
Ichki tarmoq limitlari: pps/mbps v VPC/kichik tarmoqlar, egress-qiymat (FinOps).

12) Multiregion, DR va yurisdiksiyalar

Strategiyalar: active-active (GSLB/Anycast), active-passive (issiq/issiq/sovuq DR).
Mintaqalar bo’yicha N + 1: SLO core-oqimlarini saqlab qolgan holda AZ/mintaqa yo’qotilishiga bardosh berish.
Yuridik mahalliylashtirish: trafik/ma’lumotlarni mamlakatlar bo’yicha ajratish, turli limitlar va SLOlarni provayderlarga ajratish.
DR testlari: haqiqiy yuklamali muntazam game-days.

13) Tashqi provayderlar: kvotalar va yo’nalishlar

To’lovlar/KYC/antifrod/pochta/SMS: TPS kvotalari, burst, kundalik limitlar.
Ko’p provayder: yashirin/muvaffaqiyat yo’nalishi, SLO per provayder, avto-feylover.
SLA shartnomalari: e2e-SLO muvofiqligi, eskalatsiya kanallari, status-vebxuklar.

14) FinOps: qiymati va samaradorligi

TCO: compute + storage + network egress + litsenziyalar/provayderlar + navbatchilar.
Unit Economics: 1k so’rovlar/1 ta depozit operatsiyasi/1 KYC qiymati.
Optimallashtirish: right-sizing, spot/prekfik chegirmalar, kesh-xitreyt, loglar/trassirovkalar dedupi, sovuq saqlash darajalari.
Yukni vaqtga ko’chirish: «tungi» derazalar va arzon hududlarga tanqidiy bo’lmagan batchlar.

15) Dashbordlar va hisobot (eng kam to’plam)

• Joriy yuk vs boʻgʻinlar boʻyicha barqaror throughput.
• Servislar va hududlar bo’yicha Headroom; 24/72 soat uchun prognoz.
• KPI FinOps: $/1k so’rovlar, $/depozit.

• Top tor joylar (p99, saturation, lag), DR bo’yicha zaxira.

• Provayderlarning muvaffaqiyati/latentligi va limitlari; yo’nalishlar bo’yicha trafikning ulushi.

• Jadvallar/indekslar/optimallashtirish rejasi, kutilayotgan tejamkorlik/sig’imning o’sishi.

16) Jarayonlar va rollar

RACI: Platforma (infra/klaster/balanslovchilar), DB/Ma’lumotlar (indekslar, replikatsiyalar), Servis buyruqlari (profillash/kesh), SRE (SLO, alertlar), Sec/Compliance (kripto/jurnallar), Moliya (byudjet).
Ritm: haftalik capacity-review (yo’l xaritasi, prognoz, xavflar), oylik FinOps-ma’lumotlar, har choraklik DR-testlar.
Change Management: yirik kampaniyalar/relizlar capacity-gate (pastdagi chek ro’yxati) dan o’tadi.

17) Chiqarish va kampaniyalarning chek-varaqasi (capacity-gate)

• Eng yuqori cho’qqiga va «+ x% avariya dumiga» yuk prognozi.
• Core oqimlari uchun ochiq headroom (to’lovlar/KS/login).
• Provayderlarga kvotalar tasdiqlandi; muqobil yo’nalishlar faol.
• HPA/KEDA chegaralari va warm-pool sozlangan.
• Navbatlar/limitlar va degradatsiyalar tekshirildi (pleybuklar tayyor).
• Kanareya ulushlari va avtotransport kiritilgan.
• Dashbordlar/alertlar (burn-rate, saturation, p99) tekshirildi.
• DR rejasi va eskalatsiya aloqalari dolzarbdir.

18) Anti-patternlar

«CPU <70% - hammasi yaxshi»: qaramlik chegaralarini e’tiborsiz qoldirish (DB, IOPS konnektlari, navbatlar).
Markazlashtirilgan «qora quti» per-zveno metriksiz - limit qayerda ekanligini tushunish mumkin emas.
Kesh strategiyasining yo’qligi - chiqarishdagi xatolar originni o’ldiradi.
Retraylarning budjetsiz limitlari hardkodi - so’rovlar bo’roni.
«Bitta to’lov provayderi» - cho’qqidagi rad etish nuqtasi.
Issiq zahiralarni e’tiborsiz qoldirish - voqealarning sababi sifatida sovuq start.
Davriy DR testlari yo’q - reja kerak bo’lganda ishlamaydi.

19) Mini-kalkulyatsiya (misol)

Xizmat X: pod uchun 350 RPS barqaror (vCPU = 1, RAM = 2 GiB). Maqsad - 5 000 RPS, headroom 25%.
Kerakli quvvat =’5000/0. 75 = 6667 RPS`.
Podov =’ceil (6667/350) = 20’. Plyus warm-pool 15% → yana 3 pod.
DQ: 12k TPS limiti, 9k TPS joriy krediti, 10 cho’qqisi prognozi. 5k TPS → zaxira 1. 5k (14%). Talab qilinadi: indekslar/sharding/replikalar yoki 8 gacha pasaytirish uchun keshlash. 5k.
Provayder A (KYC): kvota 120 rps, cho’qqi 95 rps, kampaniya + 40% → 133 rps> kvotalar → yo’nalish 70% A/30% B.

20) Capacity planning joriy etish namunasi

1. e2e-yo’l va tor joylarni tasvirlash.
2. Uni kiriting va har bir qatlamning barqaror throughputini oʻlchang.
3. Barcha boʻgʻinlarda saturation va p99 metriklarini moslash.
4. Tadbir/kampaniya/reliz taqvimini yaratish.
5. Kogortlar va «agar» stsenariylari bo’yicha prognoz tuzing.
6. Headroom per-oqim va per-mintaqani biriktirish (error budget bilan bogʻlash).
7. HPA/VPA/KEDA + warm-pools, limitlar/retralar/navbatlarni moslash.
8. Provayder kvotalarini tekshirish, ko’p yo’nalishlarni kiritish.
9. Dashbordlar va haftalik capacity-review ritmini yig’ish.
10. Har chorakda - DR-mashqlar va modelni qayta ko’rib chiqish.

21) Jami

Quvvatlarni rejalashtirish - bu «CPU qo’shish» emas, balki prognozlar, arxitektura cheklovlari va qiymatning boshqariladigan bog’lanishidir. Agar e2e-yo’lning har bir qatlami o’lchangan sig’imga ega bo’lsa va headroom va degradatsiya strategiyalari SLO va error budget bilan bog’liq bo’lsa, eng yuqori yuk, kampaniyalar va baxtsiz hodisalar kutilmagan voqea bo’lib qolmaydi. Bunday yondashuv hodisalar xavfini kamaytiradi, biznes-metrikani barqarorlashtiradi va xarajatlarni optimallashtiradi.