Kendilerini rasgele öldürecek programlar tasarlamalı mıyız? [kapalı]

Kısaca, genel sistemin iyiliği için programlarımıza, süreçlerimize ve konularımıza düşük seviyelerde ölüm tasarlamalı mıyız?

Arızalar olur. İşlemler ölür. Afeti planlıyoruz ve bazen ondan kurtarıyoruz. Ancak, nadiren öngörülemeyen program ölümü tasarlar ve uygularız. Hizmetlerimizin çalışma sürelerinin, çalışmalarını sürdürmeye özen gösterdiğimiz sürece devam edeceğini umuyoruz.

Bu konseptin makro örneği, bazı senaryolarda AWS örneklerini rastgele sonlandıran Netflix'in Kaos Maymunu'dur. Bunun, sorunları keşfetmelerine ve daha fazla gereksiz sistemler oluşturmalarına yardımcı olduğunu iddia ediyorlar.

Bahsettiğim şey daha düşük seviye. Fikir, geleneksel olarak uzun süre çalışan işlemlerin rastgele çıkması içindir. Bu, fazlalığı tasarıma zorlamalı ve sonuçta daha esnek sistemler üretmelidir.

Bu kavramın zaten bir adı var mı? Endüstride zaten kullanılıyor mu?

DÜZENLE

Yorum ve cevaplara göre, korkarım sorum açık değildi. Açıklık için:

• evet, rasgele demek istiyorum
• evet, üretimde demek istiyorum ve
• hayır, sadece test için değil.

Açıklamak için, çok hücreli organizmalara bir benzetme yapmak istiyorum.

Doğada organizmalar birçok hücreden oluşur. Hücreler fazlalık yaratmak için kendilerini çatallar ve sonunda ölürler. Fakat organizmanın çalışması için her zaman doğru türden yeterli hücre bulunmalıdır. Bu çok yedekli sistem aynı zamanda yaralandığında iyileşmeyi kolaylaştırır. Hücreler ölür böylece organizma yaşar.

Rasgele ölümün bir programa dahil edilmesi, büyük sistemi uygulanabilirlik konusunda fazlalık stratejileri kabul etmeye zorlar. Bu aynı stratejiler sistemin diğer öngörülemeyen başarısızlıklar karşısında istikrarlı kalmasına yardımcı olur mu?

Ve eğer biri bunu denediyse, buna ne denir? Zaten varsa, bunun hakkında daha fazla okumak istiyorum.

Hayır.

Programların bu istisnai koşulları iyi bir şekilde ele aldığını doğrulamak için uygun kötü yollu yol tutuşu tasarlamalı ve test durumları (ve diğer işlem iyileştirmeleri) tasarlamalıyız. Kaos Monkey gibi şeyler bunun bir parçası olabilir, ancak en kısa sürede yapmak gibi bir "rasgele çökecek gerekir" şartı fiili rastgele çöker test böcek olarak dosya olamaz nesnelere dönüşür.

Hata tolerans mekanizmalarını test etmek için yazılım veya donanımda hataların ortaya çıkması sürecine hata enjeksiyonu denir .

Wikipedia'dan:

Hata enjeksiyon tekniği, ilk olarak donanım seviyesinde hatalara neden olmak için kullanıldığı 1970'lere dayanır. Bu tip hata enjeksiyonuna Donanım Uygulamalı Hata Enjeksiyonu (HWIFI) adı verilir ve bir sistemdeki donanım arızalarını simüle etmeye çalışır. Donanım hatası enjeksiyonundaki ilk deneyler devre kartlarındaki bağlantıları kısaltmak ve sistem üzerindeki etkiyi gözlemlemekten başka bir şey içermiyordu (köprüleme hataları). Öncelikle donanım sisteminin güvenilirliğinin bir testi olarak kullanılmıştır. Daha sonra devre kartının belirli alanlarını ağır radyasyonla bombalayan cihazlar gibi bu tekniği genişletmek için özel bir donanım geliştirildi. Kısa sürede hataların yazılım teknikleriyle indüklenebileceği ve bu tekniğin yönlerinin yazılım sistemlerini değerlendirmek için yararlı olabileceği bulundu.

