Previsione del carico e dei rischi

1) Perché è necessario

• Pianificazione della capacità (capacity planning) e del budget
• Impostazioni SLO/SLI, bilancio degli errori e regole di alerting
• scegliere la strategia di rilascio (canary, blue-green, dark launch);
• gestione dei rischi: prevenzione del degrado, delle code, del drop delle transazioni, delle multe SLA.

2) Concetti di base

Carico (Load) - Intensità eventi/operazioni in ingresso (RPS, TPS, events/sec) e consumo CPU/RAM/IO/NET.
Capacità (Capacity) - Prestazioni sostenibili con SLO e costi specificati.
Rischio: probabilità x impatto evento indesiderato (errore SLA, incidente, sovrapprezzo).
Indicatori iniziali: metriche che crescono prima dell'incidente (latency p95/p99, queue depth, GC sessions, error rate, saturation).
Riserva robustezza (Headroom) - Il rapporto della capacità disponibile con il carico corrente.

3) Origini dati e metriche

Sorgenti: logi e metriche (Prometheus/OTTEL), tracciabili, eventi (Kafka), logi CDN/WAF/ALB, dati di marcia (campagne), calendari eventi, bollo/costa (FinOps), fittiflagi/lanci, code (Kafka/Rabbit)), database/cache.

• Traffico: RPS/TPS, utenti attivi (DAU/MAU), sessioni, conversione dei passi.
• Prestazioni: latency p50/p95/p99, throughput, errori (4xx/5xx), timeouts, retries.
• Ресурсы: CPU/LoadAvg, RAM/GC, disk IOps/lat, network bw, connection pool usage.
• Code: backlog, lag, consumer lag, time-in-queue.
• БД: QPS, lock waits, slow queries, replication lag.
• Кэши: hit ratio, eviction rate, hot keys.
• Livello di business: depositi/tassi al minuto, rifiuti di pagamento, KYC/AML code.
• Affidabilità: SLI/SLO, errore budget burn rate (1h/6h/24h).

4) Modelli di previsione di base

1. Determinati e di calendario: regressione per driver noti (data/ora, partite, tornei, market pool, geo, pass d'azione).
2. Statistiche: stagionalità/trend (ARIMA/ETS), regressione con feste, Prophet-simili approcci.
3. ML/ensemblaggi: busting gradiente/Random Forest/XGBoost/LightGBM; aggiungiamo fici: tempo, cambio, notizie sportive, iventi concorrenti.
4. Miscelati: statistiche per stagionalità di base + ML per fattori esogeni (campagne, release).
5. Quote/Quantili: previsione non solo media, ma anche p90/p95 per la pianificazione headroom.

Le uscite del modello includono la previsione RPS/TPS e la distribuzione della latitanza/errore negli orizzonti T + 1h/T + 24h/T + 7d/T + 30d con intervalli di fiducia.

5) Code e limiti: mini-teoria

La legge Little è L = © x W (media del sistema = intensità x media del tempo).
Colli di bottiglia: BD/cache/bus/pool di connessioni/limiti dei provider API.
Saturation: quando si scarica> 70-80%, la latitanza aumenta in modo non lineare.
Backpressure - Protegge i consumatori dal sovraccarico (limiti, code, regole shed, degrado del filo).

6) Pianificazione della capacità (Capacity Planning)

Metodo «da SLO» - La latitanza p99 richiesta e l'error rate valido di quale throughput si applica a headroom N%.
Il metodo «da script» è «Match LH», «Black Friday», «Torneo su larga scala», «Quantile di traffico superiore» + guasto di un AZ/nodo.
Metodo «cost-aware»: scegliamo configurazioni da $/RPS, considerando sconti, prenotazioni, spot/abbonamenti, autoscaling.

Artefatti: Capacity Model per servizio, limiti e quote (API, database, code), tabella Stretch, Azione (Charding, Cache, Replica, CQRS, async).

7) Gestione dei rischi

Registro dei rischi: identificazione, descrizione, probabilità, impatto (finanza/SLA/regolazione), proprietari, piani di prevenzione/risposta.
Categorie: carico di lavoro (surriscaldamento), infrastrutture (AZ/region fail), dipendenze (provider di pagamenti), rilascio (regress), alimentari (la campagna è salita più delle aspettative), complaence (limiti/regolatore).
Matrice: Heatmap (Low/Medium/High x Impatto).
KRI (Key Risk Indicators) - Profondità delle code, p99, calo dell'hit-ratio, burn rate> 2 x, errori dei provider.

8) Allarme precoce e alerting

Early-warning SLIs: crescita p95, riduzione dei successi di cache, crescita tail latency, crescita retry/timeout, aumento consumer lag.
Burn-rate alert di bilancio degli errori sono veloci (1h) e lenti (6-24h).
Soglie e anomalie basate su alert: soglie di base + modelli di anomalie (IQR, STL, rilevatori di flusso).
Aggregazione dei segnali: accoppiamento degli eventi di rilascio/ficcoflag/campagne di degrado.

