गैर-प्रजनन योग्य बग से निपटना


73

मान लीजिए कि आपकी टीम एक सॉफ्टवेयर सिस्टम लिखती है जो (बहुत आश्चर्यजनक रूप से!) ठीक चल रहा है।

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

कुछ समय बाद आपको दूषित / त्रुटिपूर्ण डेटा का पता चलता है और हर कोई अपना सिर खुजलाता है कि कोड का कौन सा हिस्सा इसका कारण बना और क्यों, कोई फायदा नहीं हुआ। इस बीच परियोजना प्रबंधक जोर देकर कहते हैं कि हम उस कोड का हिस्सा ढूंढते हैं जो इसका कारण बना।

आप इस के साथ कैसे पेश आएंगे?


32
यदि इंजीनियर इसके बारे में भूल गया, तो आप कैसे जानते हैं कि क्या हुआ है? आप यह कैसे भ्रष्ट करते हैं कि कोई स्क्रिप्ट चला रहा था, और बग से नहीं।
डेवग

18
एक-दो दिन बाद उन्हें एक बीमारी हो गई। यह एक काल्पनिक मामला है जिसे उन्होंने कभी याद नहीं किया जो आसानी से मामला हो सकता था।
निक किरियाकिड्स

12
यह एक काल्पनिक है। मुझे यकीन है कि पीएम ने हमारा पीछा किया होगा, जितना हम कभी याद नहीं करेंगे, उतना ही हम करेंगे। मुझे पता है मैं करूंगा।
निक किरियाकिड्स

59
xkcd.com/583 ;) [एनएसएफडब्ल्यू भाषा]
बाल्ड्रिक

100
"मान लीजिए कि आपकी टीम एक सॉफ्टवेयर सिस्टम लिखती है जो ठीक चल रहा है।" मुझे असंभव कल्पनाओं से चिढ़ाना बंद करो!
पॉल डी। वेट

जवाबों:


134

यह स्पष्ट है कि कोई भी परियोजना प्रबंधक इस तरह की समस्या में अनंत समय का निवेश नहीं करेगा। वे फिर से वही स्थिति पैदा होने से रोकना चाहते हैं।

इस लक्ष्य को प्राप्त करने के लिए, भले ही कोई व्यक्ति इस तरह की विफलता का मूल कारण नहीं खोज सकता है, अक्सर कुछ उपायों को करना संभव है

  • इस तरह की विफलताओं का पता लगाएं, इससे पहले कि वे फिर से जुट जाएं
  • कम संभावना है कि फिर से वही विफलता होगी
  • विशिष्ट प्रकार की असंगति के खिलाफ सिस्टम को अधिक मजबूत बनाएं

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

सोचें कि आपकी स्थिति में उपयुक्त प्रकार की कार्रवाई क्या हो सकती है, और टीम को यह सुझाव दें; मुझे यकीन है कि आपका प्रोजेक्ट मैनेजर प्रसन्न होगा।

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

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


8
@ नाइकोलास क्यारीकाइड्स शायद दोनों। ये सभी "डिफर्ड" डिबगिंग को सरल बनाने के लिए सामान्य ज्ञान के उपाय हैं। वे शायद अनगिनत प्रक्रियाओं में लिखे गए हैं।
निक हार्टले

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

2
@ निकोलस क्यारीकाइड्स: कई दशकों में व्यक्तिगत अनुभव।
Doc Brown

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

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

51

यह एक बग नहीं है

कम से कम अपने कोड पर नहीं। यह आपकी प्रक्रिया में एक बग है । आपका प्रोजेक्ट मैनेजर आपके कोड की तुलना में आपकी प्रक्रिया के बारे में बहुत अधिक चिंतित होना चाहिए।

आप इस के साथ कैसे पेश आएंगे?

बस, इंजीनियरों को उत्पादन या साझा विकास डेटाबेस को बदलने नहीं देने से


यह एक साझा विकास डेटाबेस है:

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

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

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

अंत में, आपके विवरण से कि आप चीजों को कैसे डीबग कर रहे हैं, ऐसा लगता है कि आप सीआई का उपयोग नहीं कर रहे हैं । CI का उपयोग करें । यह सेटअप करने के लिए थोड़ा दर्द है, लेकिन यह लंबे समय में बहुत समय बचाएगा, न कि आपको अप्रतिरोधी डेटाबेस बग के बारे में चिंता करने से रोकने के लिए। आपको अब केवल हाइजेनबग्स की चिंता करनी होगी !


यह मानते हुए कि यह एक उत्पादन डेटाबेस है:

यदि आपके देवता उत्पादन डेटाबेस बदल रहे हैं, तो कई चीजें बहुत गलत हो गई हैं, भले ही परिवर्तन बिल्कुल सही हों।