Evet. Hayır belki.

Periyodik sonlandırma, iki ucu keskin bir kılıçtır. Bir kenarla ya da diğer tarafla vurulacaksınız ve bu iki kötülüğün daha az olduğu durumunuza bağlıdır.

Bir kenarı güvenilirlik: Eğer programı rastgele (veya tahmin edilebilir şekilde) ve düzenli bir şekilde bitmeye zorlarsanız, o olaya hazırlanabilir ve onunla başa çıkabilirsiniz. Yararlı bir şeyler yapmakla meşgul olmadığında işlemin sona ereceğini garanti edebilirsiniz. Bu aynı zamanda, izin verilen çalışma süresinin ötesinde kendini gösterecek olan böceklerin, çirkin kafalarını üretimde desteklemeyeceğini garanti eder, bu iyi bir şeydir. Apache HTTPD, sonlandırmadan önce bir alt sürecin (veya daha yeni sürümlerde iş parçacığının) ne kadar istekte bulunacağını ayarlayabilmenizi sağlayan bir ayara sahiptir.

Diğer avantaj da güvenilirliktir: Programın uzun sürmesine izin vermezseniz, zaman içinde kendini gösteren hataları asla bulamazsınız. Sonunda bu hatalardan birine rastladığınızda, programın yanlış bir cevap vermesine veya bir tanesini geri getirememesine neden olması çok daha olasıdır. Daha da kötüsü, aynı işin birçok iş parçacığını çalıştırırsanız, zamana ya da sayıma bağlı bir hata, aynı anda çok sayıda görevi etkileyebilir ve ofise 03:00 bir gezi yapmasına neden olabilir.

Aynı konuların çoğunu çalıştırdığınız bir ortamda (örneğin bir web sunucusunda) pratik çözüm, kabul edilebilir bir başarısızlık oranıyla sonuçlanan karışık bir yaklaşım izlemektir. 100 iş parçacığı çalıştırırsanız, 99: 1 kısa-uzun bir oranı çalışan, yalnızca birinin uzun vadeli hatalar göstereceği anlamına gelirken, diğerleri başarısız olduklarında ne yaparsa yapsınlar. % 100 uzunluğa sahip koşarken, tüm ipliklerin aynı anda başarısız olma riskinin çok yüksek olduğu yerlerde kullanın.

Tek bir iş parçacığına sahip olduğunuzda, çalışmasına ve başarısız olmasına izin vermek muhtemelen daha iyidir, çünkü yeniden başlatma sırasındaki ölü zaman başarılı bir şekilde tamamlanacak gerçek bir iş olduğunda istenmeyen gecikmeye neden olabilir.

Her iki durumda da, süreçleri denetleyen bir şey olması önemlidir, böylece hemen yeniden başlatılabilirler. Ayrıca, bir sürecin ne kadar sürmesi gerektiği konusundaki ilk kararlarınızın taş atılması gerektiğini söyleyen bir yasa yoktur. Operasyonel verileri toplamak, sisteminizi arızaları kabul edilebilir bir seviyede tutmak için ayarlamanıza yardımcı olacaktır.

Rasgele sona ermeyi tavsiye ederim, çünkü zamanla ilgili hataları azaltmayı zorlaştırıyor. Chaos Monkey, biraz farklı bir sorun olan denetleyici yazılımın çalıştığından emin olmak için bunu yapar.

Gerçekten rastgele mi demek istiyorsun? Yazılımınızın rastgele kendisini öldürmesi korkunç bir fikir gibi görünüyor. Bu hangi noktaya hizmet eder?

Gerçekten demek istediğin, uzun süren iş parçacıkları / süreçleri konusunda gerçekçi olmamız gerektiği ve uzun süre çalıştıkları, bir tür gizli hatayla karşılaşmaları ve işlevsel olmayan bir duruma girmeleri ihtimalinin yüksek olduğunu kabul etmemiz olduğunu tahmin ediyorum. durum. Bu nedenle, tamamen pragmatik bir önlem olarak, işlemlerin ve dişlerin ömrü sınırlı olmalıdır.

