Chaos Engineering

1) Principi di base

Steady State come ipotesi originale. Definisci chiaramente la norma (ad esempio p95 <200 ms, errore rate <0. 3%, successo del flow critico> 99. 5%).
Variabili isolate. Cambiare se possibile un fattore alla volta per collegare causalmente effetto e miglioramento.
Gradi. Cominciamo con una piccola ampiezza in un ambiente sicuro, allargando la copertura e l'intensità.
Guardrails. Condizioni chiare di stop SLO/alert/bilancio degli errori.
Ripetibilità. L'esperimento deve essere ripetutamente riprodotto (script/manifesti/IaC).
Etica e sicurezza. Niente dati personali o transazioni finanziarie reali in esperimenti di rischio.

2) Cos'è «resiliente»

• Latenza p50/p95/p99 endpoint chiave.
• Percentuale di transazioni riuscite e conversione dei percorsi critici.
• Errore rate, timeout, quota di query «shed» (ritagliate durante la saturazione).
• Velocità di espansione automatica (MTTR), resistenza ai retrai (senza tempeste).
• Invarianti di dominio: nessun «svantaggio nel saldo», pagamenti eseguiti in un unico modo, consistenza delle giornate di report, ecc.

3) Catalogo iniezioni (che «rompiamo»)

Rete: ritardo, jitter, perdita/duplicazione, limitazione della larghezza di banda, scogliere TLS, flapping DNS.
Calcoli: sovraccarico CPU, pressione memoria/GC, esaurimento descrittori, clock skew.
Storage: alto p95 I/O, ENOSPC, guasto leader/replica, split-brain, fsync prolungato.
Dipendenze 5xx/429, «successo lento», degrado API esterne, rate-limit.
Dati: riprese/omissioni di messaggi, out-of-order, voci «sporche», conflitti di versione.
Operazioni: rilascio/config fallito, flag fich con bag, certificato scaduto, rotazione della chiave.
Persone e processi: indisponibilità dei responsabili, ritardo dell'apriva manuale, runbook errato.

4) Progettazione esperimento (modello)

1. Ipotesi: «Con + 300 ms al servizio di cambio p99 API principale <450 mc, si apre un breaker, si dà una risposta stale di 15 minuti fa».
2. Iniezione: profilo di errore (tipo/ampiezza/durata) e tracciato di destinazione.
3. Metriche/tag di loga: contrassegna'chaos. experiment_id`, `phase=inject|recover`.
4. Guardrails: abort a "error _ rate> 2% 'o p99> SLA x 2 più di 1 minuto.
5. Risultati/conclusioni: elenco di osservazioni, bagagli, miglioramenti, piani di lavoro e ripetizione.

5) Osservabilità: cosa obbligatoria

Tracing: percorso di query attraverso dipendenze; i segmenti con degrado sono contrassegnati.
Le metriche di risorse sono CPU, heap/GC, FD, IOPS/lat, bandwidth di rete, profondità delle code.
Metriche aziendali: conversione/successo delle operazioni, percentuale di transazioni compensate.
Loghi di eventi: apertura/chiusura dei breaker, retrai e loro budget, cambio del leader del database.
Il pannello dell'esperimento è un live-dashboard con soglie di guardrail e il pulsante rosso dell'aborto.

6) Guardrail e sicurezza

Tecnico: limite superiore errato/latency, riduzione della percentuale di operazioni di successo, crescita della DLQ.
Organizzativi: finestra del tempo coinvolta on-call, principio «una zona - un solo esperimento».
Dati/compilation: solo sintetici o insiemi impersonali; Vietare i test che comportano una violazione della regolazione.
Ripristino: procedura di rollback/disable flag/soft drain.

7) Pattern di stabilità da manifestare

Budget timeout e retrai jitteri (senza tempeste).
Circuito Breaker con mezza accelerazione (half-open) e ripristino esponenziale.
Bullkheads: isolamento dei pool per criticità (pagamenti vs analista).
Backpressure e rate-limit - Rifilo prevedibile di bassa priorità.
Cache coalescing, protezione contro le tempeste di riscaldamento.
Idampotenza effetti collaterali e sagre con azioni compensative.
Quorum, feelover e anti-entropia per il recupero dei dati.

8) Esempi di script (sketch)

8. 1 Dipendenza lenta (YAML)

yaml experiment: slow-downstream target: svc:api inject:
dependency:
name: currency mode: add_latency p95_ms: 300 duration: 10m guardrails:
error_rate: "< 1. 5%"
p99_latency: "< 450ms"
expectations:
breaker_open: true stale_data_served: "<= 15m"

8. 2 Perdita del leader del database

Iniezione: arresto del leader/rielezione forzata.
In attesa: interruzione temporanea dei record, lettura dal quorum, conservazione di WAL/Outbox, ripristino automatico della replica, assenza di duplice scrittura.

8. 3 ENOSPC su disco logico