9) Analisi scenografica e «what-if»

«Se il traffico aumenta del 60% in 10 minuti?»

«Se CDN/WAF taglia il 5% del traffico legittimo?»

«Se il provider perde il 30% delle autorizzazioni?»

Per ogni script: metriche previste, colli di bottiglia, passaggi di degrado (toggle off non critici), scale manuale/auto, commutazione dei provider.

10) Test e verifica delle previsioni

Test di carico: traffico sintetico (k6/JMeter/Locust), profili «mix reale».
Game Days/Chaos: disattivazione AZ, degrado del database, esaurimento del pool.
Shadow/Dark - Traffico «verso l'ombra» del nuovo percorso senza influire sul proto.
Retrospettiva di precisione: MAPE/SMAPE/RMSE + post-mortem "dove si sbagliano? ”.

11) Processi e ruoli

• Sassuolo: SRE/Platform/DS.
• Accountable: Head of Ops/SRE.
• Consulted: Dev Leads, Marketing, Finance (FinOps).
• Informed: Support/Compliance/Business.
• Cadence: update settimanali di previsione, revisione mensile SLO/Capacity, pre-Ivent War Rum.

12) Strumenti e pile

Dati: Kafka, ClickHouse/BigQuery, Lake/DWH, dbt.
Monitoraggio: Prometheus, Grafana, Tempo/Jaeger, Loki/ELK, OTel.
ML/Previsioni: Airflow/Argo, feature store, modelli ARIMA/ETS/GBM, servizio di proiezione (gRPC/REST).
Тесты: k6/JMeter/Locust, Fault-injection/Chaos Mesh.
Controllo: Feature Flags, Autoscaling (HPA/KEDA), Policy-as-Code.
FinOps: cost explorer, showback/changeback, $/RPS dashboard.

13) Prassi di implementazione (roadmap)

1. L'inventario delle metriche e delle dipendenze è la mappa dei percorsi critici (deposito, tasso, conclusione).
2. SLO/SLI e budget degli errori → p95/p99, errato-rates, burn-alert.
3. Raccolta e pulizia dei dati: un unico livello di eventi/metriche, deduplicazione, ritardi.
4. La previsione di base di stagionalità è di pattern diurni/settimanali, vacanze/partite.
5. Estensioni driver per la campagna market, rilasci, geo, finestre di pagamento.
6. Modelli Capacity per i servizi headroom, limiti, colli di bottiglia, piano di ottimizzazione.
7. «what-if» e tabella di degrado (kill-switches, read-only, grace).
8. La verifica tramite test/ombre consente di regolare modelli e soglie.
9. La routine della sala operatoria è di proiezioni settimanali, retro pre-event, post-event.
10. Automazione dello scalo automatico in base alle previsioni, connessione automatica dei provider, tecnologia automatica.

14) Antipattern

Prognosi «solo media» senza coda p95/p99.
Ignorando code e pool, i problemi sono in picco.
Manuale a vista, senza validazione e senza metriche di precisione.
Nessun collegamento con i costi di ridimensionamento eccessivo.
Nessun piano di degrado o di ficcaflagi.

15) Dashboard e rapporti

Exec-dashboard: previsione di RPS/TPS (p50/p90/p95), headroom, rischio-calore, burn-rate.
Tac-dashboard: p95/p99 latency per servizi, code/lag, hit-ratio, pool di connessioni, database/cache, limiti API esterni.
Finanziaria: $/RPS, previsione dei costi, effetto ottimizzazione.
Precisione previsioni: previsione vs effettiva, errore per periodi/geo/canali.

16) Modelli di manufatti

Risk Register: ID, rischio, probabilità/impatto, proprietario, KRI, piano di prevaricazione, piano di reazione.
Capacity Sheet: servizio, throughput corrente, limite, ristretto, headroom, estensione richiesta, ETA/costo.
What-If Cards: script, fattori di input, metriche previste, azioni, criteri di completamento.
Playbook Degrade: elenco dei file da disattivare, livelli di QoS, percorsi nella cache/statico, limiti retry/timeout.

17) Funzioni KPI chiave

Esecuzione di SLO (% dei periodi nell'obiettivo), tempi di risposta agli indicatori precoci, precisione delle previsioni (MAPE/SMAPE), numero di incidenti dovuti al sovraccarico, percentuale di scalabilità automatica, risparmio di $/RPS senza degrado SLO.

Totale

La previsione di carico e di rischio di sistema è un collegamento: dati qualitativi, metriche sensibili, modelli di script collaudabili e playbooks per automatizzare la scalabilità e il degrado. Questo tracciato garantisce la sostenibilità, la prevedibilità dei costi e un'esperienza utente stabile anche in picchi estremi.