90'ların sonunda Apache web sunucusunun böyle bir şey kullandığına inanıyorum. Bir işçi süreçleri havuzu (iş parçacığı değil) vardı ve her işçi süreci sabit bir ömür sonunda öldürülecekti. Bu, sunucuyu bazı patolojik durumlarda sıkışıp kalmış işçi işlemleriyle tekelleşmekten alıkoydu.

Bölgede bir süredir çalışmadım, bu yüzden hala böyle olup olmadığını bilmiyorum.

Gördüğüm sorun, eğer böyle bir program ölürse, "Ah başka bir rastgele sonlandırma - endişelenecek bir şey yok" deriz. Ama ya düzeltilmesi gereken gerçek bir sorun varsa ? Görmezden gelinir.

Zaten "rastgele" olan programlar, mystaykes yapan, onu üretim sistemlerine dönüştüren hatalara, donanım arızalarına vb. Bağlı olarak başarısız oluyor. Bu gerçekleştiğinde, bunu düzeltmek için bunu bilmek istiyoruz. Ölümleri programlara dahil etmek yalnızca başarısızlık olasılığını arttırır ve bizi fazlalığı arttırmaya zorlar ve bu da paraya mal olur.

Yedekli bir sistemi test ederken (bunun olduğundan daha fazla olması gerekir) test ortamında rastgele öldürme işlemlerinde yanlış bir şey göremiyorum, ancak üretim ortamında değil. Birkaç günde bir birkaç sabit sürücüyü canlı bir üretim sisteminden çıkarabilir miyiz, yoksa uçaklardan biriyle yolcu uçarken uçacak mıyız? Bir test senaryosunda - iyi. Canlı bir üretim senaryosunda - yapmamayı tercih ederim.

Uygulamaya rasgele çıkış kodu eklemek gerekli değildir. Test cihazları, uygulamanın işlemlerini rastgele öldüren komut dosyaları yazabilir.

Ağ oluşturmada, bir protokol uygulamasının test edilmesi uğruna güvenilmez bir ağı simüle etmek gerekir. Bu protokolün içine girmiyor; Aygıt sürücüsü düzeyinde veya bazı harici donanımlarla simüle edilebilir.

Test kodu eklemeyin, harici olarak elde edilebilecek durumlar için programı yapın.

Bu üretime yönelikse, bunun ciddi olduğuna inanamıyorum!

İlk olarak, süreçler aniden çıkmadığı sürece devam eden işlemler ve geçici veriler kaybedilirse, bu kavramın dürüst bir uygulaması değildir. Planlı, zarif çıkışlar, rastgele zamanlanmış olsalar bile, zarif olmayan gerçek kazalarla başa çıkmak için mimarinin hazırlanmasına yeterince yardımcı olmazlar.

Gerçek veya gerçekçi arızalar uygulamaya dahil edilirse, tıpkı gerçek arızalar gibi ekonomik zararla sonuçlanabilir ve amaçlı ekonomik zarar, temel olarak neredeyse tanım olarak suç teşkil eden bir eylemdir .

Yazılımın kullanımından kaynaklanan herhangi bir zarardan hukuki sorumluluktan feragat eden lisans sözleşmesindeki hükümlerden kurtulmak mümkün olabilir, ancak bu zararlar tasarım gereği ise ceza yükümlülüğünden feragat edemezsiniz.

Bunun gibi dublörleri bile düşünmeyin: Yapabildiğiniz kadar güvenilir çalışmasını sağlayın ve sahte başarısızlık senaryolarını yalnızca özel yapılara veya yapılandırmalara koyun.

