Кубаттуулуктарды пландаштыруу

1) кубаттуулуктарды пландаштыруу деген эмне жана ал эмне үчүн керек

Кубаттуулуктарды пландаштыруу (capacity planning) - бул минималдуу баада максаттуу SLOга жетүү үчүн зарыл болгон ресурстарды баалоо жана камсыз кылуунун системалуу процесси. Бул CPU/эс жөнүндө гана эмес, ошондой эле тармактардын өткөрүү жөндөмдүүлүгү, сактоо, DD/кэш, кезек/шина окуялары, тышкы провайдерлер (төлөмдөр/KUS/антифрод), ошондой эле адам ресурстары (on-call, колдоо) жөнүндө.

• SLO/SLAs да чокуларда жана деградацияларда аткаруу.
• TCO жана жөнөкөй капиталды азайтуу (overprovisioning).
• Ресурстардын түгөнүшүнөн инцидент коркунучун азайтуу (saturation → p99/каталар).
• Чыгарылыштарды жана кампанияларды (маркетинг, турнирлер, топ-матчтар) алдын ала камсыз кылуу.

2) кириш маалыматтар жана чындык булактары

Байкоо: RPS/concarrentity, p50/p95/p99, error-rate, saturation (CPU, mem, диск IOPS, тармак pps/mbps), кезек узундугу, rate чеги.
Бизнес окуялар: үгүт календарлары, сезондук (кечки/дем алыш/мега-иш-чаралар), региондор/юрисдикция.
Техдолг/Fich: roadmap релиздер, архитектуралык өзгөрүүлөр (мисалы, коддоо, жаңы логин).
Провайдерлер: квоталар жана throughput төлөм/ЖКК/почта/антифрод кызматтары.
Өткөндөгү окуялар: тар жерде (DD, кэш, L7-баланстоочу, дөңгөлөк, CDN, диск).

3) Негизги түшүнүктөр жана формулалар

Headroom - кубаттуулугу боюнча запас: 'headroom = (макс _ туруктуу _ RPS − чыныгы _ RPS )/макс _ туруктуу _ RPS'.
Максаттуу мааниси туу чокусунда 20-40% (критикалык агымдар үчүн).
Сатурация - бош эмес ресурстун жеткиликтүү ресурстарга болгон катышы (CPU%, эс/GC, байланыштар, file descriptors, IOPS, кезек тереңдиги).
Throughput туруктуу - бул p99 жана error-rate SLO узак убакыт бою (бир жолку эмес) аткарган ылдамдык.
Capacity Unit (CU) - тейлөө үчүн нормаланган кубаттуулук бирдиги (мисалы, X RPS бир pod vCPU = 1, RAM = 2 GiB).
Системалык лимит - деградациясы жок max: 'N _ pods × CU'. shared көз карандылыкты эске алуу маанилүү (BD/кэш/шина).

4) Суроо-талап модели: болжолдоо

Статистикалык катарлар: жумалык/күнүмдүк сезондук, майрамдар, спорттук финалдар, аймактык чокулар.
Когорттор: өлкөлөр, төлөм провайдерлери, түзмөктөр, VIP-сегменттер боюнча.
Окуя дельталар: кампаниялардын/мылтыктардын/релиздердин/SEO таасири.
"Эгер" (scenario planning): + 50% 19: 00-22: 00; A → B боюнча кайра бөлүштүрүү (+ 30% жашыруун).
Реалдуу убакыт корректировкалары: лидметрлер боюнча nowcasting (сессияларды жандандыруу, матчка кезек, себеттер).

5) Сунуш модели: "сынган" чынжыр

Conveyor суроо: Edge/CDN → L7-балансировщик → колдонмо → кэш → DD → тышкы API → кезек/шина → иштеп чыгуучулар/ETL.

• Кубаттуулугу (CU/инстанция), масштабдуулугу (горизонт ./вертик.) , чектери (байланыштар, pps, IOPS), кечигүү.
• Баш тартуу саясаты (rate limit, circuit breaker, деградация).
• SLO жергиликтүү жана e2e-SLO алардын салымы.

6) Каталардын запасы жана бюджети

Биз headroom error budget байлап: аз бюджет → көбүрөөк запастагы.
Критикалык агымдар үчүн (төлөм/текшерүү) - headroom жогору, экинчи даражадагы үчүн - төмөн.
Муздак/жылуу камдар: туу чокусунда/кырсыкта активдештирилген.

7) Масштабдоо: тактика

