Kaos Mühendisliği Nedir Ve İşletmelere Nasıl Fayda Sağlayabilir?

Kaos mühendisliği özellikle tekil zayıflık noktalarını bulmak için yararlı olabilir, ancak uygulanması dikkatli bir iş birliği gerektirir

Kaos mühendisliği, bir sistemin dayanıklılığına güven oluşturmak için sisteme kasıtlı olarak hatalar enjekte etme disiplinidir. BT ekiplerinin elinde, bir organizasyonun güvenliğini araştırmak için güçlü bir araç olabilir – ancak personel yükünü azaltmak ve artırmamak için doğru şekilde uygulanmalıdır.

Güvenlik Kaos Mühendisliği: Yazılım ve Sistemlerde Dayanıklılığı Sürdürme kitabının yazarı Kelly Shortridge, kaos mühendisliğinin diğer endüstrilerde gördüğümüz stres testlerinden çok da farklı olmadığını söylüyor . Burada, kuruluşlar, olumsuz koşullar sırasında uçtan uca nasıl davrandıklarını görmek için su arıtma veya nükleer reaktör tesislerindeki sistemler arasında karmaşık simülasyonlar çalıştırıyor.

Bilinmeyen senaryolara odaklanarak ve bir sistemin nasıl yanıt verdiğini test etmek için kontrollü kesintileri proaktif olarak tanıtarak düzenli hata ve güvenlik açığı testlerinden farklıdır . Bu, mühendislerin sistem dayanıklılığı hakkındaki varsayımlarını doğrulamalarını veya başarısız olduklarında gizli zayıflıkları belirlemelerini sağlar.

Kaos mühendisliğinin yükselişi

Kaos mühendisliği, yazılım ve donanım sistemlerinin giderek karmaşıklaşmasına yanıt olarak ortaya çıktı ve kuruluşlar, dayanıklılığı test ederken daha geniş resme bakma ihtiyacının farkındalar.

Cognitive Market Research verilerine göre , kaos mühendisliği pazarının 2024-2031 yılları arasında yıllık bileşik %9 büyüme kaydetmesi bekleniyor.

Fastly’de Portföy Ürün Yönetimi kıdemli direktörü olan Shortridge, “Bireysel bir kütüphane veya hizmetin davranışı gibi bileşenlere bakmanın, sistemin genel olarak kötü bir şey olduğunda nasıl tepki vereceğine dair gerçek bir fikir vermeyeceğinin farkındalar” diyor. “Bu yüzden olumsuz koşulları bir girdi olarak simüle etmeniz ve bunun sistemin bir bütün olarak nasıl etkilendiğini görmeniz gerekiyor.”

Kaos mühendisliğini benimseyen ilk şirketlerden biri Netflix‘ti, sunucularından veya iş yüklerinden birinde meydana gelen bir arızanın tüm kullanıcıların akışının kesintiye uğramasına neden olmamasını sağlamanın bir yolu olarak. Şirket, tüm filosunun sağlıklı kalmasını sağlamak için üretimde çalışırken sunucularından birini kasıtlı olarak sonlandıran Chaos Monkey’i geliştirdi.

Tekil arıza noktalarını bulma

Gartner’da analist yardımcısı olan Joachim Hershmann’ın açıkladığı gibi, kaos mühendisliği özellikle tekil arıza noktalarını bulmak için oldukça faydalıdır.

Hershmann, ITPro’ya yaptığı açıklamada, “Bu özellikle ilginç çünkü birçok kuruluşun yedek olarak bir yerlerde ikinci bir sunucusu var , ancak uygulamaların tüm zincirine baktığınızda, bunun başarısız olması durumunda her şeyin bozulmaya başladığı noktanın ne kadar sık ​​olduğunu görmek şaşırtıcı.” diyor .

“Yük dengeleme olmayabilir veya belirli bir sunucu gerektiği gibi yanıt vermiyor olabilir. Hatta bir kişi bile olabilir – belirli bir senaryoda ne yapacağını bilen tek bir kişi varsa, o zaman bu bir arıza noktasıdır. Bu tek arıza noktalarını belirlemek önemlidir çünkü bir şey ters giderse, bu sistemdeki başka bir şeyi etkiler ve bu böyle devam eder ve sonunda kaos oluşur.”

Hershmann, “Her kuruluş riski azaltmak ister ve bundan sonra kaos mühendisliğinin büyümesini yönlendirecek şeylerden biri de budur” diyor. “Ayrıca sigortayı da etkileyebilir ve bir sistemin güvenli olduğunu güvenilir bir şekilde kanıtlamanın bir yolu olarak kullanılabilir” diye belirtiyor.

Kaos mühendisleri kimlerdir?

