Kaos Mühendisliği ve SRE Mimarisi

Modern bulut bilişim dünyasında mikroservis mimarileri, çok bölgeli (multi-region) Kubernetes kümeleri, içerik dağıtım ağları (CDN) ve üçüncü parti API bağımlılıkları bir araya geldiğinde, hiçbir dağıtık sistemin %100 oranında hatasız çalışması fiziksel olarak mümkün değildir. Donanım diskleri bozulur, fiber optik kablolar kopar, DNS yönlendirmeleri gecikir, beklenmedik trafik sıçramaları veritabanı bağlantı havuzlarını tüketir ve yazılım güncellemeleri öngörülemeyen sınır durumlarını (edge cases) tetikler. Geleneksel sistem yöneticiliği yaklaşımı arızaların hiç yaşanmaması için dua etmeye ve arıza çıktığında yangın söndürmeye odaklanırken; Google tarafından literatüre kazandırılan Site Güvenilirlik Mühendisliği (Site Reliability Engineering - SRE) ve Netflix'in öncülük ettiği Kaos Mühendisliği (Chaos Engineering), arızayı kaçınılmaz bir doğa yasası olarak kabul edip sistemleri bu arızalara karşı bağışıklık kazanacak şekilde tasarlama disiplinidir.

Kurumsal ölçekli uygulama ve yazılım sistemlerinde "yüksek erişilebilirlik" (High Availability - HA) yalnızca sunucu sayısını artırmakla elde edilemez; ölçülebilir güvenilirlik hedefleri (SLI, SLO, SLA), matematiksel bir Hata Bütçesi (Error Budget) yönetimi ve üretim ortamında kontrollü hata enjeksiyonu deneyleri gerektirir. Bu kapsamlı mühendislik rehberinde; SRE felsefesinin temel yapı taşlarını, "Dört Dokuz" (%99.99) erişilebilirlik matematiğini, Chaos Monkey ve LitmusChaos ile uygulanan kaos deneylerini, devre kesici (Circuit Breaker) desenlerini ve suçlamasız olay sonrası analiz (Blameless Postmortem) kültürünü tüm teknik derinliğiyle inceliyoruz.

1. Site Güvenilirlik Mühendisliği (SRE) Nedir? DevOps ile Arasındaki İlişki

2003 yılında Google'da Ben Treynor Sloss tarafından kurulan ilk SRE ekibi, temel bir soruya yanıt arıyordu: "Bir yazılım mühendisi ekibinden bir operasyon ve sistem yönetimi birimi kurmasını isteseydik, bunu nasıl inşa ederlerdi?" Klasik BT organizasyonlarında yazılım geliştiriciler (Developers) yeni özellikleri olabildiğince hızlı canlıya almak isterken, sistem operasyon ekipleri (Operations) sistemin bozulmaması için değişikliklere direnç gösterirdi. Bu yapısal çıkar çatışması, kurum içinde hız ile kararlılık (velocity vs. stability) arasında kronik bir gerilim yaratıyordu.

DevOps kültürü bu duvarları yıkmak için "ne yapılması gerektiğini" (silo kültürünü kaldırmak, otomasyon, paylaşılan sorumluluk) tanımlarken, SRE (Site Reliability Engineering) DevOps felsefesinin somut mühendislik kurallarıyla uygulanmış bir sınıfı (class SRE implements DevOps) olarak konumlanır. SRE disiplininin temel ilkeleri şunlardır:

• Operasyonları Bir Yazılım Problemi Olarak Görmek: Manuel müdahale gerektiren, tekrarlayan, otomatize edilebilir ve kalıcı mühendislik değeri üretmeyen operasyonel işlere Angarya (Toil) adı verilir. SRE standardına göre bir mühendisin zamanının en fazla %50'si operasyonel angaryaya ve nöbet (on-call) müdahalelerine ayrılabilir; kalan en az %50'lik zaman mutlaka otomasyon yazılımları geliştirmeye ve mimari iyileştirmelere harcanmalıdır.
• %100 Güvenilirliğin Yanlış Hedef Olduğunu Kabul Etmek: Bir sistemi %99.99'dan %99.999'a çıkarmak eksponansiyel bir altyapı maliyeti gerektirir ve yeni özellik geliştirme hızını neredeyse sıfıra indirir. Üstelik son kullanıcının evindeki Wi-Fi bağlantısı veya mobil operatörü zaten %99.9 seviyesinde çalışıyorsa, sunucu tarafında %100 güvenilirlik için harcanan milyonlarca dolar kullanıcı tarafından hissedilmez bile.

