क्या हमें बेतरतीब ढंग से खुद को मारने के लिए कार्यक्रमों को डिजाइन करना चाहिए? [बन्द है]


76

संक्षेप में, क्या हमें समग्र व्यवस्था की भलाई के लिए मृत्यु को अपने कार्यक्रमों, प्रक्रियाओं और थ्रेड्स को निम्न स्तर पर डिजाइन करना चाहिए?

विफलताएं होती हैं। प्रक्रियाएं मर जाती हैं। हम आपदा की योजना बनाते हैं और कभी-कभी इससे उबर जाते हैं। लेकिन हम शायद ही कभी अप्रत्याशित कार्यक्रम मृत्यु को डिजाइन और कार्यान्वित करते हैं। हमें उम्मीद है कि जब तक हम उन्हें चालू रखने के लिए देखभाल करेंगे, तब तक हमारी सेवाओं में तेजी आएगी।

इस अवधारणा का एक वृहद उदाहरण है नेटफ्लिक्स का कैओस बंदर , जो कुछ परिदृश्यों में AWS के उदाहरणों को अनियमित रूप से समाप्त करता है। उनका दावा है कि इससे उन्हें समस्याओं का पता लगाने और अधिक निरर्थक प्रणाली बनाने में मदद मिली है।

मैं जिस बारे में बात कर रहा हूं वह निचले स्तर का है। यह विचार परंपरागत रूप से लंबे समय से चल रही प्रक्रियाओं के लिए बेतरतीब ढंग से बाहर निकलने के लिए है। यह डिजाइन में अतिरेक को मजबूर कर सकता है और अंततः अधिक लचीला सिस्टम उत्पन्न करता है।

क्या इस अवधारणा का पहले से कोई नाम है? क्या यह पहले से ही उद्योग में उपयोग किया जा रहा है?

संपादित करें

टिप्पणियों और उत्तरों के आधार पर, मुझे डर है कि मैं अपने प्रश्न में स्पष्ट नहीं था। विस्तृत जानकारी के लिए:

  • हां, मेरा मतलब बेतरतीब ढंग से है,
  • हां, मेरा मतलब उत्पादन में है, और
  • नहीं, केवल परीक्षण के लिए नहीं।

समझाने के लिए, मैं बहुकोशिकीय जीवों के लिए एक सादृश्य आकर्षित करना चाहूंगा।

प्रकृति में, जीवों में कई कोशिकाएं होती हैं। कोशिकाएँ अतिरेक पैदा करने के लिए खुद को छोड़ देती हैं, और वे अंततः मर जाती हैं। लेकिन जीव के कार्य करने के लिए हमेशा सही प्रकार की पर्याप्त कोशिकाएं होनी चाहिए। यह अत्यधिक निरर्थक प्रणाली घायल होने पर उपचार की सुविधा भी देती है। कोशिकाएँ मर जाती हैं इसलिए जीव जीवित रहता है।

एक कार्यक्रम में यादृच्छिक मौत को शामिल करना अधिक से अधिक प्रणाली को व्यवहार्य बने रहने के लिए अतिरेक रणनीतियों को अपनाने के लिए मजबूर करेगा। क्या ये वही रणनीतियाँ अन्य प्रकार की अप्रत्याशित असफलता के सामने व्यवस्था को स्थिर रखने में मदद करेंगी?

और, अगर किसी ने यह कोशिश की है, तो इसे क्या कहा जाता है? मैं इसके बारे में और पढ़ना चाहता हूँ अगर यह पहले से मौजूद है।


13
मेरे पास उत्तर के रूप में योगदान करने के लिए कुछ भी उपयोगी नहीं है, लेकिन यह निश्चित रूप से एक दिलचस्प सवाल है। यह निश्चित रूप से एक प्रोग्रामर को एक सभ्य घटक वास्तुकला लिखने के लिए मजबूर करेगा जो कि (सही ढंग से) यादृच्छिक घटक विफलताओं के साथ मुकाबला करता है यदि उन विफलताओं को घटकों की प्रकृति द्वारा स्वयं गारंटी दी गई थी।
टॉम डब्ल्यू

1
अगर मैं सही तरीके से समझूं, तो यह थोड़ा संबंधित हो सकता है: en.wikipedia.org/wiki/Mutation_testing । जबकि उत्परिवर्तन परीक्षण आपके परीक्षणों को कठोर बनाने में मदद करता है, मुझे लगता है कि आप अपने कोड को कठोर बनाने में मदद करने के लिए एक यादृच्छिकता आधारित दृष्टिकोण की तलाश कर रहे हैं।
मेटाफाइट

10
दरअसल, यह अवधारणा कंप्यूटिंग के रूप में पुरानी है, इसका उपयोग हर कार्यक्रम में किया जाता है, और निश्चित रूप से इसका एक नाम है: इसे कहा जाता है: बग
मौविसील

3
यदि आप एक अविश्वसनीय नेटवर्क पर इसका परीक्षण नहीं करते हैं, तो आप संचार प्रोटोकॉल कार्यान्वयन का परीक्षण नहीं करेंगे, जिसे आपके उपकरण विश्वसनीय होने के बाद भी नकली बनाना होगा।
कज़

5
Microsoft ने इसे थोड़ी देर के लिए आज़माया है, वे इसे कोडनेम "विंडोज़" से बुलाते हैं। यदि इसने बेहतर रणनीति बनाई है तो यह बहस का विषय है ... हो सकता है कि इसने इसके बजाय सिर्फ नीची उम्मीदों का उत्पादन किया हो।

जवाबों:


60

नहीं।

