Inginerie haos

1) Principii de bază

Starea de echilibru ca ipoteza inițială. Definiți în mod clar norma (de exemplu: p95 <200 ms, rata de eroare <0. 3%, flux critic de succes> 99. 5%).
Variabile izolate. Schimbați cât mai mult posibil un factor la un moment dat pentru a lega cauzal efectul și îmbunătățirea.
Grad. Începem cu amplitudini mici într-un mediu sigur → extindem acoperirea și intensitatea.
Guardrails. Condiții explicite de oprire a bugetului SLO/alert/error.
Repetabilitate. Experimentul trebuie să fie reproductibil deterministic (scripturi/manifeste/IaC).
Etică şi siguranţă. Nu există date cu caracter personal reale și tranzacții financiare în experimente riscante.

2) Ce este „starea de echilibru”

• p50/p95/p99 latenţele criteriilor finale cheie.
• Rata de succes și conversia traseului critic.
• Rata de eroare, timeout-uri, procentul de cereri „vărsat” (trunchiat pe saturație).
• Rata de auto-vindecare (MTTR), rezistența la retrageri (fără furtuni).
• Invarianții domeniului: lipsa „dezavantajelor în balanță”, odată executate plățile, coerența zilelor de raportare etc.

3) Catalog de injecție (ceea ce spargem)

Rețea: latență, jitter, pierdere/duplicate, limitare lățime de bandă, pauze TLS, DNS flapping.
Calcule: supraîncărcarea procesorului, presiunea memoriei/GC, epuizarea descriptorului, înclinarea ceasului.
Depozitare: p95 I/O, ENOSPC, eșec lider/replica, split-creier, persistent fsync.
Dependențe: 5xx/429, „succes lent”, degradarea API-urilor externe, limită de rată.
Date: duplicate/ratări de mesaje, out-of-order, înregistrări murdare, conflict versiune.
Operațiuni: eliberare/configurare nereușită, pavilion caracteristică cu un bug, certificat expirat, rotație cheie.
Oameni și procese: indisponibilitatea celor responsabili, întârzierea actualizării manuale, runbook incorect.

4) Design experiment (șablon)

1. Ipoteză: „La + 300 ms la serviciul valutar p99 al API principal <450 ms, se deschide un întrerupător, un răspuns vechi este dat ≤ 15 minute în urmă”.
2. Injecţie: profil eşec (tip/amplitudine/durată) şi contur ţintă.
3. Etichete metrice/jurnal: marcking 'chaos. experiment_id', 'phase = injectare' recuperare '.
4. Parapete: abandonați at 'error _ rate> 2%' sau p99> SLA × 2 pentru mai mult de 1 minut.
5. Rezultate/ieșire: listă de observații, bug-uri, îmbunătățiri, planul de lucru și re-rula.

5) Observabilitate: ceea ce este obligatoriu

Trasare: cerere cale prin dependențe; segmente cu degradare sunt marcate.
Valorile resurselor: CPU, heap/GC, FD, disk IOPS/lat, lățime de bandă de rețea, adâncime de coadă.
Valori de afaceri: conversia/succesul operațiunilor, cota tranzacțiilor compensate.
Jurnalele evenimentului: întrerupătoare de deschidere/închidere, retroactive și bugetul acestora, comutând liderul bazei de date.
Panoul de experimente: tabloul de bord live cu praguri de parapete și un „buton roșu” de avort.

6) Guardrails și securitate

Tehnic: limitele superioare ale ratei de eroare/latenței, scăderea ponderii operațiunilor de succes, creșterea DLQ.
Organizațional: fereastră de timp, de gardă implicată, principiul „o zonă - un experiment”.
Date/conformitate: numai kituri sintetice sau impersonale; interzicerea testelor care conduc la încălcarea reglementărilor.
Rollback: procedura de rollback/dezactivare a traficului de pavilion/de scurgere moale.

7) Modele de reziliență care ar trebui să apară

Bugetele de timeout și retragerile jitter (fără furtună).
Întrerupător de circuit cu recuperare jumătate deschisă și exponențială.
Pereți etanși: izolarea grupurilor critice (plăți vs analist).
Backpressure și rate-limit: limitare previzibilă a priorității scăzute.
Cache cu coalescing, protecție împotriva „furtunilor de încălzire”.
Idempotența efectelor secundare și saga cu acțiuni compensatorii.
Cvorumuri, feilover și anti-entropie pentru recuperarea datelor.

8) Scenarii de probă (schițe)

