Ingineria haosului: Reziliența sistemului

Ingineria haosului: Reziliența sistemului

1) De ce inginerie haos

• testează ipoteze despre comportamentul sistemului și validează SLO;
• detectarea SPOF-urilor ascunse, a timpilor/retraielor incorecte, a efectelor în cascadă;
• echipele de tren: zile de joc, cărți de lucru, comunicații;
• pentru a forma o cultură „sustenabilă în mod implicit”, mai degrabă decât „sperând la cel mai bun”.

Important: Chaos Engineering ≠ "rupe totul. "Aceasta este o metodă științifică: ipoteza la starea de echilibru experimentul concluziile îmbunătățirii.

2) Ciclul de experiment de bază

1. Starea de echilibru (valoarea iniţială): Ce LSI sunt stabile? (de exemplu, succesul ≤500 ms la 99. 95%).
2. Ipoteză: cu pierderea unui AZ, p95 va crește <10%, iar disponibilitatea ≥99. 9%.
3. Experiment: fault planificat cu rază de explozie limitată și criterii de oprire.
4. Observație: metrici/trasee/jurnale, burn-rate SLO, SLI de afaceri (de exemplu, depozite de succes).
5. Îmbunătățiri: înregistrăm descoperiri, modificăm termenele/limitele/rutarea, actualizăm runbook-ul.
6. Automatizare/regresie: repetați în program, adăugați la CI/CD și calendare de zile de joc.

3) Siguranța în primul rând

Raza de explozie: începe cu una îngustă - o capsulă/instanță/traseu/namespace.
Guardrails: alerte la SLO burn-rate (rapid/lent), limitele de retray, limita QPS, bugetul incident.
Criterii de oprire: „dacă rata de eroare> X% sau p99> Y ms N minute - oprire instantanee și rollback”.
Windows: ore de lucru de gardă, părți interesate notificate, versiuni înghețate.
Comunicare: IC/Tech plumb/Comms, canal clar (War-room), șablon mesaj.

4) Clasele de eșec și ideile de ipoteză

Rețea: întârziere/jitter/pierdere, cădere parțială a porturilor, comunicare „flopping” între servicii/PSP.
Computer/noduri: procese de ucidere, supraîncălzire CPU, epuizarea descriptorilor de fișiere, bazine de conexiune înguste.
Stocare și bază de date: creșterea discurilor de latență, replici de lag, oprirea unui ciob/lider, split-creier.
Dependențe: degradarea API-urilor externe, limitele furnizorului, exploziile 5xx/429.
Managementul schimbării: eliberare nereușită, pavilion caracteristică proastă, rollout parțial.
Perimetru: degradează CDN, derivă DNS/Anycast, defecțiune de protecție WAF/bot.
Regiune/AZ: pierdere completă sau incident „parțial” (puțin mai rău și imprevizibil).

5) Instrumente și tehnici

Kubernetes: Chaos Mesh, Litmus, PowerSeal, kube-maimuță.
Nori: AWS Fault Injection Simulator (FIS), Fault Domains lângă nori.
Rețea/proxy: Toxiproxy (otravă TCP), tc/netem, iptables, Vina trimisului (întârziere/avort), injectarea defectului Istio.
Procese/noduri: „stres-ng”, cgrups/CPU-accelerație, umplere disc.
Rutarea traficului: greutăți GSLB/DNS, comutare canar/albastru-verde pentru controale false.

6) scripturi de probă (Kubernetes)

6. 1 Întârziere/avort pe traseu (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 }

Ipoteză: timeout-urile/retraiele și CB-urile clienților vor deține p95 <300 ms și rata de eroare <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"

Ipoteză: balansorul și HPA compensează pierderea unei instanțe fără o creștere de p99> 20%.

6. 3 Haos de rețea (întârziere la baza de date)

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"

Ipoteză: piscine/timeout/cache va reduce impactul; plățile p95 vor rămâne ≤ SLO.

6. 4 Umplere pe disc

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"

Ipoteză: rotația jurnalelor/cotelor/alertelor va funcționa înainte de degradarea rutelor.

7) Experimente în afara K8s

7. 1 Toxiproxi (local/integrare)

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 Defecțiunea HTTP a trimisului (perimetru/plasă)

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

Experimentul „ucide” N% EC2 în Auto Scaling Group, crește artificial EBS-latență, dezactivați NAT-GW într-un singur AZ.
Criterii de oprire încorporate pentru metrica SLO CloudWatch.

8) Măsurarea observabilității în timpul haosului