हमें इन खराब स्थितियों को अच्छी तरह से संभालने के लिए उचित खराब पथ से निपटने, और डिजाइन परीक्षण के मामलों (और अन्य प्रक्रिया में सुधार) को डिजाइन करना चाहिए। अराजकता बंदर की तरह सामग्री है कि का हिस्सा हो सकता है, लेकिन जैसे ही आप कर एक "अनियमित रूप से क्रैश चाहिए" आवश्यकता वास्तविक यादृच्छिक दुर्घटनाओं बातें परीक्षकों कीड़े के रूप में दर्ज नहीं कर सकते हो जाते हैं।


10
धन्यवाद @Telastyn मुझे लगता है कि दुर्घटना का कारण यहां कारक हो सकता है। एक उद्देश्यपूर्ण मृत्यु दुर्घटना का एक साइड-इफ़ेक्ट (लॉग, एरर कोड, सिग्नल) हो सकता है जो इसे कोड विफलता से अलग करता है।
जंबो

1
यहां तक ​​कि अगर यह एक कमजोरी को उजागर करने में मदद करता है, तो इसका मतलब यह नहीं है कि यह कार्रवाई योग्य है। दोहराने के जोखिम (परिणाम और डिग्री) एक महत्वपूर्ण कारक है कि क्या आप भविष्य की घटना को कम करने के लिए उस बग के साथ कुछ भी करते हैं। यह उच्च जोखिम प्रणालियों के लिए एक दीर्घकालिक मूल्य उपकरण है।
जस्टिन सी सी

यह विचार है कि भले ही उप-घटक बेतरतीब ढंग से दुर्घटनाग्रस्त हों, उपयोगकर्ता को नोटिस नहीं करना चाहिए। इसलिए जब एक परीक्षक रिपोर्ट करता है कि यादृच्छिक दुर्घटनाओं में से एक उनके लिए दिखाई दे रहा था, तो इसका मतलब होगा कि उप-घटक दुर्घटना को पकड़ने में विफलता जो एक फिल्माने योग्य बग होगी।
फिलिप

1
जो प्रस्तावित है वह वास्तव में खराब पथ संचालन का एक जीवित परीक्षण है। कई तैनाती, और नेटफ्लिक्स उदाहरण बिंदु में एक मामला है, यथार्थवादी लोड परीक्षण की आवश्यकता होती है जो कई मामलों में वास्तविक तैनाती के दौरान केवल संभव है। प्रोग्रामेटिक क्रैश स्पष्ट लॉगिंग के साथ पता लगाने में बहुत आसान होगा - ब्याज क्या है संपार्श्विक क्षति और अंतरसंबंधित प्रणालियों पर प्रभाव।
ctpenrose

1
आप एक स्मार्ट रैंडम क्रैशर (जैसे कैओस मंकी) को लागू कर सकते हैं, जो आपको बता सकता है कि कब कोई प्रोग्राम बेतरतीब ढंग से क्रैश हो गया है। इस तरह से आप जानते हैं कि जब आप एक वैध दुर्घटना को मार चुके हैं और जब यह एक स्थिरता परीक्षण दुर्घटना है।
ज़ैन आर

19

दोष सहिष्णुता तंत्र का परीक्षण करने के लिए सॉफ़्टवेयर या हार्डवेयर में दोषों को शुरू करने की प्रक्रिया को दोष इंजेक्शन कहा जाता है

विकिपीडिया से:

गलती इंजेक्शन की तकनीक 1970 के दशक की है जब पहली बार इसका इस्तेमाल हार्डवेयर स्तर पर दोष उत्पन्न करने के लिए किया गया था। इस प्रकार के फॉल्ट इंजेक्शन को हार्डवेयर इंप्लीमेंटेड फॉल्ट इंजेक्शन (HWIFI) कहा जाता है और एक सिस्टम के भीतर हार्डवेयर विफलताओं को अनुकरण करने का प्रयास करता है। हार्डवेयर फॉल्ट इंजेक्शन के पहले प्रयोगों में सर्किट बोर्डों पर कनेक्शन को छोटा करने और सिस्टम पर प्रभाव को देखने (दोषों को कम करने) से अधिक कुछ नहीं था। इसका उपयोग मुख्य रूप से हार्डवेयर सिस्टम की निर्भरता की परीक्षा के रूप में किया जाता था। इस तकनीक का विस्तार करने के लिए बाद में विशेष हार्डवेयर विकसित किया गया था, जैसे कि भारी विकिरण वाले सर्किट बोर्ड के विशिष्ट क्षेत्रों पर बमबारी करने के लिए उपकरण। यह जल्द ही पाया गया कि दोषों को सॉफ्टवेयर तकनीकों द्वारा प्रेरित किया जा सकता है और सॉफ्टवेयर तकनीकों के आकलन के लिए इस तकनीक के पहलू उपयोगी हो सकते हैं।


+ यह दूसरे स्तर के तनाव परीक्षण के रूप में फिट बैठता है। आकस्मिक तनाव के बाद [एक संतोषजनक हद तक] बीतने के बाद, अनपेक्षित वातावरण में बदलाव नहीं होने के कारण कुछ यादृच्छिकता डालें। जब उच्च जोखिम होता है तो यह मूल्यवान हो सकता है (परिणाम की संभावना या गंभीरता)। मैं तब तक जीने के लिए तैनात नहीं होता जब तक कि मैं एक प्रयोगशाला वातावरण में बहुत आश्वस्त नहीं था, और उसके बाद केवल उन हिस्सों के लिए जो मुझे सबसे अधिक विश्वास था,
जस्टिन जेन्स

9

हाँ। किसी तरह की संभावना नहीं।

आवधिक समाप्ति एक दोधारी तलवार है। आप एक किनारे या दूसरे से टकराते जा रहे हैं, और जो दो बुराइयों से कम है वह आपकी स्थिति पर निर्भर करता है।

