1. GİRİŞ

Chaos Engineering (Kaos Mühendisliği), sistem davranışını beklenmedik koşullar altında bilimsel, deneysel yöntemlerle test etme disiplini olarak son yıllarda operasyon ve SRE ekiplerinin vazgeçilmez bir aracı hâline geldi. Bulut‑native uygulamalar, mikroservis dağıtımları, container orkestrasyon ve otomatik ölçekleme gibi kompleks altyapılar hata yüzeyini büyütür; bu karmaşıklık, üretimdeki hata senaryolarının önceden görülememesiyle sonuçlanır. Chaos Engineering, bu bilinmezlikleri azaltmak, sistemin dayanıklılığını artırmak ve operasyonel hazırlığı test etmek için kontrollü deneyler yürütür.

Neden bugün konuşuluyor?

• Dağıtık sistemlerin karmaşıklığı, hata senaryolarının kapsamını artırdı; deterministik testler bunların hepsini yakalayamaz.
• SLA ve SLO odaklı operasyonlarda, sadece "çalışıyor/çalışmıyor" testleri yeterli değildir — sistem davranışını olağanüstü koşullarda gözlemlemek gerekiyor.
• Tooling (Gremlin, Chaos Mesh, Litmus, Chaos Monkey) olgunlaşması ve CI/CD entegrasyonları, kaos deneylerini üretimde güvenli şekilde yürütmeyi mümkün kıldı.

Kimler için önemli?

• SRE ve platform mühendisleri — production resiliency ve operayonel olgunluk için.
• Backend geliştiriciler ve test mühendisleri — sistem sınırlarını anlamak ve hata toleransını iyileştirmek isteyenler.
• CTO ve operasyon liderleri — kesinti riskini azaltmak ve kullanıcı deneyimini korumak isteyen karar vericiler.

Hangi problemleri çözüyor?

• Öngörülmemiş bağımlılıklar ve single point of failure (SPOF) tespiti.
• Incident response süreçlerinin ve runbook'ların gerçekçi şekilde test edilmesi.
• Servis degrade senaryolarında kullanıcı etkisinin ölçülmesi ve recovery pattern'lerinin doğrulanması.

2. KAVRAMSAL TEMELLER

2.1 Kaos mühendisliği nedir — kısa tanım

Chaos Engineering; sistemlerin beklenen normal durumunu (steady state) tanımlayıp, bu durumu bozan kontrollü hata enjeksiyonları yaparak hipotezleri test eden mühendislik disiplinidir. Amaç, sistemin dayanıklılığını ölçmek ve zayıf halkaları bulup düzeltmektir.

2.2 Temel kavramlar

• Steady state: Sistemin normal çalışma göstergesi; CPU/latency/success rate gibi temel SLI/metric'lerin beklenen aralığı.
• Hypothesis (Hipotez): Bir deneyin beklenen etkisini ifade eden cümle; örn. "tek bir zone düşürülse bile overall error rate %1'in altında kalır".
• Blast radius: Deneyin etkileyeceği kullanıcı veya sistem yüzeyinin büyüklüğü; minimum tutulması gerekir.
• Steady state metrics: Deney öncesi ve sonrası takip edilecek ölçütler (latency p95, success rate, queue length, error budget).

2.3 Terminoloji ve roller

• Experiment owner: Deneyi tasarlayan ve sonucu raporlayan kişi.
• Runbook & remediation: Deney sırasında veya sonrası geri alma (rollback) ve recovery adımları.
• Safety constraints: Otomatik abort/stop koşulları, blast radius limitleri, maintenance window'lar.

3. NASIL ÇALIŞIR? — TEKNİK MİMARİ, BILEŞENLER VE VERI AKIŞI

3.1 Deney döngüsü — Hipotezten bulguya

1. Define steady state: Hangi metric'leri normal kabul ediyorsunuz? (ör. p95 latency, error rate)
2. Formulate hypothesis: Deneyin beklenen etkisini açık bir hipotez olarak yazın.
3. Design experiment: Hangi hata enjekte edilecek? Hangi scope? Süre? Rollback planı?
4. Run experiment with safety guards: Otomatik abort, blast radius sınırlaması, canary hedefleri.
5. Measure and analyze: Steady state metric'lerini toplayın ve hipotezi doğrulayın/çürütün.
6. Remediate & learn: Bulunan zafiyetleri düzeltin, runbook güncelleyin ve tekrarlayın.

3.2 Tooling ve entegrasyon

Chaos deneyleri genelde şu araçlarla yapılır:

• Gremlin: Commercial, kullanıcı‑dostu arayüz ve güvenlik kontrolleri sunar; network, state, CPU, disk vs. enjeksiyonları destekler.
• Chaos Mesh / Litmus / KubeMonkeys: Kubernetes ilkeli open source projeler; pod kill, network partition, io stress gibi senaryoları native olarak çalıştırır.
• Chaos Monkey: Netflix'in açık kaynak aracı; instance/pod öldürme ile resilience testi yapar.
• Fault injection libraries / FaaS hooks: Uygulama seviyesinde hata enjeksiyonu için SDK'lar (örn. Istio fault injection, Envoy filters).

3.3 Metrik ve telemetri entegrasyonu

Deneyin güvenli ve anlamlı olması için telemetri altyapısıyla sıkı entegrasyon gerekir. OpenTelemetry, Prometheus, Grafana, Loki ve tracing backend'leri ile doğrudan veri toplayıp deney öncesi/sonrası korelasyon yapılmalıdır. Alerts ve SLO'lar deney sırasında otomatik olarak devre dışı bırakılmamalı; ancak noise azaltmak için deduplication veya temporary silencing uygulanabilir.

3.4 Safety mechanisms

Production'da kaos deneyleri yaparken şu güvenlik önlemleri zorunludur:

• Blast radius minimal olmalı — önce canary veya test tenant üzerinde deneyin.
• Abort koşulları tanımlı olmalı (ör. error rate > X, user impact > Y).
• Change window ve stakeholder onayı gerekmeli; otomatik rollback ve alerting entegre edilmelidir.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Netflix — Chaos Monkey ve otomasyon kültürü

Netflix, bulut altyapısında resiliency'yi arttırmak için Chaos Monkey'i geliştirip şirket kültürüne entegre etti. Amaç, "her zaman başarısızlık bekle" yaklaşımla sistemin otomatik olarak toleranslı olmasıdır. Netflix ekosisteminde kaos testleri sadece altyapı düzeyinde değil; deploy ve veri platformlarında da düzenli olarak uygulanır.

4.2 Amazon / AWS — GameDays ve Dependency Mapping

AWS ve büyük cloud sağlayıcıları, GameDay etkinlikleri ile ekiplerin incident response ve recovery pratiklerini test eder. Ayrıca dependency mapping (hizmet bağımlılık haritaları) kaos deneylerini odaklamada kullanılır; kritik bağımlılıklar öncelikli hedeflerdir.

4.3 Uber / Lyft — Traffic shaping ve throttling testleri

Ulaşım servisleri için kuyruğun, payment gateway'inin veya external API'lerin bozulması müşteri deneyimini hızla etkiler. Uber ve Lyft, trafik yönlendirme, degrade path ve graceful degradation senaryolarını kaos deneyleriyle test eder.

4.4 Finans ve regüle sektör — kontrollü ve audited deneyler

Finans kurumları için kaos deneyleri ekstra dikkat gerektirir: audit kayıtları, transactional integrity kontrolleri ve compliance onayı zorunludur. Bu sektörlerde genellikle sandbox/replicate ortamlarda, sonra carefully governed production canary'leriyle başlamaktadır.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Gerçek dünya senaryolarında sistem dayanıklılığını ve recovery path'lerini doğrular.
• Bağımlılıkları, SPOF'ları ve operational pain point'leri erkenden ortaya çıkarır.
• Incident response ekiplerinin gerçek zamanlı yeteneklerini test eder ve iyileştirir.

Sınırlamalar

• Yanlış tasarlanmış deneyler geniş çaplı müşteri etkileşimine neden olabilir.
• Operational overhead: deney yönetimi, izinler, telemetri entegrasyonu ve runbook güncellemeleri kaynak ister.
• Kültürel direnç: ekipler kaos testlerini risk olarak görebilir; değişim yönetimi gereklidir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

Production kullanımı

• Canary‑first yaklaşımı: önce staging ve canary hedeflerde çalıştırın; kademeli rollout ile production geneline yaygınlaştırın.
• Hypothesis driven experiments: her deney net bir hipotez, ölçüt ve başarısızlık kriteri içermeli.
• Change windows & approvals: kritik zamanlarda deney yapmayın; stakeholder onayı ve incident commander hazır olmalı.

Performans ve güvenlik

• Telemetri entegrasyonunu zorunlu kılın; deney öncesi/sonrası metric snapshot'larını otomatik toplayın.
• Blast radius'u minimize edin; tenant‑scope, region‑scope veya canary pod'lar kullanın.
• Deneyleri audit edin; kim, ne zaman, hangi parametrelerle çalıştırdı kaydı tutun.

Güvenlik ve governance

• Access control: deneyi başlatma yetkisi RBAC ile sınırlandırılmalı.
• Automated rollback ve abort kriterleri: anormal metric pattern'leri gözlemlenirse deney anında durdurulmalı.