8. 1 Dependență lentă (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 Pierderea liderului DB

Injecție: Lider oprire/realegere forțată.
Așteptare: inhibare temporară a scrisului, citire cvorum, siguranță WAL/Outbox, replicare auto-restaurare, fără scriere dublă.

8. 3 ENOSPC pe Log Disk

Injecție: umpleți discul la 95-100%.
Așteptare: rotirea de urgență a jurnalelor, siguranța jurnalelor critice, dezactivarea caracteristicilor non-critice, alertă și remediere automată.

8. 4 Trafic de explozie + umbrire

Injecţie: × 3 SPR timp de 5 minute la un punct final fierbinte.
În așteptare: cădere prioritate scăzută, stabil p95 „core”, nici o cascadă retray.

9) Automatizare în CI/CD

Haos-fum în scenă pentru fiecare eliberare (injecții scurte la amplitudini sigure).
Nightly rulează în conformitate cu catalogul de experimente (servicii de matrice × tipuri de eșecuri).
Porți: Eliberarea este blocată dacă „persistența este sub prag” (de exemplu, procentul de căderi de succes este <95%).
Artefacte: raport, trasee, CPU/heap flameshraphs, instantanee de metrici și configurații.

10) Zilele jocului (Zilele jocului)

• Roluri: lider de experiment, observator metric, operator rollback, reprezentant de afaceri.
• Scenarii: degradarea memoriei cache, eșecul parțial AZ/region-feilover, „eliberarea proastă”, indisponibilitatea unui furnizor extern.
• Rezultate: s-au găsit lacune în runbook, îmbunătățiri ale alertelor, ajustări ale SLO-urilor și bugete retrase.

11) Haos pentru date, evenimente și ML

Fluxuri de date: teste pentru duplicate, lacune, out-of-order, întârzieri; validarea consumatorilor idempotenți și a strategiilor DLQ.
Depozite: degradarea indicelui, partiția la cald, conflictul de blocare, replicarea sub lag.
ML: întârziere caracteristică, revenire la modelul de bază, degradarea calității datelor de intrare (derivă) - sistemul ar trebui să „ușor contondent” și să nu cadă.

12) Anti-modele

Haos fără observabilitate: sunteți „orbi”, concluziile sunt speculative.
Injecții imediat în prod fără șine de etapă și de pază.
„Un mare experiment” pe toate dintr-o dată - nu este clar ce anume a funcționat.
Hazard haos acțiuni fără ipoteze și retestează după remedieri.
Concentrându-se doar pe infrastructură - invarianții de afaceri sunt uitați.
Ignorarea oamenilor/proceselor: alerte, de gardă, runbook - parte a sistemului.

13) Maturitatea practicii (model)

1. Ad-hoc: injecții unice la nivel local.
2. Haos de scenă: catalog de scenarii, rulează repetate, tablouri de bord.
3. Eliberați haos: haos de fum în fiecare eliberare, porți, rapoarte.
4. Haos alimentar cu restricții: trafic redus, parapete stricte, rollback gata.
5. Stabilitate continuă: auto-experimente, SLO-management, îmbunătățiri ca flux de lucru.

14) Integrarea cu practicile arhitecturale

Testarea rezistenței: Experimentele de haos completează injecțiile cu defecte și scenariile de degradare.
Testarea încărcăturii: experimente combinate de sarcină + eșec dezvăluie cascade și o furtună de retrasări.
Politica ca cod/RBAC/ABAC: guardrails, pașii și limitele rollback sunt concepute ca politici.
Managementul consimțământului/confidențialității: nu permiteți experimente care încalcă modul de prelucrare a datelor.
Geo-arhitectura: controalele haosului asupra eșecului regiunilor și obligarea datelor la jurisdicții.

15) Mini rețete (pseudocod)

Întrerupător + degradare

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()

Limitator + umbrire

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

Efect secundar idempotent

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

16) Lista de verificare a arhitectului

1. Definit starea de echilibru și parapete?
2. Există un director script (rețea/CPU/stocare/dependențe/date/operațiuni)?
3. Observabilitatea acoperă resursele, cozile de latență, invarianții de afaceri?
4. Temporizări/retrageri/întrerupătoare/limitatoare/pereți etanși activați și parametrizabili?
5. Runbook pregătit și „butonul roșu”?
6. Există haos-fum în scenă și experimente nocturne?
7. Există ferestre și roluri „sigure” pentru zilele de joc?
8. Experimentele sunt reproductibile (IaC/scripturi), rezultatele sunt versionate?
9. Îmbunătățirile sunt fixate de sarcini, retestarea se face?
10. Conducte de date și ML acoperite, nu numai HTTP?

Concluzie

Chaos Engineering transformă „incidentele neprevăzute” în scenarii previzibile. Ipoteza rezistenței, injecțiile controlate, parapetele rigide, observabilitatea bogată și disciplina retestare sunt instrumente care reduc riscul de eliberare și sporesc încrederea în platformă. Ca urmare, echipa înțelege limitele sistemului, este capabilă să se degradeze elegant și să returneze rapid serviciul utilizatorului, chiar și în condiții de defecțiuni.