एक किनारे की विश्वसनीयता है: यदि आप प्रोग्राम को बेतरतीब ढंग से (या अनुमान से) समाप्त करने और एक व्यवस्थित तरीके से बाध्य करते हैं, तो आप उस घटना के लिए तैयार हो सकते हैं और उससे निपट सकते हैं। आप यह गारंटी दे सकते हैं कि यह प्रक्रिया बाहर निकल जाएगी जब यह अन्यथा उपयोगी कुछ करने में व्यस्त नहीं होगा। यह भी गारंटी देता है कि बग्स जो स्वीकृत रन समय से आगे प्रकट होंगे, उत्पादन में अपने बदसूरत सिर को पीछे नहीं करेंगे, जो एक अच्छी बात है। अपाचे HTTPD की एक सेटिंग है जो आपको ट्यून करेगी कि कितने बच्चे अनुरोध (या अधिक हाल के संस्करणों में धागा) को समाप्त करने से पहले अनुरोध करेंगे।

दूसरी धार भी विश्वसनीयता है: यदि आप कार्यक्रम को लंबे समय तक चलाने की अनुमति नहीं देते हैं, तो आपको समय के साथ खुद को प्रकट करने वाले बग नहीं मिलेंगे। जब आप अंत में उन बग्स में से एक में दौड़ते हैं, तो प्रोग्राम के गलत उत्तर देने या एक को वापस करने में विफल होने की संभावना अधिक होती है। इससे भी बदतर, यदि आप एक ही नौकरी के कई धागे चलाते हैं, तो एक समय या गिनती-प्रेरित बग सभी पर बहुत बड़ी संख्या में कार्यों को प्रभावित कर सकते हैं और परिणाम सभी 3 बजे कार्यालय में यात्रा कर सकते हैं।

ऐसी सेटिंग में जहां आप बहुत सारे थ्रेड चलाते हैं (जैसे, वेब सर्वर पर), व्यावहारिक समाधान एक मिश्रित दृष्टिकोण लेना है, जिसके परिणामस्वरूप स्वीकार्य विफलता दर होती है। यदि आप 100 थ्रेड चलाते हैं, तो 99: 1 के शॉर्ट-टू-लॉन्ग रेशियो को चलाने का मतलब है कि केवल एक ही लॉन्ग-टर्म बग प्रदर्शित करेगा, जबकि दूसरे वे जो भी कर रहे हैं, वह बिना किसी असफलता के करते हैं। इसके विपरीत कि 100% लंबे समय तक चलने से, जहाँ आप एक ही समय में सभी थ्रेड के विफल होने का बहुत अधिक जोखिम उठाते हैं।

जहाँ आपके पास एक ही धागा होता है, शायद यह बेहतर है कि इसे केवल चलने दें और विफल रहें, क्योंकि पुनरारंभ के दौरान मृत समय के परिणामस्वरूप अवांछित विलंबता हो सकती है जब ऐसा करने के लिए वास्तविक काम होता है जो सफलतापूर्वक पूरा होगा।

या तो मामले में, यह महत्वपूर्ण है कि प्रक्रियाओं का पर्यवेक्षण करने वाली कोई चीज़ हो ताकि उन्हें तुरंत फिर से शुरू किया जा सके। इसके अलावा, ऐसा कोई कानून नहीं है जो कहता है कि आपके प्रारंभिक निर्णय कितने समय तक चलने चाहिए, इसके लिए पत्थर में डाली जानी चाहिए। परिचालन डेटा एकत्र करना आपको विफलताओं को स्वीकार्य स्तर तक बनाए रखने के लिए आपके सिस्टम को ट्यून करने में मदद करेगा।

मैं रैंडम टर्मिनेशन करने के खिलाफ सिफारिश करूंगा, क्योंकि इससे समय से संबंधित बग्स को खत्म करना मुश्किल हो जाता है। अराजकता बंदर यह सुनिश्चित करने के लिए करता है कि पर्यवेक्षी सॉफ्टवेयर काम करता है, जो थोड़ी अलग समस्या है।


यदि आप एक यादृच्छिक समय अंतराल के बाद प्रक्रिया को मारते हैं जो अनंत में फैलती है, तो कुछ प्रक्रियाएं हमेशा के लिए रहेंगी। इसलिए मुझे नहीं लगता है कि लंबे समय से चली आ रही प्रक्रियाओं के साथ मुद्दों का पता लगाने में बेतरतीब ढंग से हत्याएं असंगत हैं।
जोएरी सेब्रैट्स

9

क्या आप वास्तव में यादृच्छिक मतलब है? अपने सॉफ़्टवेयर को बेतरतीब ढंग से मारना एक भयानक विचार की तरह लगता है। वह किस बिंदु की सेवा करेगा?

मैं अनुमान लगा रहा हूं कि आप वास्तव में क्या मतलब है कि हमें लंबे समय तक चलने वाले धागे / प्रक्रियाओं के बारे में यथार्थवादी होना चाहिए और यह स्वीकार करना चाहिए कि वे जितनी देर तक चलते हैं, उतनी अधिक संभावना है कि वे किसी प्रकार के छिपे हुए बग का सामना कर सकें, और एक गैर-कार्यात्मक में मिल गए। राज्य। तो, एक विशुद्ध रूप से व्यावहारिक उपाय के रूप में, प्रक्रियाओं और थ्रेड्स का जीवनकाल सीमित होना चाहिए।

मेरा मानना ​​है कि 90 के दशक के उत्तरार्ध में अपाचे वेब सर्वर ने कुछ इस तरह से इस्तेमाल किया। उनके पास कार्यकर्ता प्रक्रियाओं (थ्रेड्स नहीं) का एक पूल था और प्रत्येक कार्यकर्ता प्रक्रिया को एक निश्चित जीवनकाल के बाद मार दिया जाएगा। इसने सर्वर को श्रमिक प्रक्रियाओं द्वारा एकाधिकार होने से रोक रखा था जो कुछ रोग अवस्था में फंस गए थे।

