Chaos Engineering Nedir? 45 Dakikada Dayanıklılık

Meta Description

Chaos Engineering nedir? Kontrollü arıza testleriyle sisteminizin zayıf noktalarını bulun, 45 dakikada ilk deneyi tasarlayıp uygulayın.

Giriş (Introduction)

Prod ortamında her şey yolunda giderken sistemin dayanıklı olduğunu varsaymak kolaydır. Ama gerçek dünyada ağ gecikir, bir servis çöker, disk dolar, CPU %100 olur, bulut sağlayıcı bir bölgede sorun yaşar. Çoğu ekip bu senaryoları ancak kullanıcılar şikayet etmeye başladığında öğrenir.

Chaos Engineering, kontrollü ve güvenli şekilde “arıza” üreterek sistemin davranışını doğrulama disiplinidir. Amaç “ortamı yakmak” değil; ölçülebilir bir hipotezle zayıf noktaları bulup iyileştirmektir.

Bu yazıda Chaos Engineering kavramını hızlıca netleştirip, 45 dakikada ilk deneyinizi tasarlayıp uygulayabileceğiniz pratik bir yol haritası vereceğim. Üstelik giriş seviyesinde başlayıp, ekip olgunlaştıkça genişletebileceğiniz şekilde.

---

Chaos Engineering Nedir? (Anahtar kavram)

Chaos Engineering, dağıtık sistemlerde beklenmeyen durumlar (servis çökmesi, ağ kesintisi, gecikme, kaynak tükenmesi vb.) karşısında sistemin hedeflenen davranışı sergileyip sergilemediğini test etmek için kontrollü deneyler yapma yaklaşımıdır.

Bunu klasik “load/stress test”ten ayıran şey:

• Load test: “Trafik artınca ne oluyor?”
• Chaos Engineering: “Bir şey bozulduğunda (ve genelde aynı anda birkaç şey), sistem beklediğimiz şekilde toparlıyor mu?”

İlişkili (LSI) kavramlar: dayanıklılık (resilience), hata toleransı, fault injection, blast radius, SLO/SLI, degrade mode, circuit breaker, retry/backoff.

---

Bunu neden yapmalıyım? (İş etkisi)

Chaos Engineering, “teknik merak” için değil, doğrudan iş hedefleri için yapılır:

• Daha az kesinti (downtime): Tek noktadan hata (SPOF) ve hatalı geri kazanım akışlarını erken yakalarsınız.
• Daha hızlı incident müdahalesi: Runbook’lar ve alarmlar gerçek olaylara göre olgunlaşır.
• Daha düşük maliyet: Gereksiz aşırı ölçeklendirme yerine nerenin kırıldığını bilerek optimize edersiniz.
• Müşteri güveni: “Sistem çöktü” yerine “kısmi degrade ile çalıştı” seviyesine gelirsiniz.

Kısacası: Chaos Engineering, “keşke önceden bilseydik” dediğiniz şeyleri size planlı ve güvenli şekilde gösterir.

---

Chaos Engineering’in 4 Temel Prensibi

1) Hipotezle başla

Deney “rastgele arıza” değildir. Bir hipotez yazın:

• “Payment servisi 30 saniye yanıt vermezse checkout, kullanıcıya ‘sonradan dene’ mesajı gösterip siparişi kuyrukta bekletmeli; hata oranı %1’i geçmemeli.”

2) Ölçülebilir başarı kriteri belirle (SLI/SLO)

Deneyin “başarılı” olup olmadığını objektif ölçün:

• 5xx oranı
• p95/p99 latency
• iş metriği (checkout completion rate)
• kuyruk uzunluğu
• error budget tüketimi

3) Blast radius’ü sınırla

İlk deneyler:

• Sadece staging veya prod’da küçük bir yüzde (ör. %1 trafik)
• Zaman penceresi kısa (10–15 dk)
• Geri alma (rollback) planı net

4) Öğren ve kalıcı iyileştir

Deney sonunda yalnızca “sistem dayanıklı” demek yetmez:

• Alert’ler doğru mu?
• Runbook yeterli mi?
• Eksik timeout/retry/backoff var mı?
• Daha iyi fallback mümkün mü?

---

45 Dakikada İlk Chaos Deneyi: Adım Adım

Aşağıdaki plan, en hızlı “ilk değer” üreten güvenli akıştır.

1) Bir kritik akış seç (5 dk)

Örnek kritik akışlar:

• Login
• Checkout / ödeme
• Bildirim gönderimi
• Dosya yükleme

Öneri: İlk deneyi “müşteri deneyimini en çok etkileyen ama blast radius’ü yönetilebilir” bir akışta yapın.

2) En zayıf varsayımı yaz (5 dk)

Şu kalıpla yazın:

• “Eğer X bozulursa, sistem Y şekilde davranmalı ve Z metriği sınırı aşmamalı.”

Örnek:

• “Orders DB bağlantısı 60 saniye kesilirse, API 2 saniye içinde timeout verip circuit breaker açmalı; thread pool dolmamalı; 5xx oranı %2’yi geçmemeli.”

3) Gözlemlenebilirlik kontrolü (10 dk)

Deneyden önce şunlar var mı?

• API latency (p95/p99)
• Hata oranı (4xx/5xx)
• Uygulama logları (correlation id)
• Alarmlar (ör. 5xx > %1)

Eksikse en azından:

• 5xx oranı
• p95 latency
• CPU/RAM

4) Arıza türünü seç (5 dk)

Başlangıç için güvenli ve yaygın arızalar:

• Latency injection: Servise +500ms ek gecikme
• Packet loss: %5 paket kaybı
• CPU stress: %80 CPU
• Pod kill / instance terminate: Bir instance’ı kapat

5) Deneyi uygula (10 dk)

Kubernetes kullananlar için en pratik başlangıç araçlarından biri Chaos Mesh’tir.

Aşağıdaki örnek, payment isimli servise %50 olasılıkla 800ms gecikme enjekte eder (staging namespace gibi düşünün).

apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: payment-latency
  namespace: staging
spec:
  action: delay
  mode: all
  selector:
    labelSelectors:
      app: payment
  delay:
    latency: "800ms"
    correlation: "50"
    jitter: "100ms"
  duration: "10m"

Uygulama:

kubectl apply -f payment-latency.yaml
kubectl -n staging describe networkchaos payment-latency

İzleme (örnek):

• p95 latency yükseldi mi?
• checkout completion rate düştü mü?
• retry fırtınası oldu mu (thundering herd)?

Durdurma:

kubectl delete -f payment-latency.yaml

İpucu: İlk deneyde “pod öldürme” yerine “gecikme ekleme” genelde daha güvenlidir ve daha çok şeyi görünür kılar (timeout, retry, UI fallback).

6) Sonuçları yaz ve aksiyon çıkar (10 dk)

Deney raporu için mini şablon:

Alan	Not
Hipotez	Örn. “800ms gecikmede checkout degrade olur, 5xx %2 altında kalır”
Gözlem	p95=2.8s oldu, 5xx %6’ya çıktı
Kök neden	Timeout 1s değil 5s, retry sınırsız
Aksiyon	Timeout=1.5s, retry=3 + exponential backoff, circuit breaker
Takip	1 hafta sonra aynı deneyi tekrarla

---

Gerçek Hayat Örneği: Retry Fırtınası ile Çöküş

Bir e-ticaret ekibi inventory servisine geçici gecikme yaşandığında tüm isteklerin otomatik retry yaptığını fark etti. Sorun şuydu:

• Timeout 10 saniye
• Retry 5 kez
• Backoff yok

Bu kombinasyonla, küçük bir gecikme tüm sistemi kilitleyen bir retry fırtınasına dönüştü.

Chaos deneyi sonrası:

• Timeout düşürüldü
• Retry 2–3 ile sınırlandı
• Exponential backoff + jitter eklendi
• Circuit breaker devreye alındı

Sonraki deneyde aynı gecikme, sadece ilgili akışta kontrollü degrade yarattı; sistem genel olarak ayakta kaldı.

---

En İyi Uygulamalar: Güvenli Chaos Engineering Checklist

Deney öncesi

• Rollback planı (tek komutla kapat)
• Deney süresi ve kapsamı net
• Alert’ler ve dashboard hazır
• Deney sahibi ve “stop” yetkilisi belirli

Deney sırasında

• Canlı metrik takibi
• Kullanıcı etkisi artarsa deney durdur
• Deney notlarını anlık tut

Deney sonrası

• Postmortem değil, learning review
• Aksiyonlar ticket’landı
• Aynı deney tekrarlanabilir hale getirildi (otomasyon)

---

Hangi Senaryolarla Başlamalı? (Deney fikirleri)

Aşağıdaki liste, ekipler tarafından en çok değer üreten başlangıç senaryolarıdır:

1. Tek instance düşerse (pod kill) servis devam ediyor mu?
2. DB bağlantısı kesilirse uygulama thread pool’u doluyor mu?
3. DNS bozulursa servis discovery nasıl etkileniyor?
4. Ağ gecikmesi artarsa timeout/retry ayarları doğru mu?
5. Queue tüketimi durursa backlog büyürken sistem davranışı ne?

---

Sık Sorulan Sorular (FAQ)

1) Chaos Engineering prod’da yapılır mı?

Evet, ama kontrollü şekilde. İlk deneyleri staging veya prod’da küçük blast radius ile yapın ve net durdurma planı oluşturun.

2) Chaos Engineering ile load test aynı şey mi?

Hayır. Load test trafik artışını test eder; Chaos Engineering ise arıza/bozulma anında sistemin dayanıklılığını ve geri kazanımını doğrular.

3) Küçük bir ekibim var, yine de gerekli mi?

Evet. Küçük ekipler için daha da kritiktir çünkü incident anında müdahale kapasitesi sınırlıdır. Az ama düzenli deneyler büyük fark yaratır.

4) En risksiz ilk deney hangisi?

Genelde latency injection (ör. +300–800ms) iyi bir başlangıçtır. Timeout, retry ve UI fallback’leri hızlıca ortaya çıkarır.

5) Başarılı bir deneyin çıktısı ne olmalı?

Bir “rapor”dan çok iyileştirme listesi: net aksiyonlar, sahipler, tarih ve tekrar koşulu (aynı deneyi yeniden çalıştırma).

---

Sonuç

Chaos Engineering, sisteminizin “bozulunca ne yaptığına” dair varsayımları test ederek dayanıklılığı ölçülebilir şekilde artırır. Hipotez + metrik + sınırlı blast radius ile ilerlediğinizde, ilk günden değer üretir.

Bugün şunu yapın: Bir kritik akış seçin, tek bir hipotez yazın ve staging’de 10 dakikalık gecikme deneyi uygulayın. Çıkan aksiyonları yorumlara yazın ya da ekibinizle paylaşın; isterseniz kullandığınız stack’i (Kubernetes/VM, dil, gözlemlenebilirlik aracı) söyleyin, size daha uygun bir deney planı önereyim.