Alibaba'nın kıdemli teknik uzmanı Zhou Yang, kaos mühendisliği teknolojisinin arkasındaki şeyleri kişisel olarak anlatıyor
2010'un sonunda, Netflix dünyaya Chaos Monkey'i başlattı. Bu teknoloji, üretim ortamındaki servis düğümlerini rastgele kapatmasıyla "kötü şöhretli" oldu. Bu, tanınmış Chaos Engineering'in ilk prototipidir. "Kaos Mühendisliği" kitabı bunu şu şekilde tanımlıyor:
Bu, Chaos Monkey'in güzelliğidir. Servis düğümü arızasının acısını olabildiğince ön plana çıkarabilir ve aynı zamanda tüm mühendislerin, başarısızlıkla başa çıkacak kadar dirençli bir sistem inşa etmede birleşik bir hedefe ulaşmasına olanak tanır.Chaos Monkey, Netflix'in birkaç yıl önce buluta taşınması sürecinden ilham aldı, esas olarak bu aşamada ortaya çıkan sorunları çözmek için. Ancak, birçok şirket buluta gitmekte hala yavaş, Kaos mühendisliğinin hala bu durumda olması gerekiyor mu? Yazılım test süreci daha olgun ve eksiksiz hale geldikçe, kaos mühendisliğine enerji harcamak gerekli mi? Gerekirse, hızlı dağıtım uygulamaları için bu alanda hangi açık kaynak araçları mevcuttur?
Yukarıdaki sorunlara yanıt olarak, InfoQ muhabirleri QCon 2019 Küresel Yazılım Geliştirme Konferansı'nda kıdemli bir Alibaba teknik uzmanı (takma ad: Zhongting) olan Zhou Yang ile röportaj yaptı ve sektördeki birçok teknik uzmanla değişen derecelerde iletişim kurdu. Bu makale popüler olmaya çalışacak. Kaos Mühendisliği'nin anlamını ve işlevini ve Alibaba'nın pratik deneyimini açıklayın.
Kaos mühendisliğinin anlamı
Kaos mühendisliği, dağıtık sistemler üzerinde deneyler yapan bir disiplindir.Amaç, sistemin üretim ortamında kontrol dışı koşullara direnme yeteneğini ve güvenini sağlamaktır.Bu cümle de "Kaos Mühendisliği" nden geliyor İlk bakışta bu anlam biraz anlaşılmaz. Kısaca özetlemek gerekirse, Zhou Yang'ın Kaos Mühendisliği anlayışı aşağıdaki gibidir:
- Başarısızlığı kucaklayan teknolojik bir kültür
- Bir dizi soyut ve titiz pratik ilke
- İstikrarlı bir aktif savunma aracı
- Hızla gelişen bir teknoloji alanı
İlkesel bir bakış açısından, Zhou Yang, kaotik mühendisliğin uygulanmasının dağıtılmış sistemlerin inşası için kaçınılmaz bir seçim olduğuna inanmaktadır. Bir yandan, mimarinin karmaşıklığı, sistem yöneticilerinin gerçek durumun beklenen tasarımı karşılaması gerektiğine güvenle söz vermesini zorlaştırır. Öte yandan, kuruluşun ROI (yatırımın geri dönüşü) arayışı, istikrar ekibinin sadece bir maliyet merkezi olmamasını ve tüm önlemlerin etkili olmasını gerektirir. Endüstrideki birçok mühendis, kaos mühendisliğini bir aşı ile karşılaştırma eğilimindedir. "Aşılama" sayesinde, sistem "kritik hastalıklara" direnme yeteneğine sahiptir. Kaotik mühendisliğin ilkeleri şu şekilde özetlenebilir: sabit durum davranışı etrafında bir hipotez oluşturmak; gerçek dünyadaki olayları çeşitlendirmek; bir üretim ortamında deneyler yürütmek; sürekli otomatik olarak deneyler yapmak; patlama yarıçapını en aza indirmek.
Muhtemelen Kaos Mühendisliğini gördükleri anda, birçok insan kafasında "test" kelimesini parlatacaktır. Günümüzde, hata yerleştirme ve hata testi yöntemleri çok olgun, neden kaos mühendisliğine ihtiyacımız var? Zhou Yang, bunlar arasında bir miktar örtüşme olduğuna inanıyor, ancak kaos mühendisliği yeni bilgileri keşfetme pratiğidir.
Hata enjeksiyonu ve hata testi, hatalar getirerek ve programın kapsamını iyileştirmek için programın bazı seyrek yollara girmesine izin vererek belirli koşulların ve değişkenlerin doğrulanmasıdır. Chaos Engineering, sistemin durumunu temsil etmek için kısa vadeli ölçüm sonuçlarını da kullansa da, ölçüm sonuçları genellikle belirli arayüz dönüş değerleri yerine izleme göstergeleridir. Kaos mühendisliği, kararlı durum etrafında bir doğrulama ve keşif sürecidir. Örneğin, kaotik maymunlar rastgele bazı düğümleri öldürür. Her deney yeni veriler oluşturabilir.
Örneğin, hata yerleştirmenin tipik senaryosu, zaman aşımları, hatalar, vb. Gibi iletişim hatalarını sistem hizmetlerine enjekte etmektir, ancak trafik dalgalanmaları, kaynak rekabet koşulları vb. Gibi diğer anormal davranışları keşfedemez. Bu uygulama süreci esasen sistemdeki bilinmeyen veya öngörülemeyen davranışları keşfedemez. Belirsiz algı. Kaos mühendisliğinin girdi koşulları, tüm bulut hizmet alanını veya veri merkezi arızasını simüle etmek; bir zaman aralığı seçmek ve trafiğin bir kısmı için ilgili hizmetler arasındaki çağrılara bazı belirli gecikmeler enjekte etmek olabilir; yöntem düzeyinde karışıklık (çalışma zamanı enjeksiyonu) ), yöntemin çeşitli istisnaları rastgele atmasına izin verin, vb.
Ayrıca kaos mühendisliğini uygulayanlar da farklıdır. Zhou Yang, Ali'nin dahili tam bağlantı stres testini örnek alarak uygulamanın esas olarak Ar-Ge personeline dayandığını söyledi. Geleneksel anlamda, test uzmanları lansmandan önceki duruma daha fazla dikkat eder ve ardından SRE ekibi operasyon ve bakımdan sorumludur. Kaos mühendisliği test etme fikri olarak anlaşılabilir, ancak testçiler tarafından yapılması zorunlu değildir.SRE, Ar-Ge, teknik destek ve hatta operasyonlar olabilir.
Hayır, kaos mühendisliğine gerek yok mu?
Burada sözde hayır, daha düşük frekanslı yinelemeler ve hassas iş değişiklikleri olarak anlaşılabilir. Yukarıda bahsedildiği gibi, Netflix'in kaos mühendisliği keşfi, veri merkezlerinin buluta geçiş sürecinden kaynaklandı.Bu nedenle birçok şirket, büyük ölçekli bulut geçişi yapılmadığı sürece kaos mühendisliği uygulamasına gerek olmadığına inanıyor.
Aslında bu fikir çok tek taraflı. İster radikal bir mimari değişiklik ister nazik bir sistem yinelemesi olsun, birçok sorun buluta geçiş nedeniyle değil, yalnızca buluta geçiş nedeniyle ortaya çıktı.
Bir üretim ortamında gerçekten dağıtılmış bir sistemi çalıştırma deneyimine sahip olduğunuz sürece, dağıtılmış sistemin doğası gereği çok sayıda etkileşim ve bağımlılık içerdiğini ve sabit disk arızası, ağ arızası ve trafik dalgalanması gibi sayısız yanlış gidebilecek yer olduğunu bileceksiniz. İnsan gücü, arızaların meydana gelmesini tamamen engelleyemez. Bunun yerine, anormal davranış tetiklenmeden önce sistemdeki mümkün olduğunca çok sayıda zayıf ve hataya açık bağlantı tanımlamalıyız.
Netflix'in uygulamasına göre, sistemleri ve hizmetleri bozmaya çalışmak basittir, ancak hepsi yapıcı ve verimli bir şekilde bulunamaz. Zhou Yang, Chaos Engineering'in bulutla çok az ilgisi olduğuna inanıyor, ancak çoğu şirket şu anda bulut geçişinin farklı aşamalarında, buluta hazır ya da bulutta yerel.Bulut geçişi durdurulamaz bir eğilim haline geldi ve bu aşama sadece bir başarısızlık. Salgının görülme sıklığının yüksek olduğu dönemde, bu sorunlar uzun süre sistemde gizli kalabilir, ancak yoğun bir şekilde keşfedilmemiştir. Değişikliklere odaklanmak için buluta giden altyapı seviyesi olmasına rağmen, üst seviye teknoloji platformunun bu süreçte etkilenip etkilenmediğini ve tutarlı olup olmadığını doğrulamak için bazı araçlara ihtiyaç vardır. Kaotik mühendisliğin tanıtımı sorunları önceden ortaya çıkarabilir ve çözebilir, bu da işletmeyi daha kapsamlı hale getirir Dağıtık sistemlerde daha iyi mühendislik tasarımı elde etmek ve sistem esnekliğini sürekli iyileştirmek için bu doğal sistematik olayları anlayın.
Buna ek olarak, Zhou Yang, Kaos Mühendisliği'nin, şirketin sistemin işleyişini önemsemediği sürece büyük şirketlere özel olmadığını vurguladı. Buna karşılık, finans, oyun, e-ticaret ve havacılık gibi işletmelerin hızla geliştiği ve kullanılabilirlik için yüksek gereksinimlere sahip olduğu alanlarda kaotik mühendisliğe daha çok ihtiyaç vardır. Kendi Ar-Ge ekibiniz veya iş ekibiniz küçükse, verimliliği ve çıktı oranını artırmak için kaos mühendisliğine de ihtiyaç vardır.
Alibaba Kaos Mühendisliği Uygulaması
2011'in başlarında, Alibaba e-ticaret, mikro hizmetlerin bağımlılık sorununu, enjeksiyon gerçekleştirme, deneysel verimlilik, iş etkisi vb.'den gelişen hata enjeksiyon teknolojisi yoluyla çözmeye çalışmaya başladı; 2012'de Alibaba, kesinti gerçekleştirmek için aynı şehirde felaket kurtarmayı başlattı. Ağ tatbikatı; 2015'te çevrimiçi olarak farklı yerlerde canlı; 2016'da MonkeyKing, arıza tespiti için kullanıldı; 2019'da Ali açık kaynaklı kaos mühendislik aracı ChaosBlade (Chaos Blade).
Zhou Yang, Ali'nin bunu yapmaya karar vermesinin sebebinin büyük terfi hazırlıklarının yansıması olduğunu söyledi.İçinde sağlam bir sistem ve süreç olmasına rağmen sistemin gerçek koşullar altında istikrarı bilinmemektedir. Bu nedenle Alibaba, kaos mühendisliği yoluyla teknik ve organizasyonel sorunları çözmek için hem yöntemleri hem de teknolojiyi kullanmaya karar verdi.
Uygulamanın ilk günlerinde ekip, mikro hizmetlerin sorununu kaos mühendisliği yoluyla yönetime dayalı olarak çözmeyi umuyordu, çünkü mikro hizmet ayrımı o zamanlar özellikle kapsamlı değildi. Örneğin, bir çekirdek hizmet ile çekirdek olmayan belirli bir hizmet arasında güçlü bir bağımlılık olabilir. Çekirdek olmayan hizmette bir sorun ortaya çıktığında, çekirdek hizmet durdurulabilir. Bu kesinlikle mantıksız ve işletme tarafından kabul edilemez. Bu nedenle ekip, güçlü bağımlılık yönetişimi için kaotik mühendislik getirerek tüm süreci optimize eder.
Bazı temel teknik ekipler de kaos mühendisliği yoluyla konteynerle ilgili sorunları çözmeye çalışır. Zhou Yang, bir bulut hizmeti olarak konteyner platformunun kendisinin PaaS katmanına ait olduğunu ve kaos mühendisliğinin uygulanmasının sistemin kendisinde hiçbir sorun yaşamamasını sağlayabileceğini tanıttı; ikincisi, geleneksel işletmeler buluta gittiğinde uygulamaları konteynerlere dönüştürme süreciyle karşı karşıya kalıyorlar ve tasarım modellerinin değiştirilmesi gerekiyor. İş istikrarı için gereksinimler varsa, kaos mühendisliğinin getirilmesi bu aşamada ortaya çıkan sorunları çözebilir.
Şu anda, Grubun güvenlik üretim ekibi, şirketler arası bir istikrar savaşı olan "baskın tatbikatları" operasyonunda başı çekmeye başladı. Kontrol edilebilir bir ortamda, planlı kavgalar ve plansız baskınlar yoluyla üretim güvenliği mavi ordusu ve iş kızıl ordusu karşı karşıya gelir ve istikrar önlemlerinin kapsamı ve etkinliği gerçek savaş tatbikatları ile kontrol edilir ve kabul edilir.
Tüm geliştirme sürecine dönüp baktığımızda, Zhou Yang daha zor olanın, ekibin tüm kararlılık zincirinin kaos mühendisliği teknolojisi ile birleştirilebileceğini ve platform kararlılığının daha otomatik ve akıllıca geliştirilebileceğini anlamasını sağlamak olduğuna inanıyor. Platform kapasitesi ne kadar kötü olursa, her ekibi desteklemek için işçilik maliyeti o kadar yüksek, platform kapasitesi o kadar yüksek, savunma tepkisi o kadar kötü; ikincisi, ister dahili ister bulut müşterileri olsun, daha fazla kişinin konsepti kabul etmesine ve uygulamasına izin vermektir. Herkes platformun sorunlarını anlayabilir ve Ali ekibi ayrıca dahili istikrar deneyimini platform tabanlı bir yolla dışa aktarmayı umuyor ve ChaosBlade açık kaynaklı.
ChaosBlade 6 yıllık iyileştirme ve uygulama sürecinden geçmiştir ve on binlerce çevrimiçi egzersiz senaryosu biriktirmiştir. Kaos deneysel modelini izleyen ve dağıtılmış sistemlerin hata toleransını ve kurtarılabilirliği geliştirmesine yardımcı olmak için zengin hata senaryoları sağlayan bir kaos mühendisliği aracıdır. Basit operasyon, invaziv olmama ve güçlü ölçeklenebilirlik ile karakterizedir. Apache Lisansı v2.0 açık kaynak anlaşmasına göre, şu anda iki depo vardır: chaosblade ve chaosblade-exe-jvm ve C ++ ve Node.js gibi diğer dillerdeki kaos deney yürüticileri daha sonra eklenecektir.
Şu anda, kaos mühendisliği alanında kube-monkey, ChaosIQ, vb. Gibi birçok mükemmel açık kaynak aracı ortaya çıkmıştır, ancak birçok açık kaynak aracının işlevleri büyük ölçüde örtüşmüştür veya gerçek talepleri karşılamak zordur. Ali, tüm hata senaryolarını çözmek için bir takım araç sistemlerinin kullanılabileceğini umuyor.Gelecekte, açık kaynak topluluğunun gücü, deneysel senaryoları iyileştirmek ve kaotik mühendislik alanının gelişimini ortaklaşa desteklemek için kullanılabilir.
Zhou Yang, AHAS'ın (Alibaba Bulut Uygulaması Yüksek Kullanılabilirlik Hizmeti) İş istikrarı için bulut hizmetleri , Bu şirketler için çok önemli. Kuruluşlar, yalnızca istikrarlı altyapının keyfini çıkarmak için değil, aynı zamanda iş istikrarını sağlamak için de buluta gidiyor. Çok az üretici bunu fark etti. AHAS'ın ortaya çıkışı, geliri artırmak değil, bulut kullanıcılarına daha iyi yardımcı olmaktır. Bir bulut yerel sistemi oluşturmalısınız.
Şu anda ChaosBlade mevcut ve hızlı bir gelişim aşamasında.Ekip, mikro hizmetler, kapsayıcılar ve yerel bulut rotasında yineleyerek her hafta bir sürüm yayınlayacak. Yakın gelecekte proje, JVM alıştırma senaryolarını geliştirecek; Redis, gRPC gibi daha genel Java ürünlerini destekleyecek; Kubernetes egzersiz senaryolarını geliştirecek ve C ++, Node.js ve diğer uygulamalar için destek sağlayacaktır. Zhou Yang, ekibin daha çok benzer düşünen arkadaşların katılacağını umduğunu ve ilgilenen arkadaşların Github platformu aracılığıyla proje hakkında bilgi edinebileceğini açıkladı.
Önerilen Kaynaklar
Alibaba Kubernetes küme sorun giderme fikirleri ve yöntemleri
Makaleyi görüntülemek için lütfen tıklayınız. daha fazlasını anla
