Güclərin planlaşdırılması

1) Gücün planlaşdırılması nədir və niyə lazımdır

Güclərin planlaşdırılması (capacity planning) minimum qiymətə hədəf SLO-ya çatmaq üçün lazım olan resursların qiymətləndirilməsi və təmin edilməsi üçün sistematik bir prosesdir. Söhbət yalnız CPU/yaddaş haqqında deyil, həm də şəbəkələrin bant genişliyi, saxlama, DB/keşlər, hadisələr növbələri/şinləri, xarici provayderlər (ödənişlər/KUS/antifrod) və insan resursları (on-call, dəstək) haqqında gedir.

• SLO/SLAs hətta pik və deqradasiyada yerinə yetirin.
• TCO və sadə kapitalı minimuma endirmək (overprovisioning).
• Resursların tükənməsindən hadisə riskini azaltın (saturation → p99/səhv).
• Relizlərin və kampaniyaların (marketinq, turnirlər, top matçlar) proqnozlaşdırılmasını təmin edin.

2) Giriş və həqiqət mənbələri

Müşahidə: RPS/konkarrentlik, p50/p95/p99, error-rate, saturation (CPU, mem, disk IOPS, şəbəkə pps/mbps), növbə uzunluqları, rate limitləri.
Biznes tədbirləri: kampaniya təqvimləri, mövsümlük (axşamlar/həftəsonu/meqa-tədbirlər), regionlar/yurisdiksiyalar.
Texdolg/Ficks: roadmap relizlər, memarlıq dəyişikliklər (məsələn, şifrələmə, yeni log).
Provayderlər: kvotalar və throughput ödəniş/KUS/poçt/antifrod xidmətləri.
Keçmişin hadisələri: harada dar yer (DB, önbellək, L7 balanslayıcı, şin, CDN, disk).

3) Əsas anlayışlar və formullar

Headroom - tutum ehtiyatı: 'headroom = (max _ davamlı _ RPS − faktiki _ RPS )/max _ davamlı _ RPS'.
Zirvədə hədəf dəyəri 20-40% (kritik axınlar üçün).
Saturation - məşğul resursun mövcud olan resurslara nisbəti (CPU%, yaddaş/GC, bağlantılar, file descriptors, IOPS, növbə dərinliyi).
Throughput davamlı - p99 və error-rate SLO-nun uzun müddət (birdəfəlik sıçrama deyil) yerinə yetirildiyi sürət.
Capacity Unit (CU) - xidmət üçün normallaşdırılmış güc vahidi (məsələn, bir vCPU = 1, RAM = 2 GiB pod başına X RPS).
Sistem limiti - deqradasiyasız max: 'N _ pods × CU'. Şəred asılılığı nəzərə almaq vacibdir (BD/Cache/Lastik).

4) Tələb modeli: proqnozlaşdırma

Statistik sıralar: həftəlik/gündəlik mövsümlük, bayramlar, idman finalları, regional zirvələr.
Kohortlar: ölkələr, ödəniş provayderləri, cihazlar, VIP seqmentlər.
Hadisə deltaları: kampaniyaların/topların/buraxılışların/SEO təsiri.
«Əgər» (scenario planning): + 50% 19: 00-22: 00; A → provayderinin düşməsi B-yə yenidən bölüşdürülməsi (+ 30% gizli).
Real-time düzəlişlər: lid-metrik novcasting (sessiyaların canlanması, matç növbəsi, səbətlər).

5) Təklif modeli: zəncir «qırılır» harada

Sorğu konveyer: Edge/CDN → L7-balans → app → cache → DB → xarici API → növbə/şina → emalçılar/ETL.

• Tutum (CU/instans), miqyaslanabilirlik (üfüq ./vertikal.) , limitləri (konnektlər, pps, IOPS), gecikmə.
• Imtina siyasəti (rate limit, circuit breaker, deqradasiya).
• SLO yerli və onların e2e-SLO töhfələri.

6) Səhv ehtiyatı və büdcəsi

Headroom-u error budget-a bağlayın: daha az büdcə → daha çox ehtiyat.
Kritik axınlar üçün (ödəniş/yoxlama) - yuxarıda headroom, ikinci dərəcəli üçün - aşağıda.
Soyuq/isti ehtiyatlar: pik/qəza zamanı aktivləşdirilir.

7) Ölçmə: taktika