मैंने कुछ समय के लिए क्षेत्र में काम नहीं किया है, इसलिए मुझे नहीं पता कि क्या यह अभी भी मामला है।


6
IIS में समय-समय पर पुनरारंभ होता है जिसे प्रबंधन UI में बनाया जाता है और डिफ़ॉल्ट रूप से सक्षम किया जाता है। वहाँ भी स्मृति और सीपीयू ट्रिगर को सीमित करता है, लेकिन समय आधारित एक ने मुझे हमेशा अजीब रूप से मारा है।
मार्क ब्रैकेट

3
आज तक, अजगर मेमोरी लीक का समाधान केवल प्रक्रिया को फिर से शुरू करना है।
ज़वी

3
मुझे नहीं लगता कि ओपी कार्यक्रम को ठीक से काम करने की स्थिति में लाने के लिए उसे मारने के बारे में पूछ रहा है, लेकिन अपनी मौत से निपटने के लिए और कार्यक्रम के किसी भी बाद के निष्पादन के लिए सिस्टम की क्षमता का परीक्षण करने के लिए एक कार्यक्रम को मारने के लिए। बाकी है।
मावलकर

1
@MarkBrackett दुर्भाग्य से, आवधिक पुनरारंभ प्रोग्रामर को खराब कोड के बारे में आकस्मिक बनाकर विपरीत उद्देश्य की सेवा देता है। यदि खराब कोड के कारण होने वाली समस्याओं को ठीक करने के लिए गर्दन में दर्द था, तो हमें खराब कोड लिखने की संभावना कम होगी।
एंथनी

+1। रैंडम खराब है। परिभाषा के अनुसार, यह ऐसा है कि आप इसके व्यवहार की भविष्यवाणी नहीं कर सकते। यहां तक ​​कि अगर आप इसे हर बार और फिर से कार्यक्रम को बंद करने के उद्देश्यों के लिए वहां रखते हैं, तो यह हो सकता है कि यह बस नहीं किया जाता है, यादृच्छिक रूप में यह है, इस प्रकार इसे शुरू करने के उद्देश्य से इसे हरा देना। प्रेडिक्टेबल मोमेंट्स के करीब आने की प्रक्रियाएँ प्रोग्रामर के लिए आसान हो सकती हैं और साथ ही उस खास फीचर को बेचने की कोशिश करने वाले बाज़ारिया को भी .. "हाँ, यह सही है। यह रैंडम मोमेंट्स पर बंद हो जाता है! नहीं, यह एक फीचर है! हैलो! नमस्ते ?!"
नील

7

मैं देख रहा हूँ कि समस्या यह है कि अगर इस तरह के कार्यक्रम की मृत्यु हो जाती है, तो हम कहेंगे "ओह यह सिर्फ एक और यादृच्छिक समाप्ति है - चिंता की कोई बात नहीं"। लेकिन क्या होगा अगर एक वास्तविक समस्या है जिसे ठीक करने की आवश्यकता है? इसे नजरअंदाज कर दिया जाएगा।

डेवलपर्स पहले से ही "बेतरतीब ढंग से" विफल हो जाते हैं, डेवलपर्स के कारण रहस्यमय तरीके से बनाते हैं, बग इसे उत्पादन प्रणालियों, हार्डवेयर विफलताओं आदि में बनाते हैं। जब ऐसा होता है, तो हम इसके बारे में जानना चाहते हैं ताकि हम इसे ठीक कर सकें। कार्यक्रमों में मृत्यु को डिजाइन करना केवल विफलता की संभावना को बढ़ाता है और हमें केवल अतिरेक को बढ़ाने के लिए मजबूर करेगा, जिसमें पैसा खर्च होता है।

मैं एक बेमानी प्रणाली का परीक्षण करते समय बेतरतीब ढंग से हत्या की प्रक्रियाओं के साथ कुछ भी गलत नहीं देखता हूं (यह उत्पादन की तुलना में अधिक होना चाहिए) लेकिन उत्पादन वातावरण में नहीं। क्या हम हर कुछ दिनों में एक लाइव प्रोडक्शन सिस्टम से कुछ हार्ड ड्राइव निकालेंगे, या किसी एक कंप्यूटर पर एक एयरक्राफ्ट को निष्क्रिय कर सकते हैं क्योंकि यह यात्रियों से भरा है? एक परीक्षण परिदृश्य में - ठीक है। एक लाइव उत्पादन परिदृश्य में - मैं नहीं बल्कि चाहता था।


यदि आप यादृच्छिक समाप्ति को लागू करेंगे, तो आप निश्चित रूप से एक लॉग संदेश प्रिंट करेंगे "अब मैं समाप्त कर रहा हूं" इस तरह कि आप बग से जानबूझकर यादृच्छिक समाप्ति को अलग कर सकते हैं। ;-) इसके अलावा, एक जोड़े की प्रक्रिया को एक बार फिर से शुरू करने से आपको अधिक रिड्यूसेंसी की आवश्यकता नहीं होगी, क्योंकि आपके पास वैसे भी होना चाहिए।
हंस-पीटर स्टॉर

4

आवेदन के लिए यादृच्छिक निकास कोड जोड़ना आवश्यक नहीं होना चाहिए। परीक्षक स्क्रिप्ट लिख सकते हैं जो आवेदन की प्रक्रियाओं को बेतरतीब ढंग से मार देती है।

