Chaos Engineering: tizimlarning barqarorligi

Chaos Engineering: tizimlarning barqarorligi

1) Nima uchun xaos-muhandislik

• tizimning xulq-atvori haqidagi farazlarni tekshirish va SLOni validatsiya qilish;
• yashirin SPOF, notoʻgʻri taymautlar/retrajlar, kaskad effektlarini aniqlash;
• buyruqlarni mashq qilish: game-days, runbook’lar, kommunikatsiyalarni mashq qilish;
• «eng yaxshisiga umid qilamiz» emas, balki «barqarorlik» madaniyatini shakllantirish.

Muhimi: Chaos Engineering ≠ «hamma narsani sindirish». Bu ilmiy usul: steady-state → gipoteza → eksperiment → xulosa → yaxshilash.

2) Eksperimentning bazaviy sikli

1. Steady-state (asosiy chiziq): qaysi SLI barqaror? (masalan, muvaffaqiyat ≤ 500 ms 99. 95%).
2. Gipoteza: bitta AZ p95 yo’qotilganda <10%, foydalanish imkoniyati esa ≥ 99. 9%.
3. Tajriba: blast radius va stop-mezonlari cheklangan rejalashtirilgan folt.
4. Kuzatish: metriklar/treyslar/loglar, burn-rate SLO, biznes-SLI (masalan, muvaffaqiyatli depozitlar).
5. Yaxshilanishlar: topilmalarni tuzatish, taymaut/limit/marshrutni o’zgartirish, runbook-ni yangilash.
6. Avtomatlashtirish/regress: jadvalda takrorlaymiz, CI/CD va game-days taqvimlariga qoʻshamiz.

3) Xavfsizlik panjaralari (safety first)

Blast radius: tor - bitta pod/instans/marshrut/namespace.
Guardrails: SLO burn-rate (tez/sekin) alertlari, retraj limitlari, QPS cheklovlari, hodisa byudjeti.
Stop-mezonlar: «agar error-rate> X% yoki p99> Y ms N daqiqa - bir zumda stop va rollback».
Oynalar: on-call ish soatlari, xabardor qilingan steykxolderlar, muzlatilgan relizlar.
Kommunikatsiya: IC/Tech lead/Comms, aniq kanal (War-room), xabarlar namunasi.

4) Rad etish klasslari va gipotezalar g’oyalari

Tarmoq: kechikish/jitter/yo’qotishlar, qisman portlar, xizmatlar/PSP o’rtasidagi aloqa.
Kompyut/uzellar: jarayonlarni o’ldirish, CPUni haddan tashqari qizdirish, fayl deskriptorlarini tugatish, tor ulanish pullari.
Omborlar va DB: disklarning latency o’sishi, lag replikalar, bitta shard/etakchini to’xtatish, split-brain.
Bog’liqlik: tashqi APIlarning tanazzulga uchrashi, provayderlar limitlari, 5xx/429 portlash.
Oʻzgarishlarni boshqarish: muvaffaqiyatsiz reliz, yomon ficha bayrogʻi, partial rollout.
Perimetri: CDN degradatsiya, DNS/Anycast drift, WAF/bot himoyasi muvaffaqiyatsiz tugadi.
Mintaqa/AZ: to’liq yo’qotish yoki «qisman» hodisa (biroz yomonroq va oldindan aytib bo’lmaydigan).

5) Asboblar va texnikalar

Kubernetes: Chaos Mesh, Litmus, PowerfulSeal, kube-monkey.
Bulutlar: AWS Fault Injection Simulator (FIS), bulutlar yaqinidagi Fault Domains.
Tarmoq/proksi: Toxiproxy (TCP-zahar), tc/netem, iptables, Envoy fault (delay/abort), Istio fault injection.
Jarayonlar/uzellar:’stress-ng’, cgroups/CPU-throttle, disk fill.
Traffik-marshrutlash: GSLB/DNS weights, canary/blue-green feylover tekshirish uchun almashtirish.

6) Ssenariy namunalari (Kubernetes)

6. Yo’nalishda 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 }

Faraz: mijoz taymautlari/retraylari va CB p95 <300 ms va error-rate <0 ni ushlab turadi. 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"

Gipoteza: balanslovchi va HPA bir nusxaning lossini p99> 20% o’smasdan kompensatsiya qiladi.

6. 3 Tarmoq tartibsizligi (DBga kechikish)

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"

Faraz: pullar/taymautlar/kesh ta’sirni kamaytiradi; p95 to’lovlar SLO ≤ qoladi.

6. 4 Diskni toʻldirish

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"

Gipoteza: log/kvota/alertlar rotatsiyasi yo’nalishlar buzilgunga qadar ishlaydi.

7) K8s tashqarisidagi eksperimentlar

7. 1 Toxiproxy (lokal/integratsiya)

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 (perimetr/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 (g’oyaga misol)

Auto Scaling Group’da N% EC2 «o’ldirish» eksperimenti, sun’iy ravishda EBS-latency ko’tarish, bitta AZ’da NAT-GW o’chirish.
CloudWatch SLO metriklari bo’yicha o’rnatilgan to’xtash mezonlari.

8) Tartibsizlik paytida kuzatish metrikasi

SLO/SLI: fraction of good requests, p95/p99, burn-rate.
Kritik yo’nalishlar bo’yicha RED-model (Rate, Errors, Duration).
Pullar: p95, utilization ulanishini kutish.
BD: lag replika, locks, dreyf p95 so’rovlar.
Tarmoq: retransmits, RTT, dscp/ecn.
Biznes-SLI: tranzaksiyalarning muvaffaqiyati (depozitlar/chekaut),% qaytarish/xatolar.
Trastirovka: tanlangan treyslar (exemplars), reliz-annotatsiyalar korrelyatsiyasi.

