Pianificazione della capacità

1) Che cosa è la pianificazione della capacità e perché è necessaria

La pianificazione della capacità (capacity planning) è un processo sistematico di valutazione e fornitura delle risorse necessarie per raggiungere gli obiettivi SLO a costi minimi. Non si tratta solo di CPU/memoria, ma anche di larghezza di banda delle reti, storage, database/cache, code/bus eventi, provider esterni (pagamenti/CUS/antifrode) e risorse umane (on-call, supporto).

• Esegui SLO/SLAs anche in picchi e degradazioni.
• Ridurre al minimo il TCO e il capitale semplice (overprovisioning).
• Ridurre il rischio di incidenti da esaurimento risorse (saturation/errore).
• Garantire la prevedibilità di lanci e campagne (marketing, tornei, top match).

2) Input e fonti di verità

Osservabilità: RPS/Concarrenza, p50/p95/p99, error-rate, saturation (CPU, mem, disk IOPS, pps/mbps in rete), lunghezza delle code, rate dei limiti.
Eventi aziendali: calendari delle campagne, stagionalità (sere/weekend/mega-eventi), regioni/giurisdizione.
Tecnolg/fici: rilasci roadmap, modifiche architettoniche (ad esempio crittografia, nuova logica).
Provider: quote e throughput pagamenti/CUS/servizi postali/servizi antifrode.
Incidenti del passato: dove si trova lo stretto (database, cash, bilanciatore L7, pneumatico, CDN, disco).

3) Concetti e formule di base

Headroom è una scorta di capacità: 'headroom = (max _ sostenibile _ RPS - effettivo _ RPS )/max _ sostenibile _ RPS'.
Target al massimo del 20-40% (per i flussi critici).
Saturation è il rapporto tra la risorsa occupata e quella disponibile (CPU%, memoria/GC, connessioni, file descriptors, IOPS, profondità della coda).
Throughput è la velocità a cui p99 e errato-rate eseguono lo SLO a lungo termine (non una volta).
Capacity Unit (CU) - Unità di potenza razionata per il servizio (ad esempio, X RPS per pod vCPU=1, RAM = 2 GiB).
Il limite di sistema è max senza degrado: 'N _ pods x CU'. È importante considerare le dipendenze shared (database/cash/pneumatico).

4) Modello di domanda: previsione

File statistiche: stagionalità settimanale/giornaliera, feste, finali sportivi, picchi regionali.
Coorti per paese, fornitori di pagamenti, dispositivi, segmenti VIP.
Gli eventi Delta sono influenzati da campagne/cannoni/release/SEO.
«E se» (scenario planning): + 50% al traffico alle 19: 00-22: 00; il provider A può essere ridistribuito in B (+ 30% alla latitanza).
Real-Time di regolazione: nowcasting per Led Metric (riattivazione delle sessioni, coda per la partita, cestini).

5) Modello di frase: dove si rompe la catena

La linea di montaggio della query è Edge/CDN L7-bilanciatore, l'applicazione DB API esterne-coda/bus-processori/ETL.

• Capacità (CU/istanza), scalabilità (orizzonte ./verticale.) , limiti (connettori, pps, iOPS), ritardi.
• Criteri di rifiuto (rate limit, circuito breaker, degrado).
• SLO locale e il loro contributo alla e2e-SLO.

6) Scorte e budget degli errori

Agganciamo headroom a errore budget: meno budget, più riserva.
Per i flussi critici (pagamento/verifica) - headroom superiore, per i flussi secondari inferiore.
Riserve fredde/calde attivabili in caso di picco/incidente.

7) Scalabilità: tattica

HPA (per metriche di carico): RPS, latency, lunghezza della coda, SLIs personalizzati (better than CPU%).
VPA - Aggiustamento delle risorse al servizio (attenta a stateful e p99 GC).
Adattatori KEDA: scalabilità per origine esterna (Kafka lag, Redis list length, CloudQueue depth).
Warm pools/riscaldamento - istanze anticipate per evitare una partenza fredda.
Load-as-Code: i criteri di scansione automatica/limiti/timeout/retrai vengono versionati e rivisti.

8) Code, backpressure e gestione della coda

L'obiettivo è quello di evitare che il p99 cresca a valanga.
Limitiamo parallelismo e dimensione della coda, inserendo finestre temporali e idempotia.
Hedging/Retry-budget - Limita il budget totale dell'utente e del sistema.
Graceful degradation - Disattiva i filetti secondari durante il sovraccarico.

9) Database, caschi e deposito

Database: limite di connettività, registro/FSync, indici, piano di query, replica lag, hot-keys/tabelle, max TPS per transazioni.
Keshi: hit-ratio per segmenti, «tempesta di errori» per segnalazione/invalidità, distribuzione delle chiavi.
Storaj: IOPS/throughput, ritardi, compressione, TTL, pulizia delle vecchie partizioni/snapshot.
Schema di migrazione: nessun blocco d'arresto.

10) Flussi di eventi e ETL

Kafka/pneumatico: larghezza di banda delle partizioni, lag, ISR, competition, limiti dei produttori/consumatori.
ETL/Batch: finestre di avvio, budget di esecuzione, impatto sullo story protetto (throttle I/O).
Idampotenza e exactly-once-like per flow critici (pagamenti/bilanci).

11) Rete e perimetro

