Chaos Engineering: sostenibilità dei sistemi

Chaos Engineering: sostenibilità dei sistemi

1) Perché l'ingegneria del caos

• verificare le ipotesi sul comportamento del sistema e convalidare lo SLO;
• rilevare SPOF nascosti, timeout/retrai errati, effetti a cascata;
• esercitare i comandi: game-days, runbook, comunicazioni;
• formare una cultura «resilienza predefinita» anziché «sperare nel meglio».

L'importante è che la Chaos Engineering si chiami «rompere tutto». Questo è un metodo scientifico: steady-state l'ipotesi di un esperimento le conclusioni di un miglioramento.

2) Ciclo di base dell'esperimento

1. Steady-state (linea base) - Quali SLI sono stabili? (ad esempio, il successo del ≤500 nel '99. 95%).
2. Ipotesi: la perdita di un AZ p95 aumenterà il <10% e la disponibilità aumenterà. 9%.
3. L'esperimento è un folt pianificato con un blast radius limitato e criteri stop.
4. Osservazione: metriche/roulotte/logi, burn-rate SLO, Business SLI (ad esempio depositi di successo).
5. Miglioramenti: rileviamo le scoperte, cambiamo timeout, limiti/routing, aggiorniamo il runbook.
6. Automazione/regress: ripetiamo nella programmazione, aggiungiamo a CI/CD e calendari game-days.

3) Ringhiera di sicurezza (safety first)

Blast radius: inizia con uno stretto - un pod/istanza/percorso/namespace.
Guardrails: alert su SLO burn-rate (rapido/lento), limiti di retro, limitazione QPS, bilancio dell'incidente.
I criteri di stop sono: «Se si è errato-rate> X% o p99> Y ms N minuti - istantaneamente stop e rollback».
Finestre: ore di lavoro on-call, steakholder notificati, rilasci congelati.
Comunicazione: IC/Tech lead/Comms, canale chiaro (War-room), modello di messaggio.

4) Classi di rifiuto e idee di ipotesi

Rete: ritardo/jitter/perdita, drop parziale delle porte, collegamento «flapping» tra servizi/PSP.
Layout/nodi: uccidere processi, surriscaldare CPU, esaurire descrittori di file, pool di connessione stretti.
Storage e database: latency disk, repliche, stop uno shard/leader, split-brain.
Dipendenze: degrado delle API esterne, limiti dei provider, 5xx/429 picchi.
Gestione delle modifiche: lancio fallito, flag fich cattivo, rollout partiale.
Perimetro: CDN degradato, DNS/Anycast drift, WAF/BOT guasto.
Regione/AZ: perdita totale o incidente «parziale» (un pò peggio e imprevedibile).

5) Strumenti e tecniche

Kubernetes: Chaos Mesh, Litmus, PowerfulSeal, kube-monkey.
Nuvole: AWS Fault Injection Simulator (FIS), Fault Domains nelle nuvole.
Rete/proxy: Toxiproxy (TCP-veleno), tc/netem, iptabili, Avvoy fault (delay/abort), Istio fault inquection.
Processi/nodi: «stress-ng», cgrups/CPU-throttle, disk fill.
Traffico-routing: GSLB/DNS weights, canary/blue-green per i failover.

6) Esempi di script (Kubernets)

6. 1 Delay/abort su rotaia (Istio VirtualService)

yaml apiVersion: networking. istio. io/v1alpha3 kind: VirtualService metadata: { name: api-chaos }
spec:
hosts: ["api. internal"]
http:
- route: [{ destination: { host: api-svc } }]
fault:
delay: { percentage: { value: 5 }, fixedDelay: 500ms }
abort: { percentage: { value: 1 }, httpStatus: 503 }

Ipotesi: timeout client/retrai e CB trattengono p95 <300 ms e errore-rate <0. 5%.

6. 2 Pod Kill (Chaos Mesh)

yaml apiVersion: chaos-mesh. org/v1alpha1 kind: PodChaos metadata: { name: kill-one-api }
spec:
action: pod-kill mode: one selector:
namespaces: ["prod"]
labelSelectors: { "app": "api" }
duration: "2m"

Ipotesi: bilanciatore e HPA compensano loss di un'istanza senza crescita p99> 20%.

6. 3 Caos di rete (ritardo al database)

yaml apiVersion: chaos-mesh. org/v1alpha1 kind: NetworkChaos metadata: { name: db-latency }
spec:
action: delay mode: all selector: { namespaces: ["prod"], labelSelectors: {"app":"payments"} }
delay: { latency: "120ms", jitter: "30ms", correlation: "25" }
direction: to target:
selector: { namespaces: ["prod"], labelSelectors: {"role":"db"} }
mode: all duration: "5m"

Ipotesi: pool/timeout/cache ridurranno l'impatto; p95 pagamenti rimarranno SLO.

6. 4 Riempimento unità

yaml apiVersion: chaos-mesh. org/v1alpha1 kind: IOChaos metadata: { name: disk-fill-logs }
spec:
action: fill mode: one selector: { labelSelectors: {"app":"ingest"} }
volumePath: /var/log size: "2Gi"
duration: "10m"

L'ipotesi è che la rotazione di unità/quote/alert funzioni prima che le rotte siano degradate.

7) Esperimenti fuori da K8s

7. 1 Toxiproxy (locale/integrativo)