9) SLO/Error-budget bilan integratsiya

Xatolar byudjeti doirasida tajribalarni rejalashtiring: xaos choraklik maqsadlarni «buzmasligi» kerak.
Burn-rate alertlari avtomatik kill-switch sifatida.
Hisobot: «qancha byudjet yoqib yuborilgan», «qanday deviatsiyalar steady-state».

10) Game-days (mashqlar)

Stsenariy: qisqacha afsona (masalan, «mintaqa-East yo’qolgan»), inyeksiya qadamlari, SLO maqsadlari, rollar, vaqt.
Baholash: RTO/RPO haqiqiy, kommunikatsiya sifati, runbook to’g "ri.
Retro: egalari va muddatlari bilan yaxshilanishlar ro’yxati, hujjatlar/dashbordlarni yangilash.

11) Avtomatlashtirish va CI/CD

Smoke-chaos: har bir relizda staging bo’yicha qisqa testlar (masalan, bitta yo’nalishda 1 pod-kill + 200 ms delay).
Tungi/haftalik: og’irroq stsenariylar (5-15 daqiqa) hisobot bilan.
Promo-geytlar: agar p95/xatolar> canary chegarasi - avto-qaytish.
Eksperimentlar katalogi (YAML + runbook + SLO-thresholds).

12) Anti-patternlar

«Parmaksiz prodni sindirish»: stop-mezonlar yo’q, haqiqiy hodisa xavfi yo’q.
Jarayon o’rniga bir martalik aksiya.
Stady-state bo’lmagan tartibsizlik: muvaffaqiyat/muvaffaqiyatsizlik deb nima hisoblash kerakligi aniq emas.
Kechikishlarni in’ektsiya qilishda ortiqcha retralar → o’z-DDoS.
Biznes-SLIni e’tiborsiz qoldirish: to’lovlar/buyurtmalar muvaffaqiyatsiz tugaganida «texnik» muvaffaqiyatlar.
Post-tahlil va yaxshilanishlar egalari yo’qligi.

13) Joriy etish chek-varaqasi (0-45 kun)

0-10 kun

steady-state SLI (foydalanuvchi + biznes) ni aniqlash.
Asbobni tanlash (Chaos Mesh/Litmus/Toxiproxy/FIS).
Panjaralarni tasvirlash: blast radius, stop-mezonlar, oynalar, rollar.

11-25 kun

Birinchi eksperimentlarni boshlash: pod-kill, 100-200 ms delay kritik apstrimga, drop 1% paketlar.
Burn-rate alertlarini moslash, kill-switchni stop-mezonlar bilan bogʻlash.
Birinchi game-day o’tkazish, retro va fikslarni yig’ish.

26-45 kun

AZ/qaramlik darajasidagi stsenariylarni qoʻshish (tashqi PSP, BD-lag).
Stagingda nightly-xaosni avtomatlashtirish; «mavsumiy» ssenariylarni (cho’qqilarni) tayyorlash.
Tajribalar katalogi va SRE uchun muntazam hisobotlar.

14) Etuklik metrikasi

Tanqidiy yo’nalishlarning 80% ≥ tavsiflangan tajribalar va steady-state metrikaga ega.
Avto kill-switch p99/error-rate chegarasidan oshganda ishga tushadi.
Har chorakda - AZ/mintaqa darajasidagi game-day; ≥ 1 marotaba/oyda - qaramlikning maqsadli stsenariysi.
MTTR yaxshilanishlar siklidan so’ng pasayadi, «release insident» korrelyatsiyasi kamayadi.
Haqiqiy muvaffaqiyatsizliklarda «kutilmagan» pasayishlar ulushi → nolga intiladi.
Dashbordlar «barqarorlik» ni KPI (burn-rate, tiklanish vaqti, muvaffaqiyatli DR-harakatlar ulushi) sifatida ko’rsatadi.

15) Guardrails va stop triggerlari misollari

Stop:’http _ req _ failed> 1%’3 daqiqa,’p99> 1000 ms’3 oynalar,’deposit _ success <99. 5%`.
Blast radiusning pasayishi: manifestning avto-qaytishi, GSLB tarozilarining qaytishi, fault-inyeksiyalarni uzib qo’yish.
Stop buyrugʻi: yagona tugma/skript.

16) Madaniyat va jarayonlar

Xaos - bu «ekstremal» emas, balki SRE ritmining bir qismidir.
Shaffof hisobotlar, zaifliklarni tan olish, tuzatuvchi harakatlar.
On-call, mijozlar/sheriklar bilan muloqotlarni simulyatsiya qilishni o’rgatish.
SLA/SLO va byudjetlar bilan bog’liqlik: tartibsizlik ishonchlilikni buzishdan ko’ra ko’tarishi kerak.

17) Xulosa

Chaos Engineering «to’qqizga umid» ni isbotlanadigan barqarorlikka aylantiradi. Stady-state shakllantiring, panjara qo’ying, kichik va nazoratni buzing, SLO va biznes-SLIni kuzating, yaxshilanishlarni tuzating va avtomatlashtiring. Shunda haqiqiy nosozliklar boshqariladigan hodisalar bo’ladi: oldindan aytib bo’ladigan RTO, himoyalangan error-budget va jamoaning vahimasiz harakat qilishga tayyorligi.