Kaos mühendisliği

1) Temel prensipler

Orijinal hipotez olarak Kararlı Durum. Normu açıkça tanımlayın (örneğin: p95 <200 ms, hata oranı <0. %3, kritik akış başarısı> 99. 5%).
İzole edilmiş değişkenler. Etki ve gelişmeyi nedensel olarak bağlamak için bir kerede mümkün olduğunca bir faktör değiştirin.
Derece. Güvenli bir ortamda küçük genliklerle başlıyoruz - kapsama ve yoğunluğu genişletiyoruz.
Korkuluklar. SLO/uyarı/hata bütçesinde açık durdurma koşulları.
Tekrarlanabilirlik. Deney deterministik olarak tekrarlanabilir olmalıdır (scriptler/manifestolar/IaC).
Etik ve güvenlik. Riskli deneylerde gerçek kişisel veriler ve finansal işlemler yoktur.

2) "Kararlı durum'nedir

• Anahtar uç noktaların p50/p95/p99 gecikmeleri.
• Başarı oranı ve kritik yol dönüşümü.
• Hata oranı, zaman aşımları, "shed" isteklerinin yüzdesi (doygunlukta kesilmiş).
• Kendi kendini iyileştirme oranı (MTTR), geri çekilmelere karşı direnç (fırtınalar olmadan).
• Alan değişmezleri: "bakiyedeki eksiler" eksikliği, bir kez yapılan ödemeler, raporlama günlerinin tutarlılığı vb.

3) Enjeksiyon kataloğu (kırdığımız şey)

Ağ: gecikme, titreme, kayıp/kopyalar, bant genişliği sınırlaması, TLS sonları, DNS çırpma.
Hesaplamalar: CPU aşırı yüklenmesi, bellek/GC basıncı, tanımlayıcı tükenmesi, saat eğriliği.
Depolama: Yüksek p95 I/O, ENOSPC, lider/çoğaltma hatası, bölünmüş beyin, kalıcı fsync.
Bağımlılıklar: 5xx/429, "yavaş başarı", harici API'lerin bozulması, oran sınırı.
Veri: mesajların kopyalanması/kaçırılması, sıra dışı, kirli kayıtlar, sürüm çakışması.
İşlemler: başarısız serbest bırakma/yapılandırma, hata içeren özellik bayrağı, süresi dolmuş sertifika, anahtar döndürme.
İnsanlar ve süreçler: sorumluların bulunmaması, manuel güncellemenin gecikmesi, yanlış çalışma kitabı.

4) Deney tasarımı (şablon)

1. Hipotez: "Ana API <450 ms'nin p99 para birimi servisine + 300 ms'de, bir kırıcı açılır, ≤ 15 dakika önce eski bir yanıt verilir".
2. Enjeksiyon: arıza profili (tip/genlik/süre) ve hedef kontur.
3. Metrikler/günlük etiketleri: marking 'chaos. experiment_id', 'phase = inject' recover '.
4. Korkuluklar: 'error _ rate> %2' veya p99> SLA × 2'de 1 dakikadan fazla iptal edin.
5. Sonuçlar/çıktı: gözlemlerin listesi, hatalar, iyileştirmeler, çalışma planı ve yeniden çalıştırma.

5) Gözlemlenebilirlik: zorunlu olan nedir

İzleme: bağımlılıklar aracılığıyla istek yolu; Bozulma olan bölümler işaretlenir.
Kaynak metrikleri: CPU, yığın/GC, FD, disk IOPS/lat, ağ bant genişliği, kuyruk derinliği.
İş metrikleri: operasyonların dönüşümü/başarısı, telafi edilen işlemlerin payı.
Olay günlükleri: açılış/kapanış kesiciler, retrays ve bütçeleri, veritabanı lideri değiştirme.
Deney paneli: Korkuluk eşikleri ve kürtaj "kırmızı düğme'ile canlı pano.

6) Korkuluklar ve güvenlik

Teknik: Hata oranı/gecikme üst sınırları, başarılı işlemlerin payında düşüş, DLQ büyümesi.
Örgütsel: zaman penceresi, çağrı üzerine dahil,'bir bölge - bir deney "ilkesi.
Veri/uyumluluk: Yalnızca sentetikler veya kişisel olmayan kitler; Düzenleyici ihlallere yol açan testleri yasaklamak.
Geri alma: bayrak/yumuşak tahliye trafiğinin hazır geri alma/devre dışı bırakma prosedürü.

7) Ortaya çıkması gereken esneklik kalıpları

Zaman aşımı bütçeleri ve jitter retreats (fırtınasız).
Yarı açık ve üstel kurtarma ile Devre Kesici.
Bulkheads: kritiklik havuzlarının izolasyonu (ödemeler analist vs).
Geri basınç ve hız sınırı: öngörülebilir düşük öncelikli kesim.
Birleştirici önbellek, "ısınma fırtınalarına" karşı koruma.
Telafi edici eylemlerle yan etkilerin ve destanların idempotansı.
Veri kurtarma için kuorum, feilover ve anti-entropi.

8) Örnek senaryolar (eskizler)