नेटवर्किंग में, प्रोटोकॉल कार्यान्वयन के परीक्षण के लिए एक अविश्वसनीय नेटवर्क का अनुकरण करना आवश्यक है। यह प्रोटोकॉल में निर्मित नहीं होता है; इसे डिवाइस ड्राइवर स्तर पर या कुछ बाहरी हार्डवेयर के साथ सिम्युलेट किया जा सकता है।

टेस्ट कोड न जोड़ें उन कार्यक्रमों के लिए कार्यक्रम करें जो बाहरी रूप से प्राप्त किए जा सकते हैं।

यदि यह उत्पादन के लिए है, तो मुझे विश्वास नहीं हो सकता कि यह गंभीर है!

सबसे पहले, जब तक प्रक्रियाएं अचानक से बाहर नहीं निकल जाती हैं ताकि प्रगति के लेनदेन और अस्थिर डेटा खो जाते हैं, तब यह अवधारणा का एक ईमानदार कार्यान्वयन नहीं है। योजनाबद्ध, सुशोभित निकास, भले ही बेतरतीब ढंग से समय पर, वास्तविक दुर्घटनाओं से निपटने के लिए वास्तुकला को तैयार करने में पर्याप्त रूप से मदद नहीं करते हैं, जो कि सुंदर नहीं हैं।

यदि वास्तविक या यथार्थवादी खराबी को उस एप्लिकेशन में बनाया गया है, जिसके परिणामस्वरूप वे वास्तविक नुकसान की तरह आर्थिक नुकसान पहुंचा सकते हैं, और उद्देश्यपूर्ण आर्थिक नुकसान मूल रूप से एक आपराधिक कृत्य है

आप लाइसेंसिंग एग्रीमेंट में क्लॉस से दूर हो सकते हैं, जो सॉफ्टवेयर के संचालन से उत्पन्न होने वाले किसी भी नुकसान से नागरिक देयता को माफ करता है, लेकिन यदि वे नुकसान डिजाइन द्वारा हैं, तो आप आपराधिक देयता को माफ करने में सक्षम नहीं हो सकते हैं।

इस तरह के स्टंट के बारे में भी मत सोचो: इसे जितना संभव हो उतना मज़बूती से काम करो, और नकली विफलता परिदृश्यों में केवल विशेष बिल्ड या कॉन्फ़िगरेशन में डाल दिया।


यह स्वीकृत उत्तर IMO होना चाहिए। एसआरपी यहां लागू होता है।
user408866

दुर्भाग्य से, मैं सिर्फ परीक्षण के लिए मतलब नहीं है। मैं समझाने के लिए प्रश्न का विस्तार करूँगा।
जिम्बो

यदि आप इसे सही कर रहे हैं, तो ये यादृच्छिक (और सुंदर नहीं!) क्रैश बिल्कुल भी कोई स्थायी नुकसान नहीं करेंगे। यह बिंदु है: समय के साथ आप सभी किनारे के मामलों को खत्म कर सकते हैं जहां नुकसान होता है; उनमें से कुछ आप परीक्षण मशीनों पर कभी नहीं देखेंगे। और अगर कभी-कभी वास्तविक दुर्घटना होती है तो आपको कोई परेशानी भी नहीं होगी। मैंने कभी यह कोशिश नहीं की, लेकिन यह मुझे कुछ परिस्थितियों में समझदार लगता है। बेशक यह एक ऐसी चीज़ है जिसके लिए एप्लिकेशन का आधिकारिक होना ज़रूरी है, न कि ऐसा कुछ जिसमें विकास नहीं होता है।
हंस-पीटर स्टॉर

3

आप मनमाने दोषों (यानी, न केवल दुर्घटनाग्रस्त प्रक्रियाओं, बल्कि दूषित डेटा और संभावित रूप से दुर्भावनापूर्ण व्यवहार भी) से निपटने के लिए " सक्रिय सुधार " और " कायाकल्प " के लिए खोज करना चाहते हैं । कितनी बार और किन परिस्थितियों में एक प्रक्रिया (एक सार अर्थ में, वास्तव में एक वीएम या एक मेजबान हो सकती है) को फिर से शुरू किया जाना चाहिए, इस पर बहुत शोध किया गया है। सहज रूप से, आप एक गद्दार प्रक्रिया की तुलना में एक मृत प्रक्रिया से निपटने के लिए दृष्टिकोण के लाभों को समझ सकते हैं ...


2

यह वास्तव में परीक्षण से अलग नहीं है। यदि आप हमेशा उपलब्ध फेलओवर समाधान (जैसे नेटफ्लिक्स) डिजाइन कर रहे हैं, तो हां - आपको इसका परीक्षण करना चाहिए। मुझे नहीं पता है कि कोड बेस के दौरान छिड़का हुआ यादृच्छिक निकास एक उपयुक्त तरीका है, हालांकि इसका परीक्षण। जब तक आप वास्तव में यह परीक्षण करने का इरादा नहीं करते हैं कि आपका डिज़ाइन पैर में खुद को गोली मारने के लिए लचीला है, तो कोड के आसपास के वातावरण में हेरफेर करके और इसे उचित रूप से व्यवहार करने की पुष्टि करके इसे परीक्षण करना अधिक उचित लगेगा ।

यदि आप अनावश्यक सिस्टम डिज़ाइन नहीं कर रहे हैं, तो नहीं - आपको उस सुविधा को नहीं जोड़ना चाहिए क्योंकि आपने कुछ यादृच्छिक निकास जोड़े हैं। आपको बस यादृच्छिक निकास को हटा देना चाहिए, और फिर आपको वह समस्या नहीं होगी। आपका वातावरण अभी भी आप पर विफल हो सकता है, जिस बिंदु पर आप या तो उसे समर्थन नहीं करेंगे / उस विफलता के खिलाफ अपने कोड को ठीक नहीं करेंगे या उसे ठीक नहीं करेंगे और इसके लिए एक परीक्षण जोड़ेंगे। अक्सर ऐसा करें, और आपको एहसास होगा कि आप वास्तव में एक निरर्थक प्रणाली डिजाइन कर रहे हैं - परिदृश्य # 1 देखें।

