Where did we fail? -- Reproducing build failures in embedded open source software
यह शोधपत्र PhantomRun को प्रस्तुत करता है, जो एक एकीकृत एब्स्ट्रैक्शन लेयर और डेटासेट है जो एम्बेडेड ओपन सोर्स सॉफ्टवेयर के लिए CI बिल्ड लॉग्स और मेटाडेटा की पुनर्प्राप्ति और निष्ठापूर्ण पुनरुत्पादन को मानकीकृत करता है, जिससे उच्च पुनर्निर्माण सटीकता के साथ ऐतिहासिक बिल्ड विफलताओं के बड़े पैमाने पर, पुनरुत्पादनीय अध्ययन सक्षम होते हैं।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
कल्पना कीजिए कि आप एक जासूस हैं जो पिछले साल एक फैक्ट्री में हुई एक रहस्यमय घटना को सुलझाने की कोशिश कर रहे हैं। यह फैक्ट्री जटिल गैजेट्स (एम्बेडेड सॉफ्टवेयर) बनाती है जो हार्डवेयर और कोड को आपस में जोड़ते हैं। जब भी एक नया गैजेट डिज़ाइन टेस्ट किया जाता है, फैक्ट्री एक विशाल, स्वचालित असेंबली लाइन (कंटीन्यूअस इंटीग्रेशन, या CI) चलाती है। कभी-कभी, असेंबली लाइन टूट जाती है और मशीन एक एरर मैसेज के साथ रुक जाती है।
समस्या क्या है? फैक्ट्री अराजक (chaotic) है। यह हर टेस्ट के लिए अलग-अलग टूल्स, अलग-अलग रोबोट और अलग-अलग ब्लूप्रिंट का उपयोग करती है। जब कोई टेस्ट फेल होता है, तो मशीन एक लंबा, बिखरा हुआ रसीद (बिल्ड लॉग) प्रिंट करती है जो यह बताती है कि वह क्यों फेल हुआ। लेकिन यहाँ एक पेंच है: ये रसीदें कुछ दिनों के बाद फेंक दी जाती हैं, और वह विशिष्ट रोबोट जिसने उन्हें प्रिंट किया था, शायद अब अस्तित्व में भी न हो। यदि आप छह महीने पहले मशीन क्यों टूटी थी, इसका अध्ययन करना चाहते हैं, तो आप केवल रसीद को देखकर नहीं कर सकते; आपको ठीक उसी फैक्ट्री सेटअप को फिर से बनाने की कोशिश करनी होगी ताकि देखें कि क्या वह फिर से टूटता है।
यही वह समस्या है जिसे पेपर "Where did we fail?" हल करता है। लेखकों ने इस समस्या को सुलझाने के लिए PhantomRun नामक एक टूल बनाया है।
समस्या: "घोस्ट" (भूतिया) फैक्ट्री
एम्बेडेड सॉफ्टवेयर की दुनिया में (जैसे आपकी कार, थर्मोस्टेट या मेडिकल डिवाइस के अंदर का कोड), सॉफ्टवेयर बनाना एक ऐसे किचन में केक बनाने जैसा है जिसका लेआउट हर बार आपके अंदर कदम रखने पर बदल जाता है।
- सामग्री बदलती रहती है: टूल्स (कंपाइलर) और हिस्से (डिपेंडेंसीज़) लगातार अपडेट होते रहते हैं।
- किचन बदलता रहता है: फैक्ट्री हर टेस्ट के लिए अलग-अलग रोबोट (रनर्स) और ब्लूप्रिंट (कॉन्फ़िगरेशन) का उपयोग करती है।
- सबूत गायब हो जाते हैं: जब कोई टेस्ट फेल होता है, तो एरर लॉग एक ऐसी रसीद की तरह होता है जिसे एक हफ्ते के बाद फाड़कर फेंक दिया जाता है।
इस कारण से, यदि कोई डेवलपर अतीत की किसी विफलता (failure) का अध्ययन करना चाहता है ताकि उसे कैसे ठीक किया जाए यह समझ सके, तो वे अक्सर ऐसा नहीं कर पाते। जिस "किचन" को उन्हें फिर से बनाने की आवश्यकता है, वह अब मौजूद नहीं है।
समाधान: PhantomRun (एक "टाइम-ट्रैवलिंग" ब्लूप्रिंट)
लेखकों ने PhantomRun बनाया है, जो इन अराजक फैक्ट्रियों के लिए एक जादुई, मानकीकृत ब्लूप्रिंट के रूप में कार्य करता है। मूल, बिखरे हुए रोबोट को खोजने के बजाय, PhantomRun एक सटीक, अलग थलग "टाइम कैप्सूल" (एक कंटेनर) बनाता है जो मूल विफलता की सटीक स्थितियों की नकल करता है।
इसे इस तरह सोचिए:
- मूल परिदृश्य: आप एक बंद हो चुके रेस्टोरेंट के एक विशिष्ट व्यंजन को फिर से बनाने की कोशिश करते हैं, लेकिन आपको नहीं पता कि उन्होंने किस ब्रांड का आटा इस्तेमाल किया था या उनके ओवन का तापमान क्या था। आप अनुमान लगाते हैं, और व्यंजन का स्वाद अलग आता है।
- PhantomRun परिदृश्य: PhantomRun एक ऐसी मशीन है जो पुराने रेस्टोरेंट के ऑर्डर टिकट को स्कैन करती है, यह पता लगाती है कि ठीक कौन सा ब्रांड का आटा और ओवन का तापमान था, और आपके बेसमेंट में उस किचन की एक अस्थायी, सटीक प्रतिलिपि बनाती है। फिर यह उस व्यंजन को फिर से पकाती है ताकि देख सके कि क्या यह बिल्कुल उसी तरह फेल होता है।
उन्होंने क्या किया
टीम ने इस टूल को चार प्रमुख ओपन-सोर्स हार्डवेयर प्रोजेक्ट्स (जैसे Zephyr और RTEMS, जो स्मार्ट डिवाइसेस के लिए ऑपरेटिंग सिस्टम हैं) पर लागू किया। उन्होंने अतीत के 4,600 से अधिक विफल टेस्ट्स का अध्ययन किया।
उन्होंने दो प्रश्न पूछे:
- क्या हम फैक्ट्री को फिर से बना सकते हैं? (क्या हम विफलता को फिर से बना सकते हैं?)
- क्या यह उसी तरह टूटता है? (क्या नया फेलियर पुराने वाले के समान है?)
परिणाम
परिणाम आश्चर्यजनक रूप से सफल रहे:
- 91.8% सफलता दर: वे लगभग 92% विफलताओं के लिए "टाइम कैप्सूल" फैक्ट्री को सफलतापूर्वक फिर से बनाने और उस टेस्ट को दोबारा चलाने में सफल रहे।
- 98% सटीकता: जब उन्होंने इसे फिर से बनाया, तो परिणाम लगभग हमेशा एक जैसा ही था। यदि मूल टेस्ट फेल हुआ, तो नया भी फेल हुआ। यदि वह सफल हुआ, तो नया भी सफल हुआ।
- "नॉइज़" (शोर) का कारक: अंतर केवल बहुत मामूली और हानिरहित चीजें थीं, जैसे लॉग पर टाइम स्टैम्प या दो असंबंधित चरणों के होने का क्रम। मुख्य "एरर मैसेज" (कारण कि केक क्यों जल गया) बिल्कुल समान था।
कुछ क्यों विफल हुए
जिन कुछ मामलों में वे विफलता को फिर से नहीं बना सके (लग लगभग 8% बार), वह इसलिए नहीं था क्योंकि उनका टूल खराब था। बल्कि इसलिए था क्योंकि "सामग्री" हमेशा के लिए गायब हो गई थी।
- गायब हार्डवेयर: कुछ टेस्ट्स को एक विशिष्ट फिजिकल चिप या बोर्ड की आवश्यकता थी जो अब मौजूद नहीं है।
- खोए हुए टूल्स: कोड बनाने के लिए उपयोग किए जाने वाले कुछ सॉफ्टवेयर टूल्स इंटरनेट से हटा दिए गए थे या इतने अपडेट हो गए थे कि वे अब संगत (compatible) नहीं रहे।
- सीक्रेट सॉस (गुप्त नुस्खा): कुछ प्रोजेक्ट्स ने निजी, प्रोप्रायटरी टूल्स का उपयोग किया था जिन्हें शोधकर्ता एक्सेस नहीं कर सके।
मुख्य निष्कर्ष
पेपर यह निष्कर्ष निकालता है कि हम इन क्षणभंगुर, बिखरे हुए एरर लॉग्स को स्थायी, विश्वसनीय अनुसंधान उपकरणों में बदल सकते हैं। PhantomRun का उपयोग करके, डेवलपर्स और शोधकर्ता अब ऐतिहासिक विफलताओं को देख सकते हैं, एक नियंत्रित वातावरण में उनका अध्ययन कर सकते हैं, और मूल, अराजक फैक्ट्री सेटअप की आवश्यकता के बिना उनसे सीख सकते हैं।
संक्षेप में: PhantomRun "ओप्स, लॉग गायब है" को "आइए उस सटीक क्षण को फिर से बनाएं जब यह टूटा था और इसका अध्ययन करें" में बदल देता है। यह हमें यह समझने में मदद करता है कि हमारे स्मार्ट डिवाइस क्यों विफल होते हैं और उन्हें भविष्य में अधिक विश्वसनीय कैसे बनाया जाए।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।