8. 1 Yavaş Bağımlılık (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 kaybı

Enjeksiyon: Liderin durması/zorla yeniden seçilmesi.
Bekleme: geçici yazma inhibe, çekirdek okuma, WAL/Outbox güvenli, otomatik geri yükleme çoğaltma, çift yazma yok.

8. Günlük Diskinde 3 ENOSPC

Enjeksiyon: diski %95-100 oranında doldurun.
Bekleme: günlüklerin acil dönüşü, kritik günlüklerin güvenliği, kritik olmayan özelliklerin devre dışı bırakılması, uyarı ve otomatik iyileştirme.

8. 4 Patlama trafiği + gölgeleme

Enjeksiyon: Sıcak bir uç noktada 5 dakika boyunca 3 RPS ×.
Bekleme: düşük öncelikli, stabil p95 "çekirdek" bırakarak, geri ödeme kaskadı yok.

9) CI/CD'de otomasyon

Her salınım için aşamada kaos-duman (güvenli genliklerde kısa enjeksiyonlar).
Nightly, deney kataloğuna göre çalışır (matris hizmetleri × arıza türleri).
Kapılar: "Süreklilik eşiğin altındaysa" serbest bırakma engellenir (örneğin, başarılı geri dönüşlerin yüzdesi <%95'tir).
Artifaktlar: rapor, yollar, CPU/yığın flameshraphs, metriklerin ve yapılandırmaların anlık görüntüleri.

10) Oyun günleri (oyun günleri)

• Roller: deney lideri, metrik gözlemcisi, geri dönüş operatörü, iş temsilcisi.
• Senaryolar: önbellek bozulması, kısmi AZ/region-feilover hatası, "kötü sürüm", harici bir sağlayıcının bulunmaması.
• Sonuçlar: Çalışma kitabında boşluklar, uyarılardaki iyileştirmeler, SLO'larda ayarlamalar ve bütçeleri yeniden ödeme bulundu.

11) Veri, olaylar ve ML için kaos

Veri akışları: kopyalar, boşluklar, sıra dışı, gecikmeler için testler; idempotent tüketicilerin ve DLQ stratejilerinin doğrulanması.
Depolar: dizin bozulması, sıcak bölme, kilit çakışması, gecikme altında çoğaltma.
ML: özellik gecikmesi, temel modele geri dönme, giriş veri kalitesinin bozulması (sürüklenme) - sistem "yumuşak bir şekilde körelmeli've düşmemelidir.

12) Anti-desenler

Gözlemlenebilirliği olmayan kaos: siz "körsünüz", sonuçlar spekülatif.
Sahne ve koruma rayları olmadan derhal prod enjeksiyonları.
Aynı anda her şey üzerinde "büyük bir deney" - tam olarak neyin işe yaradığı belli değil.
Hipotezler olmadan gelişigüzel kaos eylemleri ve düzeltmelerden sonra tekrar testler.
Sadece altyapıya odaklanmak - iş değişmezleri unutulur.
İnsanları/süreçleri göz ardı etme: uyarılar, çağrı üzerine, runbook - sistemin bir parçası.

13) Uygulamanın olgunluğu (model)

1. Ad-hoc: Lokal olarak tek enjeksiyonlar.
2. Sahne kaosu: senaryo kataloğu, tekrarlanan işler, gösterge panoları.
3. Kaosu serbest bırakın: her sürümde duman kaosu, kapılar, raporlar.
4. Kısıtlamalarla yiyecek kaosu: düşük trafik, sıkı korkuluklar, hazır geri alma.
5. Sürekli kararlılık: Otomatik deneyler, SLO yönetimi, iş akışı olarak iyileştirmeler.

14) Mimari uygulamalarla entegrasyon

Direnç testi: Kaos deneyleri hata enjeksiyonlarını ve bozulma senaryolarını tamamlar.
Yük testi: Kombine yük + başarısız deneyler kaskadları ve bir geri çekilme fırtınasını ortaya çıkarır.
Kod Olarak Politika/RBAC/ABAC: Korkuluklar, geri alma adımları ve sınırları politika olarak tasarlanmıştır.
Onay/gizlilik yönetimi: veri işleme modunu ihlal eden deneylere izin vermeyin.
Jeo-mimari: Bölgelerin failover ve yargı için bağlayıcı verilerin kaos kontrolleri.

15) Mini tarifler (pseudocode)

Kırıcı + bozma

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

Sınırlayıcı + gölgelendirme

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

Idempotent yan etkisi

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

16) Mimar kontrol listesi

1. Tanımlanmış Kararlı Durum ve korkuluklar?
2. Bir komut dizini var mı (ağ/CPU/depolama/bağımlılıklar/veri/işlemler)?
3. Gözlemlenebilirlik kaynakları, gecikme kuyruklarını, iş değişmezlerini kapsıyor mu?
4. Zaman aşımları/geri çekilmeler/kesiciler/sınırlayıcılar/bölmeler etkin ve parametrelendirilebilir mi?
5. Hazır runbook ve "kırmızı düğme"?
6. Sahnede ve gece deneylerinde kaos-duman var mı?
7. Oyun günleri için "güvenli" pencereler ve roller var mı?
8. Deneyler tekrarlanabilir (IaC/scripts), sonuçlar sürüm?
9. İyileştirmeler görevler tarafından belirlenir, yeniden test yapılır mı?
10. Veri ve ML boru hatları kaplıdır, sadece HTTP değil?

Sonuç

Chaos Engineering, "öngörülemeyen olayları" öngörülebilir senaryolara dönüştürür. Direnç hipotezi, kontrollü enjeksiyonlar, sert korkuluklar, zengin gözlemlenebilirlik ve yeniden test disiplini, serbest bırakma riskini azaltan ve platforma olan güveni artıran araçlardır. Sonuç olarak, ekip sistemin sınırlarını anlar, zarif bir şekilde bozulabilir ve arıza koşullarında bile hizmeti kullanıcıya hızlı bir şekilde iade edebilir.