कुछ बिंदु पर, आप यह निर्धारित कर सकते हैं कि अब आप सुनिश्चित नहीं हैं कि क्या विफलताएं हैं या नियंत्रित नहीं हैं। अब आप विफलता के बिंदुओं का पता लगाने के लिए बेतरतीब ढंग से गलीचा खींचना शुरू कर सकते हैं।

नेटफ्लिक्स के उदाहरण के बारे में एकमात्र दिलचस्प बात यह है कि वे उत्पादन में इन परीक्षणों को चलाते हैं। यह एक निश्चित मात्रा में समझ में आता है - कुछ कीड़े वास्तव में केवल उन चीजों का उत्पादन करते हैं जो एक पृथक वातावरण में अनुकरण करना बहुत कठिन या असंभव है। मुझे संदेह है कि नेटफ्लिक्स ने परीक्षण वातावरण में एक लंबा समय बिताया, क्योंकि वे उत्पादन में ऐसा करने के लिए पर्याप्त आरामदायक थे। और वास्तव में वे सब कर रहे हैं व्यापार घंटे के दौरान होने वाली दुर्घटनाओं को प्राप्त करने की कोशिश कर रहे हैं, जो कि उनके बाजार के लिए एक निश्चित राशि बनाता है, लेकिन बहुत सारे लोगों के लिए नहीं।


2

आप जिस शब्द की तलाश कर रहे हैं, वह हाल ही में नासिम निकोलस तालेब द्वारा गढ़ा गया है: एंटीफ्रागिलिटी। उनकी पुस्तक एंटीफ्रागाइल निश्चित रूप से अनुशंसित है। इसमें बमुश्किल आईटी का उल्लेख है, लेकिन स्पष्ट, स्पष्ट समानताएं सबसे प्रेरणादायक हैं। उनका विचार नाजुक <-> नाजुक से मजबूत <-> मजबूत <-> एंटीफ्रेगाइल के पैमाने का विस्तार करना है। बेतरतीब घटनाओं के साथ नाजुक टूटता है, यादृच्छिक घटनाओं के साथ मजबूत प्रबंधन और यादृच्छिक घटनाओं के साथ विरोधी नाजुक लाभ।


1

निर्भर करता है। मैंने देखा है कि प्रोग्रामर उन तकनीकों को अतिरंजित करते हैं जो उनके विशिष्ट डोमेन पर लागू होते हैं जो अन्य सभी को अनदेखा करते हैं। उदाहरण के लिए सभी बग्स को ठीक करने की कीमत पर जारी किया गया कार्यक्रम अच्छा हो सकता है ... जब तक आप विमान नियंत्रक, परमाणु रिएक्टर आदि का कार्यक्रम नहीं करते हैं, "अनुकूलन न करें - प्रोग्रामर की लागत अधिक है तो कार्यक्रम चलाने की लागत" आवश्यक नहीं है HPC के लिए मान्य है क्योंकि अपेक्षाकृत सरल कार्यक्रम महीनों आदि के लिए क्लस्टर पर कब्जा कर सकते हैं (या यहां तक ​​कि एक लोकप्रिय कार्यक्रम जो बड़ी मात्रा में उपयोगकर्ताओं द्वारा उपयोग किया जाता है)। यहां तक ​​कि अगर कंपनी एक्स बहुत अच्छे कारण के लिए वाई कर रही है तो आपको उनके नक्शेकदम का पालन करने की आवश्यकता नहीं है क्योंकि आपकी स्थिति अलग हो सकती है।

आमतौर पर त्रुटि से निपटने की दिनचर्या कोड का सबसे खराब परीक्षण किया गया भाग है - जबकि यह सरल लगता है कि यह अनुकरण करना कठिन है कि अपर्याप्त मेमोरी है या कोई महत्वपूर्ण फ़ाइल नहीं है। इस कारण से मैं उन पाठों को पढ़ता हूं जो यूनिक्स कर्नेल के लिए कुछ सिस्टम कॉल को बेतरतीब ढंग से विफल करने के लिए प्रस्तावित करता है। हालाँकि, यह लिखने के लिए एक सरल प्रोग्राम को कठिन बना देगा (यदि मुझे त्रुटि से निपटने के लिए परेशान नहीं करना है तो एक बार 2 फ़ाइलों पर एक प्रोग्राम चलाने के लिए 3 सी ++ लाइब्रेरीज़ को एक साथ प्लग करना होगा)। अपवादों के साथ भी, जीसी आपको यह सुनिश्चित करने की आवश्यकता है कि आपने लगातार राज्य छोड़ दिया है (कल्पना सूची में नोड जोड़ने के बीच में अपवाद की कल्पना करें)।

आपके पास जितनी अधिक वितरित सेवाएं हैं, उतनी अधिक विफलताएं "कितनी बार" और फिर "अगर" या "कब" का सवाल है। डेटा केंद्रों में RAID में डिस्क प्रतिस्थापन रूटीन ऑपरेशन का हिस्सा है जो मुझे पता है - एक अप्रत्याशित विफलता नहीं। यदि आप बड़े पैमाने पर काम करते हैं, तो आपको इसे ध्यान में रखना होगा, भले ही एक घटक की विफलता की संभावना छोटी हो, संभावना है कि कुछ विफल हो जाएगा।