Şu anki haliyle, kaos mühendisliğinin belirgin bir kariyer yolu yoktur ve çok az kişi yalnızca kaos mühendisi rolündedir. Bunun yerine, kaos mühendisliği büyük ölçüde platform mühendisliğinin kapsamına girer ve bu mühendislerin sistemlerin öngörüldüğü gibi çalıştığını doğrulamak için ellerindeki birçok araçtan biri olarak görülür.

Başlangıçta bu ekip kaos deneylerini tasarlamak ve yürütmekten sorumlu olacak ancak ideal olarak daha sonra birleşik bir model benimsemelidir. Forrester’daki baş analist David Mooter, ekiplerin kaos mühendisliği altyapısından ve biraz uzmanlığa ihtiyaç duyan ekiplere yardımcı olmaktan sorumlu olduğu yer burasıdır diyor.

“Kaos testlerinin oluşturulması ve yürütülmesinin uygulama geliştiricilerine dayatılmasını istersiniz,” diye açıklıyor. “Merkezi kalırlarsa, birincisi, bu merkezi ekibi bunalttığı için ölçeklenmeyecektir, ikincisi, işler ters gittiğinde gruplar arasında ‘biz ve onlar’ zihniyeti ve parmak sallama kültürü yaratacaktır ve üçüncüsü, uygulama geliştiricileri deneylere doğrudan dahil olmazlarsa dayanıklılık için öğrenmeyecek ve sezgi oluşturmayacaktır,” diye belirtiyor Mooter.

Kaos mühendisliği öğrenmekle ilgilidir; hem teknik açıdan hem de organizasyonel/insan perspektifinden; dolayısıyla doğru paydaşları bir araya getirerek işe başlamalısınız.

Dahil olan ekipler arasında operasyonlar, geliştiriciler, güvenlik ve mimarlar yer alabilir ve bunlar bilgilerine dayanarak ne olacağını düşündüklerini varsaymalıdır. Deney yürütüldükten sonra, karşılaştırmalar yapılabilir ve gelecekteki karar alma süreçlerini bilgilendirmek için dersler çıkarılabilir.

Hershmann, “Bu deneyi yalnızca sisteme ne olacağını öğrenmek için değil, aynı zamanda buna yönelik bir acil durum planınız olup olmadığını öğrenmek için yapıyorsunuz,” diye açıklıyor. “Belki de beklentileriniz doğruydu, belki de değildi.

“İkinci ders, bir acil durum planınız varsa, işe yarıyor mu? Bunu alın, gerektiği gibi değişiklikler yapın ve ardından deneyi tekrar çalıştırın. Umarım bu sefer her şey yoluna girer ve beklendiği gibi amacına hizmet eder.”

Küçükten başlamak ve nereye odaklanmak gerekir

Kaos mühendisliğine ilk kez adım atmayı düşünüyorsanız, uzmanlar giriş sayfanızdaki çerezlerin öngörüldüğü gibi çalıştığını doğrulamak gibi küçük bir şeyle başlamanızı öneriyor.

Shortridge, “Başlangıçta yeterince karşı çıkamadığım çok daha büyük bir deneyle başlarsanız, bu pahalı olacaktır çünkü birkaç ekibi dahil etmeniz ve bilgiyi seviyelendirmeniz gerekecektir” diyor.

Ayrıca bir sahneleme veya test ortamıyla başlamayı öneriyor çünkü “eğer bir üretim ortamında Netflix tarzında bir şeyler yaparsanız ve bir şeyler ters giderse, işleri yoluna koymak çok daha acil hale gelir.”

Konu neyi test edeceğinize geldiğinde Shortridge, en büyük ticari etkiyi yaratacak alanlara odaklanmanız gerektiğini vurguluyor.

“Bir şeyler ters giderse, işletmenize para, zaman veya itibar kaybettirecek olan, iş açısından kritik şeyler olmalı ,” diye açıklıyor. “Bunların öngörüldüğü gibi çalıştığından ve olası başarısızlıkların etkisini en aza indirmek için her şeyin yerli yerinde olduğundan emin olmak istersiniz.”

Shortridge, kuruluşların GDPR gibi düzenlemelere uyumlarını , bir sistemin belirteçleri anonimleştirme becerisine ilişkin varsayımlarını test ederek sürdürmelerine örnek veriyor.

” Şifrelenmemiş bir token enjekte edebilirsiniz – ideal olarak üretim ortamından ziyade bir test ortamında – sistemin bunu nasıl işlediğini görmek için. Önemli olan bunu uçtan uca görmektir. Sadece başlangıçta bir ret olup olmadığına değil, aynı zamanda aşağı akışa da bakıyorsunuz.

“Bir uyarı var mıydı? İnsanlarınız uyarıyı fark etti mi? Bu konuda ne yapabilirlerdi – müdahale etmeleri ve harekete geçmeleri için yeterli bağlam var mıydı? Uyumluluk ekibi bilgilendirildi mi? Gerçekten önemli olan sistemin uçtan uca resmidir,” diye sonlandırıyor.