SLO/SLI: fracțiune de cereri bune, p95/p99, burn-rate.
Modelul RED pentru rutele critice (rată, erori, durată).
Piscine: așteptare pentru conexiune p95, utilizare.
DB: replici lag, încuietori, drift p95 cereri.
Rețea: retransmiteri, RTT, comportament dscp/ecn.
Business SLI: succesul tranzacțiilor (depozite/cecuri),% returnări/erori.
Urmărire: trasee selective (exemplare), corelarea adnotărilor de eliberare.

9) Integrarea cu SLO/Error-buget

Planul de experimente în cadrul bugetului de greșeli: haos nu ar trebui să „perturbe” obiectivele trimestriale.
Alerte Burn-rate ca kill-switch automat.
Raportare: „cât de mult a ars bugetul”, „ce abateri la starea de echilibru”.

10) Joc-zile (exercițiu)

Scenariu: scurtă legendă (ex. „region-East lost”), pași de injecție, obiective SLO, roluri, timp.
Rating: RTO/RPO real, calitatea comunicațiilor, corectitudinea runbook.
Retro: lista îmbunătățirilor cu proprietarii și termenele limită, actualizarea documentației/tablourilor de bord.

11) Automatizare și CI/CD

Fum-haos: teste de stadiu scurt pe fiecare versiune (de ex. 1 pod-kill + 200ms întârziere pe traseu).
Nightly/Săptămânal: Scenarii mai grele (5-15 min) cu raport.
Porți promoționale: dacă p95/erori> prag pe canar - auto-rollback.
Depozite cu un catalog de experimente (YAML + runbook + praguri SLO).

12) Anti-modele

„Spargerea alimentelor fără balustrade”: fără criterii de oprire, fără gardă → riscul unui incident real.
Acţiune unică în loc de proces.
Haos fără stare de echilibru: Nu este clar ce contează ca succes/eșec.
Reîncărcări excesive → auto-DDoS la injectarea întârzierilor.
Ignorarea SLI de afaceri: succesul „Technarian” atunci când plățile/comenzile eșuează.
Lipsa proprietarilor post-analiză și îmbunătățire.

13) Lista de verificare a implementării (0-45 zile)

0-10 zile

Definiți SLI la starea de echilibru (utilizator + afacere).
Selectați un instrument (Chaos Mesh/Litmus/Toxiproxy/FIS).
Descrieți balustradele: raza de explozie, criteriile de oprire, ferestrele, rolurile.

11-25 zile

Rulați primele experimente: pod-kill, 100-200 ms întârziere per critic în amonte, picătură 1% din pachete.
Configurați alerte burn-rate, asociați kill-switch cu criteriile stop.
Petreceți prima zi de joc, colectați retro și remedieri.

26-45 zile

Adăugați scripturi de nivel AZ/dependență (PSP extern, DB-lag).
Automatizarea haosului nocturn pe montaj; pregătește scenarii „sezoniere” (vârfuri).
Catalog de experimente și rapoarte periodice pentru management/SRE.

14) Valorile maturității

≥80% din rutele critice au experimentele descrise și valorile stării de echilibru.
Kill-switch-ul automat este declanșat atunci când pragurile p99/errate sunt depășite.
Trimestrial - nivel de joc-zi AZ/regiune, ≥1 ori/lună - scenariu țintă de dependențe.
MTTR scade după un ciclu de îmbunătățiri, corelația „eliberare ↔ incident” scade.
Proporția de „neașteptate” scade în eșecuri reale → tinde spre zero.
Tablourile de bord arată „reziliență” ca KPI (burn-rate, timpul de recuperare, proporția de acțiuni DR de succes).

15) Exemple de parapete și declanșatoare de oprire

Stop la: 'http _ req _ failed> 1%' 3 minute, 'p99> 1000 ms' 3 ferestre,' deposit _ success <99. 5%`.
Reducerea razei de explozie: auto-rollback a manifestului, revenirea greutăților GSLB, dezactivarea injecțiilor cu defecte.
Opriți comanda: un singur buton/script cu logarea cauzelor.

16) Cultură și procese

Haosul face parte din ritmul SRE, nu „extrem”.
Raportare transparentă, recunoașterea vulnerabilității, acțiuni corective.
Training de gardă, simularea comunicării cu clienții/partenerii.
Conectarea cu SLA/SLO și bugete: Haosul ar trebui să sporească, nu să submineze, fiabilitatea.

17) Concluzie

Chaos Engineering transformă „speranța pe nouari” într-o sustenabilitate dovedită. Formulați starea de echilibru, plasați balustrade, rupeți mici și controlate, observați SLO și SLI de afaceri, înregistrați și automatizați îmbunătățirile. Atunci eșecurile reale vor deveni evenimente controlate: RTO previzibil, bugetul de eroare protejat și disponibilitatea echipei de a acționa fără panică.