Chaos Engineering Nedir? Tanım, Amaç ve Modern Kurumsal Bağlam
Chaos engineering, üretim ortamına benzeyen sistemlere kontrollü arıza (failure) enjekte ederek bu sistemlerin türbülansa karşı dayanıklılığına olan güveni artırmayı amaçlayan disiplinli bir mühendislik pratiğidir. 2010 yılında Netflix’in dağıtık AWS migrasyonu sırasında Chaos Monkey aracını duyurmasıyla popülerleşen yaklaşım, 2026 itibarıyla CNCF radarında “graduated/incubating” düzeyinde araçları, Fortune 500 SRE ekiplerinin standart koşum kitlerini ve finans/telco düzenleyici denetim raporlarının resilience kanıt sayfasını besliyor. Bir başka deyişle “chaos engineering nedir” sorusunun 2026 cevabı tek cümlede şudur: üretim güvenini, varsayım yerine deneyle ölçen sistematik bir resilience disiplini.
Pratikte chaos engineering bir test değil bir hipotez doğrulama çerçevesidir. SRE ekibi “node ölürse pod 30 saniyede başka node’a kayar, p95 latency 250 ms altında kalır” gibi nicel bir hipotez kurar, deneyi minimum blast radius ile çalıştırır, telemetriyi karşılaştırır ve hipotez çürürse runbook/SLO/mimari güncellenir. CNCF Annual Survey 2024’e göre kuruluşların yaklaşık %44’ü üretimde en az bir chaos deneyi koştuğunu beyan ederken, Gremlin “State of Chaos Engineering 2024” raporunda haftalık deney koşan ekiplerin MTTR’ı 11 dakika altı seviyeye çekebildiği rapor ediliyor. Ömer Önal olarak yürüttüğüm SRE danışmanlığı görevlerinde, üretimde resilience kanıtı isteyen finans ve e-ticaret müşterilerinin %70’ten fazlasının chaos engineering programına 6 ay içinde geçtiğini gözlemliyorum.
Modern chaos engineering 4 katmana yayılır: infrastructure chaos (node kill, AZ blackhole), platform chaos (Kubernetes pod delete), application chaos (HTTP 500 inject, latency 800 ms) ve dependency chaos (DNS fail, Kafka partition loss). Bu yazı LitmusChaos ile Gremlin başta olmak üzere temel araçları, deney metodolojisini ve 90 günlük adoption planını veriyle anlatıyor.
Chaos Engineering’in 5 İlkesi ve “Principles of Chaos” Manifestosu
2015’te principlesofchaos.org üzerinden yayımlanan ve halen güncel kabul edilen 5 ilke chaos engineering literatürünün omurgasıdır. Sırasıyla: (1) Steady-state davranış üzerinden hipotez kur, (2) Gerçek dünya olaylarını çeşitlendir, (3) Deneyleri üretim ortamında çalıştır, (4) Deneyleri sürekli (continuous) otomatikleştir, (5) Blast radius’u minimize et. Manifestoyu yorumlarken 2026 perspektifinde önemli olan nokta, “üretimde koş” maddesinin “kontrol altında, gözetimli, abort-edilebilir bir blast radius ile koş” şeklinde olgunlaşmış olmasıdır; senior ekipler bile deneylerin %80’inden fazlasını staging’de prova ediyor ve sadece doğrulanmış senaryoları üretime taşıyor.
Steady-state’i tanımlarken business KPI tercih edilir: ödeme platformu için “saniyede başarılı tx >= 120”, ad-tech için “bid response < 80 ms". Sadece CPU/memory metriği seçmek prensibin ruhuna aykırıdır. Aşağıdaki tablo 5 ilkeyi pratik uygulama, sık yapılan hata ve önerilen telemetri ile özetler.
| İlke | Pratik Uygulama | Sık Yapılan Hata | Önerilen Telemetri |
|---|---|---|---|
| Steady-state hipotez | Business KPI bazlı SLO eşiği | Sadece infrastructure metric | Prometheus + RUM + iş loglari |
| Gerçek dünya olayı | AZ blackhole, DNS NXDOMAIN | Sadece pod kill ile sınırlı kalmak | Cloud event injection traces |
| Üretimde koş | Canary cluster + feature flag | Tüm trafiğe deney | Distributed tracing, error budget |
| Sürekli otomasyon | CI’ye chaos step ekle | Yılda 1 GameDay | Argo Workflows + Litmus probe |
| Min blast radius | %1 trafik, region scoped | Cluster-wide pod delete | Halt conditions, kill switch |
İlkeleri uygulayan ekiplerin Resilience Maturity Model üzerinde 4 seviyede ilerlemesi beklenir: Ad-hoc, Reactive, Proactive, Continuous. Bu modeli benimsemek için Cloud-Native Mimari yazısındaki SLO katmanlandırması ile başlayıp GitOps Kubernetes üzerinden deney koşum hattını otomatikleştirmek pratik yoldur.
LitmusChaos: CNCF Incubating Açık Kaynak Chaos Platformu
LitmusChaos, MayaData (şimdi ChaosNative) tarafından geliştirilen, 2020’de CNCF’ye sandbox olarak kabul edilen ve 2022 yılında incubating seviyeye yükseltilen Kubernetes-native chaos engineering platformudur. GitHub’da yaklaşık 4.5K star, 60’ı aşkın aktif maintainer ve 400+ ChaosHub deneyi ile açık kaynak ekosistemin referans aracıdır. Litmus 3.x mimarisi 4 ana bileşenden oluşur: ChaosCenter (Web UI + GraphQL), ChaosAgent (target cluster sidecar), ChaosExperiment CRD’leri (Kubernetes custom resource) ve Litmus Probe sistemi (deney sırasında SLO doğrulama).
Litmus’un kurumsal cazibesinin temel sebebi tamamen açık kaynak, ücretsiz olması ve Kubernetes API’sine native entegrasyonudur. ChaosSchedule CRD’si ile otomatik deney, Argo Workflows ve GitHub Actions ile pipeline entegrasyonu, OpenTelemetry uyumlu observability hook’ları ve RBAC tabanlı multi-tenancy sağlar. ChaosHub içinde 80+ hazır deney bulunur: pod-delete, node-drain, network-loss, http-latency, aws-az-blackhole, kafka-broker-pod-failure.
Aşağıdaki tablo Litmus 3.x’in temel özelliklerini kurumsal SRE perspektifinden özetler. CNCF/GitHub kaynaklarına göre yaklaşık değerler 2025 sonu verisidir.
| Özellik | Litmus 3.x Durumu | Notlar |
|---|---|---|
| Lisans | Apache 2.0 | Tamamen açık kaynak |
| CNCF seviyesi | Incubating (2022+) | Sandbox değil, olgun |
| Deploy modeli | Helm chart, Operator pattern | kubectl apply ile 10 dk kurulum |
| Hazır deney sayısı | 80+ (ChaosHub) | Topluluk + ChaosNative katkıları |
| UI | ChaosCenter React SPA | GraphQL backend |
| RBAC | Proje + ortam izolasyonu | Multi-team kullanıma uygun |
| SLO probe | HTTP, Prometheus, Cmd, K8s probe | Hipotez otomatik doğrulama |
| Cost | Sıfır lisans, sadece infra | Self-host pod ~0.5 vCPU/512 MB |
Litmus’un en güçlü tarafı workflow kavramıdır: ChaosWorkflow CRD’si birden fazla deneyi zincirler ve resilience skorunu yüzde olarak raporlar. Örnek bir ödeme servisi için 6 haftada %62’den %89’a çıkan skor, mimari iyileştirmenin somut kanıtıdır. Kubernetes Operator deseni Litmus’un mimari temelini oluşturur.
Gremlin: Ticari Chaos-as-a-Service Lideri
Gremlin 2016’da Netflix ve Amazon eski mühendisleri Kolton Andrus ve Matthew Fornaciari tarafından kurulan, kurumsal pazarın en olgun ticari chaos platformudur. SaaS modeli ile çalışır; müşteri kendi altyapısına Gremlin Agent (Linux daemon veya Kubernetes DaemonSet) kurar, kontrol düzlemi app.gremlin.com üzerinden yönetilir. Gremlin’in 2024 müşteri portföyünde Twilio, Mailchimp, Salesforce, US Bank ve TransUnion gibi Fortune 500 markaları yer alır; toplam yatırım miktarı 75 milyon doları aşmıştır.
Gremlin’in farkı sadece arıza enjeksiyonu değil, Reliability Management dediği bütünleşik resilience programıdır. Platform 3 ana modül sunar: Chaos Engineering (attack library, blast radius controller), Detected Risks (SPOF, missing health check auditing), Reliability Score (servis bazında 0-100 skor). Attack library 13 kategoriye yayılır: CPU, memory, IO, disk, shutdown, time travel, DNS, latency, packet loss, blackhole, process killer, container shutdown, Kubernetes-specific.
Lisans modeli per host tabanlıdır; tipik kurumsal anlaşma yaklaşık 8.000-12.000 USD/yıl başlangıç tier’ı ile başlar. Gremlin vaka çalışmalarında müşteriler MTTR’da ortalama %40-65 düşüş, üretim incident sayısında %30-50 azalma rapor ediyor. Aşağıdaki tablo temel attack kategorilerini gösterir.
| Attack Kategorisi | Tipik Senaryo | Risk Seviyesi | Tavsiye Edilen Süre |
|---|---|---|---|
| CPU | Autoscaler tetiklemesi doğrulama | Düşük | 3-5 dk |
| Memory | OOMKill ve restart davranışı | Orta | 5-10 dk |
| Latency | p95 SLO dayanıklılık testi | Orta | 10-15 dk |
| Packet Loss %5-30 | Retry/circuit breaker doğrulama | Orta-Yüksek | 5-8 dk |
| Blackhole | Dependency outage simülasyonu | Yüksek | 2-5 dk |
| Shutdown | HA failover testi | Yüksek | 1-2 dk |
| Time Travel | Sertifika expiry, TZ bug | Yüksek | 15-30 dk |
| Process Killer | Pod restart loop davranışı | Düşük-Orta | 1 dk |
Gremlin’in Halt Conditions özelliği prensip 5’i somut bir mühendislik kontrolüne dönüştürür: Datadog/PagerDuty alarm eşiği aşarsa deney otomatik durur ve sistem geri yüklenir.
LitmusChaos vs Gremlin: Kurumsal Karar Matrisi
SRE liderleri LitmusChaos ile Gremlin arasında seçim yaparken 6 boyutta değerlendirme yapar: maliyet, operational overhead, destek SLA, denetim/regülatif evidence, deney genişliği ve multi-cluster yönetimi. Litmus self-host olduğundan TCO düşük ama platform ekibinin sürekli bakımı gerekir; Gremlin SaaS modeliyle TCO yüksek ama bakım yükü minimaldir. Finans sektörü genellikle Gremlin’in audit log + SOC 2 raporlarını tercih ederken, scale-up’lar Litmus’un esnekliğini öne çıkarır.
| Kriter | LitmusChaos | Gremlin |
|---|---|---|
| Model | Self-host açık kaynak | SaaS ticari |
| Tipik yıllık maliyet | ~3.000-8.000 USD (infra+1 SRE) | ~8.000-50.000 USD (host’a göre) |
| Kurulum süresi | 1-2 gün (Helm + entegrasyon) | 30 dk (agent kurulumu) |
| Deney sayısı | 80+ ChaosHub + custom | 13 kategori, ince granül |
| Multi-cloud | Native (Kubernetes her yerde) | Native (Linux/K8s agent) |
| SLO probe | Built-in (HTTP/Prom/Cmd) | Halt conditions + Datadog |
| Audit/SOC 2 | Kullanıcı sorumluluğunda | SOC 2 Type II |
| Destek SLA | Topluluk + ChaosNative paid | 7/24 enterprise SLA |
| API/CLI | kubectl + GraphQL | Web + REST + CLI |
| Pipeline entegrasyon | Argo, Tekton, GitHub Actions | Jenkins, GitHub, GitLab, Spinnaker |
Karar çerçevesi olarak şu kurallar pratikte iyi çalışır:
- Avantaj (Litmus): Sıfır lisans, GitOps native, custom CRD ile sınırsız extension.
- Dezavantaj (Litmus): UI olgunluğu Gremlin’in gerisinde, denetim için ek tooling şart.
- Ne zaman seç (Litmus): Tek tip Kubernetes-only stack, içe dönük platform ekibi, açık kaynak kültürü.
- Avantaj (Gremlin): 30 dk’da değer üretir, kurumsal raporlama hazır, halt condition güvenliği.
- Dezavantaj (Gremlin): Lisans maliyeti, vendor lock-in, on-prem hibrit karmaşıklığı.
- Ne zaman seç (Gremlin): Finans/sigorta/regülatif sektör, hibrit Linux+K8s ortam, hızlı time-to-value.
Çok bulutlu mimaride araç seçimi karmaşıklaşır: AWS+GCP+Azure üçlüsünde Litmus’un Kubernetes-native modeli daha homojen, hibrit datacenter+cloud’da Gremlin agent yaklaşımı daha pürüzsüzdür.
Chaos Engineering Ekosisteminin Geri Kalanı: AWS FIS, Chaos Mesh, Steadybit, Azure Chaos Studio
Litmus ve Gremlin dışında 4 ana alternatif var. AWS Fault Injection Service (FIS) EC2, ECS, EKS, RDS üzerinde IAM ile entegre arıza enjeksiyonu sunar; aylık maliyet 50-500 USD aralığında. Chaos Mesh PingCAP’ın geliştirdiği CNCF incubating Kubernetes-native açık kaynak araçtır. Steadybit Gremlin’in Avrupa rakibidir, GDPR uyumlu data residency sunar. Azure Chaos Studio AKS, Service Bus, Cosmos DB için tek tık deney verir.
| Araç | Tip | Best Fit | Tipik Aylık Maliyet |
|---|---|---|---|
| LitmusChaos | OSS K8s native | Çok kümeli Kubernetes | ~250-700 USD (infra) |
| Gremlin | SaaS ticari | Hibrit Linux+K8s, finans | ~700-4.200 USD |
| Chaos Mesh | OSS K8s native | TiDB / Çin ekosistemi | ~200-600 USD (infra) |
| AWS FIS | Cloud-native | AWS-only stack | ~50-500 USD |
| Steadybit | SaaS ticari | AB merkezli, GDPR ağırlıklı | ~600-3.500 USD |
| Azure Chaos Studio | Cloud-native | Azure-only stack | ~80-700 USD |
Bu araç seçimini yaparken FinOps Bulut Maliyet perspektifinden bütçe tavanı koymak pratik bir yaklaşımdır. Resmi vendor dokümantasyonu için AWS Fault Injection Service docs ve Azure Chaos Studio docs referans alınmalıdır.
Deney Tasarımı: GameDay’den Sürekli Chaos’a 5 Adımlı Metodoloji
GameDay ile continuous chaos arasındaki fark sık karıştırılır. GameDay 2-4 saatlik tatbikattır: ekipler senaryoyu (örn. “us-east-1 AZ-a kaybedildi”) elle koşturur, runbook’u gözlemler, retrospektif yapar. Continuous chaos ise CI/CD’ye gömülü, otomatik halt condition’lı, self-evaluating deney akışıdır. Olgun programlar ikisini birlikte kullanır: ayda 1 GameDay + haftalık 5-15 continuous deney.
Etkili bir deneyin tasarım iskeleti 5 adımdır:
- Steady-state tanımı: “Checkout başarı oranı 5 dakikalık pencerede >= %99.5”.
- Hipotez: “Redis master kaybolursa sentinel 15 saniyede failover yapar ve başarı oranı düşmez”.
- Blast radius: “Sadece staging cluster + canary %5 trafik”.
- Deney koşumu: 10 dakika boyunca Redis master pod delete, her 30 sn’de bir SLO probe.
- Sonuç ve aksiyon: Hipotez doğru çıkarsa runbook’a kaydet; çürüdüyse Jira ticket + mimari iyileştirme.
Bu metodoloji CI/CD Pipeline Kurulumu içine entegre edildiğinde her release sonrası otomatik resilience doğrulaması mümkün olur. PR merge → staging deploy → smoke test → chaos suite → canary promote zinciri SRE olgunluğunun altın standardıdır.
| Deney Tipi | Hedef SLO | Tipik Blast Radius | Otomasyon Önceliği |
|---|---|---|---|
| Pod delete | Pod restart < 30 s | 1 namespace, 1 deploy | Yüksek (CI’de günlük) |
| Network latency 300 ms | p95 < 800 ms | %5 canary | Orta (haftalık) |
| AZ blackhole | Failover < 90 s | 1 AZ, off-peak | Düşük (aylık GameDay) |
| DNS NXDOMAIN | Retry + circuit break | 1 namespace | Orta (haftalık) |
| Disk full %95 | Eviction + alert | 1 node | Orta (haftalık) |
| Time skew +5 dk | JWT + cert valid | 1 pod | Düşük (aylık) |
Service mesh kullanan ekipler için Envoy HTTP fault injection filter, uygulama kodu değiştirilmeden retry/timeout politikalarını test eder. Network policy katmanı ile birleştirildiğinde “policy ihlali simülasyonu” gibi güvenlik+resilience kesişimi deneyler tasarlanabilir.
Üretimde Chaos: Blast Radius, Kill Switch ve Regülatif Gereksinimler
Üretimde chaos engineering “vahşice deney yapmak” değil, en katı emniyet protokolleriyle çalışan kontrollü mühendisliktir. 2026’da finans, sağlık ve telco sektörlerinde DORA, TIBER-EU, ISO 22301 ve NIST SP 800-160 Vol. 2 resilience kanıtı talep ediyor. AB bankalarının DORA Article 25-26 kapsamında “advanced testing” kanıt sayfalarını yıllık tutması bekleniyor; chaos engineering artık “nice to have” değil “compliance enabler” konumunda.
Üretim chaos için 6 koruma katmanı zorunludur:
- Feature flag: Deney instant disable; LaunchDarkly/Unleash benzeri tool gerek.
- Halt condition: Datadog/Prometheus alarm tetiklenirse otomatik durdurma.
- Blast radius limiti: <%5 trafik, single AZ, single namespace.
- Saat penceresi: Off-peak (örn. salı 02:00-04:00 UTC).
- RBAC + audit log: Kim, ne zaman, hangi deneyi koştu kaydı.
- İletişim: Slack #chaos-engineering kanalına auto-announcement.
Container güvenliği ve DevSecOps pratiklerinin kesişimi 2025’ten itibaren “security chaos engineering” alt disiplinini doğurdu. IAM token süresi düşürme, KMS rotation hatası, log shipping kaybı gibi deneyler IR ekibinin tatbikatlarını besler.
| Regülatif Çerçeve | Bölge/Sektör | Chaos İle İlgili Madde | Beklenen Kanıt |
|---|---|---|---|
| DORA | AB, finans | Art. 24-26 advanced testing | Yıllık chaos report |
| ISO 22301 | Global, BCM | Clause 8.5 exercise & test | BC test logs |
| NIST SP 800-160 Vol. 2 | ABD, federal | Adverse condition testing | Resilience assessment |
| TIBER-EU | AB, kritik altyapı | Red team + scenario | Scenario test rapor |
| PCI DSS v4.0 | Ödeme sistemleri | Req. 11.4 / IR test | IR drill kanıtı |
| SOC 2 Type II | Global, SaaS | CC7.5 — sistem dayanıklılığı | Audit trail |
CNCF tarafından yayımlanan CNCF Chaos Engineering Whitepaper üretim chaos için 12 adımlı bir adoption framework önerir; bu doküman compliance ekipleriyle teknik tartışmalar için ortak dildir.
Observability, SLO ve Resilience Score: Chaos’tan Karar Üretmek
Chaos deneylerinin değeri ürettiği kararla ölçülür. Deney sonrası 4 olası çıktı vardır: hipotez doğrulandı, çürüdü, belirsiz veya abort. Her durumda aksiyon önceden tanımlanmalı; aksi halde chaos “ilginç gözlem üreten ama runbook’a dönüşmeyen” hobi olur. Olgun ekipler her deneyi Resilience Decision Log tablosunda izler.
Observability tarafında 3 katman zorunludur: metric (Prometheus/Datadog), logs (Loki/Elastic), traces (Jaeger/Tempo). OpenTelemetry (CNCF graduated) chaos deneylerini özel span olarak işaretler — “Redis chaos sırasında p95 artışı” gibi sorgular granular cevap verir.
| Telemetri Katmanı | Önerilen Stack | Chaos Sırasında Kritik Sorgu |
|---|---|---|
| Metric | Prometheus + Grafana | p95 latency, error rate, RPS |
| Logs | Loki / Elastic | 5xx burst, OOMKill events |
| Traces | Jaeger / Tempo | Slow span detection |
| RUM | Datadog RUM / Sentry | Frontend error spike |
| Business | Custom Prom metrics | Checkout success rate |
| Audit | Litmus events / Gremlin API | Deney kim/ne zaman koştu |
Uygulanabilir KPI seti: Chaos Coverage, Resilience Score, MTTR Trend, Discovered Risks, Time-to-Fix. Bu metriklerin executive dashboard’unda izlenmesi bütçe savunmasında belirleyicidir; Kubernetes cost optimizasyon metrikleri ile birleştirilirse “resilience ROI” hikayesi tam oluşur.
Performans, Maliyet ve Adoption Yol Haritası: 90 Günlük Plan
Chaos programını 0’dan kurmak için tipik 90 günlük yol haritası: Hafta 1-2 sponsor ve hedef servis seçimi, Hafta 3-4 tooling kurulumu + ilk staging deneyi, Hafta 5-8 halt condition + observability + runbook, Hafta 9-12 üretim canary + ilk GameDay + executive dashboard.
Maliyet tarafında tipik bir 100 microservice, 500 node Kubernetes ortamı için yıllık chaos bütçesi:
- Tooling: Litmus self-host ~6.000 USD/yıl (infra), Gremlin ~25.000 USD/yıl (mid-tier), AWS FIS ~3.500 USD/yıl.
- Mühendis efor: 1 SRE %30 zaman = ~45.000 USD/yıl.
- Observability: Datadog/NewRelic chaos modülü ~10.000-20.000 USD/yıl.
- Eğitim: 2 günlük workshop + GameDay facilitator ~8.000 USD/yıl.
- Toplam: Yıllık ~70.000-100.000 USD; tipik kurumsal incident maliyetinin (saatlik 100.000-500.000 USD) bir incident’inden az.
AWS Well-Architected Reliability Pillar ve CNCF Annual Survey 2024 rehberdir. Edge mimarilerde failure domain daha dağıtık olduğu için chaos zorunludur; Docker/Kubernetes temel pratiklerinin oturmuş olması programın ön koşuludur.
| Hafta | Aktivite | Çıktı | Sorumlu |
|---|---|---|---|
| 1-2 | Sponsor + ekip + servis seçimi | Charter dokümanı | SRE Lead |
| 3-4 | Tool kurulumu, ilk deney | Pod-delete staging | Platform |
| 5-6 | 5 deney, probe, runbook | Resilience score v1 | SRE + Dev |
| 7-8 | Halt condition, on-call drill | Auto-abort kuralları | SRE + Ops |
| 9-10 | İlk canary chaos prod | Üretim deneyi raporu | SRE Lead |
| 11-12 | GameDay + exec report | KPI dashboard live | SRE + CTO |
Sıkça Sorulan Sorular
Chaos engineering ile load testing arasındaki fark nedir?
Load testing sistemin kapasitesini ölçer (kaç RPS dayanır), chaos engineering ise arıza karşısındaki dayanıklılığını ölçer (bir bileşen bozulduğunda steady-state korunur mu). İkisi tamamlayıcıdır; bir SRE programı her ikisini de pipeline’da çalıştırmalıdır. Load test “ne zaman kırılır?” sorusuna, chaos engineering “kırılınca ne olur?” sorusuna cevap verir.
LitmusChaos’u üretim ortamında kullanmak güvenli mi?
Evet, doğru yapılandırıldığında güvenlidir. Üretim kullanımı için 4 koşul önerilir: RBAC ile namespace izolasyonu, ChaosResultProbe ile SLO doğrulama, ChaosSchedule içinde halt condition, ve audit log’ların SIEM’e ihracı. Önce staging’de en az 4 hafta deney koşmuş olmak iyi bir teamülldür. Düzenleyici ortamda DORA/SOC 2 uyumluluğu için Gremlin’in audit-ready raporları tercih edilebilir.
Gremlin’in fiyatlandırması nasıl çalışıyor?
Gremlin per-host SaaS modeli ile çalışır; tipik kurumsal anlaşma yaklaşık 8.000 USD/yıl başlangıç tier’ı ile başlar ve host (sunucu veya Kubernetes node) sayısına göre artar. Detected Risks ve Reliability Score modülleri ayrı tier’larda olabilir. Resmi rakam için Gremlin sales ekibi ile özel teklif sürecine girmek gerekir; kamuya açık fiyat liste yayımlanmaz.
Chaos deneyi sırasında bir incident olursa kim sorumlu?
Standart pratik: deney sahibi SRE incident’in birinci sorumlusudur; ancak deney charter dokümanında onay zinciri (SRE Lead + Service Owner + Security) belirtildiyse sorumluluk paylaşımlıdır. Halt condition tetiklenip otomatik geri yükleme başarılıysa incident “minor” sınıflandırılır. Postmortem her zaman blameless olmalı; öğrenme runbook iyileştirmesi ve mimari ticket’ı ile sonuçlanmalıdır.
Küçük bir startup chaos engineering’e ne zaman başlamalı?
Pratik eşik: en az 10 microservice, 1 SRE/Platform mühendis ve %99.9 SLO commit edilmiş müşteri sözleşmeleri olduğunda. Bu seviyeye gelmemiş ekipler için AWS FIS veya Litmus ile haftada 1 saatlik düşük yoğunluklu deney yeterlidir. Asıl yatırım, organizasyon 50+ mühendis ve üretimde gerçek müşteri trafiği olduğunda yapılır.
Sonuç
Chaos engineering 2026’da artık silikon vadisi merakı değil, finans regülasyonlarının ve kurumsal SLA’larının zorunlu kıldığı bir resilience disiplinidir. LitmusChaos açık kaynak, GitOps-native ve Kubernetes ağırlıklı modern stack’ler için en uygun aday iken, Gremlin hibrit Linux+K8s, audit-ready ve hızlı time-to-value arayan kurumsal müşteriler için lider tercihtir. AWS FIS, Azure Chaos Studio, Chaos Mesh ve Steadybit ise belirli ekosistem ve coğrafya koşullarında değerli alternatiflerdir.
Karar çerçevesi şudur: (1) Ekosistem tek tip Kubernetes ve platform ekibi varsa Litmus ile başla; (2) Finans/sigorta/regülatif yoğun bir sektördeysen ve hibrit altyapın varsa Gremlin’i tercih et; (3) AWS/Azure-only ortamlardaysan cloud-native FIS/Chaos Studio ile MVP kur, sonra olgunlaştıkça Litmus/Gremlin’e geçişi değerlendir. Hangi araç seçilirse seçilsin, 5 ilke + halt condition + observability + runbook üçgeni atlanırsa chaos programı değer üretmez.
Kurumsal bir chaos engineering programı için sıfırdan tooling seçimi, 90 günlük roadmap, GameDay tasarımı ve compliance evidence kurgusu yapmak için omeronal.com/iletisim üzerinden danışmanlık talebi iletebilir, ekibinize özel bir resilience yol haritası hazırlatabilirsiniz. Üretimde güveni varsayım değil deneyle ölçen ekiplerin uzun vadede hem MTTR’ı düştüğünü hem de mimari kararlarının çok daha hızlı doğrulandığını net olarak görüyorum.
Ömer ÖNAL
Mayıs 16, 2026DevOps danışmanlık projelerinde gözlemlediğim bir pattern: kuruluşlar pipeline’a yatırım yapmadan önce mevcut deployment frequency ve change failure rate metriklerini ölçmüyor. Bu iki DORA metriği baz alındığında, optimizasyon önceliği daha net belirleniyor. Aksi takdirde yatırım kararı sezgisel kalıyor. Yorumlarınızı bekliyorum.