Chaos Engineering: sistemlərin sabitliyi

Chaos Engineering: sistemlərin sabitliyi

1) Niyə xaos mühəndisliyi

• sistemin davranışı haqqında fərziyyələri yoxlamaq və SLO-nu təsdiqləmək;
• gizli SPOF, səhv zaman/retras, kaskad effektləri aşkar etmək;
• komandaları məşq etmək: game-days, runbook 'ların hazırlanması, kommunikasiyalar;
• «yaxşı ümid» deyil, «default sabitlik» mədəniyyətini formalaşdırmaq.

Əhəmiyyətli: Chaos Engineering «hər şeyi qırmaq» ≠. Bu elmi metoddur: steady-state → hipotez → eksperiment → nəticələr → təkmilləşdirilməsi.

2) Eksperimentin əsas dövrü

1. Steady-state (baza xətti): Hansı SLI stabil? (məsələn, uğur ≤ 500 ms 99. 95%).
2. Fərziyyə: bir AZ p95 itirdikdə <10% artacaq və mövcudluq 99 ≥. 9%.
3. Sınaq: məhdud blast radius və stop kriteriyaları ilə planlaşdırılmış folt.
4. Müşahidə: metriklər/treys/log, burn-rate SLO, biznes SLI (məsələn, uğurlu depozitlər).
5. Təkmilləşdirmələr: tapıntıları düzəldirik, vaxtları/limitləri/marşrutu dəyişdiririk, runbook yeniləyirik.
6. Avtomatlaşdırma/reqress: cədvəldə təkrarlayın, CI/CD və game-days təqvimlərinə əlavə edin.

3) Təhlükəsizlik məhəccəri (safety first)

Blast radius: dar başlayın - bir pod/instance/marşrut/namespace.
Guardrails: SLO burn-rate (sürətli/yavaş), retraj limitləri, QPS məhdudiyyəti, hadisə büdcəsi.
Stop-meyarlar: «əgər error-rate> X% və ya p99> Y ms N dəqiqə - dərhal stop və rollback».
Pəncərələr: on-call iş saatları, xəbərdar steykholderlər, dondurulmuş buraxılışlar.
Rabitə: IC/Tech lead/Comms, aydın kanal (War-room), mesaj şablonu.

4) Uğursuzluq sinifləri və fərziyyə ideyaları

Şəbəkə: gecikmə/jitter/itki, liman qismən darmadağın, xidmətlər/PSP arasında «flop» əlaqə.
Kompüter/qovşaqlar: proseslərin öldürülməsi, CPU-nun həddindən artıq qızması, fayl deskriptorlarının tükənməsi, dar qoşulma hovuzları.
Depolama və DB: artım latency disklər, lag replikalar, stop bir cüt/lider, split-brain.
Asılılıqlar: xarici API deqradasiyası, provayder limitləri, 5xx/429 sıçrayışlar.
Dəyişikliyin idarə edilməsi: uğursuz buraxılış, pis fiqa bayrağı, partial rollout.
Perimetri: CDN deqradasiya, DNS/Anycast drift, WAF/bot qorunması uğursuz.
Region/AZ: tam itki və ya «qismən» hadisə (bir az daha pis və gözlənilməz).

5) Alətlər və texnikalar

Kubernetes: Chaos Mesh, Litmus, PowerfulSeal, kube-monkey.
Buludlar: AWS Fault Injection Simulator (FIS), Buludlarda Fault Domains.
Şəbəkə/proxy: Toxiproxy (TCP-zəhər), tc/netem, iptables, Envoy fault (delay/abort), Istio fault injection.
Proseslər/qovşaqlar: 'stress-ng', cgroups/CPU-throttle, disk fill.
Trafik marşrutu: GSLB/DNS weights, canary/blue-green feylover yoxlamalar üçün keçid.

6) Ssenari nümunələri (Kubernetes)

6. Marşrutda 1 Delay/abort (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 }

Fərziyyə: müştəri vaxtı/retraut və CB p95 <300 ms və error-rate <0 saxlayacaq. 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"

Hipotez: Balanslaşdırıcı və HPA p99> 20% böyümədən bir nümunənin itkisini kompensasiya edir.

6. 3 Şəbəkə xaosu (DB-yə gecikmə)

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"

Hipotez: hovuzlar/taymautlar/cache təsiri azaldacaq; p95 ödənişlər SLO ≤ qalacaq.

6. 4 Disk doldurma

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"

Fərziyyə: loques/kvota/alert rotasiyası marşrutların deqradasiyasına qədər işləyəcək.

7) Xaricdə təcrübələr K8s

7. 1 Toxiproxy (yerli/inteqrasiya)

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 Envoy HTTP fault (perimetri/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 (fikir nümunəsi)

Auto Scaling Group-da N% EC2 «öldürmək» eksperimenti, süni olaraq EBS-latency qaldırmaq, bir AZ-da NAT-GW-ni söndürmək.
CloudWatch SLO metrikləri ilə daxili stop meyarları.

8) Xaos zamanı müşahidə metrikası

