Operazioni e gestione della capacità di Alerta

Alert di capacità

1) Perché è necessario

Gli alert di capacità avvertono di avvicinarsi ai limiti tecnici molto prima dell'incidente, «siamo all '80% del soffitto - è ora di scalare». Per le imprese alimentari si tratta direttamente di denaro: scommesse/depositi mancanti, sessioni di drop, ritardi nei giochi live e rinunce ai provider = ricavi persi, reputazione, multe e rimborsi.

• Prevedibilmente resistere ai picchi di carico (iventi, tornei, striam, grandi campagne).
• Includere lo skailing automatico in tempo e pianificare capacity uplift.
• Abbassare il rumore e svegliarsi quando i soldi sono a rischio SLO.
• Dare consigli precisi agli ingegneri attraverso il runbook.

2) Concetti di base

Capacità (Capacity): larghezza di banda massima (RPS/TPS, connettori, IOPS, throughput).
Headroom - Riserva tra il carico corrente e i limiti.
SLO/SLA: target di disponibilità/tempo di risposta Gli alert devono essere «SLO-aware».
Burn-rate: velocità di bruciatura del bilancio SLO degli errori/latitanza.
High/Low Watermark - Livelli superiori/inferiori per attivazioni e ripristino automatico.

3) Architettura dei segnali e delle origini dati

Telemetria: metriche (Prometheus/OTel), logi (ELK/ClickHouse), tracciabili (OTel/Jaeger).
Approccio a livello: alert a livello (Edge) API, servizi di business code/striam, database/cache, file/oggetti, provider esterni.
Contesto: phicheflagi, release, campagne di marketing, tornei, geo-design.
Incidente pneumatico: Alertmanager/PagerDuty/Opsgenie/Slack; riferimento al runbook e alla matrice di escalation.

4) Metriche chiave per livello (cosa monitor e perché)

Edge / L7

RPS, 95-/99-percentile latency, errorrate (5xx/4xx), open connection.
Rate-limits/quotas, drops на CDN/WAF/Firewall.

API-шлюз / Backend-for-Frontend

Saturation per worker/work pool, coda di richieste, timeouts ai downstream.
Percentuale di degrado (fallbacks, circuiti-breakers).

Code/Streaming (Kafka/Rabbit/Pulsar)

Lag/consumer delay, backlog growth rate, throughput (msg/s, MB/s).
Partition skew, rebalancing churn, ISR (per Kafka), retrai/nonno lettore.

Worker asincroni

Tempo di attesa delle operazioni, lunghezza della coda, percentuale di operazioni SLA scadute.
Saturation CPU/Memory/FD nei pool.

Cache (Redis/Memcached)

Hit ratio, latency, evictions, used memory, client connessi/ops/s.
Cluster: slot/repliche, failover events.

БД (PostgreSQL/MySQL/ClickHouse)

Active connections vs max, lock waits, replication lag, buffer/cache hit.
IOPS, read/write latency, checkpoint/flush, bloat/fragmentation.

Archivio oggetti/file

PUT/GET latency, 4xx/5xx, egress, query/s, limiti del provider.

Provider esterni (pagamenti/CUS/provider di giochi)

Limiti TPS, finestre QPS, errore rate/timeout, coda di retrai, «cost per call».

Infrastruttura

CPU/Memory/FD/IOPS/Network saturation su nodi/pod/ASG.
Eventi HPA/VPA, pending pods, contenitori OOM/Throttling.

5) Tipi di alert di capacità

1. Soglie statiche

Semplice e comprensibile: 'db _ connessioni> 80% max'. Bene come «segnale-faro».

2. Soglie adattive (dinamiche)

Basati su stagionalità e trend (rolling windows, decomposizione STL). Permettono di catturare «fuori luogo per questa settimana».

3. Orientati SLO (burn-rate)

Si agisce quando la velocità di deambulazione error-budget mette a rischio la SLO nell'orizzonte X dell'orologio.

4. Predittiva (forecast-alerts)

Tra 20 minuti, con la tendenza attuale, la coda raggiungerà il 90%. Usano una previsione lineare/Robust/Prophet simile su finestre brevi.

5. Composti (multi-signal)

Triguerà con la combinazione dì queue _ lag «+» consumer _ cpu 85% '+ «autoscaling at max» «richiede un intervento manuale».