bash toxiproxy-cli create psp --listen 127. 0. 0. 1:9999 --upstream psp. prod:443 toxiproxy-cli toxic add psp -t latency -a latency=200 -a jitter=50 toxiproxy-cli toxic add psp -t timeout -a timeout=1000

7. 2 Avvoy HTTP fault (perimetro/mesh)

yaml fault:
delay: { fixed_delay: 0. 3s, percentage: { numerator: 10, denominator: HUNDRED } }
abort: { http_status: 503, percentage: { numerator: 1, denominator: HUNDRED } }

7. 3 AWS FIS (esempio di idea)

L'esperimento «uccidere» N% EC2 in Auto Scaling Group, sollevare artificialmente EBS-latency, disattivare NAT-GW in un AZ.
Criteri di stop integrati per le metriche SLO.

8) Metriche di osservabilità durante il caos

SLO/SLI: fraction of good requests, p95/p99, burn-rate.
Modello RED su percorsi critici (Rate, Errors, Duration).
Pool in attesa della connessione p95, utilization.
Lag repliche, locks, p95 richieste alla deriva.
Rete: retransmits, RTT, comportamento dscp/ecn.
Business SLI: successo delle transazioni (depositi/checkout),% dei rimborsi/errori.
Traccia - Tracciati selettivi (exemplars), correlazione di annotazioni di output.

9) Integrazione con SLO/Errore-budget

Pianificate esperimenti all'interno di un bilancio di errori, il caos non dovrebbe distruggere gli obiettivi trimestrali.
Burn-rate alert come automatico kill-switch.
«Quanto budget bruciato», «quali deviazioni steady-state».

10) Game-days (esercitazioni)

Copione: leggenda breve (ad esempio, regione-East persa), passi iniettabili, obiettivi SLO, ruoli, tempo.
Valutazione: RTO/RPO effettivo, qualità delle comunicazioni, correttezza runbook.
La lista dei miglioramenti con proprietari e scadenze, l'aggiornamento della documentazione/dashboard.

11) Automazione e CI/CD

Smoke-chaos: test di staging brevi a ogni rilascio (ad esempio, 1 pod-kill + 200 ms delay per percorso).
Notturni/settimanali: script più pesanti (5-15 min) con report.
Promozioni: se p95/errori> soglia canary - Auto-ritorno.
Repository con directory di esperimenti (YAML + runbook + SLO-thresholds).

12) Anti-pattern

«Rompere una prua senza ringhiera»: nessun criterio stop, nessun rischio on-call per un vero incidente.
Azione monouso anziché processo.
Caos senza steady-state: non è chiaro cosa considerare successo/fallimento.
Ritai eccessivi per l'iniezione di ritardi.
Ignorare il Business SLI: successo tecnico in caso di fallimento di pagamenti/ordini.
Nessuna analisi post-analisi e proprietari di miglioramenti.

13) Assegno foglio di implementazione (0-45 giorni)

0-10 giorni

Definisci lo steady-state SLI (personalizzato + business).
Seleziona utensile (Chaos Mesh/Litmus/Toxiproxy/FIS).
Descrivi la ringhiera: blast radius, criteri stop, finestre, ruoli.

11-25 giorni

Avvia i primi esperimenti: pod-kill, 100-200 mc delay per upstream critico, drop 1% pacchetti.
Configura gli alert burn-rate, collega kill-switch ai criteri stop.
Trascorrere il primo game-day, raccogliere retrò e fissaggi.

26-45 giorni

Aggiungi script di livello AZ/dipendenze (PSP esterno, database-lag).
Automatizzare il caos nightly sullo staging; cucinare scenari «stagionali» (picchi).
Catalogo di esperimenti e report regolari per la guida/SRE.

14) Metriche di maturità

Il ≥80% delle rotte critiche ha gli esperimenti descritti e le metriche steady-state.
Auto kill-switch funziona quando si superano le soglie p99/errore-rate.
Trimestrale - game-day di livello AZ/regione; ≥1 volte/mi è lo scenario target delle dipendenze.
MTTR si riduce dopo un ciclo di miglioramento, la correlazione «rilascio» diminuisce.
La percentuale di cadute «inaspettate» in caso di vere e proprie falle è destinata a zero.
I dashboard mostrano «resilienza» come KPI (burn-rate, tempi di ripristino, percentuale di azioni DR di successo).

15) Esempi di guardrail e trigger stop

Stop a: 'http _ req _ failed> 1%' 3 minuti, 'p99> 1000 ms' 3 finestre, 'deposit _ success <99. 5%`.
Riduzione dei blast radius: reimpostazione automatica del manifesto, restituzione dei pesi GSLB, disattivazione delle iniezioni fault.
Il comando stop è un unico pulsante/script con la logica dei motivi.

16) Cultura e processi

Il caos fa parte del ritmo SRE, non «estrim».
Report trasparenti, riconoscimento delle vulnerabilità, azioni correttive.
Formazione on-call, simulazione delle comunicazioni con clienti/partner.
Collegamento con SLA/SLO e budget: il caos dovrebbe aumentare, non compromettere l'affidabilità.

17) Conclusione

Chaos Engineering trasforma la speranza dei nove in una resilienza dimostrabile. Formulare steady-state, mettere una ringhiera, rompere una piccola e controllata, osservare SLO e Business SLI, registrare e automatizzare i miglioramenti. I veri guasti diventeranno eventi gestibili: RTO prevedibile, error-budget protetto e la volontà del team di agire senza panico.