Ölçeklenebilirlik

• Deney otomasyonunu CI/CD pipeline'a entegre edin; scheduled ve repeatable deneyler oluşturun.
• Experiment catalog tutun: geçmiş deneyler, sonuçlar, remediation ve runbook linkleri kaydedilsin.

8. SIK YAPILAN HATALAR

• Hipotez olmadan ad hoc hata enjeksiyonu — öğrenme sağlanmaz.
• Blast radius kontrolü yok — geniş kullanıcı kitlesine zarar verebilir.
• Telemetri eksikliği — deney sonuçlarını yorumlamak imkansızlaşır.
• Stakeholder iletişimi eksik — operasyonel sürprizler ve güven kaybı.

9. GELECEK TRENDLER

1. AI destekli deney tasarımı: ML modelleri risk analizi yapıp hangi deneylerin en fazla bilgi getireceğini önermeye başlayacak.
2. Autonomous resilience: Kaos sonuçlarına göre otomatik remediation playbook'larının tetiklenmesi ve self‑healing pattern'lerinin yaygınlaşması.
3. Policy as code & safe experiments: Deney politikalarının koda dönüştürülmesiyle governance otomatikleşecek ve denetim kolaylaşacak.
4. Edge/IoT kaos testi: Uç cihazlarda offline‑friendly kaos senaryoları ve senkronizasyon testleri artacak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. Kaos mühendisliğine nereden başlamalıyım?

   Önce küçük başlayın: staging ortamında basit pod kill veya latency injection deneyleriyle başlayın. Steady state metric'lerinizi tanımlayın ve hipotez geliştirin.

2. 2. Production'da kaos güvenli midir?

   Güvenlik önlemleri (blast radius, abort koşulları, stakeholder onayı) alındığında kontrollü production deneyleri mümkündür. Ancak her zaman canary ve staging aşamalarından geçmek en güvenli yaklaşımdır.

3. 3. Hangi metric'leri izlemeliyim?

   Success rate, latency (p95/p99), error budget, queue depth, downstream latency ve business metric'ler (conversion rate) önceliklidir.

4. 4. Kaos deneyleri hangi sıklıkla yapılmalı?

   Süreklilik esastır: haftalık veya aylık scheduled deneyler ile sistem sürekli test edilmelidir. Ayrıca kritik değişiklik sonrası otomatik deneyler tetiklenebilir.

5. 5. Blast radius nasıl belirlenir?

   Önce canary ve tenant‑scope deneyler yapın; etki tahmini metrikleri (kullanıcı sayısı, transaction share) ile blast radius'u sınırlandırın.

6. 6. Hataları nasıl raporlarım?

   Experiment catalog'ında hipotez, metrikler, sonuçlar, remediation ve runbook güncellemeleri açıkça dokümante edilmeli; postmortem benzeri öğrenme dökümü tutulmalıdır.

7. 7. Kaos mühendisliği için hangi araçları önerirsiniz?

   Başlangıç için Chaos Mesh veya Litmus (Kubernetes), sonra Gremlin gibi enterprise araçları değerlendirebilirsiniz. Tool seçimi altyapı, güvenlik ve bütçe ile belirlenmelidir.

8. 8. Kaos mühendisliği kültürü nasıl yayılır?

   Leadership desteği, düzenli GameDay etkinlikleri, blameless öğrenme kültürü ve runbook'ların paylaşılmasıyla kaos pratiği organizasyon geneline yayılır.

Anahtar Kavramlar

Steady State

Sistemin normal çalışma koşullarında gösterdiği davranış ve metric aralığı.

Blast Radius

Bir deneyin etkileyeceği kullanıcı veya sistem yüzeyinin büyüklüğü.

Hypothesis

Deneyin beklenen etkilerini açıkça belirten test edilebilir iddia.

Abort Criteria

Deneyin otomatik olarak durdurulmasını sağlayan güvenlik eşikleri (ör. error rate threshold).

Experiment Catalog

Geçmiş deneylerin, sonuçların ve öğrenimlerin kayıtlı olduğu merkezi depo.

Öğrenme Yol Haritası

1. 0–1 ay: Kaos mühendisliğinin temel kavramlarını öğrenin; küçük bir staging deneyini tasarlayıp çalıştırın.
2. 1–3 ay: Canary testleri, controlled blast radius, runbook güncelleme ve telemetri entegrasyonunu uygulayın.
3. 3–6 ay: Scheduled GameDay etkinlikleri, workflow otomasyonu ve experiment catalog kurma üzerine çalışın.
4. 6–12 ay: Production canary'leri, AI‑assisted risk analizleri, policy as code ve autonomous remediation pattern'leri deneyin.