2010-01-28 16 views
16

हमारा उत्पाद एक वितरित प्रणाली है। जिन मॉड्यूल पर मैं काम करता हूं वे बिल्कुल नए, काफी कठोर, अच्छी तरह से परीक्षण किए जाते हैं। वे हाल ही में सर्वोत्तम प्रथाओं के साथ दिमाग में विकसित किए गए थे। अन्य मॉड्यूल विरासत सॉफ्टवेयर के रूप में माना जा सकता है।विफल फास्ट बनाम मजबूती

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

लेकिन मैं जिस तर्क के खिलाफ आ रहा हूं वह यह है: "हम इस सामान को उत्पादन में विफल नहीं होने दे सकते हैं, ग्राहक को यह काम करने की उम्मीद है, आप इस समस्या के आसपास क्यों काम नहीं करते हैं"। और यह दृढ़ता के लिए एक तर्क होगा: जो आप स्वीकार करते हैं उसमें उदार रहें, जो आप भेजते हैं उसमें रूढ़िवादी।

मुझे यह भी ध्यान रखना चाहिए कि ये अधिकतर समस्याएं हैं। हम उन्हें एकीकरण परीक्षण में देखते हैं लेकिन उन्हें पुन: पेश करना मुश्किल होता है। समय और सहमति शामिल हैं।

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

मुझे कहना चाहिए कि सिस्टम उत्पादन में "क्रैशिंग" नहीं कर रहा है, लेकिन मेरा मॉड्यूल ऑपरेटर को बस एक त्रुटि प्रदर्शित कर सकता है और उन्हें समर्थन से संपर्क करने के लिए कह सकता है। एक दुर्घटना एक बड़ी समस्या होगी, लेकिन अगर मैं स्पष्ट रूप से त्रुटि की रिपोर्ट कर रहा हूं, तो क्या यह सही काम नहीं है? मुझे संदेह है कि मेरे साथियों को सिर्फ ग्राहक नहीं चाहते हैं कि कोई समस्या, अवधि। लेकिन मेरा मॉड्यूल हमारे उत्पाद के भीतर अन्य मॉड्यूल से डेटा अस्वीकार कर रहा है, ग्राहक इनपुट नहीं। तो मुझे ऐसा लगता है कि हम सिर्फ समस्याओं का सामना नहीं कर रहे हैं।

तो, क्या मुझे और अधिक व्यावहारिक होने या मेरी जमीन पकड़ने की आवश्यकता है?

उत्तर

1

सभी को धन्यवाद। इस सवाल को प्रेरित करने वाला मामला अच्छी तरह समाप्त हो गया, और अंतर्दृष्टि के लिए आंशिक रूप से धन्यवाद, मुझे ऊपर दिए गए उत्तरों से मिला।

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

मैंने इस मामले के लिए एक नया हैंडलर और कोड पथ जोड़ने की योजना बनाई है, जो उचित रूप से निष्पादित होगा जैसे कि यह एक विशेष उपयोग केस था जिसे पहले अनियंत्रित किया गया था।

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

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

लेकिन सभी चुनौतियों और संभावित समाधानों को प्रसारित करने के बाद, हम अंततः डेटा को ठीक करने पर सहमत हुए, और अब तक ऐसा लगता है कि हमारी समस्या हल हो गई है। हमारे एकीकरण परीक्षण अब लगातार गुजर रहे हैं, लेकिन हमने लॉगिंग भी जोड़ दी है और इसकी निगरानी जारी रखेगी।

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

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

+0

वाह, टिप्पणियों और उत्तरों सहित पूरे धागे, पूरी तरह पेशेवर और अच्छी तरह से बाहर थे। कोई घुटने-झटके प्रतिक्रिया नहीं, कोई उंगली इंगित नहीं, कोई शिकायत नहीं। मैं भाग लेने वाले हर किसी से प्रभावित हूं। निष्कर्ष प्रदान करने के लिए ऊपर वोट - हालांकि अपने उत्तर को स्वीकार करने के बारे में थोड़ा iffy। – MJB

+0

मुझे यकीन नहीं था कि जवाबों के बारे में क्या करना है। मैंने सोचा कि इसका मतलब कार्रवाई का कोर्स होना था। अभी भी सीखना कि यह कैसे काम करें। – tolak