6) Regole di soglia e anti-rumore

• Su: avvertenza 70-75%, creta 85-90%. Giù: isteresi 5-10 p. Per non «segare alla soglia».

• «for: 5m» per i criti, «for: 10-15m» per gli avvisi. Night-mode - ruotare il non-ritico in chat senza cercapersone.

• Raggruppa per servizio/cluster/geo per non produrre schede di incidenti.

• Se il provider KYC è su out e errori API, la conseguenza è il cercapersone del proprietario dell'integrazione, non tutti i consumatori.

• Durante il periodo di azioni aumentare le soglie di rumore per la «crescita prevista», ma lasciare gli alert SLO intatti.

7) Esempi di regole (pseudo-Prometheus)

ALERT PostgresConnectionsHigh
IF (pg_stat_activity_active / pg_max_connections) > 0. 85
FOR 5m
LABELS {severity="critical", team="core-db"}
ANNOTATIONS {summary="Postgres connections >85%"}

ALERT StreamBacklogAtRisk
IF (kafka_consumer_lag > 5_000_000 AND rate(kafka_consumer_lag[5m]) > 50_000)
AND (hpa_desired_replicas == hpa_max_replicas)
FOR 10m
LABELS {severity="critical", team="streaming"}

ALERT ApiLatencySLOBurn
IF slo_latency_budget_burnrate{le="300ms"} > 4
FOR 15m
LABELS {severity="page", team="api"}
ANNOTATIONS {runbook="wiki://runbooks/api-latency"}

ALERT RedisEvictions
IF rate(redis_evicted_keys_total[5m]) > 0
AND (redis_used_memory / redis_maxmemory) > 0. 8
FOR 5m
LABELS {severity="warning", team="caching"}

ALERT PSPThroughputLimitNear
IF increase(psp_calls_total[10m]) > 0. 9 psp_rate_limit_window
FOR 5m
LABELS {severity="warning", team="payments", provider="PSP-X"}

8) Approccio SLO e priorità aziendale

Da segnale a esposizione a business: gli alert di capacità devono fare riferimento a risk to SLO (giochi specifici/geo/metriche GGR, conversione deposito).
Allarmi su più livelli per il servizio on-call; Crit - Server del proprietario del dominio La caduta SLO è un incidente grave e un canale di comando.
Phicheflagi di degrado: riduzione automatica del carico di lavoro (read-only parziale, taglio dei pesi pesanti, riduzione della frequenza di jackpot broadcast, spegnimento delle animazioni «pesanti» nei giochi live).

9) Scale automatico e trigger «corretti»

HPA/VPA: target non solo per CPU/Memory, ma anche per metriche aziendali (RPS, queue lag, p99 latency).
Warm-up timing - Considera la partenza fredda e i limiti del provider (ASG spin-up, contenitori, riscaldamento della cache).
Condizioni di arresto in caso di aumento di errori; Protezione contro gli skailing.
Capacity-playbooks: dove e come aggiungere shard/partition/replica, come ridistribuire il traffico per regione.

10) Processo: dalla progettazione all'utilizzo

1. Mappatura dei limiti: raccoglie i limiti «veri» bottleneck per ogni livello (max conns, iOPS, TPS, quotas provider).
2. Selezione dei predatori metrici: quali segnali prima di tutti indicano «battersi in N minuti».
3. Il design delle soglie è high/low + slo-burn + composto.
4. Runbook per ogni crit: fasi di diagnostica («cosa aprire», «quali comandi», «dove ingrandire»), tre opzioni: giro rapido, ridimensionamento, degrado.
5. Test: simulazione dei carichi (chaos/game days), avvio secco degli alert, controllo anti-rumore.
6. Il proprietario del segnale = proprietario del servizio. Senza il proprietario, niente pagelle.
7. Retrospettive e sintonizzazioni: analisi settimanale di falsi/omessi; metrica «MTTA (ack), MTTD, MTTR, Noise/Segnale ratio».

11) Anti-pattern

CPU> 90% panico, senza correlazione con latency/queues può essere normale.
Una soglia su tutte: regioni/zone temporali diverse - profili di traffico diversi.
Alert senza runbook: il software senza un'azione chiara esaurisce l'on-call.
Cecità ai provider: quote/limiti esterni spesso sono i primi a rompere gli script (PSP, KYC, antifrode, provider di giochi).
Nessuna isteresi, «segare» al confine 80 %/79%.

