Test di stabilità

1) Concetti e obiettivi di base

Affidabilità - Probabilità di integrità resilienza - Comportamento durante e dopo un guasto.
SLO/bilancio errato: criteri di accettabilità del degrado.
Steady-state hypothesis - Attesa formale di metriche stabili (ad esempio p95 <200 ms, error rate <0. 5%). L'esperimento è considerato un successo se l'ipotesi è accettata.
Tipi di guasto: rete (latitanza, perdita/ripresa, interruzioni), calcolo (CPU, memoria), storiage (I/O, esaurimento del disco), dipendenze (5xx, timeouts, rate-limit), logici (incidenti parziali, degrado lento), operativi (rilascio, config), scuri (incidenti parziali, degrado) split-brain, turni orari).

2) Piramide della stabilità

1. Test unit di errore logico (retrai, idampotenza, timeout).
2. Componenti con adattatori fault-inject (Testcontainers/tc-netem).
3. Integrazione/sistema con rete/database/cache e profili real-world.
4. Esperimenti di caos in pre-prod (e poi limitatamente in vendita) per runbook '.
5. Game Day è un insegnamento scenografico della squadra (uomini + strumenti).

3) Osservabilità come base

SLI: latitanza p50/p95/p99, error rate, saturation (CPU/heap/FD/IOPS), drop/timeout, queue depth.
Tracciati per trovare i colli di bottiglia in caso di guasto.
Metriche di stabilità semantiche: percentuale di graceful-degrade di successo, percentuale di query shed, velocità di autosufficienza (MTTR).
Etichettatura esperimenti: 'chaos. experience _ id ',' phase = inject/recover'negli eventi/login.

4) Catalogo delle iniezioni di guasto (faults)

Rete: ritardo/jitter, perdita/duplicazione/reordering, limitazione della larghezza di banda, batch, scogliere TLS.
Host: limitazione CPU, perdite/limiti di memoria, interruzioni GC, esaurimento descrittori, clock skew.
Storage: aumento della latitanza, EROFS, ENOSPC, degrado della replica, perdita del leader.
Dipendenze: 5xx/429, rallentamento, flapping DNS, certificati obsoleti, rate-limit, risposte parziali.
Dati: danni alla scrittura, buchi nei flussi, riprese di eventi, conflitti di versione.
Operazioni: lancio fallito, flag fiech, deriva config, errore manuale (all'interno della simulazione).

5) Pattern di stabilità (cosa verificare)

Retrai con jitter e timeout su ogni RPC.
Circuito Breaker (apertura/semiapertura, ripristino esponenziale).
Bulkheads (isolamento dei pool/code sui domini critici).
Load Shedding (reimpostare richieste a bassa priorità durante la saturazione).
Backpressure (segnali verso l'alto, limiti di parallelismo).
Idempotency (chiavi di idempotenza su «effetti collaterali»).
Cash e branco in caso di degrado della sorgente.
Graceful Degradation (risposte agevolate, dati stale, disattivazione del filetto).
Timeout-budget (bilancio totale del tempo per catena di chiamate).
Atomicità/compensi (Saga/Outbox/Transactional Inbox).
Quorum e replica (R/W quorum, degrado della consistenza per la disponibilità).
Anti-entropy/repliche (ripristino in «buchi» di eventi).

6) Prescrizioni per iniezioni e aspettative (pseudocode)

Retrai con jitter e breaker

for attempt in 1..N:
if breaker. open(): return fallback()
res = call(dep, timeout = base 0. 8)
if res. ok: return res sleep(exp_backoff(attempt) jitter(0. 5..1. 5))
if attempt == N: breaker. trip()
return fallback()

Shading e backprescher

if queue. depth() > HIGH          cpu. load() > 0. 85:
if request. priority < HIGH: return 503_SHED limiter. acquire () # constrain concurrency

Idampotenza

key = hash("payout:"+external_id)
if store. exists(key): return store. get(key)
result = do_side_effect()
store. put(key, result, ttl=30d)
return result

7) Esperimenti: scenari e ipotesi

7. 1 «Dipendenza lenta»

Iniezione: + 400 ms p95 all'API esterna.
Attesa: aumento dei timeout X%, apertura del breaker, risposte fallback, salvataggio del servizio p99 <SLA, nessuna cascata per i retrai.

7. 2 «Perdita parziale della cache»

Iniezione: perdita del 50% dei nodi Redis/Kesh Shard.
Attesa: miss ingrandita, ma senza valanga all'origine (richiest coalescing/immutabili TTL), riscaldamento automatico e recupero.