2. Güvenilirliğin Ölçümü: SLI, SLO ve SLA Kavramlarının Kesin Ayrımı

Bir sistemin "güvenilir" veya "hızlı" olduğunu söylemek mühendislik açısından hiçbir anlam ifade etmez; güvenilirlik sayısal metriklerle tanımlanmalıdır. SRE mimarisinde bu ölçüm üç katmanlı bir hiyerarşiyle yapılır:

A. SLI (Service Level Indicator - Hizmet Seviyesi Göstergesi)

Sistemin sağlığını kullanıcı gözüyle ölçen, kesin olarak tanımlanmış nicel bir metriktir. SLI oluşturulurken genellikle "Başarılı Olay Sayısı / Toplam Geçerli Olay Sayısı × 100" formülü kullanılır. En yaygın SLI türleri şunlardır:

• Erişilebilirlik (Availability): HTTP 5xx sunucu hatası döndürmeyen başarılı API yanıtlarının tüm geçerli HTTP isteklerine oranı.
• Gecikme Süresi (Latency): Ortalamalar (average/mean) yanıltıcı olduğu içinSRE'de her zaman yüzdelik dilimler (percentiles - p95, p99, p99.9) kullanılır. Örneğin: "Ödeme API'sine gelen isteklerin p99 gecikme süresi (yani en yavaş %1'lik kuyruk hariç tamamı) 250 milisaniyenin altında yanıtlanmalıdır."
• Veri Tazeliği ve Doğruluk (Freshness & Correctness): Veri işleme hatlarında (data pipelines) verinin kaynağa yazılmasından analitik sorgularda görünür olmasına kadar geçen süre.

B. SLO (Service Level Objective - Hizmet Seviyesi Hedefi)

Bir SLI metriğinin belirli bir zaman penceresi (genellikle 28 gün veya 30 günlük kayan pencere - rolling window) içinde uyması gereken iç mühendislik hedefidir. Örneğin: "Son 30 günlük pencerede Kimlik Doğrulama Servisi'nin başarılı yanıt oranı (SLI) en az %99.95 olmalıdır." SLO, mühendislik ekibinin ürün yönetimine ve kendisine verdiği teknik sözdür; hukuki bir para cezası içermez ancak teknik yol haritasını doğrudan yönetir.

C. SLA (Service Level Agreement - Hizmet Seviyesi Anlaşması)

Şirket ile müşterileri arasında imzalanan, SLO hedeflerinin daha esnek bir alt sınırını içeren ve ihlal edildiğinde finansal yaptırımları (hizmet kredisi iadesi, sözleşme fesih hakkı veya para cezası) devreye sokan ticari ve hukuki sözleşmedir. İyi bir SRE mimarisinde SLO her zaman SLA'den daha sıkı (daha yüksek) tutulur. Örneğin müşteriye imzalanan SLA %99.9 ise, iç mühendislik hedefi olan SLO %99.95 olarak belirlenir; böylece SLA ihlal edilmeden önce erken uyarı mekanizmaları devreye girer.

3. "Dokuzların Matematiği" (The Math of Nines) ve Hata Bütçesi (Error Budget)

Bulut mimarilerinde erişilebilirlik hedefleri genellikle "Dokuzların Sayısı" (Two Nines, Three Nines, Four Nines, Five Nines) ile ifade edilir. Her bir ek "9" rakamı, izin verilen maksimum kesinti süresini (downtime) 10 kat azaltırken, mimari karmaşıklığı katbekat artırır:

Erişilebilirlik Seviyesi	Adlandırma	Yıllık Maksimum Kesinti	Aylık Maksimum Kesinti	Haftalık Maksimum Kesinti	Gerekli Mimari Altyapı Standardı
%99.0	İki Dokuz (Two Nines)	3 gün 15 saat 40 dk	7 saat 18 dk	1 saat 40 dk	Tek bölge, temel yedekleme, manuel kurtarma
%99.9	Üç Dokuz (Three Nines)	8 saat 45 dk 56 sn	43 dk 49 sn	10 dk 4 sn	Çoklu Erişilebilirlik Alanı (Multi-AZ), otomatik yük dengeleyici
%99.95	Üç Buçuk Dokuz	4 saat 22 dk 58 sn	21 dk 54 sn	5 dk 2 sn	Otomatik ölçekleme, veritabanı okuma kopyaları, hızlı failover
%99.99	Dört Dokuz (Four Nines)	52 dk 35 sn	4 dk 23 sn	1 dk 0.5 sn	Çoklu bölge (Multi-Region) yedeklilik, sıfır kesintili dağıtım, Kaos Mühendisliği
%99.999	Beş Dokuz (Five Nines)	5 dk 15 sn	26.3 saniye	6.05 saniye	Aktif-Aktif küresel dağıtık mimari (Spanner/CockroachDB), otonom kendi kendini iyileştirme

Hata Bütçesi (Error Budget) Nasıl Çalışır?

Hata Bütçesi, 100% - SLO formülüyle hesaplanan ve sistemin belirli bir dönemde "bozulmasına veya hata üretmesine izin verilen" kredi miktarıdır. Örneğin aylık %99.9 SLO hedefi olan ve ayda 100 milyon API isteği alan bir sistemin aylık hata bütçesi 100.000 hatalı istek (veya 43 dakika 49 saniye kesinti) kadardır.

Hata bütçesi, ürün geliştirme (Dev) ile güvenilirlik (SRE) arasındaki tartışmaları politik olmaktan çıkarıp tamamen matematiksel bir kurala bağlar:

1. Hata Bütçesi Pozitifse (Kredi Varsa): Geliştirme ekibi istediği kadar hızlı yeni özellik (feature) yayınlayabilir, riskli mimari geçişler yapabilir ve üretim ortamında Kaos Mühendisliği deneyleri yürütebilir.
2. Hata Bütçesi Tükenirse (Sıfırlanırsa): Kritik güvenlik yamaları ve P0/P1 acil hata düzeltmeleri dışındaki tüm yeni özellik dağıtımları durdurulur (Feature Freeze). Tüm yazılım ekibi, hata bütçesi yeniden güvenli seviyeye dönene kadar teknik borçları temizlemeye, birim/entegrasyon testlerini güçlendirmeye ve sistem kararlılığını artırmaya odaklanır.

Ayrıca modern SRE ekiplerinde hata bütçesinin tükenme hızını izlemek için Tükenme Hızı (Burn Rate) uyarıları kullanılır. Örneğin 30 günlük bütçenin %2'si yalnızca 1 saat içinde tükeniyorsa (Burn Rate = 14.4x), PagerDuty veya Opsgenie üzerinden nöbetçi mühendise anında kritik çağrı (page) gönderilir.

4. Kaos Mühendisliği (Chaos Engineering) Nedir? Üretimde Kontrollü Fırtına

Bir binanın depreme dayanıklı olup olmadığını sadece mimari çizimlere bakarak bilemezsiniz; sarsıntı simülatörleriyle test etmeniz gerekir. Benzer şekilde, kurumsal bulut çözümleri üzerinde çalışan dağıtık bir yazılımın yüksek erişilebilirlik mekanizmalarının (auto-scaling, failover, circuit breaker, retry logic) gerçekten çalışıp çalışmadığını gece saat 03:00'te gerçek bir veri merkezi çöktüğünde öğrenmek istemezsiniz.

Kaos Mühendisliği (Chaos Engineering), bir dağıtık sistemin üretim ortamındaki çalkantılı ve beklenmedik koşullara karşı direncini (resilience) doğrulamak amacıyla sistem üzerinde kontrollü ve bilimsel deneyler yapma disiplinidir. Netflix'in 2008 yılında yaşadığı büyük veritabanı kesintisinin ardından kendi veri merkezlerinden AWS bulutuna taşınırken geliştirdiği Chaos Monkey aracı, bu disiplinin doğuşunu sağlamıştır. Chaos Monkey'nin yaptığı şey çok basitti ancak devrim niteliğindeydi: Mesai saatleri içinde, üretim ortamındaki sanal sunucuları (EC2 instance) rastgele ve haber vermeden kapatmak! Mühendisler sunucularının her an kapanabileceğini bildikleri için, yazdıkları her servisi durumsuz (stateless), yedekli ve hata toleranslı tasarlamak zorunda kaldılar.

Kaos Mühendisliğinin 5 Bilimsel Adımı

Kaos mühendisliği rastgele sunucu fişi çekmek değildir; tamamen bilimsel yönteme dayanan 5 aşamalı bir protokol izler:

1. Kararlı Durumu (Steady State) Tanımlama: Sistemin normal çalışırken ürettiği iş ve teknik metrikleri (örneğin saniyede tamamlanan sipariş sayısı, p99 gecikme süresi, hata oranı) baz çizgisi (baseline) olarak belirleyin.
2. Hipotez Kurma: "Eğer Öneri Motoru (Recommendation Service) mikroservisinin Redis önbellek kümesi tamamen erişilemez hale gelirse veya 2000 ms gecikme üretirse, ana e-ticaret sayfası çökmeyecek; varsayılan popüler ürünler listesini göstererek (Graceful Degradation) kararlı durumu koruyacaktır." şeklinde pozitif bir hipotez kurun.
3. Gerçek Dünya Arızalarını Enjekte Etme (Fault Injection): Ağ paketi kaybı (packet loss), yapay gecikme (latency injection), CPU/RAM darboğazı, disk doluluğu, DNS çözümleme hatası veya tüm bir erişilebilirlik alanının (Availability Zone) kesilmesi gibi gerçekçi arızaları simüle edin.
4. Patlama Yarıçapını (Blast Radius) Sınırlandırma ve Gözlemleme: Deneyi ilk başta tüm kullanıcılarda değil, trafiğin yalnızca %1'ini alan küçük bir kanarya (canary) grubunda çalıştırın. Eğer SLO metrikleri kritik eşiği aşarsa deneyi milisaniyeler içinde otomatik durduran bir Acil Durdurma Anahtarı (Abort / Stop Condition) tanımlayın.
5. Bulguları Onarma ve Otomatize Etme: Eğer hipotez çürütüldüyse (örneğin Öneri Motoru yavaşladığında ana sayfa da kilitlendiyse), eksik olan zaman aşımı (timeout) veya devre kesiciyi koda ekleyin ve bu kaos deneyini CI/CD boru hattına bağlayarak sürekli hale getirin.

5. Dayanıklılık Tasarım Desenleri (Resilience Design Patterns)

Kaos mühendisliği deneylerinden başarıyla çıkan bir SRE mimarisi inşa etmek için yazılım katmanında aşağıdaki dört dayanıklılık deseninin mutlaka uygulanması gerekir:

• Zaman Aşımı (Timeouts) ve Üstel Geri Çekilme (Exponential Backoff with Jitter): Hiçbir ağ çağrısı sonsuz (infinite) zaman aşımıyla yapılmamalıdır. Ayrıca çökmekte olan bir servise başarısız olan istemcilerin aynı milisaniyede tekrar tekrar istek atarak "Sürü Etkisi" (Thundering Herd / Retry Storm) yaratmasını önlemek için her yeniden deneme (retry) arasına rastgele sapmalı (jitter) üstel artan bekleme süreleri eklenmelidir.
• Devre Kesici (Circuit Breaker): Tıpkı evlerdeki elektrik sigortası gibi çalışır. Bir alt servis (downstream service) üst üste belirli bir oranda (örneğin son 20 isteğin %50'sinde) hata veya zaman aşımı üretirse, devre kesici "Açık" (Open) konuma geçer ve alt servise yeni istek göndermeyi anında keserek hızlı hata (fail-fast) veya yedek yanıt (fallback) döndürür. Böylece arızanın üst servislere sıçrayarak tüm sistemi çökertmesi (Cascading Failure) engellenir.
• Bölme Duvarı (Bulkhead Pattern): Gemilerin su aldığında batmasını önleyen izole kompartımanlar gibi, sunucu kaynaklarını (iş parçacığı havuzları / thread pools ve bağlantı havuzları) servis bazında izole eder. Böylece raporlama servisindeki ağır bir sorgu tüm veritabanı bağlantılarını tüketse bile, ödeme ve giriş servisleri kendi ayrılmış havuzlarından çalışmaya devam eder.
• Zarif Bozulma (Graceful Degradation): Sistem aşırı yük altındayken veya kısmi arıza yaşadığında temel olmayan özellikleri devre dışı bırakarak çekirdek işlevi ayakta tutmaktır (örneğin canlı stok sayacını kapatıp sepete ekleme işlemini sürdürmek).

# Kubernetes Üzerinde LitmusChaos / Chaos Mesh ile Ağ Gecikmesi Deneyi (YAML Örneği)
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: odeme-servisi-gecikme-deneyi
  namespace: production-chaos
spec:
  action: delay
  mode: fixed-percent
  value: "25" # Pod'ların yalnızca %25'ini etkile (Dar Patlama Yarıçapı)
  selector:
    namespaces:
      - ecommerce-prod
    labelSelectors:
      app: payment-gateway-service
  delay:
    latency: "450ms"
    correlation: "50"
    jitter: "50ms"
  duration: "5m" # Deney 5 dakika sonra otomatik sonlanır

6. Modern Kaos Mühendisliği Araçları ve Oyun Günleri (GameDays)

Günümüzde bulut-yerel (cloud-native) mimarilerde ve merkezsiz dağıtık ağlarda kaos deneylerini yürütmek için gelişmiş açık kaynaklı ve kurumsal platformlar kullanılmaktadır:

• LitmusChaos & Chaos Mesh (CNCF Projeleri): Kubernetes ortamları için özel olarak geliştirilmiş açık kaynaklı platformlardır. Pod silme, konteyner CPU/IO doygunluğu, DNS hatası ve ağ bölünmesi (network partition) deneylerini Kubernetes CRD (Custom Resource Definition) nesneleri olarak yönetirler.
• AWS Fault Injection Service (FIS) & Azure Chaos Studio: Bulut sağlayıcılarının doğrudan kendi altyapı katmanında sunduğu yönetilen kaos servisleridir. CloudWatch veya Prometheus alarmlarına doğrudan bağlanarak, alarm tetiklendiği anda deneyi otomatik olarak geri alırlar (Auto-Rollback).
• Gremlin: Kurumsal düzeyde güvenilirlik skorlaması ve kapsamlı hata enjeksiyonu sunan ticari platformdur.

Teknik araçların yanı sıra SRE ekiplerinin en etkili pratiklerinden biri GameDay (Oyun Günü) tatbikatlarıdır. Belirli aralıklarla düzenlenen GameDay etkinliklerinde geliştirme, SRE ve yapay zeka siber güvenlik ekipleri bir araya gelir; simüle edilen büyük bir kesinti senaryosunda izleme panellerinin (Grafana, Datadog, OpenTelemetry) sorunu doğru gösterip göstermediğini, nöbetçi mühendislerin müdahale kılavuzlarını (Runbooks) ne kadar sürede uyguladığını ve ortalama kurtarma süresini (MTTR - Mean Time To Recovery) canlı olarak test ederler.

7. Suçlamasız Olay Sonrası Analiz (Blameless Postmortem) Kültürü

Bir kesinti veya kaos deneyi başarısızlığı yaşandığında, geleneksel şirketlerde genellikle "Hangi mühendis bu hatalı komutu çalıştırdı?" sorusu sorulur ve kişi cezalandırılır. Oysa SRE kültüründe insan hatası bir kök neden (root cause) değil, kusurlu bir sistem tasarımının belirtisidir (symptom).

Eğer bir mühendis yorgun bir anında yanlış bir yapılandırma dosyasını canlıya göndererek tüm sistemi çökertebiliyorsa, buradaki gerçek sorun mühendisin dikkatsizliği değil; CI/CD boru hattında otomatik şema doğrulamasının, akran değerlendirmesinin (peer review), kanarya dağıtımının (canary deployment) ve otomatik geri alma (auto-rollback) mekanizmalarının bulunmamasıdır. Suçlamasız Postmortem (Blameless Postmortem) dokümanlarında kişi isimleri asla suçlayıcı biçimde yer almaz; olayın dakika dakika zaman çizelgesi (timeline), tespit süresi (MTTD), iyileştirme süresi (MTTR), şans eseri nelerin doğru gittiği ve aynı hatanın bir daha yaşanmasını teknik olarak imkansız kılacak somut Aksiyon Maddeleri (Action Items) kayıt altına alınır. Benzer şekilde karmaşık ikili dosyaların veya çöken süreçlerin analizinde yapay zeka destekli tersine mühendislik ve kök neden analizi teknikleri de postmortem süreçlerini büyük ölçüde hızlandırmaktadır.

Sıkça Sorulan Sorular (SSS)

1. Kaos Mühendisliği deneyleri doğrudan üretim (production) ortamında mı yapılmalıdır?

Kaos mühendisliğinin nihai hedefi üretim ortamında test yapmaktır çünkü hiçbir test veya hazırlık (staging) ortamı gerçek üretim trafiğinin çeşitliliğini, ölçeğini ve ağ topolojisini birebir kopyalayamaz. Ancak olgunluk seviyesi düşük sistemlerde deneylere mutlaka önce Staging ortamında başlanmalı, temel dayanıklılık mekanizmaları (circuit breaker, retry, timeout) doğrulandıktan sonra üretim ortamında çok küçük bir patlama yarıçapıyla (%1 trafik) canlı testlere geçilmelidir.

2. MTBF ve MTTR nedir, modern SRE mimarisinde hangisi daha önemlidir?

MTBF (Mean Time Between Failures - Arızalar Arası Ortalama Süre) sistemin ne kadar seyrek bozulduğunu, MTTR (Mean Time To Recovery - Ortalama Kurtarma Süresi) ise bozulan bir sistemin ne kadar hızlı ayağa kaldırıldığını ölçer. Günümüzün hızla değişen mikroservis mimarilerinde arızaları tamamen sıfırlamak (MTBF'yi sonsuza çıkarmak) imkansız olduğu için, modern SRE ekipleri MTTR'ı dakikalardan saniyelere indirmeye (otomatik tespit ve kendi kendini iyileştirme) çok daha fazla odaklanır.

3. Küçük ve orta ölçekli yazılım ekipleri SRE ve Hata Bütçesi uygulayabilir mi?

Kesinlikle evet. SRE uygulamak için Google ölçeğinde binlerce sunucuya veya ayrı bir SRE departmanına sahip olmanız gerekmez. Mevcut geliştirici ekibinizin en kritik 2 kullanıcı yolculuğu için (örneğin "Kullanıcı Girişi" ve "Sipariş Tamamlama") basit bir erişilebilirlik ve gecikme SLO'su tanımlaması, Prometheus/Grafana ile hata bütçesini izlemesi ve her büyük kesinti sonrasında suçlamasız bir postmortem yazması bile sistem kararlılığında devasa bir sıçrama yaratır.

4. Kaos Mühendisliği ile Sızma Testi (Penetration Testing) veya Yük Testi arasındaki fark nedir?

Yük testi (Load/Stress Testing) sistemin belirli bir trafik hacmi altındaki kapasitesini ölçer; Sızma testi (Pentest) güvenlik açıklarını ve yetkisiz erişim vektörlerini arar. Kaos Mühendisliği ise altyapı bileşenleri, ağ bağlantıları veya bağımlı servisler arızalandığında sistemin hata toleransını (fault tolerance) ve yüksek erişilebilirliğini koruyup koruyamadığını test eder. Son yıllarda bu disiplinlerin kesişimiyle Güvenlik Kaos Mühendisliği (Security Chaos Engineering) kavramı da doğmuştur.

5. "Beş Dokuz" (%99.999) erişilebilirlik her kurumsal yazılım için hedeflenmeli midir?

Hayır. %99.999 erişilebilirlik yılda yalnızca 5 dakika 15 saniye kesinti hakkı tanır. Bu seviyeye ulaşmak için aktif-aktif çok bölgeli küresel veritabanları, özel ağ omurgaları ve 7/24 anında müdahale eden küresel nöbetçi ekipler gerekir ki bu da bulut maliyetlerini 5 ila 10 kat artırır. Kalp pili izleme sistemleri, havacılık kontrol yazılımları veya çekirdek bankacılık takas ağları için %99.999 şartken; standart bir kurumsal SaaS veya e-ticaret platformu için %99.9 ile %99.99 arası hem maliyet hem de kullanıcı memnuniyeti açısından en optimum noktadır.