Kaos Mühendisliğine aşina değilseniz yada ilk defa duyuyorsanız önce , tanımla başlayalım:
Kaos Mühendisliği, canlı ortamda oluşabilecek çalkantılı koşullara dayanma kabiliyetine olan güveni artırmak için dağıtık bir sistem üzerinde deney yapma disiplinidir.
Disaster planlarına çok benziyor olabilir ama aslında Disaster planınıdan çok uzak bir kavram. Böyle bir durumda şirketler, veri merkezi veya bina kaybı gibi büyük bir arıza durumunda hizmeti nasıl hızlı bir şekilde geri yükleyebileceklerini test etme eğilimindedir. Kontrol edilebilir bir ortamda önceden oluşturulmuş olan prosedürler ışığında simülasyonlar yapılır ve bu simülasyona dahil olan her ekip ile beraber ne zaman planını hayata geçirileceği konusunda anlaşırlar. Herhangi bir gerçek hayat baskısı yada sorun anında yapılan mobbing olmadan planlar uygulanır.
Kaos Mühendisliği ise bu durumdan tamamen farklıdır.
Büyük ölçekli dağıtık sistemlerdeki gelişmeler, yazılım mühendisliği alanında oyunun kurallarını değiştirmekteler. Endüstri olarak, geliştirmenin esnekliğini ve dağıtımın sıklığını artıran değişiklikleri hızlı biçimde benimsiyoruz. Bu değişikliklerin getirdiği avantajları önemli bir soru takip ediyor: Canlı ortamlara sunduğumuz kompleks sistemlere ne kadar güvenebiliriz ?
Dağıtık bir sistemdeki tüm servisler ayrı ayrı düzgün çalışıyor olsalar bile, bu servislerin arasındaki ilişkiler beklenmeyen sonuçlar doğurabilirler. Prod ortamınızın her zaman çalışması istenir. Bu çalışma sürecinde de sizin manuel yaptığınız işlemler ve devamlılığı olan işlemler de belli araçlar yada scriptler aracılığıyla otomatikleştirdiğiniz işlemleriniz vardır. Bu aşamada kullandığınız araçlarda bir sorun olabilir, bir servisi yada sanal makineyi kapatmaktan öte, kullanıcılarınız yaşadığı yavaşlıklar yada veritabanlarınızdaki sorgularınızda gecikmeler olabilir. Beklenmeyen sonuçlar, canlı ortamları etkileyen nadir fakat yıkıcı gerçek dünya olayları ile birleştiklerinde, dağıtık sistemler doğal olarak kaotik olurlar.
Her Sistem En Zayıf Noktası Kadar Güçlüdür.
Zayıflıkları, sistem çapında anormal davranışlara dönüşmeden önce tanımlamamız gerekir. Sistemsel zayıflıklar: servisin kullanım dışı kalması durumunda geri dönüş planlarının düzgün çalışmamasına sebep olan ayarlar; Yanlış ayarlanmış zaman aşımı süreleri sebebiyle oluşan yeniden deneme kuyrukları; Fazla trafikten kaynaklanan kesintiler; “Tek hata noktası” durumlarının üst üste gelmesi ve benzeri durumlar olarak ortaya çıkabilir. Müşterilerinizin canlı ortamlarını etkilemeden önce, en önemli zayıflıkları proaktif olarak ele alınmalıdır. Bu sistemlerdeki kaosu yönetmenin, artan esneklik ve hızın avantajlarını kullanmanın ve kompleksitelerine rağmen canlı ortamlarımıza olan güveni artırmanın bir yolunu bulmalıyız.
Ampirik, sistem tabanlı bir yaklaşım, dağıtık sistemlerdeki kaosu ölçeklendirir ve bu sistemlerin gerçekçi koşullara dayanma becerisine olan güveni artırır. Bizler, dağıtık bir sistemin davranışlarını, kontrollü bir deney ile gözlemleyerek öğreniyoruz. Biz buna Kaos Mühendisliği diyoruz.
Kaos Mühendisliği Nasıl Çalışır?
Hypothesis: Mühendisler kendilerine bir değişkeni değiştirirlerse ne olacağını sorarlar. Hizmetleri rastgele sonlandırırlarsa, hizmetin kesintisiz devam edeceğini varsayarlar. Soru ve varsayım bir hipotez oluşturur.
Testing: Hipotezi test etmek için, kaos mühendisleri, yük testiyle birlikte simüle edilmiş belirsizliği düzenler ve uygulamayı sunan hizmetlerde, altyapıda, ağlarda ve cihazlarda karışıklık belirtilerini izler. Yığındaki herhangi bir başarısızlık hipotezi bozar.
Blast Radius: Mühendisler, arızaları yalıtarak ve inceleyerek, kararsız bulut koşullarında neler olduğunu anlayabilir. Testin neden olduğu herhangi bir hasar veya etki ‘patlama yarıçapı’ olarak bilinir. Kaos mühendisleri, testleri kontrol ederek patlama yarıçapını yönetebilir.
Insights: Keşifler, yazılım geliştirme ve teslim sürecine girdiler oluşturur, bu nedenle yeni yazılımlar ve mikro hizmetler, öngörülemeyen olaylara daha iyi dayanacaktır.
Prod ortamlarına verilen zararı azaltmak için, kaos mühendisleri üretim dışı bir ortamda başlar ve ardından kontrollü bir şekilde yavaş yavaş proda uzanır. Kaos mühendisliği bir kez kurulduktan sonra, , hizmet düzeyi göstergeleri ve hedeflerine ince ayar yapmanın, uyarıları iyileştirmenin ve daha verimli panolar oluşturmanın etkili bir yolu haline gelir. Böylece ortamınızı doğru bir şekilde gözlemlemek ve analiz etmek için ihtiyaç duyduğunuz tüm verileri topladığınızı bilirsiniz.
Neden Kaos Mühendisliği Yapmalısınız?
Birincisi, izleme ortamınızı test etmektir.
Uygun uyarılar doğru zamanda gönderiliyor mu? (Son kullanma tarihi dolmak üzere olan bir SSL sertifikası var, neyse ki meslektaşım, onu yenilemek için kullandığı yılın o zamanını hatırladı, baktı ve sertifikanın 4 gün sonra süresinin dolmak üzere olduğunu gördü. İzleme sunucusu “kapalı” olduğunu kontrol etmesi gerekiyordu)
Arızaları tespit edemiyorsanız, bir şeyleri kırmanın anlamı nedir? Kaos Mühendisliği ile altyapınızı doğru bir şekilde izlemenizi sağlarsınız.
Tepkinizi ölçün
İnsanlar, oluşturulan uyarıları nasıl ele alacaklarını bilecek kadar eğitimli mi?
Nasıl cevap vereceklerini biliyorlar mı?
Dokümantasyon mevcut mu?
Yeterli sorun giderme sağlıyorlar mı?
Eskalasyon ekibine hangi bilgiler sağlanmalı?
Bazı otomatik düzeltmeler yapmak mümkün mü?
Bir durumu düzeltmek için ne kadar zamana ihtiyaçları var?
Sorunu azaltmak için ilgili bir geçici çözüm bulabiliyorlar mı? Otomatikleştirilebilir mi?
Yanıt vermek için ne kadar çok eğitilirlerse, bir başarısızlıkla karşılaştıklarında o kadar emin olurlar ve diğer insanlar bir sorunu çözmek için hizmetinizin kalitesine/dayanıklılığına o kadar güvenirler.
Altyapınıza ne olabileceğini ve nasıl yanıt vereceğinizi ne kadar çok bilirseniz, belirsizlik stresine o kadar az maruz kalacaksınız.
Ve son olarak, süreçlerinizi sürekli olarak iyileştirebilirsiniz.
Monitörleri, threshold’ları, dökümanları iyileştirmeniz ve geliştirmeniz, mümkün olduğunda otomatik düzeltmeyi devreye sokmanıza ve tüm bunları test etmenize olanak tanır!
Bağımlılıkları ve etkileri belirlersiniz ve kapsamınızın dışında kalan ancak hizmetinizi etkileyen arızanın “farkında” olmak için monitörler/uyarılar koyarsınız.
Kaos Mühendisliğinin Zorlukları
Kaos testinin faydaları açık olmasına rağmen, üzerinde düşünülerek yapılması gereken bir uygulamadır.
Gereksiz hasar: Kaos testiyle ilgili en büyük endişe, gereksiz hasar potansiyelidir. Kaos mühendisliği, haklı testlerin izinlerini aşan gerçek dünya kaybına yol açabilir. Uygulama güvenlik açıklarını ortaya çıkarmanın maliyetini sınırlamak için kuruluşlar, belirlenen patlama yarıçapını aşan testlerden kaçınmalıdır. Amaç, patlama yarıçapını kontrol etmektir, böylece gereksiz yere yeni arıza noktaları ortaya koymadan arızanın nedenini tam olarak belirleyebilirsiniz.
Gözlenebilirlik eksikliği: Bir patlama yarıçapının etkileyebileceği tüm sistemlerde uçtan uca gözlemlenebilirlik ve izleme eksikliği yaygın bir sorundur. Kapsamlı gözlemlenebilirlik olmadan, kritik bağımlılıkları kritik olmayan bağımlılıklara karşı anlamak veya düzeltmelere öncelik vermek için bir hatanın veya bozulmanın gerçek iş etkisini anlamak için yeterli bağlama sahip olmak zor olabilir. Görünürlük eksikliği, ekiplerin bir sorunun kesin kök nedenini belirlemesini de zorlaştırabilir ve bu da düzeltme planlarını karmaşıklaştırabilir.
Belirsiz başlangıç sistemi durumu . Diğer bir sorun, test çalıştırılmadan önce sistemin başlangıç durumunun net bir resmine sahip olmaktır. Bu netlik olmadan ekipler, testin gerçek etkilerini anlamakta zorluk çekebilir. Bu, kaos testinin etkinliğini azaltabilir ve aşağı akış sistemlerini daha büyük risk altına sokabilir ve patlama yarıçapını kontrol etmeyi zorlaştırabilir.
Kaos Mühendisliğine Nasıl Başlanır?
Herhangi bir bilimsel deneyde olduğu gibi, kaos mühendisliğine başlamak biraz hazırlık, organizasyon ve sonuçları izleme ve ölçme yeteneği gerektirir.
Ortamınızın başlangıç durumunu bilin . İyi kontrol edilen bir kaos testi planlamak ve testin etkilerini anlayabilmek için ortamınızın uygulamalarını, mikro hizmetlerini ve mimari tasarımını anlamalısınız. Son durumla karşılaştırabileceğiniz bir temele sahip olmak, test sırasında izleme ve sonrasında sonuçları analiz etmek için bir plan oluşturur.
Neyin yanlış gidebileceğini sorun ve bir hipotez kurun . Sistemin başlangıç durumuna ilişkin net bir fikirle, neyin yanlış gidebileceğini sorun. Sistemin başlangıç durumuna ilişkin net bir fikirle, neyin yanlış gidebileceğini sorun. Hizmet düzeyi göstergelerini ve hizmet düzeyi hedeflerini anlayın ve bunları sistemin baskı altında nasıl çalışması gerektiğine ilişkin bir varsayım oluşturmak için bir temel olarak kullanın.
Her seferinde bir değişken kaosu tanıtın . Patlama yarıçapını kontrol altında tutmak için, sonuçları takdir edebilmeniz için her seferinde yalnızca biraz kaos uygulayın. Belirli koşullar altında deneyi iptal etmeye hazır olun, böylece üretim yazılımına hiçbir zarar gelmez ve bir şeyler ters giderse geri alma planınız da olur. Test sırasında, sistem esnekliğini geliştirmek için odaklanılacak alanları keşfetmek için hipotezi çürütmeye çalışın.
Sonuçları izleyin ve kaydedin . Uygulama davranışındaki herhangi bir nüansı kaydetmek için deneyi izleyin. Uygulamanın nasıl yanıt verdiğini ve testlerin ekiplerin beklentilerini karşılayıp karşılamadığını görmek için sonuçları analiz edin. Yavaşlamaların ve arızaların kesin kök nedenlerini anlamak için araştırma araçlarını kullanın.
