Kaos mühendisliği: Sistem esnekliği

Kaos mühendisliği: Sistem esnekliği

1) Neden kaos mühendisliği

• Sistem davranışı hakkındaki hipotezleri test edin ve SLO'yu doğrulayın;
• Gizli SPOF'ları, yanlış zaman aşımlarını/geri dönüşleri, basamaklı efektleri algılar;
• tren takımları: oyun günleri, çalışma kitapları, iletişim;
• "En iyisini ummak" yerine "varsayılan olarak sürdürülebilirlik" kültürü oluşturmak.

Önemli: Kaos Mühendisliği ≠'her şeyi kırın. "Bu bilimsel bir yöntemdir: durağan durum, hipotez, deney, sonuç, iyileştirme.

2) Temel deney döngüsü

1. Steady-state (baseline): Hangi SLI'lar stabildir? (Örneğin, başarı ms ≤500 99'da. 95%).
2. Hipotez: Bir AZ kaybıyla, p95 <%10 artacak ve kullanılabilirlik ≥99. 9%.
3. Deney: Sınırlı patlama yarıçapı ve durma kriterleri ile planlanmış faul.
4. Gözlem: metrikler/yollar/günlükler, yakma oranı SLO, iş SLI (örneğin, başarılı mevduat).
5. İyileştirmeler: Bulguları kaydeder, zaman aşımlarını/sınırları/yönlendirmeyi değiştirir, çalışma kitabını güncelleriz.
6. Otomasyon/regresyon: Programda tekrarlayın, CI/CD ve oyun günleri takvimlerine ekleyin.

3) Önce güvenlik

Patlama yarıçapı: dar bir taneyle başlayın - bir pod/örnek/rota/ad alanı.
Korkuluklar: SLO yanma oranına (hızlı/yavaş), yeniden ödeme limitlerine, QPS limitine, olay bütçesine yönelik uyarılar.
Durdurma ölçütleri: "Hata oranı> % X veya p99> Y ms N dakika ise - anında durdurun ve geri alın".
Windows: nöbetçi çalışma saatleri, bilgilendirilmiş paydaşlar, dondurulmuş sürümler.
İletişim: IC/Tech kurşun/İletişim, açık kanal (Savaş odası), mesaj şablonu.

4) Başarısızlık sınıfları ve hipotez fikirleri

Ağ: delay/jitter/loss, portların kısmi düşüşü, hizmetler/PSP arasında "flopping" iletişimi.
Bilgisayar/düğümler: öldürme işlemleri, CPU aşırı ısınması, dosya tanımlayıcılarının tükenmesi, dar bağlantı havuzları.
Depolama ve veritabanı: gecikme disklerinin büyümesi, gecikme kopyaları, bir parça/lideri durdurun, bölünmüş beyin.
Bağımlılıklar: harici API'lerin bozulması, sağlayıcı sınırları, 5xx/429 patlamaları.
Değişiklik yönetimi: başarısız sürüm, kötü özellik bayrağı, kısmi sunum.
Çevre: CDN bozulur, DNS/Anycast sürüklenme, WAF/bot koruma hatası.
Bölge/AZ: Tam kayıp veya "kısmi" olay (biraz daha kötü ve öngörülemeyen).

5) Araçlar ve teknikler

Kubernetes: Chaos Mesh, Litmus, PowerfulSeal, kube-monkey.
Bulutlar: AWS Arıza Enjeksiyon Simülatörü (FIS), Bulutların yakınındaki Arıza Etki Alanları.
Ağ/proxy: Toxiproxy (TCP zehiri), tc/netem, iptables, Elçi hatası (gecikme/iptal), Istio hata enjeksiyonu.
İşlemler/düğümler: 'stress-ng', cgroups/CPU-throttle, disk dolgusu.
Trafik yönlendirme: GSLB/DNS ağırlıkları, sahte kontroller için kanarya/mavi-yeşil anahtarlama.

6) Örnek komut dosyaları (Kubernetes)

6. 1 Rotadaki gecikme/iptal (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 }

Hipotez: Istemci zaman aşımları/retrays ve CB'ler p95 <300 ms ve hata oranı <0 olacaktır. 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: Dengeleyici ve HPA, p99> %20'lik bir büyüme olmadan bir örneğin kaybını telafi eder.

6. 3 Ağ kaosu (veritabanına gecikme)

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: havuzlar/zaman aşımları/önbellek etkiyi azaltacaktır; P95 ödemeleri SLO ≤ kalacaktır.

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"

Hipotez: Rotasyon günlükleri/kotalar/uyarılar rotasyon yolları bozulma önce çalışacaktır.

7) K8s dışındaki deneyler

7. 1 Toxiproxy (yerel/entegrasyon)

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 Elçi HTTP hatası (çevre/kafes)

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 (örnek fikir)

Otomatik Ölçekleme Grubunda % EC2'yi "öldür" deneyi yapın, EBS gecikmesini yapay olarak yükseltin, bir AZ'de NAT-GW'yi devre dışı bırakın.
CloudWatch SLO metrikleri için yerleşik durdurma kriterleri.

8) Kaos sırasında gözlemlenebilirlik metrikleri