7. 3 «Split-brain in database»

Iniezione: perdita del leader, cambio di battuta.
Attesa: deny record a breve termine, leggiamo dal quorum, nessuna perdita di dati, Outbox non perde il messaggio.

7. 4 «ENOSPC/disco pieno»

L'iniezione è al 95-100%.
In attesa: rotazioni di emergenza dei fogli, interruzione dei fili non bloccanti, conservazione dei registri critici (WAL), degli alert e della vista automatica.

7. 5 «Traffico burst»

Iniezione: x 3 RPS per endpoint hot 10 min

L'attesa è: shading di bassa priorità, p95 stabili nelle vie «nucleari», crescita delle code entro i limiti, assenza di tempeste DLQ.

7. 6 «Clock Skew»

Iniezione: scostamento del tempo del fieno di +/- 2 minuti

In attesa: TTL/firme corrette (leeway), timer monotonici nei retrai, token validi alla deriva accettabile.

8) Ambienti e sicurezza degli esperimenti

Iniziate con il pre-prod, i dati sintetici più vicini alla vendita di confighi/topologia.
In vendita ci sono solo finestre controllate, flag fich, ampiezza passo passo, auto-rientro, pulsante rosso.
Guardrails: limiti RPS/errori, guardie SLO, blocco dei lanci durante incidenti critici.
Il runbook è obbligatorio: come ritoccare, chi chiamare, dove guardare.

9) Automazione e CI/CD

Elenco degli esperimenti come codice (YAML/DSL): obiettivi, iniezioni, metriche, soglie, pulsanti di ripristino.
Smoke-chaos in ogni comunicato: iniezioni brevi (ad esempio, 2 min + 200 ms alla dipendenza) in staidge.
I test notturni della matrice sono servizi e tipi di guasti.
Gate di rilascio: proibisce il deploy se la stabilità è inferiore alla soglia (ad esempio, 'fallback coverage <95%' sotto «dipendenza lenta»).

10) Dati e consistenza

Verifica compensi - Le operazioni parzialmente eseguite devono arrivare allo stato concordato.
Testare ripetizioni/riprese di eventi, spedizioni out-of-order, buchi e repliche.
Convalida gli invarianti di dominio in caso di guasto: il saldo non è negativo, le transazioni non sono bloccate, i limiti non sono violati.

11) Anti-pattern

Prova solo happy-path e carico senza guasti.
I retrai senza jitter hanno → una tempesta sotto il degrado.
L'assenza di un budget globale per i timeout ha → i timeout a cascata.
Un unico pool per tutte le attività → l'assenza di isolamento (bulkheads).
«Infinite» code per l'aumento della latitanza/OOM.
La telemetria zero degli esperimenti è una pratica di caos cieco.
Caos in vendita senza ritiri/limiti/proprietario responsabile.

12) Assegno-foglio architetto

1. Ipotesi steady-state definita e SLO?
2. Ogni RPC ha timeout, retrai con jitter, breaker?
3. Implementati bulkheads, limitatori, backpressure, load-shedding?
4. Coalescing, protezione contro le tempeste, riscaldamento?
5. Outbox/Saga per gli effetti collaterali, chiavi idipotenti?
6. Quorum/replica/feelover testati?
7. Ci sono un catalogo di esperimenti, caos nightly e gate in CHI/CD?
8. Le metriche e le tracce segnano gli esperimenti, ci sono i dashboard?
9. Runbook e il pulsante rosso sono pronti, la responsabilità è assegnata?
10. Giochi regolari che coinvolgono il Deve/SRE/Support?

13) Mini strumenti e esempi di script (sketch YAML)

Rete (tc/netem)

yaml experiment: add-latency target: svc:payments inject:
netem:
delay_ms: 300 jitter_ms: 50 loss: 2%
duration: 10m guardrails:
error_rate: "< 1%"
p95_latency: "< 400ms"

CPU/Heap

yaml inject:
cpu_burn: { cores: 2, duration: 5m }
heap_fill: { mb: 512 }

Dipendenza

yaml inject:
dependency:
name: currency-api mode: slow p95_add_ms: 500 fallback_expectation: "serve stale rates ≤ 15m old"

Conclusione

Il test della stabilità non è un trucco nel caos, ma una disciplina che rende il sistema prevedibile in caso di guasti. Ipotesi chiare, telemetria, catalogo di esperimenti gestiti e pattern integrati nell'architettura (timeout, breaker, isolamento, idepotenza) trasformano potenziali incidenti in scenari controllati. Il team ottiene la certezza delle release e gli utenti un servizio stabile anche in caso di guasti.