Kaos Mühendisliği: Arızayı Kontrollü Şekilde Önceden Yaşamak

Kaos mühendisliği nedir?

Kaos mühendisliği (chaos engineering), dağıtık bir sistemin beklenmedik koşullara karşı dayanıklılığına olan güveni, sisteme bilinçli ve kontrollü arızalar enjekte ederek sınama yaklaşımıdır. Amaç sistemi bozmak değil, zayıf noktaları gerçek bir kesinti sırasında değil, hazırlıklı olunan bir deney sırasında bulmaktır.

Yaklaşım, çok sayıda servisten oluşan sistemlerde 'bir bileşen arızalanırsa ne olur' sorusunun toplantıda tartışılarak yanıtlanamayacağı fikrine dayanır. Gerçek yanıtı vermenin yolu, arızayı küçük ve izlenen bir ölçekte oluşturup sistemin tepkisini gözlemektir. Yaklaşımın bilinen öncüsü, rastgele sanal makineleri kapatan Chaos Monkey aracıdır.

Bir kaos deneyi nasıl yürütülür?

Kaos deneyi bilimsel bir deney gibi kurgulanır: • Kararlı durumu tanımla: Sistemin sağlıklı davrandığını gösteren ölçülebilir göstergeleri belirle (başarılı istek oranı, yanıt süresi, sipariş tamamlama gibi iş metrikleri). • Hipotez kur: 'Bu servis yanıt vermezse kullanıcılar yedek akışa düşer ve sipariş tamamlanmaya devam eder.' • Etki alanını sınırla: Deneyi küçük bir kullanıcı grubu, tek bir servis ya da test ortamıyla başlat. • Arızayı enjekte et: Sunucu kapatma, ağ gecikmesi ekleme, bağımlılığı yanıtsız bırakma gibi bir hata oluştur. • Gözle ve karşılaştır: Kararlı durum göstergelerinin değişip değişmediğine bak. • Durdurma koşulu belirle: Beklenenden büyük etki görülürse deneyi derhal geri al. • Öğren ve düzelt: Hipotez çürüdüyse bulguyu giderip deneyi yeniden koş.

Hangi arızalar denenir?

Deneyler genelde gerçek hayatta görülen arıza türlerinden türetilir: • Altyapı: Sunucunun ya da kapsayıcının (container) kapanması, disk dolması, işlemci ya da bellek baskısı. • Ağ ve bağımlılık: Gecikme artışı, paket kaybı, bir dış servisin yanıt vermemesi, DNS sorunu. • Uygulama: Hatalı yanıt dönen bir servis, zaman aşımı, yapılandırma hatası. • Operasyonel: Yedek alma ve geri yükleme süreci, nöbetçi ekibin müdahale akışı, uyarı sisteminin gerçekten alarm verip vermediği.

Hata modu analizi bu seçimi besler: olası arızaları ve etkilerini önceden listeleyip riski en yüksek olanları deneme sırasına koymak, deneyleri rastgele seçmekten daha verimlidir.

Örnek: ödeme servisi gecikmesi

Örneğin bir sipariş sisteminde ödeme sağlayıcısına yapılan çağrının zaman aşımına uğraması deneyi kurgulanır. Hipotez şudur: ödeme çağrısı belirli süre içinde dönmezse sistem müşteriye anlaşılır bir mesaj verir, siparişi tekrar denenebilir durumda tutar ve çift tahsilat oluşmaz.

Deney sırasında ödeme çağrısına yapay gecikme eklenir. Gözlem sonucunda zaman aşımı değeri çok uzun olduğu için istek iş parçacıklarının tükendiği ve diğer sayfaların da yavaşladığı görülür. Bu bir bulgudur: zaman aşımı kısaltılır, devre kesici (circuit breaker) eklenir ve deney tekrarlanarak düzeltmenin işe yaradığı doğrulanır. Gerçek bir kesintide aynı zayıflık, en yoğun saatte ortaya çıkacaktı.

Game day ve otomasyon

Game day (oyun günü), ekibin önceden planlanmış bir zamanda bir arıza senaryosunu bilerek yaşadığı çalışmadır. Mühendisler, nöbetçiler ve ilgili iş ekipleri aynı anda katılır; hem sistemin tepkisi hem de insanların ve süreçlerin tepkisi sınanır: alarm geldi mi, doğru kişi uyandı mı, çalışma kitabı (runbook) güncel miydi?

Olgunluk arttıkça deneyler elle yapılan çalışmadan otomatik koşan süreçlere taşınır. Sürekli teslimat hattına eklenen küçük deneyler, bir değişikliğin dayanıklılığı bozup bozmadığını erken gösterir. Başlangıçta üretim yerine hazırlık ortamında denemek, güven oluştukça üretim kapsamını kademeli genişletmek yaygın bir yoldur.

Sık yapılan hatalar

• Gözlemlenebilirlik olmadan deney yapmak. Metrik, günlük ve izleme yoksa arızanın etkisi görülemez.
• Etki alanını sınırlamamak. Deney müşteriyi etkileyen kesintiye dönüşebilir.
• Hipotez kurmadan rastgele arıza üretmek. Ne öğrenileceği belli değilse deney bilgi üretmez.
• Bulguyu düzeltmemek. Deney yapıp bulguyu kayda geçirmemek, aynı zayıflığın yeniden yaşanmasına yol açar.
• Ekibi bilgilendirmemek. Kaos deneyi kültürel bir güven işidir; suçlayıcı olmayan bir yaklaşım gerektirir.

Mindset eğitimlerinde nerede işlenir?

Kaos Mühendisliği (Chaos Engineering) programı kaos mühendisliği ilkelerini, hata modu analizini, altyapı ve ağ düzeyi deneyleri ile oyun günü yürütmeyi kapsar. Site Reliability Engineering (SRE) Pratikleri programında SLI, SLO ve incident yönetimi gibi güvenilirlik konuları yer alır; DevOps Temelleri programı ise izleme ve geri bildirim döngüsünü işler.

SRE, platform ve DevOps ekipleri ile sistem dayanıklılığından sorumlu mimarlar bu programları birlikte değerlendirebilir.