केवल

Question

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

Answer 1

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

Answer 2

संक्षेप में, पद्धति पर्यावरण के बीच मतभेदों को अलग और समझना है और एक या कोई समस्या उत्पन्न कर सकता है।

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

2. यह देखने के लिए जांचें कि क्या यह विशेष डेटा है जो समस्या का कारण हो सकता है। यदि आप कर सकते हैं, डेटाबेस की प्रतिलिपि को टेस्ट से वापस स्थानीय पर खींचें और देखें कि क्या आपको समस्या को दोबारा करने में सक्षम बनाता है।

3. अन्य डेवलपर्स के साथ जांचें। देखें कि क्या वे repro कर सकते हैं। उनके पर्यावरण में मुद्दा। अपने क्यूए लोगों से जांचें, इस तरह के मुद्दे के कारण होने पर उनके विचार प्राप्त करें (अक्सर बार वे "समान" मुद्दों को देख चुके होंगे और आपको एक सुराग दे सकते हैं)।

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

Answer 3

वैज्ञानिक विधि हमेशा लागू होती है - पहले अपनी धारणाओं की जांच करें। यदि सिस्टम अलग हैं, तो समस्या किसी प्रकार के निहित डिफ़ॉल्ट भिन्न हो सकती है, या कुछ फ़ंक्शन का एक अलग कार्यान्वयन हो सकता है।

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

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

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

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