Bilanciatori L4/L7: connection limits, syn backlog, TLS offload, sessione reuse.
CDN/Edge: larghezza di banda, criteri di cache per ridurre il carico di lavoro origin.
Limiti intranet: pps/mbps in VPC/subnet, costo egress (FinOps).

12) Multiregione, DR e giurisdizione

Strategie: active-active (GSLB/Anycast), active-passive (calda/calda/fredda DR).
N + 1 per regione: sopportare la perdita di AZ/regione mantenendo il flusso core SLO.
Localizzazione legale: suddivisione del traffico/dati per paese, limiti diversi e SLO per provider.
Test DR: game-days regolari con trasferimento effettivo del carico.

13) Provider esterni: quote e percorsi

Pagamenti/KYC/antifrode/posta/SMS: quote TPS, burst, limiti diurni.
Multi-provider: routing per latenza/successo, SLO per provider, faulker automatico.
Contratti SLA: conformità e2e-SLO, canali di escalation, stato-web.

14) FinOps: costo ed efficienza

TCO: compute + storage + network egress + licenze/provider + servizio di servizio.
Unità Economics: costo 1k richieste/1 deposito/1 KYC.
Ottimizzazione: right-sizing, sconti spot/prefisso, cache-furbizia, dedotto di logi/tracciati, livelli di conservazione freddi.
Spostamento del carico di lavoro nel tempo: batch non critici in finestre notturne e regioni economiche.

15) Dashboard e reporting (set minimo)

• Il carico corrente di vs è un throughput costante lungo gli anelli.
• Headroom per servizi e regioni; La previsione è di 24/72 ore.
• KPI FinOps: $/1k richieste, $/deposito.

• Top stretching (p99, saturation, lag), scorta per DR.

• Successo/latitanza e limiti dei provider; Parte del traffico lungo le rotte.

• Piano di upgrade/indici/ottimizzazioni, risparmio previsto/crescita della capacità.

16) Processi e ruoli

RACI: Platea (Infra/Cluster/Bilanciatori), Database/Dati (indici, repliche), Comandi di servizio (profilassi/cache), SRE (SLO, alert), Sec/Compliance (cripto/riviste), Finanza (budget).
Ritmo: capacity-review settimanale (road map, previsione, rischi), FinOps mensili, test DR trimestrali.
Change Management: le principali campagne/release sono capacity-gate (il foglio di assegno sotto).

17) Scontrino di rilascio e campagne (capacity-gate)

• Previsione del carico di picco e «+ x% coda di emergenza».
• Headroom disponibile per core-thread (pagamenti/CUS/login).
• I provider hanno le quote confermate; Le rotte alternative sono attive.
• Le soglie HPA/KEDA e il warm-pool sono configurati.
• Code/limiti e degrado verificati (playbook pronti).
• Le quote canarie e il rientro automatico sono inclusi.
• I dashboard/alert (burn-rate, saturation, p99) sono stati controllati.
• Il piano DR e i contatti delle escalation sono aggiornati.

18) Anti-pattern

CPU <70% - Tutto bene "- Ignora i limiti delle dipendenze (connettori database, IOPS, code).
Scatola nera centralizzata senza metriche per-anello - impossibile capire dove si trova il limite.
Nessuna strategia cache - I fallimenti durante il rilascio uccidono origin.
L'Hardcode dei limiti dei retraici senza budget è una tempesta di richieste.
«Un provider di pagamenti» è il punto di rifiuto al massimo.
Ignorare le riserve calde è un inizio freddo come causa di incidenti.
Nessun test DR periodico. Il piano non funziona quando serve.

19) Mini-calcolazione (esempio)

Servizio X: robustamente 350 RPS per pod (vCPU=1, RAM = 2 GiB). Obiettivo: 5.000 RPS, headroom 25%.
Potenza necessaria = '5000/0. 75 = 6667 RPS`.
Sottov = 'ceil (6667/350) = 20'. Oltre al warm-pool, il 15% ha → altri 3 pod.
Database: limite 12k TPS, prestito corrente 9k TPS, previsione di picco 10. 5k TPS → 1. 5k (14%). Sono necessari indici/charding/repliche o cache per ridurre fino a 8. 5k.
Provider A (KYC): quota 120 rps, picco 95 rps, campagna + 40% 133 rps> quote di routing 70% A/30% B.

20) Modello di implementazione capacity planning

1. Descrivere il percorso e2e e i colli di bottiglia.
2. Immettere la CU e misurare il throughput resistente di ogni livello.
3. Configura le metriche saturation e p99 su tutti gli anelli.
4. Crea un calendario eventi/campagne/rilasci.
5. Fare previsioni su coorti e sceneggiature.
6. Blocca headroom per-thread e per-regione (riferimento a errore budget).
7. Configura HPA/VPA/KEDA + warm-pools, limiti/retrai/code.
8. Controllare le quote di provider, attivare le rotte multi.
9. Raccogliere i dashboard e il ritmo settimanale capacity-review.
10. Trimestrale - esercitazioni DR e revisione del modello.

21) Totale

La pianificazione della capacità è un collegamento gestito tra previsioni, limiti architettonici e costi, anziché aggiungere CPU. Quando ogni strato del percorso e2e ha una capacità misurata, e headroom e strategie di degrado sono associati con SLO e errore budget, i picchi di carico, le campagne e gli incidenti smettono di essere una sorpresa. Questo approccio riduce il rischio di incidenti, stabilizza le metriche aziendali e ottimizza i costi.