Chaos Engineering

1) Əsas prinsiplər

Steady State ilkin fərziyyə kimi. Normanı aydın təyin edin (məsələn: p95 <200 ms, error rate <0. 3%, kritik flow müvəffəqiyyəti> 99. 5%).
Təcrid olunmuş dəyişənlər. Təsir və yaxşılaşma səbəbiylə əlaqələndirmək üçün bir anda mümkün qədər bir amili dəyişdirin.
Dərəcə. Təhlükəsiz mühitdə kiçik amplitudalarla başlayırıq → əhatə dairəsini və intensivliyini genişləndiririk.
Guardrails. SLO/alert/səhv büdcəsi üçün açıq stop şərtləri.
Təkrarlanabilirlik. Təcrübə determinasiya olunmalıdır (skriptlər/manifestlər/IaC).
Etika və təhlükəsizlik. Riskli təcrübələrdə real şəxsi məlumatlar və maliyyə əməliyyatları yoxdur.

2) «Sabit vəziyyət» nədir

• Gizli p50/p95/p99 əsas end nöqtələri.
• Uğurlu əməliyyatların payı və kritik yolların çevrilməsi.
• Error rate, taymaut, pay «shed» sorğular (doyma zamanı kəsilmiş).
• Özünü bərpa sürəti (MTTR), retraya qarşı müqavimət (fırtınasız).
• Domen invariantları: «balansda mənfi cəhətlərin» olmaması, birdəfəlik ödənişlər, hesabat gününün konsistentliyi və s.

3) Enjeksiyon kataloqu («sındırmaq»)

Şəbəkə: gecikmə, jitter, itki/təkrarlama, bant genişliyi məhdudiyyəti, TLS qırılmaları, DNS flapping.
Hesablamalar: CPU həddindən artıq yükləmə, yaddaş təzyiqi/GC, deskriptorların tükənməsi, clock skew.
Depolama: yüksək p95 I/O, ENOSPC, lider uğursuzluğu/replikalar, split-brain, fsync.
Asılılıq: 5xx/429, «yavaş uğur», xarici API deqradasiyası, rate-limit.
Data: dubllar/mesajlar, out-of-order, «çirkli» qeydlər, versiyalar münaqişəsi.
Əməliyyatlar: uğursuz Release/ , bug ilə Ficha bayrağı, müddəti bitmiş sertifikat, açar rotasiyası.
İnsanlar və proseslər: cavabdehlərin əlçatmazlığı, əl yeniliyinin gecikməsi, səhv runbook.

4) Təcrübə dizaynı (şablon)

1. Fərziyyə: «Əsas API <450 ms-in p99 valyuta xidmətinə + 300 ms olduqda, breyker açılır, 15 dəqiqə əvvəl stale-cavab verilir».
2. Enjeksiyon: uğursuzluq profili (tip/genlik/uzunluq) və hədəf konturu.
3. Metriklər/log tags: 'chaos. experiment_id`, `phase=inject|recover`.
4. Guardrails: 'error _ rate> 2%' və ya p99> SLA × 1 dəqiqədən çox 2.
5. Nəticələr/nəticə: müşahidələr, uğursuzluqlar, təkmilləşdirmələr, iş planı və təkrar qaçış siyahısı.

5) Müşahidə: nə lazımdır

Trace: asılılıqlar vasitəsilə sorğu yolu; deqradasiya seqmentləri qeyd olunur.
Resursların metrikası: CPU, heap/GC, FD, disk IOPS/lat, şəbəkə bandwidth, növbə dərinliyi.
Biznes metrikası: konvertasiya/əməliyyatların müvəffəqiyyəti, kompensasiya edilmiş əməliyyatların payı.
Hadisə qeydləri: breykerlərin açılması/bağlanması, retralar və onların büdcəsi, DB liderinin dəyişdirilməsi.
Təcrübə paneli: guardrails astanaları və abortun «qırmızı düyməsi» ilə canlı dashboard.

6) Guardrails və təhlükəsizlik

Texniki: üst sərhədləri error rate/latency, uğurlu əməliyyatların payının azalması, DLQ artımı.
Təşkilati: on-call-da iştirak edən vaxt pəncərəsi, 'bir zona - bir təcrübə "prinsipi.
Data/complayens: yalnız sintetik və ya anonim dəstlər; tənzimləyicilərin pozulmasına səbəb olan testlərin qadağan edilməsi.
Geri dönüş: Hazır rulback/disable bayraq/yumşaq drain trafik proseduru.

7) Özünü göstərməli olan sabitlik nümunələri

Taymaut büdcələri və jitter retraları (fırtınasız).
Yarım örtüklü (half-open) və eksponensial bərpa ilə Circuit Breaker.
Bulkheads: kritik hovuz izolyasiyası (analitik vs ödənişlər).
Backpressure və rate-limit: aşağı prioritetin proqnozlaşdırıla bilən kəsilməsi.
coalescing ilə cache, «istilik fırtına» qarşı müdafiə.
Yan təsirlərin idempotentliyi və kompensasiya hərəkətləri ilə dastan.
Məlumatların bərpası üçün kvorumlar, feylover və anti-entropiya.

8) Ssenari nümunələri (eskizlər)

