Chaos engineering: cum verifici că redundanța chiar funcționează

Chaos engineering este practica de a injecta defecte deliberat într-un sistem, cu scopul de a verifica dacă comportamentul lui sub condiții turbulente corespunde cu ce crezi că se va întâmpla. Nu este o tehnică de sabotaj, ci un experiment controlat: formulezi o ipoteză, provoci o perturbare limitată și observi dacă sistemul o absoarbe sau se prăbușește.

Confuzia obișnuită este că redundanța, circuit breaker-ele și replicarea bazelor de date garantează rezistența prin simpla lor existență. Nu garantează. Garantează numai dacă ai verificat că funcționează în condiții reale, cu dependențele reale ale sistemului. Chaos engineering este verificarea aceea.

Ce este chaos engineering și de unde vine termenul?

Termenul s-a cristalizat la Netflix între 2010 și 2011, când inginerii au construit Chaos Monkey, un instrument care termina instanțe EC2 aleatoriu în producție. Raționamentul era direct: Netflix știa că instanțele EC2 vor pica, inevitabil. Dacă le termini tu aleatoriu, echipele sunt forțate să construiască servicii care rezistă la pierderi de noduri, nu servicii care presupun că nodurile sunt mereu disponibile.

Până în 2016, Netflix a publicat Principles of Chaos Engineering, un document care formalizează ce înseamnă un experiment valid de chaos. Definiția formală: chaos engineering este disciplina experimentării pe un sistem cu scopul de a construi încredere în capacitatea lui de a rezista la condiții turbulente în producție.

Cuvântul cheie din definiție este „experiment". Chaos engineering nu este haos fără metodă. Are structură:

• Ipoteza steady state. Definești cum arată sistemul când funcționează normal: un metric măsurabil (rata de erori, latența p95, numărul de comenzi procesate pe minut). Orice abatere semnificativă de la steady state este un semnal că experimentul a descoperit ceva.
• Variabila reală. Experimentul perturbează ceva real: un nod care cade, o rețea care devine lentă, un serviciu terț care returnează erori. Nu configurații artificiale care n-au corespondent în producție.
• Blast radius controlat. Începi mic: un singur nod, un singur serviciu auxiliar, un procent mic din trafic. Crești magnitudinea pe măsură ce câștigi încredere că consecințele sunt gestionabile.
• Observabilitate înainte de experiment. Dacă nu poți observa impactul, experimentul nu produce nimic. Ai nevoie de metrics, logs și alertare care funcționează înaintea primei injecții de defect.

Care sunt principiile de bază ale chaos engineering?

Documentul original de la Netflix listează cinci principii pe care un experiment valid le respectă:

• Ipoteză despre steady state. Alege un metric de output care reflectă comportamentul normal: comenzi procesate pe minut, rata de răspunsuri 2xx. Ipoteza: dacă perturbăm X, steady state-ul rămâne în limite normale.
• Variază evenimente reale. Perturbările trebuie să se poată întâmpla în producție: server care pică, disc plin, rețea cu 500ms latență, dependință externă care returnează 503.
• Rulează în producție. Staging-ul nu are datele și traficul real. Producția este singurul mediu în care observi comportamentul autentic. Cu blast radius controlat, riscul este gestionabil.
• Automatizează continuu. Un experiment manual o dată pe an nu construiește încredere. Chaos-ul automatizat rulează la fiecare deploy și detectează regresiile înainte să ajungă la utilizatori.
• Minimizează blast radius-ul. Pornești mic și crești treptat. Scopul nu este să produci un incident, ci să verifici un comportament specific cu impact minim.

Principiile nu sunt toate-sau-nimic. O echipă care aplică primele trei fără automatizare face chaos engineering mai serios decât una care are o platformă automată dar nu formulează ipoteze clare.

Ce tooling există pentru chaos engineering?

Instrumentele disponibile acoperă un spectru larg, de la comenzi de sistem simple până la platforme specializate:

• Kill -9 și iptables. Cel mai simplu punct de start. Oprești un proces cu kill -9 și observi dacă sistemul se recuperează singur. Adaugi latență de rețea cu tc netem delay 200ms. Fără dependențe externe, funcționează pe orice sistem Linux.
• Pumba. Instrument open-source pentru injectarea de defecte în containere Docker: delay, packet loss, process kill. Potrivit pentru echipele care rulează Docker Compose sau Docker Swarm fără Kubernetes.
• Chaos Mesh. Platformă pentru Kubernetes care acoperă network chaos, pod failure, stress testing pe CPU și memorie, și injecție de erori în DNS. Interfață grafică, experimente declarative în YAML, integrare cu CI/CD.
• Gremlin. SaaS comercial cu acoperire largă (infrastructură, rețea, aplicație, date). Produce rapoarte structurate și are safety guards care opresc automat experimentul dacă metrics-urile depășesc un prag. Mai potrivit pentru echipele care vor confort și nu vor să întrețină propria platformă de chaos.
• AWS Fault Injection Simulator / Azure Chaos Studio. Opțiuni native în cloud, integrate direct cu serviciile provider-ului. Dacă rulezi majoritar pe AWS sau Azure, acoperă scenariile comune fără infrastructură suplimentară.

Alegerea tooling-ului depinde de infrastructură, nu de preferință de brand. Pe un VPS cu Docker Compose, Chaos Mesh nu are sens; kill -9 și Pumba sunt suficiente. Pe Kubernetes la scară, Chaos Mesh sau Gremlin adaugă valoare prin structura experimentelor și jurnalizarea rezultatelor.

Game days vs chaos automatizat: ce alegi când?

Echipele aleg de obicei între două moduri de a practica chaos engineering, fiecare cu compromisuri clare:

Game day-urile sunt sesiuni structurate, manuale: echipa formulează un scenariu, îl execută împreună și analizează comportamentul în timp real. Produc înțelegere colectivă, toți văd aceleași date. Dezavantajul: sunt discontinue. Un game day trimestrial descoperă ce știai că nu știi, nu regresiile introduse între sesiuni.

Chaos-ul automatizat rulează experimente mici la fiecare deploy, fără intervenție umană. Descoperă regresii repede și construiește o bibliotecă de experimente care crește cu sistemul. Dezavantajul: cere timp de configurare, întreținere și integrare cu observabilitatea. O platformă de chaos pe care echipa n-o întrețin activ produce alerte ignorate, exact ca un dashboard fără owner.

Alegerea nu este exclusivă. Echipele mature folosesc ambele: chaos automatizat pentru regresii de bază, game days pentru scenarii complexe. Echipele mici câștigă mai mult dintr-un game day trimestrial bine structurat decât dintr-o platformă automată abandonată după prima lună. Un runbook scris după un game day valorează mai mult decât un tool de chaos neconfigurat.

Când e supradimensionat pentru echipa ta?

Chaos engineering are un cost real: configurare, mentenanță, risc de impact accidental. Înainte de a investi, are sens să verifici dacă baza e pusă la punct.

Dacă nu ai observabilitate funcțională, chaos engineering este prematur. Injectezi un defect, nu ai metrics corelabile, nu ai alertare, deci experimentul nu produce nicio concluzie validă. Construiești mai întâi: metrics de SLA, logs structurate, o alertă acționabilă. Abia după poți formula o ipoteză de chaos și o poți verifica.

Dacă sistemul nu are redundanță (un singur nod, nicio replică, niciun circuit breaker), chaos engineering nu descoperă nimic nou. Știi deja că sistemul cade dacă nodul cade. Construiești mai întâi redundanța, o verifici după.

Pivotul real: un game day informal trimestrial bate zero chaos engineering, la fel cum un singur dashboard funcțional bate zero observabilitate. Nu ai nevoie de Chaos Mesh sau Gremlin pentru primul experiment. Ai nevoie de o ipoteză clară, un metric de steady state măsurabil și cineva care oprește dacă lucrurile merg prost.

La crawlerra, stack-ul de observabilitate acoperă șase produse cu Prometheus, Loki și Grafana¹, cu alertare sub un minut latență² și douăzeci de runbook-uri active³. Fără acea bază, orice experiment de chaos ar produce date fără context. Detalii despre construirea bazei: ghidul despre site reliability engineering.

1. Stack-ul de observabilitate crawlerra acoperă șase produse în producție: PromoAzi, RestoInsights, FarmaAzi, Crawlerra.com, Hub Travel Domus și o instanță medical-blog. [ops.products_count]
2. Mediana pe ultimele 90 de zile a duratei dintre evenimentul declanșator și primul ping pe canalul de alertare. [ops.alert_latency]
3. Numărul de runbook-uri active în repo-ul de operațiuni la momentul ultimei revizii. [ops.runbooks_count]