HPA (жүктөө көрсөткүчтөрү боюнча): RPS, latency, кезек узундугу, атайын SLIs (мыкты CPU%).
VPA: Ресурстарды тууралоо (stateful жана p99 GC менен кылдаттык менен).
KEDA/адаптерлер: тышкы булактары боюнча масштабдоо (Kafka lag, Redis list length, CloudQueue depth).
Warm Pools/жылытуу: муздак баштоо үчүн алдын ала көтөрүлгөн бийлик.
"Load-as-Code" ыкмасы: Автоскейлдин/лимиттердин/таймауттардын/ретрациялардын саясаты версияланып, review өтөт.

8) кезек, backpressure жана куйрук башкаруу

Максаты - p99 көчкү өсүшүнө жол бербөө.
Биз параллелизмди жана кезектин өлчөмүн чектейбиз, убактылуу терезелерди жана демпотенттикти киргизебиз.
Hedging/Retry-budget: колдонуучунун жана системанын жалпы бюджетин чектөө.
Graceful degradation: Ашыкча жүктөөдө экинчи баскычты өчүрүү.

9) БД, кэш жана сактоо

БД: байланыш чеги, журнал/FSync, индекстер, суроо планы, replica lag, hot-keys/таблицалар, транзакциялар үчүн max TPS.
Кэши: сегменттер боюнча hit-ratio, бошотуу/майыптык учурунда "бороон-чапкын", ачкычтарды бөлүштүрүү.
Storage: IOPS/throughput, кечигүү, кысуу, TTL, эски партия/snapshot тазалоо.
Миграция схемасы: expand → migrate → contract токтоочу блоктору жок.

10) окуялар агымы жана ETL

Kafka/шиналар: партиялардын өткөрүү жөндөмдүүлүгү, lag, ISR, compaction, продюсерлердин/консумерлердин лимиттери.
ETL/батчи: терезелер ишке киргизүү, убакыт бюджеттери, прод-сторана таасири (throttle I/O).
Dempotentity жана exactly-once-like үчүн критикалык flow (төлөмдөр/баланстар).

11) Тармак жана периметри

L4/L7 балансировщиктер: connection limits, syn backlog, TLS offload, session reuse.
CDN/Edge: өткөрүү, origin-жүктү азайтуу үчүн кэш саясаты.
Тармак ичиндеги лимиттер: pps/mbps VPC/подсети, egress-наркы (FinOps).

12) Мультирегион, DR жана юрисдикциялар

Стратегиялары: active-active (GSLB/Anycast), active-passive (ысык/жылуу/муздак DR).
Аймактар боюнча N + 1: SLO core-агымдарын сактоо менен AZ/аймактын жоготуусуна туруштук берүү.
Юридикалык локализация: трафикти/маалыматтарды өлкөлөр боюнча бөлүү, ар кандай лимиттер жана SLO провайдерлерге.
DR Tests: чыныгы жүк которуу менен үзгүлтүксүз оюн-күн.

13) Тышкы провайдерлер: квоталар жана маршруттар

Төлөмдөр/KYC/антифрод/почта/SMS: TPS квоталары, бурст, күндөлүк лимиттер.
Мульти-провайдер: жашыруун/ийгилик багыттоо, SLO per провайдер, авто-фейловер.
SLA контракттары: e2e-SLO шайкештиги, эскалация каналдары, статус-вебхактар.

14) FinOps: наркы жана натыйжалуулугу

TCO: compute + storage + network egress + лицензиялар/провайдерлер + нөөмөт.
Бирдик Экономика: 1k суроо-талап наркы/1 депозиттик операция/1 KYC.
оптималдаштыруу: right-sizing, spot/алдын ала арзандатуулар, кэш-хитрейт, дедуп Логин/Tracking, муздак сактоо деңгээл.
Убакыттын өтүшү менен жүктү өткөрүп берүү: "түнкү" терезелерге жана арзан аймактарга маанилүү эмес.

15) Dashboard жана отчеттуулук (минималдуу топтому)

• Учурдагы жүк vs туруктуу throughput шилтемелер боюнча.
• Headroom кызмат жана региондор боюнча; 24/72 саатка болжолдоо.
• KPI FinOps: $/1k суроолор, $/аманат.

• Жогорку тар жерлер (p99, saturation, lag), DR боюнча запас.

• Ийгилик/жашыруун жана провайдерлердин лимиттери; каттамдар боюнча трафиктин үлүшү.

• Жаңылоо/индекстер/оптималдаштыруу планы, күтүлгөн үнөмдөө/кубаттуулуктун өсүшү.