Hataya toleranslı dağıtılmış sistemler bağlamında " proaktif iyileşme " ve " gençleştirme " yi aramak , rastgele hatalarla uğraşmak isteyebilirsiniz (örneğin, yalnızca çökmüş süreçler değil, bozuk veriler ve potansiyel olarak kötü niyetli davranışlar). Bir sürecin (soyut anlamda, aslında bir VM veya ana bilgisayar olabilir) ne sıklıkta ve hangi koşullarda yeniden başlatılması gerektiği konusunda çok sayıda araştırma yapılmıştır. Sezgisel olarak, bir hain süreçten ziyade ölü bir süreçle başa çıkmayı tercih eden yaklaşımın avantajlarını anlayabilirsiniz ...

Bu gerçekten testten farklı değil. Her zaman kullanılabilir bir yük devretme çözümü tasarlıyorsanız (Netflix gibi), o zaman evet - test etmelisiniz. Kod temeli üzerine serpilmiş rastgele çıkışların bunu test etmenin uygun bir yolu olduğunu bilmiyorum. Tasarımınızın kendinizi ayağınıza çekmeye dirençli olduğunu test etme niyetinde olmadığınız sürece , kod etrafındaki ortamı manipüle ederek ve uygun şekilde davrandığını doğrulayarak test etmek daha uygun olur .

Gereksiz sistemler tasarlamıyorsanız, hayır - bu özelliği eklememelisiniz, çünkü bazı rastgele çıkışlar eklediniz. Sadece rastgele çıkışları silmelisin ve o zaman bu problemle karşılaşmayacaksın. Ortamınız hala size karşı başarısız olabilir, bu noktada onu desteklenmeyen olarak işaretleyeceksiniz / düzeltmeyecek veya kodunuzu bu arızaya karşı sertleştirecek ve bunun için bir test ekleyeceksiniz. Yeterince sık Bunu yap ve sen aslında fark edeceksiniz olan gereksiz bir sistem tasarımı - senaryo 1. bkz.

Bir noktada, hangi arızaların ele alındığından ya da geçilmediğinden emin olmadığınızı belirleyebilirsiniz. Artık arızayı tespit etmek için halıyı rastgele çekerek başlatabilirsiniz.

Netflix örneğiyle ilgili tek ilginç şey, bu testleri üretimde gerçekleştirmeleridir. Belli bir anlam ifade ediyor - bazı böcekler yalnızca izole bir ortamda simüle edilmesi çok zor veya imkansız olan şeyler üretiyorlar. Netflix'in üretim ortamında bunu yapacak kadar rahat olmadan önce test ortamlarında uzun zaman geçirdiğinden şüpheleniyorum. Ve yaptıkları işlerin hepsi mesai saatleri boyunca meydana gelen çökmelere neden oluyor, bu da pazarları için belirli bir anlam ifade ediyor, ancak pek çoğu için değil.

Aradığınız terim son zamanlarda Nassim Nicholas Taleb: Antifragility tarafından oluşturuldu. Antifragile adlı kitabı kesinlikle önerilir. BT'den çok az bahseder, ancak söylenmeyen, belirgin paralellikler en ilham verici olanıdır. Onun fikri, kırılgan <-> kırılgan <-> sağlam <-> antifragil skalasını genişletmektir. Rastgele olaylarla kırılgan kırılmalar, rastgele olaylarla sağlam yönetme ve rastgele olaylarla kırılganlık kazanımları.

Değişir. Programcıların, diğerlerini görmezden geldikleri kendi özel alanlarına uygulanan teknikleri aşırı genelleştirme eğiliminde olduklarını fark ettim. Örneğin, tüm hataları düzeltme pahasına bir programın yayınlanması iyi olabilir ... eğer uçak kontrolörü, nükleer reaktör vb. Göreceli olarak basit bir program aylarca vb. kümeleri kaplayabildiğinden HPC için geçerlidir (veya büyük miktarda kullanıcı tarafından kullanılan popüler bir programdır). X şirketi çok iyi bir nedenden ötürü Y yapıyor olsa bile, durumunuz farklı olabileceğinden ayak izlerini takip etmeniz gerekmez.