डेवलपर्स को कभी भी उत्पादन डेटाबेस तक नहीं पहुंचना चाहिए । वहाँ बिल्कुल कोई कारण नहीं है, और बहुत सारी चीजें हैं जो बहुत गलत हो सकती हैं ।

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

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


12
तो, आपका अनुशंसित समाधान समय यात्रा है?
बेनुबर्ड

7
हालांकि यह दिए गए उदाहरण के लिए एक सभ्य समाधान है, इस सवाल में कीड़े से निपटने का एक बहुत अधिक सामान्य संदर्भ है जिसे पुन: प्रस्तुत नहीं किया जा सकता है और प्रबंधक जो चाहते हैं कि वे इन्हें बनाए रखें। यह डेटाबेस मुद्दों और अनुमति प्रबंधन की तुलना में बहुत अधिक लागू हो सकता है। मुझे ऐसा लगता है कि यह उत्तर वास्तव में दिए गए उदाहरण का जवाब नहीं देता है।
काइल वार्डल

@ केलीवर्ल्ड सहमत। मुझे लगता है कि डॉक ब्राउन का जवाब सामान्य मामले (विस्तृत लॉगिंग और त्रुटि से निपटने, गार्ड की स्थिति) को अच्छी तरह से कवर करता है। मैंने ज्यादातर मेरा जोड़ा क्योंकि मैंने देखा कि किसी ने भी इस प्रक्रिया में विफलताओं का उल्लेख नहीं किया था जिसके कारण पहली बार में समस्या हुई थी
गॉन्कॉप्लॉप

2
@ बेनुबर्ड मुझे लगता है कि उत्तर "जिस तरह से आप इससे निपटते हैं वह इसे फिर से होने से रोक रहा है"। मुझे नहीं लगता कि आप एक सॉफ्टवेयर इंजीनियरिंग के नजरिए से एक दूषित उत्पादन डेटाबेस को "हल" कर सकते हैं।
गॉनकॉल्प

1
आप देव डेटाबेस में डेटा डालने के लिए कोड बदलने नहीं जा रहे हैं। हर जगह मैंने काम किया है, जिसमें विशाल निगम शामिल हैं, डेवलपर्स परीक्षण डेटा सम्मिलित करने के लिए स्वतंत्र हैं, और एप्लिकेशन का उपयोग करने वाले समान क्रेडेंशियल्स का उपयोग करते हैं।
डेविड कॉनरेड

13

एक उत्पादन डेटाबेस में पूर्ण पहुँच लॉगिंग और भूमिका आधारित अभिगम नियंत्रण होना चाहिए। इस प्रकार आपके पास कठोर सबूत होना चाहिए क्योंकि WHO ने डेटाबेस पर क्या किया और इस तरह कोड से गरीब परिचालन सुरक्षा की ओर ध्यान आकर्षित किया।


2
ऐसा लगता है कि वे ठीक से नहीं जानते हैं कि डेटा भ्रष्टाचार कब हुआ, जिससे यह पता लगाना मुश्किल हो सकता है कि उन्हें जांचने के लिए किन लॉग की जरूरत है।
नेथेल

3
दुर्भाग्य से इनमें से किसी एक को ट्रेस करने पर हमें पता चला कि यह लॉग्स को भी रौंद रहा था। (हां, यह। यह बग वास्तविक था।)
जोशुआ

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

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

@DavidConrad: एप्लिकेशन में उत्पादन में उपयोग किए जाने वाले क्रेडेंशियल्स तक देवों की पहुंच क्यों है? आपको किसी प्रकार के गुप्त प्रबंधन का उपयोग करना चाहिए ताकि उत्पादन एप्लिकेशन सर्वरों से उन क्रेडेंशियल को आपके एप्लिकेशन सेवा खाते के अलावा भी नहीं पढ़ा जा सके।
डैनियल प्राइडेन

6

इस मामले में, आपने अंततः कारण का पता लगा लिया, लेकिन अपने काल्पनिक को ध्यान में रखते हुए ...

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

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

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


5
  1. अपने प्रोजेक्ट मैनेजर को समझाएं कि आपको लगता है कि सबसे संभावित कारण मैनुअल डेटाबेस एक्सेस है।
  2. यदि वे अभी भी आपको उस कोड की तलाश करना चाहते हैं जिसके कारण यह है, तो कोड पर एक और नज़र डालें।
  3. कुछ घंटों (या किसी अन्य उपयुक्त समय) में वापस आएं और कहें कि आपको ऐसा कोई कोड नहीं मिल सकता है, जिसके कारण ऐसा हुआ हो, इसलिए आप अभी भी मानते हैं कि सबसे संभावित कारण मैनुअल डेटाबेस एक्सेस है।
  4. यदि वे अभी भी चाहते हैं कि आप कोड की तलाश करें, तो पूछें कि वे इस पर कितना समय देना चाहेंगे। जब आप ऐसा कर रहे हों, तो उन्हें याद दिलाएं कि आप फीचर X, बग Y या एन्हांसमेंट Z पर काम नहीं कर रहे हैं।
  5. जितना वे पूछते हैं, उतना समय बिताएं। यदि आपको अभी भी लगता है कि सबसे संभावित कारण मैनुअल डेटाबेस एक्सेस है, तो उन्हें यह बताएं।
  6. यदि वे अभी भी आपको कोड की तलाश करना चाहते हैं, तो समस्या को बढ़ाएं क्योंकि यह स्पष्ट रूप से आपकी टीम के समय का अनुत्पादक उपयोग बन गया है।

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


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