SLO/SLI: iyi isteklerin oranı, p95/p99, yanma oranı.
Kritik rotalar için RED modeli (Hız, Hatalar, Süre).
Havuzlar: p95 bağlantısı, kullanım için bekliyor.
DB: gecikme kopyaları, kilitler, sürüklenme p95 istekleri.
Ağ: yeniden iletimler, RTT, dscp/ecn davranışı.
İş SLI: işlemlerin başarısı (para yatırma/kontrol etme), % iade/hata.
İzleme: seçici yollar (örnekler), sürüm ek açıklamalarının korelasyonu.

9) SLO/Hata bütçesi ile entegrasyon

Deneyleri hatalar bütçesi içinde planlayın: kaos, üç aylık hedefleri "bozmamalıdır".
Otomatik kill-switch olarak yanma oranı uyarıları.
Raporlama:'ne kadar bütçe yandı ",'ne sapmalar sabit durum".

10) Oyun günleri (egzersiz)

Senaryo: kısa efsane (örn. "Bölge-Doğu kayıp"), enjeksiyon adımları, SLO hedefleri, roller, zaman.
Değerlendirme: RTO/RPO gerçek, iletişim kalitesi, çalışma kitabı doğruluğu.
Retro: sahipler ve son tarihler ile iyileştirmelerin listesi, güncelleme belgeleri/gösterge tabloları.

11) Otomasyon ve CI/CD

Duman-kaos: Her sürümde kısa evreleme testleri (örn. 1 pod-kill + rota başına 200ms gecikme).
Gecelik/Haftalık: Rapor ile daha ağır senaryolar (5-15 dakika).
Promo kapıları: eğer p95/hatalar> kanarya eşiği - otomatik geri alma.
Deney kataloğu içeren havuzlar (YAML + runbook + SLO-thresholds).

12) Anti-desenler

"Korkuluklar olmadan yiyecek kırma": durdurma kriterleri yok, çağrı yok - gerçek bir olay riski.
Süreç yerine tek seferlik eylem.
Sabit durum olmadan kaos: Neyin başarı/başarısızlık olarak sayıldığı açık değildir.
Aşırı retrays - gecikmeleri enjekte ederken kendi kendine DDoS.
İş SLI'sini göz ardı etme: Ödemeler/siparişler başarısız olduğunda "Technarian" başarısı.
Analiz sonrası ve iyileştirme sahiplerinin eksikliği.

13) Uygulama kontrol listesi (0-45 gün)

0-10 gün

Kararlı durum SLI (kullanıcı + işletme) tanımlayın.
Bir araç seçin (Chaos Mesh/Litmus/Toxiproxy/FIS).
Korkulukları tanımlayın: patlama yarıçapı, durma kriterleri, pencereler, roller.

11-25 gün

İlk deneyleri çalıştırın: pod-kill, kritik yukarı akış başına 100-200 ms gecikme, paketlerin %1'ini düşürün.
Yazma hızı uyarılarını yapılandırın, kill-switch'i stop-criteria ile ilişkilendirin.
İlk oyun gününü geçirin, retro ve düzeltmeleri toplayın.

26-45 gün

AZ düzeyi/bağımlılık komut dosyaları ekleyin (harici PSP, DB-lag).
Sahnelemede gece kaosunu otomatikleştirin; "Mevsimsel" senaryolar hazırlayın (zirveler).
Yönetim/SRE için deney kataloğu ve düzenli raporlar.

14) Olgunluk metrikleri

Kritik rotaların % ≥80'i açıklanan deneylere ve kararlı durum ölçümlerine sahiptir.
Otomatik kill-switch, p99/hata oranı eşikleri aşıldığında tetiklenir.
Üç aylık - oyun günü seviyesi AZ/bölge; ≥1 kez/ay - bağımlılıkların hedef senaryosu.
Bir iyileştirme döngüsünden sonra MTTR azalır,'olay ↔ salınımı "korelasyonu azalır.
Gerçek başarısızlıklarda "beklenmedik" düşüşlerin oranı - sıfıra eğilimlidir.
Panolar KPI'lar olarak "esneklik" gösterir (yanma oranı, iyileşme süresi, başarılı DR eylemlerinin oranı).

15) Korkuluk örnekleri ve durdurma tetikleyicileri

Dur: 'http _ req _ failed> 1 %' 3 minutes, 'p99> 1000 ms' 3 winds ', deposit _ success <99. 5%`.
Patlama yarıçapının azaltılması: Manifestonun otomatik olarak geri alınması, GSLB ağırlıklarının geri dönüşü, arıza enjeksiyonlarının devre dışı bırakılması.
Stop komutu: Nedenlerin günlüğe kaydedilmesiyle tek düğme/komut dosyası.

16) Kültür ve süreçler

Kaos, SRE ritminin bir parçasıdır, "aşırı'değil.
Şeffaf raporlama, güvenlik açığı tanıma, düzeltici eylem.
Çağrı üzerine eğitim, müşterilerle/ortaklarla iletişim simülasyonu.
SLA/SLO ve bütçelerle bağlantı kurma: Kaos, güvenilirliği zayıflatmamalı, artırmalıdır.

17) Sonuç

Kaos Mühendisliği, "dokuzlu umutları" kanıtlanabilir sürdürülebilirliğe dönüştürür. Kararlı durum formüle edin, korkulukları yerleştirin, küçük ve kontrollü kırın, SLO ve iş SLI'sini gözlemleyin, iyileştirmeleri kaydedin ve otomatikleştirin. O zaman gerçek başarısızlıklar kontrollü olaylar haline gelecektir: öngörülebilir RTO, korunan hata bütçesi ve ekibin panik olmadan hareket etme isteği.