मुझे नहीं पता कि आप वास्तव में क्या कर रहे हैं, लेकिन यह जानने के लिए कि क्या यह इसके लायक है आपको यह सोचने की ज़रूरत है कि क्या विफलता कुछ है जिसे आपको ध्यान में रखने की आवश्यकता है (जैसा कि इसे अनदेखा करता है) या विश्लेषण करने के लिए यह बहुत महंगा है (त्रुटियों को लेने के रूप में) खाते में विकास का समय लगता है)।


"प्रोग्रामर अपने विशिष्ट डोमेन पर लागू होने वाली तकनीकों को अतिरंजित करते हैं" मैं इस उद्धरण को फ्रेम करना चाहता हूं और इसे दीवार पर लटका सकता हूं। यह सच है, और न केवल सॉफ्टवेयर का बल्कि सामान्य रूप से जीवन का।
मार्क ई। हासे

1

IIS सर्वर में एक विन्यास योग्य सुविधा होती है जो एक निश्चित मात्रा में मेमोरी का उपयोग करने के बाद या एक निश्चित संख्या के लिए जीवित रहने के बाद या तो एक निश्चित मात्रा में सर्विसिंग करने के बाद या फिर एक निश्चित समय सीमा तक जीवित रहने के बाद श्रमिक प्रक्रियाओं को स्वचालित रूप से रीसायकल करती है। ( http://msdn.microsoft.com/en-us/library/ms525803(v=vs.90).aspx ) और ( http://www.microsoft.com/technet/prodtechnol/WindowsServer2003-Library/IIS/ 1652e79e-21f9-4e89-bc4b-c13f894a0cfe.mspx? Mfr = true )

जब IIS जैसा कोई CONTAINER करता है, तो यह सर्वर को दुष्ट प्रक्रियाओं से बचाने के लिए समझ में आता है। हालाँकि, मैं इसे बंद रखना पसंद करूंगा, क्योंकि यह समझ में नहीं आता है कि आपने अपने कोड का पर्याप्त परीक्षण किया है या नहीं।

हम पहले से ही अविश्वसनीय परतों (हार्डवेयर, नेटवर्क) पर काम करते हैं, इसलिए मैं कभी भी ऐसा कोई कोड नहीं लिखूंगा जो बेतरतीब ढंग से उसके धागे या प्रक्रियाओं को जानबूझकर मार दे। यादृच्छिक हत्या भी एक आर्थिक दृष्टिकोण से एक बुरा विचार है- कोई भी मेरे एपीआई का उपयोग नहीं करेगा यदि उन्हें लगा कि मैंने इसे बेतरतीब ढंग से दुर्घटनाग्रस्त होने के लिए प्रोग्राम किया है। अंत में, अगर मुझे एपीआई का उपभोग करना था या बेतरतीब ढंग से दुर्घटनाग्रस्त धागे के साथ एक प्रणाली का उपयोग करना था, तो मुझे इसके लिए एक मजबूत पर्याप्त निगरानी तंत्र बनाने के लिए बहुत पैसा खर्च करना होगा ताकि मैं रात में शांति से सो सकूं।

इसके बजाय अगर मैं एक प्रणाली या एक एपीआई विकसित कर रहा था, तो मैं स्क्रिप्ट लिखूंगा या एक हार्नेस का उपयोग करूंगा, जो इस विशुद्ध रूप से तनाव को प्रणाली की लचीलापन का परीक्षण करने के लिए करेगा। और मैं खराब बिल्ड की पहचान करने के लिए सभी बिल्डरों पर इस तरह का एक परीक्षण चलाऊंगा। हालाँकि, जबकि यह एक आवश्यक परीक्षा होगी, यह कभी भी "पर्याप्त" परीक्षण नहीं हो सकता है।


1

इस विचार से संबंधित एक साहित्य है, इसका क्रैश-ओनली सॉफ्टवेयर (रिकवरी ओरिएंटेड कम्प्यूटिंग भी कहा जाता है) और आप 2003 से कैंडे एंड फॉक्स द्वारा इस usenix पेपर के साथ शुरू कर सकते हैं । बल्कि रैंडम मार के बजाय, लेखक का तर्क है कि आप केवल विश्वसनीयता में सुधार कर सकते हैं कभी भी उन्हें मारने से अपने कार्यक्रमों को रोकना, इसलिए शट डाउन बटन के रूप में एकल किल स्विच और वसूली के लिए एक अच्छी तरह से व्यायाम स्टार्ट-अप पथ।

हालांकि मुझे यकीन नहीं है कि यह विचार कितना अच्छा है, कुछ विशिष्ट तकनीक उपयोगी हैं। उदाहरण के लिए अपने सॉफ़्टवेयर पर भरोसा न करने का अनुरोध करने पर स्वयं को बंद करने में सक्षम होने और इसलिए विशेष पर्यवेक्षी कार्यक्रमों (जैसे पर्यवेक्षक आदि) का उपयोग करने के लिए, और यह भी ध्यान से सोचें कि कौन सा कार्यक्रम राज्य आवश्यक है और यह सुनिश्चित करें कि उचित समय पर रिकॉर्ड किए गए डेटा स्टोर में डिज़ाइन किया गया हो पुनर्प्राप्ति को सक्षम करने के लिए (इसलिए एक sql डेटाबेस)।


2
लिंक बासी हो जाते हैं। यदि आप अपने जवाब में केवल सॉफ्टवेयर क्रैश के प्रमुख बिंदुओं को संक्षेप में प्रस्तुत करते हैं तो आपका उत्तर और मजबूत होगा।

1

सचमुच बेतरतीब ढंग से, नहीं। लेकिन किसी दिए गए अंतराल पर लंबे समय से चल रही प्रक्रियाओं / थ्रेड्स से बाहर निकलने / फिर से शुरू करने के लिए या किसी दिए गए (लेकिन कुछ मानदंडों पर निर्भर) के लिए निष्क्रिय होने के बाद, या किसी विशेष प्रकार के कार्य को निष्पादित करने के लिए यह एक अच्छा विचार है। लंबे समय से चल रही प्रक्रियाएं बासी चीजों सहित अनिवार्य रूप से राज्य का निर्माण करती हैं, संभवत: स्वैप स्पेस को रोकने के लिए स्मृति को लटका सकती हैं, जिनमें से सभी को बाहर निकलने पर साफ हो जाता है (या प्राप्त करना चाहिए) जब वे बाहर निकलते हैं, तो सामान्य सिस्टम स्थिरता में सुधार होता है।


1

यह उस एप्लिकेशन के प्रकार पर निर्भर करता है जिसे आप डिज़ाइन कर रहे हैं।

रैंडम क्रैश वितरित (नेटवर्क की गई) प्रणालियों की मजबूती का परीक्षण और सुधार करने का एक शानदार तरीका है।

नेटफ्लिक्स उदाहरण में, जब आपका प्रोग्राम दूरस्थ सेवाओं पर निर्भर करता है जो कई कारणों से विफल हो सकते हैं जो आपके नियंत्रण से बाहर हैं (हार्ड डिस्क खराब हो जाती है, बिजली की हानि होती है, उल्का क्रैश डेटा सेंटर में क्रैश हो जाता है, आदि)। आपकी सेवा को हालांकि अभी भी किसी तरह चालू रखना है।

आप उसे कैसे करते हैं? अतिरेक और स्केलिंग में जोड़ें एक सामान्य समाधान है।

उदाहरण के लिए, यदि कोई माउस आपके सर्वर की पावर केबल से गुजरता है, तो आपकी सेवा को चालू रखने के लिए कुछ समाधान होना चाहिए। यह उदाहरण के लिए निरर्थक बैकअप सर्वर रख सकता है जो इसके बजाय इसका उपयोग करना शुरू कर देगा।

हालाँकि, यदि आपका प्रोग्राम एक एकल प्रक्रिया अनुप्रयोग है जो किसी नेटवर्क में काम नहीं करता है, तो उसे मारना ही कुछ भी नहीं है क्योंकि इससे उबरने का कोई तरीका नहीं है।

यहाँ कैओस बंदरों की अवधारणा पर कुछ अतिरिक्त टिप्पणी दी गई है http://www.codinghorror.com/blog/2011/04/working-with-the-chaos-monkey.html


1

यह संभव है कि ब्रह्मांडीय विकिरण के कारण एक यादृच्छिक बिट फ्लिप होता है । इस समस्या को मान्यता दी गई थी, और बिट फ्लिपिंग को रोकने के लिए विभिन्न तकनीकों का विकास किया गया था।

हालांकि, इसे 100% ठीक करना संभव नहीं है, और स्मृति भ्रष्टाचार अभी भी समस्याएं पैदा कर सकता है, और ये समस्याएं अभी भी हो रही हैं ( बहुत कम अक्षमता के साथ )।

अब आपके प्रश्न का उत्तर देने के लिए। आपको बहुत मजबूत प्रणाली को डिजाइन करने की आवश्यकता है या नहीं, यह इस बात पर निर्भर करता है कि आप क्या कर रहे हैं। यदि आपको एक अंतरिक्ष शिल्प बनाने की आवश्यकता है, तो आप इसे बेहतर रूप से सुपर मजबूत बनाते हैं, और फिर आपको हर संभव मुद्दे को ध्यान में रखना होगा।

यदि आपको एक सामान्य डेस्कटॉप एप्लिकेशन डिजाइन करने की आवश्यकता है, तो आपको अपने कोड में बग्स के रूप में यादृच्छिक दुर्घटनाओं को देखना चाहिए।


0

ऐसा लगता नहीं है कि एक विचार के पूर्ववर्ती।

एंड्रॉइड ओएस हर समय उपयोगकर्ता एप्लिकेशन / सेवाओं को बेतरतीब ढंग से मारता है और पुनरारंभ करता है। मेरे अनुभव में यह निश्चित रूप से मुझे त्रुटि स्थितियों के बारे में अधिक गहराई से सोचने के साथ-साथ अधिक मजबूत आर्किटेक्चर डिजाइन करने में मदद करता है।


4
Android की कार्रवाइयाँ यादृच्छिक नहीं हैं, लेकिन गतिविधियों को राज्य को बचाने में सक्षम होने की आवश्यकता होती है जब उसे बताया जाता है। एक सूक्ष्म, लेकिन महत्वपूर्ण, अंतर है।
ब्लरफुल

मैं क्या पढ़ा है से कोई गारंटी नहीं कि वहाँ onDestroy, onPause, onSaveInstanceState, आदि ... कभी एक गतिविधि या सेवा पर बुलाया जाएगा। एप्लिकेशन स्तर पर onDestoryकॉलबैक भी नहीं है । तो हाँ कुछ शटडाउन बंद करने के लिए कुछ हुक हैं, लेकिन आपको अभी भी यादृच्छिक निकास के लिए तैयार रहना होगा।
Xavi

onPause()किसी गतिविधि के मारे जाने से पहले आपको कॉल की गारंटी दी जाती है। हनीकॉम्ब के बाद, आपको उस प्लस की गारंटी दी जाती है onStop()। एंड्रॉइड ऐप केवल उन गतिविधियों का संग्रह है जो संबंधित होते हैं और जहां तक ​​निष्पादन जीवनचक्र का संबंध है, किसी भी चीज़ की कोई ऐप-स्तरीय अवधारणा नहीं है।
ब्लरफुल

आह जानकर अच्छा लगा
Xavi
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.