Genellikle hata işleme yordamları, kodun en kötü şekilde test edilmiş kısmıdır - basit görünmesine rağmen, yetersiz bellek olduğunu veya bazı önemli dosyaların bulunmadığını taklit etmek zor görünebilir. Bu nedenle, Unix çekirdeğinin bazı sistem çağrılarını rastgele kesmesini öneren metinleri okudum. Bununla birlikte, basit bir programın yazılmasını zorlaştırır (bir programı 2 dosya üzerinde çalıştırmak için 3 C ++ kitaplığını birlikte takmam gerekirse, hata işlemeyle uğraşmak istemiyorum). İstisnalar dışında, GC, tutarlı bir durumu geride bıraktığınızdan emin olmanız gerekir (bağlantılı listeye düğüm eklemenin ortasında bir istisna hayal edin).

Ne kadar çok dağıtılmış servis varsa, o kadar çok başarısızlık “ne sıklıkta” sonra “sonra” veya “ne zaman” sorusudur. Veri merkezlerinde, RAID'lerde disk değiştirme beklenmedik bir hata değil, bildiğim kadarıyla rutin işlemlerin bir parçası. Büyük çapta çalışıyorsanız, bir bileşenin arızalanma olasılığı küçük olsa bile bunu dikkate almanız gerekir, bir şeyin başarısız olacağı ihtimali vardır.

Tam olarak ne yaptığınızı bilmiyorum ama buna değip değmeyeceğini bilmek, başarısızlığın hesaba katmanız gereken bir şey olup olmadığını (maliyeti göz ardı ettiği gibi) ya da analiz etmek için çok pahalı bir şey olduğunu düşünmeniz gerekir (hata almak gibi). maliyet geliştirme süresini hesaba katar).