Iniezione: riempimento del disco fino al 95-100%.
In attesa: rotazione di emergenza dei logi, conservazione dei registri critici, disattivazione dei fili non ritrici, alert e remediazione automatica.

8. 4 Traffico burst + shading

Iniezione: x 3 RPS per 5 minuti per endpoint caldo.
Attesa: scollegamento di bassa priorità, fisso p95 «core», assenza di cascata di retrai.

9) Automazione in CI/CD

Chaos-smoke in stage per ogni rilascio (iniezioni brevi su ampiezze sicure).
Test notturni su un catalogo di esperimenti (matrice servizi x tipi di guasti).
Gate: il lancio viene bloccato se la «stabilità è al di sotto della soglia» (ad esempio, la percentuale di fallback di successo <95%).
Manufatti: resoconti, roulotte, flauti CPU/heap, smistamenti di metriche e configure.

10) Giorni di gioco (Game Days)

• Ruoli: esperimento principale, osservatore di metriche, operatore di riscossione, rappresentante aziendale.
• Script: degrado della cache, guasto parziale AZ/regione faulover, scarso rilascio, indisponibilità del provider esterno.
• Risultati: le lacune trovate nel runbook, i miglioramenti degli alert, l'aggiustamento dello SLO e i bilanci dei retrai.

11) Caos per dati, eventi e ML

Flussi di dati: test per duplicati, omissioni, out-of-order, ritardi; Verifica di IDUMER e delle strategie DLQ.
Storage: degrado degli indici, hot-partition, conflitto di blocchi, replica sotto la barra.
ML: ritenzione del fich store, ritocco sul modello baseline, deterioramento della qualità dei dati di input (draft) - il sistema deve essere «morbido» anziché cadere.

12) Anti-pattern

Il caos è che siete ciechi, le conclusioni sono speculative.
Iniezioni subito in vendita senza stage e guardrail.
«Un grande esperimento» non è chiaro cosa abbia funzionato.
Azioni di caos non sistemiche senza ipotesi e retest dopo i registri.
Concentrarsi solo sull'infrastruttura - gli invarianti aziendali sono stati dimenticati.
Ignorare persone/processi: alert, on-call, runbook è parte del sistema.

13) Maturità della pratica (modello)

1. Iniezioni singole localmente.
2. Il caos stage è un catalogo di script, test ripetitivi, dashboard.
3. Comunicato-caos: smoke-caos in ogni comunicato, gate, rapporti.
4. Disordine con limitazioni: traffico ridotto, guardrail rigido, recupero pronto.
5. Resilienza continua: esperimenti automatici, controllo SLO, miglioramenti come flusso di lavoro.

14) Integrazione con le pratiche architettoniche

Test di stabilità: esperimenti di caos completano fault-iniezioni e scenari di degrado.
Test di carico - Gli esperimenti combinati di carico e guasto rivelano cascate e tempeste di retrai.
Policy as Code/RBAC/ABAC: guardrail, passi di rimozione e limiti come regole.
Gestione del consenso/privacy: non consentire esperimenti che violano la modalità di elaborazione dei dati.
Architettura Geo: controllo del caos del feelover regionale e collegamento dei dati alle giurisdizioni.

15) Mini-ricette (pseudocode)

Breaker + degrado

if breaker. open():
return serve_stale(cache. max_age=15m)
try:
res = call(dep, timeout=250ms)
return res except Timeout:
breaker. trip()
return serve_stale()

Limitatore + shading

if cpu. load() > 0. 85 or queue. depth() > HIGH:
if req. priority < HIGH: return 503_SHED limiter. acquire()

Effetto collaterale idipotente

key = "payout:"+external_id if kv. exists(key): return kv. get(key)
res = side_effect()
kv. put(key, res, ttl=30d)
return res

16) Assegno-foglia architetto

1. Definiti Steady State e Guardrails?
2. C'è un catalogo di script (rete/CPU/archivio/dipendenze/dati/operazioni)?
3. L'osservabilità copre risorse, code di latitanza, invarianti aziendali?
4. Timeout/retrai/breaker/limitatori/bulkheads sono inclusi e parametrabili?
5. Il runbook e il pulsante rosso sono pronti?
6. C'è caos-smoke in stage e esperimenti nightly?
7. Ci sono finestre e ruoli sicuri per i giorni di gioco?
8. Gli esperimenti sono riprodotti (IaC/script), i risultati sono versionati?
9. I miglioramenti sono fissati dagli obiettivi, si fa retest?
10. Le catene di consegna e ML sono coperte, non solo HTTP?

Conclusione

Chaos Engineering trasforma «incidenti imprevisti» in scenari prevedibili. Ipotesi di stabilità, iniezioni controllate, guardrail rigide, osservabilità e disciplina dei retesti sono strumenti che riducono il rischio di rilascio e aumentano la fiducia nella piattaforma. Alla fine il team capisce i limiti del sistema, sa degradare elegantemente e restituire rapidamente il servizio all'utente anche in caso di guasti.