Қуаттарды жоспарлау

1) Қуаттарды жоспарлау дегеніміз не және ол не үшін қажет

Қуаттарды жоспарлау (capacity planning) - бұл ең төменгі құны кезінде нысаналы SLO-ға қол жеткізу үшін қажетті ресурстарды бағалау мен қамтамасыз етудің жүйелі процесі. Әңгіме тек CPU/жад туралы ғана емес, сонымен қатар желілердің өткізу қабілеттілігі, сақтау, ДБ/кештер, оқиғалар кезектері/шина, сыртқы провайдерлер (төлемдер/АҚЖ/антифрод), сондай-ақ адам ресурстары (on-call, қолдау) туралы болып отыр.

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

2) Кіріс деректері және ақиқат көздері

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

3) Базалық ұғымдар мен формулалар

Headroom - сыйымдылығы бойынша қор: 'headroom = (макс _ орнықты _ RPS − нақты _ RPS )/макс _ орнықты _ RPS'.
Шыңдағы нысаналы мәні 20-40% (сындарлы ағындар үшін).
Saturation - бос емес ресурстың қол жетімді ресурсқа қатынасы (CPU%, жады/GC, қосылыстар, file descriptors, IOPS, кезек тереңдігі).
Throughput тұрақты - p99 және error-rate SLO ұзақ уақыт орындайтын жылдамдық (бір реттік емес секіріс).
Capacity Unit (CU) - сервис үшін қуаттың нормаланған бірлігі (мысалы, бір pod vCPU = 1, RAM = 2 GiB X RPS).
Жүйелік лимит - деградациясыз max: 'N _ pods × CU'. Shared тәуелділікті ескеру маңызды (ДБ/кеш/шина).

4) Сұраныс моделі: болжау

Статистикалық қатарлар: апталық/тәуліктік маусымдық, мерекелер, спорттық финалдар, өңірлік шыңдар.
Когорттар: елдер, төлем провайдерлері, құрылғылар, VIP-сегменттер бойынша.
Оқиға дельталары: кампаниялардың/мылтықтардың/релиздердің/SEO әсері.
«Егер не болса» (scenario planning): + 50% трафикке 19: 00-22: 00; провайдердің түсуі A → B-ге қайта бөлу (жасырындылыққа + 30%).
Real-time түзетулер: лид- метриктер бойынша nowcasting (сессияларды жандандыру, матчқа кезек, себеттер).

5) Ұсыныс моделі: тізбек «сынады»

Сұрау конвейері: Edge/CDN → L7-теңгеруші → қосымша → кэш → БД → сыртқы API → кезек/шина → өңдеушілер/ETL.

• Сыйымдылығы (CU/инстанс), масштабталуы (көкжиек/тікұшақ) , шектері (коннектілер, pps, IOPS), кешігу.
• Бас тарту саясаты (rate limit, circuit breaker, тозу).
• SLO жергілікті және олардың e2e-SLO қосқан үлесі.

6) Қателер қоры және бюджеті

Біз headroom-ды error budget-ке байланыстырамыз: бюджет аз → қор көп.
Сыни ағындар үшін (төлем/верификация) - headroom жоғары, екінші дәрежелі ағындар үшін - төмен.
Суық/жылы резервтер: пик/авария кезінде активтендірілетін.

7) Масштабтау: тактика

HPA (жүктеме өлшемдері бойынша): RPS, latency, кезек ұзындығы, пайдаланушы SLIs (better than 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, ескі партияларды/снапшоттарды тазалау.
Көші-қон схемасы: expand → migrate → contract тоқтату бұғаттауынсыз.

10) Оқиға ағындары және ETL

Kafka/шина: партиялардың өткізу қабілеті, lag, ISR, compaction, продюсерлердің/консьюмерлердің лимиттері.
ETL/батчилер: іске қосу терезелері, орындау уақытының бюджеттері, прод-сторанға әсері (throttle I/O).
Сыни флоу үшін теңсіздік және exactly-once-like (төлемдер/баланстар).

11) Желі және периметр

L4/L7 теңгерушілер: connection limits, syn backlog, TLS offload, session reuse.
CDN/Edge: origin жүктемесін төмендету үшін өткізу, кэш саясаты.
Ішкі желілік лимиттер: VPC/кіші желідегі pps/mbps, egress-құны (FinOps).

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

Стратегиялар: active-active (GSLB/Anycast), active-passive (ыстық/жылы/суық DR).
Өңірлер бойынша N + 1: SLO core-ағындарын сақтай отырып, AZ/өңірдің шығынына шыдау.
Заңды оқшаулау: трафикті/деректерді елдер бойынша бөлу, әртүрлі лимиттер мен SLO провайдерлерге бөлу.
DR тесттері: жүктемені нақты тасымалдаумен тұрақты game-days.