SLO/SLI: fraction of good requests, p95/p99, burn-rate.
Kritik marşrutlar (Rate, Errors, Duration) üzrə RED modeli.
Hovuzlar: p95 birləşməsi, utilization gözləmək.
BD: lag replika, locks, drift p95 sorğular.
Şəbəkə: retransmits, RTT, dscp/ecn davranış.
Biznes SLI: əməliyyatların müvəffəqiyyəti (depozitlər/çekaut),% geri qaytarmalar/səhvlər.
Tracking: seçici treys (exemplars), release-annotasiyaların korrelyasiyası.

9) SLO/Error-budget ilə inteqrasiya

Səhvlərin büdcəsi çərçivəsində təcrübələr planlaşdırın: xaos rüblük hədəfləri «pozmamalıdır».
Burn-rate alert kimi avtomatik kill-switch.
Hesabat: «neçə büdcə yandırıldı», «steady-state hansı deviasiyalar».

10) Game-days (təlimlər)

Ssenari: qısa əfsanə (məsələn, «region-East itirilmiş»), inyeksiya addımları, SLO məqsədləri, rolları, vaxt.
Qiymətləndirmə: RTO/RPO faktiki, rabitə keyfiyyəti, düzgün runbook.
Retro: sahibləri və şərtləri ilə təkmilləşdirmələrin siyahısı, sənədlərin/daşbordların yenilənməsi.

11) Avtomatlaşdırma və CI/CD

Smoke-chaos: Hər buraxılışda qısa staging testləri (məsələn, bir marşrutda 1 pod-kill + 200 ms delay).
Gecə/həftəlik: ağır ssenarilər (5-15 dəq) hesabat ilə.
Promo geytlar: əgər p95/səhvlər> canary üçün eşik - avtomatik geri.
Təcrübə kataloqu ilə anbarlar (YAML + runbook + SLO-thresholds).

12) Anti-nümunələr

«Məhəccərsiz sındırmaq»: heç bir stop-meyar, heç bir on-call → real hadisə riski.
Proses əvəzinə birdəfəlik aksiya.
Steady-state olmadan xaos: uğur/uğursuzluq hesab etmək üçün nə aydın deyil.
Gecikmələrin inyeksiyasında həddindən artıq retralar → öz-DDoS.
Biznes-SLI-yə məhəl qoymamaq: ödənişlər/sifarişlər uğursuz olduqda «texniki» uğurlar.
Post-analiz və təkmilləşdirmə sahiblərinin olmaması.

13) Giriş çek siyahısı (0-45 gün)

0-10 gün

steady-state SLI (xüsusi + biznes) müəyyən edin.
Bir alət seçin (Chaos Mesh/Litmus/Toxiproxy/FIS).
Məhəccərləri təsvir edin: blast radius, stop-meyarlar, pəncərələr, rollar.

11-25 gün

İlk təcrübələri başlatın: pod-kill, kritik axın 100-200 ms delay, drop 1% paket.
Burn-rate riskləri qurmaq, kill-switch-i stop-meyarlarla əlaqələndirmək.
İlk game-day keçirmək, retro və fiks toplamaq.

26-45 gün

AZ/asılılıq ssenariləri əlavə edin (xarici PSP, BD-lag).
staging nightly-xaos avtomatlaşdırmaq; «mövsümi» ssenarilər (zirvələr) hazırlamaq.
Təlimat/SRE üçün təcrübə kataloqu və müntəzəm hesabatlar.

14) Yetkinlik metrikası

Kritik marşrutların ≥ 80% -i təsvir edilmiş təcrübələrə və sabit state metriklərə malikdir.
Avto kill-switch p99/error-rate həddini aşdıqda işə düşür.
Rüblük - AZ/region səviyyəsində game-day; ≥ 1 dəfə/ay - hədəf asılılıq ssenarisi.
MTTR təkmilləşdirmə dövrü sonra azalır, korrelyasiya «release insident» azalır.
Real uğursuzluqlarda «gözlənilməz» enişlərin payı → sıfıra doğru gedir.
Daşbordlar KPI (burn-rate, bərpa vaxtı, uğurlu DR hərəkətlərinin payı) kimi «sabitlik» göstərir.

15) Guardrails nümunələri və stop tetikləyiciləri

Stop: 'http _ req _ failed> 1%' 3 dəqiqə, 'p99> 1000 ms' 3 pəncərələr, 'deposit _ success <99. 5%`.
blast radius azaldılması: avtomatik geri manifest, GSLB tərəzi qaytarılması, fault-injection off.
Stop əmri: səbəbləri qeyd edən vahid düymə/skript.

16) Mədəniyyət və proseslər

Xaos «ekstremal» deyil, SRE ritminin bir hissəsidir.
Şəffaf hesabatlar, zəifliklərin tanınması, düzəliş hərəkətləri.
On-call təlim, müştərilər/tərəfdaşlar ilə rabitə simulyasiyası.
SLA/SLO və büdcələrlə əlaqələndirin: xaos etibarlılığı pozmaq əvəzinə artırmalıdır.

17) Nəticə

Chaos Engineering «doqquz ümidini» sübut edilə bilən sabitliyə çevirir. Sabit state formalaşdırın, məhəccərləri qoyun, kiçik və nəzarətdə saxlayın, SLO və biznes SLI-ni müşahidə edin, təkmilləşdirmələri düzəldin və avtomatlaşdırın. Sonra real uğursuzluqlar idarə olunan hadisələrə çevriləcək: proqnozlaşdırıla bilən RTO, qorunan error-budget və komandanın panikasız hərəkət etməyə hazır olması.