3

मैं कहूंगा कि यह निर्भर करता है कि यदि आप रुकते हैं तो क्या होता है। क्या किसी का पेचेक संसाधित हो जाता है? क्या गलत आदेश भेजा जाता है? यह रोकने के लायक होगा।

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

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

यह वास्तव में नीचे आता है कि जो व्यक्ति आपके प्रदर्शन की समीक्षा करता है वह आपके द्वारा चाहता है, खासकर जब आप उन्हें ईमेल के माध्यम से समस्या की व्याख्या करते हैं।

0

यह एक मुश्किल है। यदि आपके मॉड्यूल को खराब डेटा प्राप्त होता है और यह आपके लिए कुछ भी नहीं करने के लिए "ठीक" है और वापस लौटाता है, तो मैं उपयोगकर्ता को त्रुटि दिखाने के बजाय त्रुटि लॉग लिखने का सुझाव दूंगा।

2

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

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

नीचे की रेखा, आपको दोनों की आवश्यकता है। आपको डेटा को व्यावहारिक के रूप में त्रुटि मुक्त करने की कोशिश करने की आवश्यकता है, लेकिन अप्रत्याशित रिपोर्ट भी करें।

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

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

+0

संतुलित और अच्छी तरह से प्रतिक्रिया के लिए धन्यवाद। इससे मुझे इस मुद्दे को तैयार करने में मदद मिली। – tolak

2

मैं कारणों में नहीं जाऊंगा, लेकिन आप सही हैं।

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

मेरी सलाह है कि आप अपनी जमीन खड़े हों। सदा।

+0

तो हम सॉफ्टवेयर विकसित करते हैं, और इस बात पर विचार नहीं करते कि उपयोगकर्ता क्या चाहता है या जरूरत है? er, no, (-1) – DanSingerman

+2

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

4

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

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

सावधान रहें कि आप विचारों को कैसे रोकते हैं। लगातार अन्य प्रणालियों का जिक्र करते हुए "बहुत जटिल और नाजुक" लोगों को गलत तरीके से रगड़ सकता है। एक्सप्रेस बस सिस्टम आपके लिए नए हैं और समझने में अधिक समय लेते हैं। उन्हें समझने में समय दें, इसलिए आप अपनी क्षमता की लोगों की अपेक्षाओं को कम नहीं करते हैं।

+0

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

0

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

मेरे दिमाग में हालांकि डेटा शुद्धता कार्य प्रणाली को टंप करता है, आप खराब डेटा को कहीं और प्रचारित करने और अन्य सिस्टम दूषित करने की अनुमति नहीं दे सकते हैं।हद तक आप सही होने के लिए डेटा मालिश कर सकते हैं और फिर आगे बढ़ते रहें, आपको इस सिद्धांत पर ऐसा करना चाहिए कि डेटा सुरक्षित है और आपको सिस्टम को चलाना चाहिए ...

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

0

सवाल अपने साथियों से है:

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

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

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

आपके डोमेन के आधार पर, आपके लिए खराब डेटा का पता लगाना संभव हो सकता है, और उपयोगकर्ता को असुविधा के बिना डेटा के लिए दूसरा अनुरोध करना संभव हो सकता है। (यह स्पष्ट रूप से केवल उन मामलों में प्रासंगिक है जहां आप डेटा को दूसरी बार बेहतर होने की उम्मीद करेंगे, लेकिन आप कहते हैं कि जिन मुद्दों का आप अनुभव कर रहे हैं वे अंतःस्थापित और संभावित समवर्ती संबंधित हैं) ...

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

+0

यह एक महत्वपूर्ण प्रणाली है, लेकिन यह मानव ऑपरेटरों के लिए एक मार्गदर्शन है। यह एक ऑपरेटर को नहीं बता सकता है जिसने कुछ सरल मुद्दा दिया है कि कुछ आंतरिक मुद्दों के कारण, उसे रोकना होगा। मैं उत्पादन में सतह की समस्याओं के लिए अनिच्छा को समझ सकता हूं जहां उपयोगकर्ता सही तरीके से प्रदर्शन कर रहा है लेकिन सिस्टम असफल रहा है। – tolak

संबंधित मुद्दे