5
"मेरा सवाल यह है कि क्या होता है यदि आप कारण नहीं खोज सकते हैं और सुझाव नहीं दे सकते हैं कि संभावित कारण क्या हो सकता है" यह सटीक कारण है जो 'ठीक नहीं करेगा - डुप्लिकेट नहीं कर सकता' ध्वज का आविष्कार किया गया था।
esoterik

4

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

चरण 0: डेटाबेस की मरम्मत करके ग्राहक को फिर से उठने और चलने में मदद करें।

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

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

चरण 2: हमने तब सॉफ्टवेयर में दो बदलाव किए: (a) गलती से इस आशय का कारण बन जाना मुश्किल था कि "हाँ मुझे पता है कि मैं क्या कर रहा हूँ" उपयोगकर्ता इंटरफ़ेस, और (b) एक नई लॉग फ़ाइल शुरू करना ताकि यदि यह कभी भी फिर से हुआ, हमारे पास उपयोगकर्ता के कार्यों का रिकॉर्ड होगा।

तो मूल रूप से (ए) क्षति की मरम्मत करता है और लाइव रनिंग को पुनर्स्थापित करता है, (बी) मूल कारण का पता लगाता है, (सी) इसे फिर से होने से रोकने के लिए या फिर ऐसा होने पर आसान निदान को सक्षम करने के लिए जो कुछ भी आवश्यक है वह करें।


3

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

एक उत्पादन डेटाबेस में पूर्ण पहुँच लॉगिंग और भूमिका आधारित अभिगम नियंत्रण होना चाहिए। इस प्रकार आपके पास कठोर सबूत होना चाहिए क्योंकि WHO ने डेटाबेस पर क्या किया और इस तरह कोड से गरीब परिचालन सुरक्षा की ओर ध्यान आकर्षित किया।

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

कहीं न कहीं इस तरह एक उद्धरण होना चाहिए, यदि आप मुझे इस पर उद्धृत नहीं कर सकते हैं:

शौचालयों की सफाई के लिए रसोइये के जिम्मेदार न होने का एक अच्छा कारण है।


1

कई चीजें हैं जो गैर-प्रजनन योग्य बग के साथ की जानी चाहिए।

  1. इसके लिए टिकट बनाएं

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

  1. एक सख्त विश्लेषण करें

सिस्टम को देखें, क्या विफल हुआ, और यह कैसे विफल हुआ। उस कोड के क्षेत्र को खोजने का प्रयास करें जिसे विफलता की संभावना कम करने के लिए अद्यतन किया जा सकता है। कुछ उदाहरण...

  • एक समर्पित कॉल के execute(<query>)साथ (जैसे के साथ) तदर्थ कोड को बदलेंexecuteMyStoredProcedure(<params>)
  • डेटा अखंडता को सत्यापित करने के लिए रात में सत्यापन स्क्रिप्ट चलाएं (ताकि अगली बार 24 घंटों के भीतर इसका पता लगाया जा सके)
  • लॉगिंग और संग्रहण (बैक अप) जोड़ें / सुधारें।
  • अनुचित सुरक्षा सीमाएँ बदलें (उदाहरण के लिए, लोग / प्रोग्राम जो केवल डेटा पढ़ते हैं उनके पास लिखित अनुमति नहीं है; उन डेवलपर्स को नहीं देते जो उत्पादन सर्वर में लॉग इन करने में सक्षम होने से उत्पादन के लिए ज़िम्मेदार नहीं हैं)
  • लापता होने पर डेटा सत्यापन / स्वच्छता जोड़ें

यह बग को ठीक नहीं कर सकता है, लेकिन अगर ऐसा नहीं होता है, तो सिस्टम अब अधिक स्थिर / सुरक्षित है, इसलिए यह अभी भी भुगतान करता है।

  1. सिस्टम अलर्ट जोड़ें

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


0

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

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

उस मामले में आप अभी भी जानते हैं कि एक समस्या थी जिसे आप दोहराया नहीं जाना चाहते हैं, इसलिए आप पहले मामले की तरह ही कार्रवाई करते हैं।

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