Planificarea capacității

1) Ce este planificarea capacității și de ce este necesară

Planificarea capacităților este procesul sistematic de evaluare și securizare a resurselor necesare pentru atingerea SLO-urilor țintă la costuri minime. Vorbim nu numai despre procesor/memorie, ci și despre lățimea de bandă a rețelei, stocare, baze de date/cache-uri, cozi/autobuz de evenimente, furnizori externi (plăți/CCM/antifraudă), precum și resurse umane (de gardă, suport).

• Efectuați SLO/SLAs chiar și în vârfuri și degrade.
• Minimizarea TCO și overprovisioning de capital.
• Reduceți riscul incidentelor de a rămâne fără resurse (saturație → p99/eroare).
• Asigurați-vă predictibilitatea lansărilor și campaniilor (marketing, turnee, meciuri de top).

2) Intrările și sursele adevărului

Observabilitate: RPS/concatenare, p50/p95/p99, rata de eroare, saturație (CPU, mem, disk IOPS, rețea pps/mbps), lungimi de coadă, limite de rată.
Evenimente de afaceri: calendare de campanie, sezonalitate (seri/weekenduri/mega-evenimente), regiuni/jurisdicții.
Datoria tehnică/caracteristici: foaia de parcurs a versiunilor, modificări arhitecturale (de exemplu, criptare, noi exploatări forestiere).
Furnizori: cote și transfer de servicii de plată/CUS/mail/antifraudă.
Incidente din trecut: unde este blocajul (bază de date, cache, L7 balancer, autobuz, CDN, disc).

3) Concepte și formule de bază

Headroom - marja de capacitate: 'headroom = (max _ stabil _ RPS − actual _ RPS )/max _ stabil _ RPS'.
Țintă la 20-40% vârf (pentru fluxurile critice).
Saturație - raportul dintre resursa ocupată și cea disponibilă (procesor%, memorie/GC, conexiuni, descriptori de fișiere, IOPS, adâncimea de coadă).
Debit stabil - viteza cu care p99 și rata de eroare efectuează SLO pentru o lungă perioadă de timp (nu o spargere unică).
Unitatea de capacitate (CU) - unitate normalizată de putere pentru serviciu (de exemplu, X RPS per pod vCPU = 1, RAM = 2 GiB).
Limita sistemului este max fără degradare: 'N _ pods × CU'. Este important să se ia în considerare dependențele partajate (DB/cache/bus).

4) Modelul cererii: Prognoză

Serii statistice: sezonalitate săptămânală/zilnică, sărbători, finale sportive, vârfuri regionale.
Cohorte: pe țări, furnizori de plăți, dispozitive, segmente VIP.
Eveniment deltas: impactul campaniilor/pooches/releases/SEO.
„Ce se întâmplă dacă” (planificarea scenariului): + 50% la trafic la 19: 00-22: 00; cădere a furnizorului A → redistribuire la B (+ 30% la latență).
Ajustări în timp real: nowcasting prin valori de plumb (revitalizarea sesiunilor, coadă pentru un meci, coșuri).

5) Modelul de aprovizionare: în cazul în care lanțul „se rupe”

Anchetă transportor: Edge/CDN L7 balancer cerere cache DB extern API turn/anvelope handlers/ETL.

• Capacitate (CU/instanță), scalabilitate (orizont/nod), limite (conexiuni, pps, IOPS), întârzieri.
• Politici de avarie (limită de rată, întrerupător de circuit, degradare).
• SLO-urile sunt locale și contribuția lor la e2e-SLO.

6) Marja de eroare și bugetul

Legăm sala de picioare de bugetul de eroare: mai puțin buget → mai mult stoc.
Pentru fluxurile critice (plată/verificare) - spațiul de mai sus, pentru fluxurile secundare - mai jos.
Rezerve reci/calde: activate la vârf/accident.

7) Scalare: Tactici

HPA (după valorile de încărcare): RPS, latență, lungime de coadă, SLI-uri ale utilizatorilor (mai bune decât procesorul%).
VPA: corectarea resurselor podam (atent cu statuete și p99 GC).
KEDA/adaptoare: scalare după surse externe (Kafka lag, lungimea listei Redis, adâncimea CloudQueue).
Piscine calde/încălzire: cazuri pre-ridicate pentru a evita un început rece.
Abordarea „Load-as-Code”: Politicile autoscale/limită/timeout/retray sunt versionate și revizuite.

8) Cozi, backpressure și controlul cozii

Scopul este de a preveni o creștere asemănătoare avalanșelor de p99.
Limităm concurența și dimensiunea cozii, introducem ferestrele de timp și idempotența.
Hedging/Retry-buget: limitați bugetul total de timp al utilizatorului și al sistemului.
Degradare grațioasă: dezactivarea caracteristicilor secundare la supraîncărcare.

9) DB, cache-uri și de stocare

DB: limita de conexiune, logare/FSync, indici, planul de interogare, replica lag, hot-keys/tabele, TPS max pentru tranzacții.
Keshi: hit-raport pe segment, „furtună de ratări” în timpul eliberării/dizabilității, distribuție cheie.
Stocare: IOPS/debit, întârzieri, compresie, TTL, curățare loturi vechi/instantanee.
Schema de migrare: expand→migrate→contract fără încuietori de oprire.

10) Fluxuri de evenimente și ETL-uri

Kafka/autobuz: party throughput, lag, ISR, compactare, limite producător/consumator.

ETL/loturi: ferestre de pornire, bugete de rulare, accelerație I/O

Idempotența și exact o dată pentru fluxul critic (plăți/solduri).

11) Rețea și perimetru