IIS sunucusu, çalışan işlemlerini belirli miktarda bellek kullandıktan sonra veya belirli sayıda istekleri yerine getirdikten sonra ya da belirli bir zaman dilimi için hayatta olduktan sonra otomatik olarak geri dönüştüren yapılandırılabilir bir özelliğe sahiptir. ( http://msdn.microsoft.com/en-us/library/ms525803(v=vs.90).aspx ) ve ( http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/ 1652e79e-21f9-4e89-bc4b-c13f894a0cfe.mspx = mfr = doğru )

IIS gibi bir KONTEYNER bunu yaptığında, sunucuyu hileli işlemlerden korumak mantıklı olur. Bununla birlikte, bu kodu kapalı tutmayı tercih ederim, çünkü kodunuzu yeterince sınamışsanız, bir anlamı yoktur.

Zaten güvenilmez katmanları (donanım, ağ) üzerinde çalışıyoruz, bu yüzden asla kasıtlı olarak iş parçacığını veya işlemlerini rasgele öldüren herhangi bir kod yazmam. Rastgele öldürme, aynı zamanda ekonomik açıdan da kötü bir fikirdir - rastgele çarpmak için programladığımı düşünürlerse kimse API'mı kullanmaz. Son olarak, eğer bir API tüketmek ya da rastgele çökmekte olan ipliklerle bir sistemi kullanmak isteseydim, geceleri huzur içinde uyuyabilmem için yeterince sağlam bir izleme mekanizması oluşturmak için çok para harcamam gerekirdi.

Bunun yerine, bir sistem veya API geliştiriyor olsaydım, betik yazardım ya da sistemin direncini test etmek için bunu yapacak bir koşum kullanırdım. Ve kötü yapıları tanımlamak için tüm yapılarda böyle bir deneme çalışması yapacağım. Ancak, bu gerekli bir test olsa da, asla "yeterli" bir test olamaz.

Bu fikirle ilgili bir literatür var, Crash-Only yazılımı (aynı zamanda Kurtarma Odaklı Bilgi İşlem) ve bu usenix makalesini 2003'ten itibaren Candea & Fox'tan başlatabilirsiniz. Rasgele öldürmeler yerine, yazarın sistem güvenilirliğini yalnızca programlarınızı öldürerek durdurarak durdurma düğmesi olarak durdurma düğmesi olarak tek bir açma / kapama düğmesi ve toparlanma için iyi bir şekilde çalıştırılan tek bir başlangıç ​​yoluna sahip olmak.

Bu fikrin ne kadar iyi yakalandığından emin olmasam da, belirli tekniklerin bazıları işe yarar. Örneğin, özel denetleme programlarını (örneğin denetçi vb.) Kullanarak, istendiğinde kendi kendini kapatabilecek yazılımınıza güvenmemek ve ayrıca hangi program durumunun gerekli olduğunu dikkatlice düşünmek ve tasarlanan bir veri deposunda uygun zamanlarda kaydedildiğinden emin olmak Kurtarmayı etkinleştirmek için (örneğin, bir sql veritabanı).

Gerçekten rastgele, hayır. Ancak, uzun süreli işlemlerin / iş parçacıklarının belirli bir aralıkta veya belirli bir süre boyunca boşta kaldıktan sonra (ancak belirli ölçütlere bağlı olarak) veya belirli bir görevi yerine getirdikten sonra çıkıp yeniden başlatılması iyi bir fikir olabilir. Uzun süren süreçler kaçınılmaz olarak eski şeyleri de içeren bir durum oluşturur; büyük olasılıkla, çıktıkları zaman genel sistem kararlılığını artırarak, çıktıklarında temizlenecek (veya çıkarması gereken) takas alanını önleyen büyük olasılıkla belleğe takılabilir.

Tasarladığınız uygulamanın türüne bağlıdır.

Rastgele çökmeler, dağıtılmış (ağ bağlantılı) sistemlerin sağlamlığını test etmek ve iyileştirmek için mükemmel bir yoldur.

Netflix örneğinde, programınız kontrolünüz dışındaki çeşitli nedenlerle başarısız olabilecek uzak servislere bağlı olduğunda (sabit disk arızalanır, güç kaybı olur, meteor veri merkezine çarpar vb.). Hizmetiniz yine de bir şekilde çalışmaya devam etmeli.

Bunu nasıl yaptın? Artıklıkta ekleme ve ölçeklendirme yaygın bir çözümdür.

Örneğin, bir fare sunucunuzun elektrik kablosundan çiğnenirse, hizmetinizin çalışmaya devam etmesi için bir çözümü olmalıdır. Örneğin, yerine kullanmaya başlayacağı yedek yedekleme sunucularını tutabilir.

Ancak, programınız bir ağda çalışmayan tek bir işlem uygulamasıysa, kendisini öldürmesi hiçbir şeyi test edemez, çünkü bundan kurtarmanın bir yolu yoktur.

İşte Kaos Maymunları kavramıyla ilgili bazı açıklamalar: http://www.codinghorror.com/blog/2011/04/working-with-the-chaos-monkey.html

Kozmik radyasyon nedeniyle rastgele bir bit çevirme gerçekleşebilir . Bu problem kabul edildi ve bit saygısızlığı önlemek için çeşitli teknikler geliştirildi.

Ancak, bunu% 100 düzeltmek mümkün değildir ve hafıza bozulması hala sorunlara neden olabilir ve bu sorunlar hala devam etmektedir ( çok düşük olasılıkla ).

Şimdi sorunuzu cevaplamak için. Çok sağlam bir sistem tasarlamak isteyip istemediğiniz, ne yaptığınıza bağlıdır. Bir uzay aracı yaratmanız gerekiyorsa, onu süper sağlam kılmanız daha iyi olur ve ardından olası her konuyu dikkate almanız gerekir.

Normal bir masaüstü uygulaması tasarlamanız gerekiyorsa, kodunuzdaki hatalar olarak rastgele çökmelere bakmalısınız.

Bu bir fikrin aldatıcı görünmüyor.

Android işletim sistemi, kullanıcı uygulamalarını / hizmetlerini her zaman rasgele öldürür ve yeniden başlatır. Tecrübelerime göre, daha sağlam mimariler tasarlamanın yanı sıra hata koşulları hakkında daha derin düşünmeme kesinlikle yardımcı oldu.