13) Сыртқы провайдерлер: квоталар мен бағыттар

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

14) FinOps: құны және тиімділігі

TCO: compute + storage + network egress + лицензиялар/провайдерлер + кезекшілік.
Unit Economics: 1k сұрау құны/1 депозиттік операция/1 KYC.
Оңтайландыру: right-sizing, spot/префиксті жеңілдіктер, кэш-хитрейт, логтардың/трассировкалардың дедупы, салқын сақтау деңгейлері.
Жүктемені уақыт бойынша ауыстыру: «түнгі» терезелерге және арзан өңірлерге сыни емес батчилер.

15) Дашбордтар және есептілік (ең аз жиынтық)

• Ағымдағы жүктеме vs буындар бойынша тұрақты throughput.
• Сервистер және өңірлер бойынша Headroom; 24/72 сағатқа болжам.
• KPI FinOps: $/1k сұрау, $/депозит.

• Жоғарғы тар жерлер (p99, saturation, lag), DR бойынша қор.

• Провайдерлердің табыстылығы/жасырындылығы және лимиттері; маршруттар бойынша трафиктің үлесі.

• Апгрейдтер/индекстер/оңтайландыру жоспары, күтілетін үнемдеу/сыйымдылықтың өсуі.

16) Процестер мен рөлдер

RACI: Платформалық (инфра/кластер/теңгерушілер), ДБ/Деректер (индекстер, репликациялар), Сервистік командалар (бейіндеу/кэш), SRE (SLO, алерттар), Sec/Compliance (крипто/журналдар), Қаржы (бюджет).
Ырғақ: апталық capacity-review (жол картасы, болжам, тәуекелдер), ай сайынғы FinOps-мәліметтер, тоқсан сайынғы DR-тесттер.
Change Management: ірі кампаниялар/релиздер capacity-gate (төменде чек парағы) өтеді.

17) Шығарылым мен кампаниялардың чек-парағы (capacity-gate)

• Шыңға жүктеме болжамы және «+ x% авариялық артқы».
• Негізгі ағындар үшін қол жетімді headroom (төлемдер/АКЖ/логин).
• Провайдерлерге квоталар расталды; баламалы бағыттар белсенді.
• HPA/KEDA табалдырықтары мен warm-pool теңшелген.
• Кезектер/лимиттер және тозулар тексерілді (ойнатқыштар дайын).
• Канареялық үлестер мен авто-кері қайту қосылған.
• Дашбордтар/алерталар (burn-rate, saturation, p99) тексерілді.
• DR жоспары мен эскалация байланыстары өзекті.

18) Қарсы үлгілер

«CPU <70% - бәрі жақсы»: тәуелділік шегін елемеу (БД, IOPS коннектілері, кезектер).
per-звено метрикасыз орталықтандырылған «қара жәшік» - лимиттің қайда екенін түсіну мүмкін емес.
Кэш-стратегияның жоқтығы - релиздегі қателіктер origin-ді өлтіреді.
Бюджеттерсіз ретрайлер лимиттерінің хардкоды - сұраулар дауылы.
«Бір төлем провайдері» - бас тарту нүктесі.
Жылы резервтерді елемеу - тосын оқиғалар себебі ретінде суық бастау.
Мерзімді DR-тесттер жоқ - жоспар қажет болғанда жұмыс істемейді.

19) Шағын калькуляциялар (мысал)

X сервисі: тұрақты 350 RPS pod (vCPU = 1, RAM = 2 GiB). Мақсаты - 5 000 RPS, headroom 25%.
Қажетті қуат = '5000/0. 75 = 6667 RPS`.
Подов = 'ceil (6667/350) = 20'. Плюс warm-pool 15% → тағы 3 pod.
БД: 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, шектеулер/ретрайлер/кезектерді теңшеу.
8. Провайдерлік квоталарды тексеру, мульти-маршруттарды қосу.
9. Дашбордтарды және capacity-review апталық ырғағын жинау.
10. Тоқсан сайын - DR-жаттығулар және модельді қайта қарау.

21) Қорытынды

Қуаттарды жоспарлау - бұл «CPU қосу» емес, болжамдардың, сәулеттік шектеулер мен құнның басқарылатын байланысы. e2e-жолдың әрбір қабаты өлшенген сыйымдылыққа ие болса, ал headroom және деградация стратегиялары SLO және error budget-пен байланысты болса, ең жоғары жүктемелер, науқандар және авариялар тосын сый болудан қалады. Мұндай тәсіл оқыс оқиғалар қаупін азайтады, бизнес-метриканы тұрақтандырады және шығындарды оңтайландырады.