डेवलपर टूल के रूप में अंतर्ज्ञान

सभी को नमस्कार! मेरा नाम दिमित्री चेपल है, मैं Acronis में एक विशेषज्ञ हूं। यह सिर्फ इतना हुआ कि वे मुझे उन समस्याओं से रूबरू कराते हैं जो मेरे सहकर्मी नहीं सुलझा सके। कोई सोचता है कि मेरे पास "विकास संबंधी स्वभाव", अंतर्ज्ञान है। मैं आपके बारे में नहीं जानता, लेकिन मेरा मानना ​​है कि अंतर्ज्ञान बाकी के रूप में एक ही विकास उपकरण है, और इसे बेहतर और प्रशिक्षित किया जा सकता है।

एक उपकरण के रूप में अंतर्ज्ञान

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

उदाहरण 1: सेल्फ डैमेजिंग आर्काइव

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

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

व्यापक क्षितिज -> व्यापक अनुभव -> त्रुटियों के लिए त्वरित खोज

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

उदाहरण 2: क्लाइंट ऑपरेशन के परिणाम की प्रतीक्षा नहीं कर सकता और एक त्रुटि के साथ क्रैश हो सकता है

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

उदाहरण 3: बैकअप के बाद न पुनर्प्राप्त करने वाली मशीनें

यहाँ हाल के अतीत से एक और दिलचस्प कहानी है: Acronis में, हमेशा की तरह, वे लगातार याद करते हैं और कुछ सुधार करते हैं, या इसे खरोंच से भी विकसित करते हैं, पिछले अनुभव को ध्यान में रखते हुए। इस विशेष उदाहरण में, डेवलपर्स ने डिस्क बैकअप करने के लिए एक नए प्रकार के संग्रह पर काम किया, जो कि Acronis Cloud Storage का हिस्सा बन जाएगा (या पहले से ही, बन जाएगा)। कोड लिखा गया था, जाँच की गई थी, लड़ाई के परीक्षणों का समय आ गया है। हमने डेटा डाउनलोड किया, एक बैकअप बनाया, इसे क्लाउड पर भेजा और फिर कंप्यूटर को पुनर्स्थापित करने का प्रयास किया। हम परिणामों की जांच करते हैं: भाग - यह काम करता है, भाग - नहीं, कंप्यूटर बस बूट नहीं करते हैं। डिबगिंग, लॉगिंग, स्वचालित और मैन्युअल मोड में त्रुटि जांच की एक थकाऊ श्रृंखला शुरू होती है, पूरी वसूली के लिए फाइल सिस्टम पर एक प्रत्यक्ष नज़र - सब कुछ क्रम में है, वॉल्यूम माउंट है, सभी फाइलें पढ़ी जाती हैं। कुछ छोटी चीजें मिलीं, निश्चित की गईं, लेकिन उन्होंने इस तथ्य को प्रभावित नहीं किया कि कंप्यूटर बूट नहीं करते हैं। कुल मिलाकर, उन्होंने कई रातों की नींद हराम करने के लिए अनलोडिंग के कारण को पकड़ने की कोशिश की (और, फिर से, मैं इसे दोहराना चाहता हूं - केवल कुछ कंप्यूटर लोड नहीं किए गए थे)। सामान्य तौर पर, डेवलपर्स बाहर निकलने के बिना डिबगिंग चक्र में शामिल हो गए। संयोग से, उन्होंने इस तथ्य की ओर ध्यान आकर्षित किया कि mft खंडित है (लगभग डेढ़ हजार भागों में)। तुरंत, यह विचार उत्पन्न हुआ कि बूटलोडर बस इस तरह की जानकारी की एक प्रक्रिया को याद करने के लिए कुछ याद कर रहा था। हमने कोड में प्रवेश किया, फ़ाइल सिस्टम पार्सर को अनुकूलित किया, कुछ स्ट्रोक को ठीक किया और समस्या तुरंत गायब हो गई। इस विशेष मामले में, डिबग-लूप से सभी संभावित trifles पर प्रतिबंध संबंधी ध्यान हटा दिया गया था। और फिर से, रेट्रोस्पेक्ट में, समाधान सरल और स्पष्ट लगता है, और विकास के समय, विखंडन की जांच करने का विचार और पार्सर अंतर्दृष्टि और अचानक उतरा डेवलपर ग्रेस के समान था।

एक निष्कर्ष के बजाय

अपने उत्पाद को जानें, अपने कोड को जानें और अपने परिवेश को जानें। कीड़े को पकड़ने की एक ही विधि पर मत लटकाओ।


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