HPA (yük metriklərinə görə): RPS, latency, növbə uzunluğu, xüsusi SLIs (daha yaxşı CPU%).
VPA: Resurs düzəliş (stateful və p99 GC ilə daha diqqətli).
KEDA/adapterlər: xarici mənbələrə görə (Kafka lag, Redis list length, CloudQueue depth).
Warm pools/isitmə: soyuq başlamaq qarşısını almaq üçün əvvəlcədən qaldırılmış instants.
«Load-as-Code» yanaşması: avtoskeyl/limit/taymaut/retraj siyasətləri versiyası və review keçir.

8) Növbələr, backpressure və quyruq idarə

Məqsəd p99 uçqun böyüməsinin qarşısını almaqdır.
Paralelliyi və növbənin ölçüsünü məhdudlaşdırırıq, müvəqqəti pəncərələr və idempotentliyi daxil edirik.
Hedging/Retry-budget: istifadəçi və sistemin ümumi vaxt büdcəsini məhdudlaşdırın.
Graceful degradation: həddindən artıq yükləmə zamanı ikinci dərəcəli xüsusiyyətləri söndürmək.

9) DB, keşlər və saxlama

BD: bağlantı limiti, jurnallaşdırma/FSync, indekslər, sorğu planı, replica lag, hot-keys/cədvəllər, əməliyyatlar üçün max TPS.
Keşi: seqmentlər üzrə hit-ratio, buraxılış/əlillik zamanı «qaçırma fırtınası», açarların paylanması.
Storage: IOPS/throughput, gecikmələr, sıxılma, TTL, köhnə partiyalar/snapshots təmizlənməsi.
Miqrasiya sxemi: dayandırma blokları olmadan expand → migrate → contract.

10) Hadisə axını və ETL

Kafka/şina: partiyalar, lag, ISR, compaction, prodüser/konsumer limitləri.
ETL/batches: başlanğıc pəncərələri, vaxt büdcələri, prod-storana təsiri (throttle I/O).
İdempotentlik və kritik flow üçün exactly-once-like (ödənişlər/balans).

11) Şəbəkə və perimetr

L4/L7 balanslayıcılar: connection limits, syn backlog, TLS offload, session reuse.
CDN/Edge: giriş, origin yükünü azaltmaq üçün cache siyasəti.
Şəbəkədaxili limitlər: VPC/alt şəbəkələrdə pps/mbps, egress-dəyər (FinOps).

12) Multiregion, DR və yurisdiksiyalar

Strategiyalar: active-active (GSLB/Anycast), active-passive (isti/isti/soyuq DR).
Regionlar üzrə N + 1: SLO core axınlarını saxlayarkən AZ/region itkisinə tab gətirmək.
Hüquqi lokalizasiya: trafik/məlumatların ölkələr üzrə bölünməsi, müxtəlif limitlər və SLO-lar provayderlərə bölünür.
DR testləri: real yük köçürülməsi ilə müntəzəm game-days.

13) Xarici provayderlər: kvotalar və marşrutlar

Ödənişlər/KYC/antifrod/mail/SMS: TPS kvotaları, burst, gündəlik limitlər.
Multi-provayder: gizlilik/uğur marşrutu, SLO per provayder, avto-feylover.
SLA müqavilələri: e2e-SLO uyğunluğu, eskalasiya kanalları, status-vebhuk.

14) FinOps: dəyəri və səmərəliliyi

TCO: compute + storage + network egress + lisenziyalar/provayderlər + vəzifələr.
Unit Economics: 1k sorğu/1 depozit əməliyyat/1 KYC dəyəri.
Optimallaşdırma: right-sizing, spot/preekstvo endirimləri, cache hiyləsi, giriş/tracking deadup, soyuq saxlama səviyyələri.
Yükün vaxtında köçürülməsi: kritik olmayan batches «gecə» pəncərələrinə və ucuz bölgələrə.

15) Daşbordlar və hesabatlar (minimum dəst)

• Cari yük vs davamlı throughput links.
• Xidmətlər və regionlar üzrə Headroom; 24/72 saat üçün proqnoz.
• KPI FinOps: $/1k sorğular, $/depozit.

• Top dar yerlər (p99, saturation, lag), DR ehtiyatı.

• Uğur/gizlilik və provayderlərin limitləri; marşrutlar üzrə trafik payı.