16) Процесстер жана ролдор

RACI: Платформа (Infra/Cluster/баланстагыч), DD/Маалыматтар (индекстер, репликациялар), Тейлөө буйруктары (профилдөө/кэш), SRE (SLO, алерттар), Sec/Compliance (крипто/журналдар), Финансы (бюджет).
Ритм: жумалык capacity-review (жол картасы, болжолдоо, тобокелдиктер), ай сайын FinOps-отчеттор, чейректик DR-тесттер.
Change Management: ири кампаниялар/релиздер capacity-gate (төмөнкү чек тизмеси) өтөт.

17) Чыгаруунун жана кампаниялардын чек тизмеси (capacity-gate)

• чокусуна жана "+ x% авариялык куйругу боюнча жүк болжолдоо".
• Негизги агымдар үчүн жеткиликтүү headroom (төлөмдөр/CUS/логин).
• Провайдерлерге квоталар тастыкталган; жолдору активдүү.
• HPA/KEDA босоголор жана warm-pool орнотулган.
• Кезектер/лимиттер жана деградациялар текшерилди (плейбуктар даяр).
• Канар үлүштөрү жана авто-артка чегинүү кирет.
• Dashboard/alerty (burn-rate, saturation, p99) текшерилген.
• DR планы жана эскалация байланыштар актуалдуу болуп саналат.

18) Анти-үлгүлөрү

"CPU <70% - баары жакшы": көз карандылыктын чегине көңүл бурбоо (DD, IOPS, кезек).
борборлоштурулган "кара куту" эч кандай метрик per-звено - лимит кайда экенин түшүнүү мүмкүн эмес.
Кэш стратегиясынын жоктугу - релиздеги каталар origin өлтүрөт.
Бюджети жок ретрайлардын лимиттеринин хардкоды - суроо-талаптардын бороону.
"Бир төлөм провайдери" - эң жогорку чегиндеги баш тартуу чекити.
Жылуу камдарды этибарга албоо - окуялардын себеби катары суук башталышы.
Эч кандай мезгил-мезгили менен DR-тесттер - план керек болгондо иштебейт.

19) Mini Calculation (мисал)

Кызмат X: pod туруктуу 350 RPS (vCPU = 1, RAM = 2 GiB). Максаты - 5 000 RPS, headroom 25%.
Керектүү кубаттуулугу = '5000/0. 75 = 6667 RPS`.
Подов = 'ceil (6667/350) = 20'. Плюс warm-pool 15% → дагы 3 pod.
BD: 12k TPS чеги, 9k TPS учурдагы насыя, 10 чокусуна болжолдоо. 5k TPS → запасы 1. 5k (14%). Талап кылынат: индекстер/шардинг/реплика же 8 чейин төмөндөтүү үчүн кэш. 5k.

Провайдер A (KYC): 120 rps квота, 95 rps чокусу, кампания + 40% → 133 rps> квота → 70% A/30% B. багыттоо

20) capacity planning киргизүү шаблон

1. Сүрөттөө e2e-жол жана тар.
2. CU киргизүү жана ар бир катмардын туруктуу throughput өлчөө.
3. Бардык шилтемелерде saturation жана p99 метрикаларын орнотуу.
4. Иш-чаралардын/кампаниялардын/релиздердин календарын түзүү.
5. Когорталар жана сценарийлер боюнча прогноз түзүү "эгер эмне болсо".
6. Headroom per-агым жана per-аймак (error budget байлап) бекитүү.
7. HPA/VPA/KEDA + Warm-Pools, чеги/Retry/кезек.
8. Провайдердик квоталарды текшерүү, көп маршруттарды киргизүү.
9. dashboard жана жумалык ритм capacity-review чогултуу.
10. Чейрек сайын - DR-машыгуу жана моделин кайра карап чыгуу.

21) Жыйынтык

Кубаттуулуктарды пландаштыруу - бул "CPU кошуу" эмес, болжолдоолордун, архитектуралык чектөөлөрдүн жана нарктын башкарылуучу байланышы. E2e жолунун ар бир катмары өлчөнгөн сыйымдуулукка ээ болгондо, жана headroom жана деградация стратегиялары SLO жана error budget менен байланышкан болсо, анда эң жогорку жүктөр, кампаниялар жана авариялар күтүүсүз болбой калат. Мындай ыкма инциденттердин коркунучун азайтат, бизнес-метриканы турукташтырат жана чыгымдарды оптималдаштырат.