12) Caratteristiche iGaming/finplatform

Picchi orari: prime time, finali di tornei, grandi partite; Aumentare in anticipo le repliche di destinazione e riempire la cache.
I live-striam e i jackpot sono i picchi delle emittenti e i limiti sui broker/siti web.
Pagamenti e KYC: finestre dei provider, antifrode-screen; mantenere le rotte di riserva e la modalità «grace» dei depositi.
Geo-bilanciamento: le scorribande locali del provider - portare il traffico nella regione vicina dove c'è headroom.
Responsabilità: quando si corrono rischi di perdita di scommesse/jackpot è un comando di dominio istantaneo + notifica aziendale.

13) Dashboard (set minimo)

Capacity Overview: headroom per strati, top 3 aree a rischio, burn-rate SLO.
Stream & Queues: lag, backlog growth, consumer saturation, HPA state.
DB & Cache: connettori, repl-lag, p95/p99 latency, hit ratio, evictions.
Providers: TPS/finestre/quote, timeouts/errors, costo delle chiamate.
Release/Feature text - Rilasci/ficcaflagi accanto alle curve.

14) Assegno foglio di implementazione

• Elenco dei limiti e dei proprietari «veri».
• Mappa dei predatori metrici + associazione tra i livelli.
• Soglie statiche + isteresi.
• SLO-burn-alert su percorsi critici (deposito, puntata, avvio live-game).
• Alert predittivi in coda/striam/connettori.
• Suppressione/maintenance della finestra; anti-rumore della politica.
• Runbook ', con comandi, grafici, fitte di degrado.
• Analisi settimanale di falsi effetti e sintonizzazione.
• Conteggio delle campagne di marketing e del calendario degli iventi.

15) Esempio di modello runbook (abbreviato)

Segnale dì StreamBacklogAtRisk "

Obiettivo: Evitare che lag> 10 milioni e guadagni in ritardo> 5 minuti

1. Controlla «hpa _ desired/max», throttle/oom nei pod.

2. Vedere «rate (lag)», distribuzione per partenze (skew).

3. Controlla il broker (ISR, under-replicated, network).

• Aumenta il consumer-replica di + N, alza max-in-flight.
• Abilita il pool di priorità per i topic critici.
• Ridurre temporaneamente la frequenza di guadagno secondario/entrichment.
• Se ASG at max - richiedere un uplift temporaneo alla nuvola; parallelamente, attivare il degrado delle funzioni pesanti.
• Ripristina - Torna al profilo «normale» dopo «lag <1 milione» 15 minuti.
• Escalation: proprietario del cluster Kafka, seguito dalla piattaforma SRE.

16) KPI e qualità dei segnali

Coverage:% percorsi critici chiusi con alert di capacità.
Noise/Ni: non più di 1 falso pagella per on-call/settimana.
MTTD/MTTR: gli incidenti di capacità vengono rilevati ≤5 minuti prima dei colpi SLO.
Proactive saves: problemi evitati (postmortem).

17) Partenza rapida (default conservatori)

OBD: avvertenza del 75% dei connettori/iOPS/lat; creta 85%, isteresi 8-10 p.
Cache: 'hit <0. 9 'Y'evictions> 0'> 5 minuti - Avviso; 'used _ mem> 85%' - creta.
Code: «lag» altezza> 3 media per 30d + «hpa at max» - creta.
API: `p99 > SLO1. 3 '10 min - Avviso;' burn-rate> 4 '15 min - creta.
Provider: 'throughput> 90% di quota' - Avviso; 'timeouts> 5%' - creta.

18) FAQ

Q: Perché non allungare semplicemente «CPU> 80%»?
A: Senza il contesto latency/code è rumore. La CPU da sola non è un rischio.

Sono necessarie soglie adattive?
A: Sì, per la stagionalità giornaliera/settimanale, diminuiscono i falsi effetti.

Q: Come si tiene conto del marketing/ivent?
A: Calendario delle campagne di annotazione su grafici + regolazione temporanea anti-rumore, ma non toccare gli alert SLO.