अपने करियर की शुरुआत में, मैं अंदाज़े से डीबग करता था। कुछ टूटता, मैं कोड को घूरता, कुछ बदलता, फिर से डिप्लॉय करता, उम्मीद करता। कभी-कभी यह काम करता। अक्सर यह चीज़ों को और खराब कर देता।
जब आप ऐसे सिस्टम बना रहे होते हैं जिन पर लोग निर्भर होते हैं, तो आप अनुमान लगाने का जोखिम नहीं उठा सकते। मैंने व्यवस्थित रूप से डीबग करने के लिए एक फ्रेमवर्क विकसित किया। यह आकर्षक नहीं है, लेकिन यह हर बार काम करता है।
फ्रेमवर्क: ISOLATE
I — लक्षण की पहचान करें (कारण की नहीं) S — प्रभाव क्षेत्र का दायरा निर्धारित करें O — डेटा का अवलोकन करें (लॉग, मेट्रिक्स, ट्रेसेस) L — परिकल्पनाओं की सूची बनाएं (कम से कम 3) A — प्रत्येक परिकल्पना का साक्ष्य के साथ मूल्यांकन करें T — फिक्स को अलग-थलग करके परखें E — समझाएं कि क्या हुआ (पोस्टमॉर्टम)
आइए एक वास्तविक उदाहरण देखें।
वास्तविक मामला: डैशबोर्ड 30 सेकंड में लोड हो रहा है
I — लक्षण की पहचान करें। उपयोगकर्ता रिपोर्ट करते हैं कि क्वालिटी डैशबोर्ड लोड होने में 30+ सेकंड लग रहे हैं। लोकली यह 2 सेकंड में लोड होता है। केवल प्रोडक्शन में।
अभी "यह डेटाबेस की समस्या है" या "यह नेटवर्क की समस्या है" पर न कूदें। बस वही बताएं जो आप देख रहे हैं।
S — प्रभाव क्षेत्र का दायरा निर्धारित करें। क्या यह सभी उपयोगकर्ताओं के लिए है या विशिष्ट उपयोगकर्ताओं के लिए? सभी ब्राउज़र? कब शुरू हुआ? क्या यह किसी डिप्लॉय से संबंधित है?
इस मामले में: सभी उपयोगकर्ता, 3 दिन पहले शुरू हुआ, उस समय सीमा में कोई डिप्लॉय नहीं। यह "हमने टूटा हुआ कोड शिप किया" को कारण के रूप में खारिज करता है।
O — डेटा का अवलोकन करें।
\\