• Yeniləmə/indekslər/optimallaşdırma planı, gözlənilən qənaət/artan tutum.

16) Proseslər və rollar

RACI: Platforma (infra/klaster/balanslayıcılar), DB/Data (indekslər, replikasiyalar), Xidmət komandaları (profil/cache), SRE (SLO, alertlər), Sec/Compliance (kripto/jurnallar), Maliyyə (büdcə).
Ritm: həftəlik capacity-review (yol xəritəsi, proqnoz, risklər), aylıq FinOps hesabatları, rüblük DR testləri.
Change Management: böyük kampaniyalar/buraxılışlar capacity-gate (aşağıdakı çek siyahısı) keçir.

17) Buraxılış və kampaniya çek siyahısı (capacity-gate)

• Pik yük proqnozu və «+ x% təcili quyruq».
• core axınları üçün mövcud headroom (ödənişlər/KUS/giriş).
• Provayderlər kvotaları təsdiq; alternativ marşrutlar aktivdir.
• HPA/KEDA eşik və warm-pool özelleştirilmiş.
• Növbələr/limitlər və deqradasiyalar yoxlanılıb (playbook hazır).
• Kanarya payları və avtomatik geri çəkilmə daxildir.
• Daşbordlar/alertlər (burn-rate, saturation, p99) yoxlanılıb.
• DR planı və eskalasiya əlaqələri aktualdır.

18) Anti-nümunələr

«CPU <70% - hər şey yaxşıdır»: asılılıq limitlərinə məhəl qoymamaq (DB, IOPS, növbələr).
per-link metrik olmadan mərkəzləşdirilmiş «qara qutu» - limitin harada olduğunu anlamaq mümkün deyil.
Cache strategiyasının olmaması - buraxılışdakı səhvlər origin 'i öldürür.
Büdcəsiz retraj limitlərinin hardcodu - fırtına sorğuları.
«Bir ödəniş provayderi» - pik nöqtədə imtina nöqtəsi.
İsti ehtiyatlara məhəl qoymamaq hadisələrin səbəbi kimi soyuq başlanğıcdır.
Periodik DR testləri yoxdur - plan lazım olduqda işləmir.

19) Mini kalkulyasiya (nümunə)

Xidmət X: pod 350 RPS davamlı (vCPU = 1, RAM = 2 GiB). Məqsəd - 5 000 RPS, baş otaq 25%.
İstədiyiniz güc = '5000/0. 75 = 6667 RPS`.
Podov = 'ceil (6667/350) = 20'. Plus warm-pool 15% → daha 3 pod.
BD: limit 12k TPS, cari kredit 9k TPS, pik proqnozu 10. 5k TPS → ehtiyat 1. 5k (14%). Tələb olunur: indekslər/sharding/replica və ya 8-ə endirmək üçün caching. 5k.
Provayder A (KYC): kvota 120 rps, pik 95 rps, kampaniya + 40% → 133 rps> kvota → marşrut 70% A/30% B.

20) Capacity planning tətbiqi şablon

1. e2e yolu və dar yerləri təsvir edin.
2. CU daxil və hər qat sabit throughput ölçmək.
3. Bütün linklərdə saturation və p99 metriklərini konfiqurasiya edin.
4. Hadisələrin/kampaniyaların/buraxılışların təqvimini formalaşdırın.
5. Kohortlar və ssenarilər üçün bir proqnoz qurmaq «əgər».
6. Headroom per-stream və per-region (error budget bağlamaq).
7. HPA/VPA/KEDA + warm-pools, limitlər/retralar/növbələr.
8. Provayder kvotalarını yoxlayın, çox marşrutları daxil edin.
9. Dashboard və həftəlik ritm capacity-review yığın.
10. Rüblük - DR təlimləri və modelin yenidən baxılması.

21) Yekun

Güclərin planlaşdırılması «CPU əlavə etmək» deyil, proqnozların, memarlıq məhdudiyyətlərinin və dəyərlərin idarə olunan birləşməsidir. E2e-yolun hər bir qatının ölçülmüş tutumu və baş otağı və deqradasiya strategiyaları SLO və error budget ilə əlaqəli olduqda, pik yüklər, kampaniyalar və qəzalar sürpriz olmağı dayandırır. Bu yanaşma insident riskini azaldır, biznes metrikasını sabitləşdirir və xərcləri optimallaşdırır.