balansoare L4/L7: limite de conectare, restanțe Syn, descărcare TLS, reutilizare sesiune.
CDN/Edge: lățime de bandă, politică cache pentru a reduce sarcina de origine.
Limite intra-rețea: pps/mbps în VPC/subrețea, cost de ieșire (FinOps).

12) Multi-regiune, DR și jurisdicții

Strategii: activ-activ (GSLB/Anycast), activ-pasiv (fierbinte/cald/rece DR).
N + 1 în funcție de regiune: Susțineți pierderea AZ/regiune, menținând în același timp fluxurile de bază SLO.
Localizare legală: împărțirea traficului/datelor pe țări, limite diferite și SLO-uri în furnizori.
Teste DR: zile regulate de joc cu transfer real de sarcină.

13) Furnizori externi: cote și rute

Plăți/KYC/anti-fraudă/mail/SMS: TPS, cote de spargere, limite zilnice.
Multi-furnizor: rutare prin latență/succes, SLO per furnizor, auto-feiler.
Contracte SLA: conformitate e2e-SLO, canale de escaladare, carti web de stare.

14) FinOps: Cost și eficiență

TCO: calculați + stocare + ieșire din rețea + licențe/furnizori + taxe.
Unit Economics: costul cererilor 1k/1 tranzacție de depozit/1 KYC.
Optimizare: dimensionare dreapta, discounturi spot/prefix, hitrat de cache, log/trace dedup, niveluri de depozitare la rece.
Transfer de sarcină în timp: loturi non-critice în ferestre „de noapte” și regiuni ieftine.

15) Tablouri de bord și raportare (set minim)

• Sarcina curentă vs debit constant peste link-uri.
• Headroom după serviciu și regiune; Prognoza 24/72 oră.
• FinOps KPI: $/1k cereri, $/depozit.

• Blocaje de top (p99, saturație, lag), marja DR.

• Succesul/latența și limitele furnizorului; ponderea traficului pe rute.

• Plan de upgrade/index/optimizare, economii preconizate/cresterea capacitatii.

16) Procese și roluri

RACI: Platform (infra/clusters/balancers), Database/Data (indici, replici), Service commands (profilare/cache), SRE (SLO, alerte), Sec/Compliance (crypto/busteni), Finance (buget).
Ritm: revizuire săptămânală a capacității (foaie de parcurs, prognoză, riscuri), rapoarte lunare FinOps, teste trimestriale DR.
Change Management: Campaniile/versiunile majore merg capacity-gate (lista de verificare de mai jos).

17) Capacitate-poarta

• Prognoza de sarcină maximă și „+ x% coadă de urgență”.
• Spațiu disponibil pentru fluxurile de bază (plăți/ACC/autentificare).
• Cotele au fost confirmate furnizorilor; rute alternative sunt active.
• Pragurile HPA/KEDA și warm-pool sunt configurate.
• Cozi/limite și degradare verificate (playbook-uri gata).
• Acțiunile canare și auto-rollback sunt activate.
• Tablouri de bord/alerte (burn-rate, saturație, p99) verificate.
• Planul DR și contactele de escaladare sunt relevante.

18) Anti-modele

„CPU <70% - totul este bine”: ignorarea limitelor de dependență (conexiuni DB, IOPS, cozi).
Centralizat „cutie neagră”, fără metrici per-link - este imposibil de înțeles în cazul în care limita este.
Lipsa strategiei cache - eliberarea ratează originea ucide.
Codul hardcode limită Retray fără bugete este o furtună de cereri.
„Un singur furnizor de plăți” este un punct de eșec la apogeu.
Ignorarea rezervelor calde este un început rece ca o cauză a incidentelor.
Nu există teste DR periodice - planul nu funcționează atunci când este necesar.

19) Mini estimări de costuri (exemplu)

Serviciul X: stabil 350 RPS pe pod (vCPU = 1, RAM = 2 GiB). Scopul este de 5.000 SPR, înălțime 25%.
Putere necesară = '5000/0. 75 = 6667 RPS ".
Podov = 'ceil (6667/350) = 20'. Plus piscină caldă 15% → încă 3 păstăi.
DB: 12k TPS limita, 9k TPS curent de credit, 10 vârf de prognoză. 5k TPS → stoc 1. 5k (14%). Necesită indici/sharding/replici sau caching pentru a reduce la 8. 5k.
Furnizorul A (KYC): cota 120 rps, vârf 95 rps, campanie + 40% → 133 rps> cote → rutare 70% A/30% B.

20) Șablon de implementare a planificării capacității

1. Descrieți calea e2e și blocajele.
2. Introduceți CU și măsurați debitul susținut al fiecărui strat.
3. Configurați saturația și metrica p99 pe toate link-urile.
4. Generați calendar eveniment/campanie/lansare.
5. Construiți predicția cohortă și ce-dacă scenarii.
6. Pin headroom per-thread și per-region (obligatoriu pentru bugetul de eroare).
7. Configurați piscine calde HPA/VPA/KEDA +, limite/retribuții/cozi.
8. Verificați cotele furnizorului, activați mai multe rute.
9. Colectați tablouri de bord și revizuirea săptămânală a capacității ritmului.
10. Trimestrial - exerciții DR și revizuirea modelului.

21) Linia de jos

Planificarea capacității este un pachet ușor de gestionat de previziuni, constrângeri arhitecturale și costuri, nu "adăuga CPU. "Când fiecare strat al căii e2e are o capacitate măsurată, iar strategiile de înălțime și degradare sunt asociate cu SLO și bugetul de eroare, atunci încărcăturile de vârf, campaniile și accidentele încetează să mai fie o surpriză. Această abordare reduce riscul de incidente, stabilizează valorile de afaceri și optimizează costurile.