8. 1 Yavaş asılılıq (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 DB liderinin itkisi

Enjeksiyon: lider/məcburi təkrar seçki dayandırılması.
Gözləmə: qeydlərin müvəqqəti qadağan edilməsi, kvorum oxunması, WAL/Outbox təhlükəsizliyi, replikasiyanın avtomatik bərpası, ikiqat qeydlərin olmaması.

8. 3 ENOSPC log disk

Enjeksiyon: 95-100% -ə qədər diskin doldurulması.
Gözləmə: qeydlərin təcili rotasiyası, kritik jurnalların təhlükəsizliyi, kritik olmayan fiqurların söndürülməsi, alert və avtomatik remediasiya.

8. 4 Burst trafiki + shading

Enjeksiyon: isti end nöqtəsi ilə 5 dəqiqə ərzində 3 RPS ×.
Gözləmə: aşağı prioritet atılması, sabit p95 «nüvəsi», retraj kaskadının olmaması.

9) CI/CD-də avtomatlaşdırma

Chaos-smoke hər buraxılış üçün steyj (qısa enjeksiyon təhlükəsiz amplitudalar).
Eksperimentlər kataloqu üzrə gecə qaçışları (matris xidmətləri × nasazlıq növləri).
Geytalar: «müqavimət həddindən aşağı olduqda» buraxılış bloklanır (məsələn, uğurlu fallback payı <95%).
Artefaktlar: hesabat, treys, CPU/heap fleyqrafları, metrik və konfiqurasiyaların snapshotları.

10) Oyun günləri (Game Days)

• Rollar: eksperimentin aparıcısı, metrik müşahidəçi, geri dönüş operatoru, biznes nümayəndəsi.
• Ssenarilər: cache deqradasiyası, AZ/region-feylover qismən uğursuzluğu, «pis buraxılış», xarici provayderin əlçatmazlığı.
• Nəticələr: runbook-da tapılan boşluqlar, alertlərin yaxşılaşdırılması, SLO və retraj büdcələrinin tənzimlənməsi.

11) Məlumatlar, hadisələr və ML üçün xaos

Verilənlər axını: təkrarlanan testlər, boşluqlar, out-of-order, gecikmələr; idempotent konsumerlərin və DLQ strategiyalarının yoxlanılması.
Saxlama: indekslərin deqradasiyası, hot-partition, kilidləmə münaqişəsi, lag altında replikasiya.
ML: fasilənin gecikməsi, bazeline modelinə geri çəkilmə, giriş məlumatlarının keyfiyyətinin pisləşməsi (drift) - sistem düşmək əvəzinə «yumşaq axmaq» olmalıdır.

12) Anti-nümunələr

Müşahidə olunmayan xaos: siz «korsunuz», nəticələr spekulyativdir.
Enjeksiyonlar dərhal steyj və qvard rayları olmadan bir proda.
Hər şey üçün «bir böyük təcrübə» - tam olaraq nə işlədiyi bəlli deyil.
Hipotezlər və fikslərdən sonra retest olmadan sistemsiz xaos hərəkətləri.
Yalnız infrastruktura diqqət - biznes invariantları unudulur.
İnsanlar/proseslərə məhəl qoymamaq: həyəcan, on-call, runbook sistemin bir hissəsidir.

13) Yetkinlik təcrübəsi (model)

1. Ad-hoc: yerli bir dəfə inyeksiya.
2. Steyj-xaos: ssenari kataloqu, təkrarlanan qaçışlar, daşbordlar.
3. Release-xaos: hər buraxılışda smoke-xaos, geytlər, hesabatlar.
4. Məhdudiyyətlərlə Prod-xaos: kiçik trafik, ciddi qoruyucular, hazır geri dönüş.
5. Davamlı sabitlik: avtomatik təcrübələr, SLO idarə, iş axını kimi təkmilləşdirilməsi.

14) Memarlıq təcrübələri ilə inteqrasiya

Davamlı test: xaos təcrübələri fault inyeksiyaları və deqradasiya ssenarilərini tamamlayır.
Yükləmə testi: «yük + uğursuzluq» kombinə edilmiş təcrübələr kaskad və fırtına retraylarını aşkar edir.
Policy as Code/RBAC/ABAC: guardrails, geri qaytarma addımları və limitləri siyasət kimi tərtib edin.
Razılıq/məxfiliyin idarə edilməsi: məlumatların emal rejimini pozan təcrübələrə yol verməyin.
Geo-memarlıq: Regionların feyloverlərinin xaos yoxlanılması və məlumatların yurisdiksiyalara bağlanması.

15) Mini reseptlər (psevdokod)

Breyker + deqradasiya

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

Limiter + shading

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

İdempotent yan təsiri

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

16) Memarın yoxlama siyahısı

1. Steady State və guardrails müəyyən?
2. Script kataloqu varmı (şəbəkə/CPU/saxlama/asılılıq/məlumat/əməliyyatlar)?
3. Müşahidə resursları, gizli quyruqları, biznes invariantlarını əhatə edir?
4. Taymaut/retrains/breakers/limiters/bulkheads daxil və parametrləşdirilə bilər?
5. Runbook və «qırmızı düymə» hazırlanmış?
6. Steyj və nightly təcrübələrdə xaos-smoke var?
7. Oyun günlərində «təhlükəsiz» pəncərələr və rollar var?
8. Təcrübələr təkrar olunur (IaC/skriptlər), nəticələr versiya olunur?
9. Təkmilləşdirmələr vəzifələr tərəfindən düzəldilir, retest edilir?
10. Verilənlər və ML konveyerləri, yalnız HTTP deyil?

Nəticə

Chaos Engineering «gözlənilməz hadisələri» proqnozlaşdırıla bilən ssenarilərə çevirir. Dayanıqlılıq hipotezi, nəzarət edilən inyeksiyalar, sərt qoruyucular, zəngin müşahidə və retest intizamı buraxılış riskini azaldan və platformaya inamı artıran vasitələrdir. Nəticədə komanda sistemin sərhədlərini başa düşür, zərif şəkildə pozulmağı və hətta uğursuzluq şəraitində də istifadəçiyə xidməti tez qaytarmağı bacarır.