Not. tercüme: Bu makale, BT sistemlerindeki arızaların sonuçlarını hafifletmek için denemelerin önemini basit ve net bir şekilde açıklamaya çalışan AWS teknoloji savunucusu Adrian Hornsby'nin harika makale serisinin devamı niteliğindedir.
“Eğer bir plan hazırlamakta başarısız olursanız, başarısız olmayı planlamış olursunuz.” - Benjamin Franklin
В Bu yazı dizisinde kaos mühendisliği kavramını tanıttım ve sistemdeki kusurların üretim hatalarına yol açmadan önce bulunup düzeltilmesine nasıl yardımcı olduğunu anlattım. Ayrıca kaos mühendisliğinin organizasyonlar içinde olumlu kültürel değişimi nasıl teşvik ettiği de tartışıldı.
İlk bölümün sonunda “sistemlere arıza vermenin araç ve yöntemleri”nden bahsedeceğime söz verdim. Ne yazık ki kafamın bu konuda kendi planları vardı ve bu yazıda kaos mühendisliğine girmek isteyenler arasında ortaya çıkan en popüler soruyu cevaplamaya çalışacağım: İlk önce ne kırılmalı?
Harika soru! Ancak bu pandadan pek de rahatsız olmuş gibi görünmüyor...
Kaos pandasına bulaşmayın!
Kısa cevap: İstek yolu boyunca kritik hizmetleri hedefleyin.
Daha uzun ama daha net cevap: Kaos denemelerine nereden başlayacağınızı anlamak için üç alana dikkat edin:
- Bak kilitlenme geçmişi ve kalıpları tanımlayın;
- Karar verilen kritik bağımlılıklar;
- Sözde kullanın aşırı güven etkisi.
Komik ama bu kısım da aynı kolaylıkla adlandırılabilir "Kendini Keşfetmeye ve Aydınlanmaya Yolculuk". İçinde bazı harika enstrümanlarla “çalmaya” başlayacağız.
1. Cevap geçmişte yatıyor
Hatırlarsanız, ilk bölümde Hataların Düzeltilmesi (COE) kavramını tanıtmıştım - hatalarımızı - teknoloji, süreç veya organizasyondaki hataları - nedenlerini anlamak ve önlemek için analiz ettiğimiz bir yöntem. gelecekte tekrarlanması. Genel olarak başlamanız gereken yer burasıdır.
"Bugünü anlamak için geçmişi bilmeniz gerekir." - Carl sagan
Arızaların geçmişine bakın, bunları COE'de veya otopsilerde etiketleyin ve sınıflandırın. Çoğunlukla sorunlara yol açan ortak kalıpları belirleyin ve her bir COE için kendinize şu soruyu sorun:
“Bu öngörülebilir miydi ve dolayısıyla hata enjeksiyonu ile önlenebilir miydi?”
Kariyerimin başlarında bir başarısızlığı hatırlıyorum. Birkaç basit kaos deneyi yapmış olsaydık bu kolaylıkla önlenebilirdi:
Normal koşullar altında arka uç örnekleri, durum denetimlerine yanıt verir. ). ELB, istekleri sağlıklı örneklere yönlendirmek için bu kontrolleri kullanır. Bir örneğin "sağlıksız" olduğu ortaya çıktığında ELB, ona istek göndermeyi durdurur. Başarılı bir pazarlama kampanyasının ardından bir gün trafik hacmi arttı ve arka uçlar durum kontrollerine normalden daha yavaş yanıt vermeye başladı. Söylemek gerekir ki bu sağlık kontrolleri yani bağımlılıkların durumu kontrol edildi.
Ancak bir süreliğine her şey yolundaydı.
Daha sonra, zaten oldukça stresli koşullar altında, bulut sunucularından biri kritik olmayan, düzenli bir ETL cron görevini yürütmeye başladı. Yüksek trafik ve cronjob birleşimi CPU kullanımını neredeyse %100'e çıkardı. CPU'nun aşırı yüklenmesi, durum kontrollerine verilen yanıtları daha da yavaşlattı; öyle ki ELB, örneğin performans sorunları yaşadığına karar verdi. Beklendiği gibi dengeleyici kendisine trafik dağıtmayı bıraktı ve bu da gruptaki geri kalan örneklerin yükünün artmasına neden oldu.
Aniden diğer tüm örnekler de sağlık kontrolünden geçememeye başladı.
Yeni bir örneğin başlatılması, paketlerin indirilip kurulmasını gerektiriyordu ve ELB'nin bunları otomatik ölçeklendirme grubunda tek tek devre dışı bırakmasından çok daha uzun sürüyordu. Kısa sürede tüm sürecin kritik bir noktaya ulaştığı ve uygulamanın çöktüğü açıktır.
Sonra sonsuza dek aşağıdaki noktaları anladık:
- Yeni bir örnek oluştururken yazılımı yüklemek uzun zaman alır; değişmez yaklaşımı tercih etmek daha iyidir ve .
- Zor durumlarda, sağlık kontrollerine ve ELB'lere verilen yanıtlar öncelikli olmalıdır; isteyeceğiniz son şey, geri kalan durumlarda hayatı karmaşık hale getirmektir.
- Durum kontrollerinin yerel olarak önbelleğe alınması çok yardımcı olur (birkaç saniye için bile olsa).
- Zor bir durumda cron görevlerini ve diğer kritik olmayan işlemleri çalıştırmayın; kaynakları en önemli görevler için saklayın.
- Otomatik ölçeklendirme sırasında daha küçük örnekler kullanın. 10 küçük örnekten oluşan bir grup, 4 büyük örnekten oluşan bir gruptan daha iyidir; bir örnek başarısız olursa, ilk durumda trafiğin %10'u 9 noktaya, ikinci durumda ise trafiğin %25'i üç noktaya dağıtılacaktır.
Bu durumda, Bu öngörülebilir miydi ve dolayısıyla sorunun ortaya çıkmasıyla engellenebilir miydi?
Evetve çeşitli şekillerde.
İlk olarak, aşağıdaki gibi araçları kullanarak yüksek CPU kullanımını simüle ederek: veya :
❯ stress-ng --matrix 1 -t 60s
stres
İkinci olarak, örneği aşırı yükleyerek ve diğer benzer yardımcı programlar:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
Deneyler nispeten basittir, ancak gerçek bir başarısızlığın stresini yaşamak zorunda kalmadan, düşünmek için iyi bir besin sağlayabilir.
Ancak orada durma. Kilitlenmeyi bir test ortamında yeniden oluşturmayı deneyin ve şu soruya verdiğiniz cevabı kontrol edin:Bu öngörülebilir miydi ve dolayısıyla bir hata getirilerek engellenebilir miydi?" Bu, varsayımları test etmek için bir kaos deneyi içindeki mini bir kaos deneyidir, ancak başarısızlıkla başlar.
Bu bir rüya mıydı, yoksa gerçekten oldu mu?
Öyleyse başarısızlıkların geçmişini inceleyin, analiz edin MÖ, bunları "isabet yarıçapına" (veya daha doğrusu etkilenen müşteri sayısına) göre etiketleyip sınıflandırın ve ardından kalıpları arayın. Sorunun ortaya çıkmasıyla bunun tahmin edilip önlenebileceğini kendinize sorun. Cevabını kontrol et.
Daha sonra en geniş aralığa sahip en yaygın modellere geçin.
2. Bir bağımlılık haritası oluşturun
Başvurunuz hakkında düşünmek için bir dakikanızı ayırın. Bağımlılıklarının net bir haritası var mı? Bir başarısızlık durumunda bunların ne gibi etkileri olacağını biliyor musunuz?
Uygulamanızın koduna pek aşina değilseniz veya çok büyük hale geldiyse, kodun ne yaptığını ve bağımlılıklarının neler olduğunu anlamak zor olabilir. Bu bağımlılıkları ve bunların uygulama ve kullanıcılar üzerindeki olası etkilerini anlamak, kaos mühendisliğine nereden başlayacağınızı bilmek açısından kritik öneme sahiptir: başlangıç noktası, en büyük etki yarıçapına sahip bileşendir.
Bağımlılıkların belirlenmesi ve belgelenmesine " denirbağımlılık haritası oluşturma» (bağımlılık haritalaması). Bu genellikle kod profili oluşturma araçları kullanılarak geniş kod tabanına sahip uygulamalar için yapılır. (kod profili oluşturma) ve enstrümantasyon (enstrümantasyon). Ağ trafiğini izleyerek de bir harita oluşturabilirsiniz.
Ancak tüm bağımlılıklar aynı değildir (bu da süreci daha da karmaşık hale getirir). Bazı kritik, diğer - ikincil (en azından teoride, çökmeler genellikle kritik olmadığı düşünülen bağımlılıklarla ilgili sorunlar nedeniyle meydana geldiğinden).
Kritik bağımlılıklar olmadan hizmet çalışamaz. Kritik olmayan bağımlılıklar "yapmamalı» Düşme durumunda hizmeti etkilemek için. Bağımlılıkları anlamak için uygulamanız tarafından kullanılan API'leri net bir şekilde anlamanız gerekir. Bu, en azından büyük uygulamalar için göründüğünden çok daha zor olabilir.
Tüm API'leri inceleyerek başlayın. En çok vurgulayın önemli ve kritik... Almak bağlı kod deposundan kontrol edin bağlantı günlükleri, ardından görüntüle belgeleme (tabii ki, eğer varsa - aksi halde halaоdaha büyük sorunlar). Araçları kullanarak profil oluşturma ve izleme, harici aramaları filtreleyin.
Gibi programları kullanabilirsiniz netstat - sistemdeki tüm ağ bağlantılarının (etkin yuvalar) listesini görüntüleyen bir komut satırı yardımcı programı. Örneğin, tüm mevcut bağlantıları listelemek için şunu yazın:
❯ netstat -a | more
AWS'de kullanabilirsiniz (akış günlükleri) VPC, bir VPC'deki ağ arayüzlerine giden veya ağ arayüzlerinden giden IP trafiği hakkında bilgi toplamanıza olanak tanıyan bir yöntemdir. Bu tür günlükler, örneğin belirli trafiğin neden örneğe ulaşmadığı sorusuna yanıt bulmak gibi diğer görevlerde de yardımcı olabilir.
Ayrıca kullanabilirsiniz . X-Ray ayrıntılı, "nihai" görüntü elde etmenizi sağlar (uçtan uca) uygulamada ilerledikçe isteklere genel bakış sağlar ve ayrıca uygulamanın temel bileşenlerinin bir haritasını oluşturur. Bağımlılıkları tanımlamanız gerekiyorsa çok kullanışlıdır.
AWS X-Ray Konsolu
Ağ bağımlılık haritası yalnızca kısmi bir çözümdür. Evet, hangi uygulamanın hangisiyle iletişim kurduğunu gösterir ancak başka bağımlılıklar da vardır.
Birçok uygulama bağımlılıklara bağlanmak için DNS'yi kullanırken diğerleri hizmet bulmayı ve hatta yapılandırma dosyalarındaki sabit kodlanmış IP adreslerini kullanabilir (örn. /etc/hosts).
Örneğin, oluşturabilirsiniz üzerinden iptables ve neyin kırıldığını görün. Bunu yapmak için aşağıdaki komutu girin:
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
DNS kara deliği
Eğer /etc/hosts veya diğer yapılandırma dosyalarında, hakkında hiçbir şey bilmediğiniz IP adreslerini bulacaksınız (evet, ne yazık ki bu da oluyor), tekrar kurtarmaya gelebilirsiniz iptables. Diyelim ki keşfettiniz 8.8.8.8 ve bunun Google'ın genel DNS sunucusu adresi olduğunu bilmiyorum. Kullanarak iptables Aşağıdaki komutları kullanarak bu adrese gelen ve giden trafiği engelleyebilirsiniz:
❯ iptables -A INPUT -s 8.8.8.8 -j DROP -m comment --comment "Reject from 8.8.8.8"
❯ iptables -A OUTPUT -d 8.8.8.8 -j DROP -m comment --comment "Reject to 8.8.8.8"
Erişim kapatılıyor
İlk kural, tüm paketleri Google'ın genel DNS'sinden çıkarır: ping çalışıyor ancak paketler iade edilmiyor. İkinci kural, sisteminizden kaynaklanan tüm paketleri, yanıt olarak Google'ın genel DNS'sine bırakır. ping alırız Çalışma izin verilmez.
Not: Bu özel durumda kullanmak daha iyi olurdu whois 8.8.8.8ama bu sadece bir örnek.
Tavşan deliğinin daha da derinlerine inebiliriz çünkü TCP ve UDP kullanan her şey aslında IP'ye de bağlıdır. Çoğu durumda IP, ARP'ye bağlıdır. Güvenlik duvarlarını unutmayın...
Kırmızı hapı alırsan Harikalar Diyarında kalırsın, ben de sana tavşan deliğinin ne kadar derin olduğunu göstereceğim."
Daha radikal bir yaklaşım ise kesmek Arabaları birer birer ve neyin bozulduğunu görün... bir "kaos maymunu" haline gelin. Elbette pek çok üretim sistemi bu kadar kaba kuvvet saldırısı için tasarlanmamıştır ancak en azından bir test ortamında denenebilir.
Bir bağımlılık haritası oluşturmak genellikle çok uzun bir iştir. Geçenlerde yüzlerce mikro hizmet ve komut için yarı otomatik olarak bağımlılık haritaları oluşturan bir araç geliştirmek için neredeyse 2 yılını harcayan bir müşteriyle konuştum.
Ancak sonuç son derece ilginç ve faydalıdır. Sisteminiz, bağımlılıkları ve işlemleri hakkında çok şey öğreneceksiniz. Tekrar ediyorum sabırlı olun; en önemli şey yolculuğun kendisidir.
3. Aşırı özgüvene dikkat edin
"Kim neyi hayal ederse ona inanır." — Demosthenes
Hiç duydun mu aşırı güven etkisi?
Wikipedia'ya göre aşırı güven etkisi, "bir kişinin eylemlerine ve kararlarına olan güveninin, özellikle güven düzeyi nispeten yüksek olduğunda, bu kararların nesnel doğruluğundan önemli ölçüde daha fazla olduğu bilişsel bir önyargıdır."
İçgüdü ve tecrübeye dayalı...
Deneyimlerime dayanarak, bu çarpıklığın kaos mühendisliğine nereden başlanacağına dair harika bir ipucu olduğunu söyleyebilirim.
Kendine aşırı güvenen operatöre dikkat edin:
Charlie: "Bu şey beş yıldır düşmedi, her şey yolunda!"
Crash: "Bekle... Yakında orada olacağım!"
Aşırı güvenin bir sonucu olarak ortaya çıkan önyargı, onu etkileyen çeşitli faktörler nedeniyle sinsi ve hatta tehlikeli bir şeydir. Bu, özellikle ekip üyeleri bir teknolojiye yüreklerini adadıklarında veya onu "düzeltmek" için çok zaman harcadıklarında geçerlidir.
Özetliyor
Kaos mühendisliği için bir başlangıç noktası arayışı her zaman beklenenden daha fazla sonuç getirir ve işleri çok çabuk bozmaya başlayan ekipler (kaos-)'un daha küresel ve ilginç özünü gözden kaçırırlar.mühendislik - yaratıcı kullanım bilimsel yöntemler и ampirik kanıtlar (yazılım) sistemlerinin tasarımı, geliştirilmesi, işletilmesi, bakımı ve iyileştirilmesi için.
Böylece ikinci bölüm tamamlanıyor. Lütfen yorum yazın, fikirlerinizi paylaşın veya sadece alkışlayın . Bir sonraki bölümde ben gerçekten Arızaları sistemlere sokmak için araçları ve yöntemleri ele alacağım. Değin!
çevirmenden PS
Blogumuzda da okuyun:
- «";
- «";
- «";
- «'.
Kaynak: habr.com