Dayanıklılık, “problem yokken” yapılan yatırımla kazanılır. Fakat üretimde dayanıklılık testi yapmak çoğu ekipte haklı bir refleksle korku yaratır: “Ya gerçekten kırarsak?” Bu yazıda kaosu romantize etmeden, operasyonel gerçeklikte çalışan bir yaklaşımı anlatıyorum: deney düzlemi.
Chaos engineering’i ne zaman ciddiye alırım?
Şu üç koşul varsa kaos çalışması “olsa güzel olur” değil, risk azaltma işidir:
- Üretimde çoklu bağımlılık (DB, cache, queue, 3rd party, network katmanı) büyüdüyse
- Incident sonrası “bunu test edemezdik” cümlesi tekrar etmeye başladıysa
- Değişiklik hızlandı ama SLO/SLA baskısı aynı kaldıysa
Deney düzlemi: Kaosu güvenli kılan mimari
Benim önerdiğim model dört katmandan oluşur:
- Hipotez katmanı: “Şu bileşen 2 dakika gecikirse, kullanıcı etkisi X olur” gibi ölçülebilir hedef.
- Blast radius katmanı: Deneyi tüm trafiğe değil, hedefli bir parçaya uygula.
- Guardrail katmanı: Otomatik durdurma/geri alma sınırları.
- Delil katmanı: Metrik + log + trace ile “gerçekten ne oldu?” sorusunu kanıtla.
Bu model yoksa chaos engineering genelde “cesaret gösterisi”ne döner ve ekip güvenini yakar.
Başlangıç için en güvenli 6 deney tipi
Üretimde en az sürpriz çıkaran deneyler:
- Latency injection (ör. downstream’e 200–500ms)
- Error rate injection (kontrollü 5xx/timeout)
- Pod/VM kill (tek instance öldürme)
- Network partition simulasyonu (kısıtlı segmentte)
- Rate limit / quota (kademeli sıkılaştırma)
- Dependency blackhole (yalnızca canary ring’te)
Blast radius: “Herkese” değil “hedefe” uygula
Blast radius’ı düşürmek için pratik yöntemler:
- Release ring: deneyi sadece canary ring’e uygula
- Tenant/segment: yalnızca düşük riskli tenant’a uygula
- Endpoint: sadece arka planda çalışan job endpoint’lerine uygula
- Zaman penceresi: belirli dakikalarda, on-call hazırken uygula
En önemli prensip şudur: Deney etki alanı, geri dönüş hızınızdan büyük olmamalı.
Guardrail: Deney otomatik nasıl durur?
Kaosun güvenli olması için “insan fark eder” yaklaşımı yeterli değildir. Ben genelde şu guardrail’leri şart koşarım:
- SLO tabanlı stop: error budget burn belirli eşiği aşarsa deney kapanır
- Latency stop: p95/p99 belirli eşiği aşarsa kapanır
- Satürasyon stop: queue depth, thread pool, conn pool doyarsa kapanır
- İkincil sinyal stop: “checkout success rate” gibi iş metriği düşerse kapanır
- Otomatik rollback: config flag / traffic split geri alınır
Guardrail’ler, deney tanımıyla birlikte version’lanmalı ve review’dan geçmelidir.
Deney formatı: Tek sayfalık disiplin
Bu formatı minimum standart yapınca kaos çalışması “bireysel kahramanlık”tan çıkar:
- Amaç: hangi riski azaltıyoruz?
- Hipotez: beklenen davranış (ölçülebilir)
- Ön koşullar: alert’ler, dashboard’lar, runbook hazır mı?
- Blast radius: hangi ring/tenant/endpoint?
- Guardrail: hangi sinyallerde otomatik stop?
- Geri dönüş: tek komutla/tek flag ile kapanıyor mu?
- Delil: çıktılar nereye yazılıyor?
Başarı kriteri: “Kırmadık” değil, “öğrendik”
Deney sonunda şu sorulara net cevap yoksa deney boşa gider:
- Beklediğimiz alarmlar gerçekten tetiklendi mi?
- On-call akışı doğru mu çalıştı?
- Hangi dashboard’lar yetersiz kaldı?
- Geri dönüş süresi (MTTR) neydi?
- Aynı sınıf incident tekrar etse daha hızlı toparlar mıyız?
Kaos çalışmasının ROI’si burada çıkar: daha az sürpriz, daha hızlı toparlanma, daha az operasyonel stres.