Cross-Project Flakiness: A Case Study of the OpenStack Ecosystem

कल्पना कीजिए कि आप एक विशाल, वैश्विक निर्माण दल का हिस्सा हैं जो OpenStack नामक एक विशाल, जटिल क्लाउड शहर बना रहा है। यह शहर एक व्यक्ति द्वारा नहीं बनाया गया है; इसे हजारों श्रमिकों (डेवलपर्स) द्वारा सैकड़ों अलग-अलग मोहल्लों (प्रोजेक्ट्स) जैसे कि Cinder, Glance और Nova पर काम करके बनाया गया है। यह सुनिश्चित करने के लिए कि शहर ढह न जाए, जब भी कोई नया ईंट जोड़ता है या पाइप बदलता है, तो वे स्वचालित "सुरक्षा जांच" (टेस्ट्स) की एक श्रृंखला चलाते हैं।

आदर्श रूप से, ये सुरक्षा जांच एक आदर्श ट्रैफिक लाइट की तरह होनी चाहिए: हरा मतलब "जाएं, बदलाव सुरक्षित है," और लाल मतलब "रुकें, एक समस्या है।"

लेकिन कभी-कभी, ट्रैफिक लाइट टिमटिमाती है। यह बिना किसी ठोस कारण के लाल हो जाती है, फिर दोबारा जांच करने पर हरी हो जाती है, और फिर से लाल हो जाती है। सॉफ्टवेयर की दुनिया में, इसे "Flakiness" (अस्थिरता) कहा जाता है। यह एक ऐसे टेस्ट की तरह है जो "मूड वाला" है—उसे नहीं पता कि उसे पास होना है या फेल, भले ही कोड में कुछ भी न बदला गया हो।

यह शोध पत्र एक जासूसी कहानी है कि कैसे यह "मूड वाला" व्यवहार पूरे OpenStack शहर में, न कि केवल एक मोहल्ले में, फैलता है।

दो बड़ी समस्याएं जो उन्होंने पाईं

शोधकर्ताओं ने पाया कि यह "म mood वाला" व्यवहार दो विशिष्ट तरीकों से परेशानी पैदा करता है:

1. "छूत वाली" गड़बड़ी (Cross-Project Flakiness)
कल्पना कीजिए कि एक विशिष्ट सुरक्षा जांच (एक टेस्ट) जो यह सत्यापित करने के लिए है कि दरवाजे का लॉक काम करता है या नहीं। इस शहर में, वही लॉक-चेक Cinder मोहल्ले, Glance मोहल्ले और Nova मोहल्ले में उपयोग किया जाता है।

• समस्या: लॉक-चेक "मूड वाला" है। यह तीनों मोहल्लों में बेतरतीब ढंग से विफल होता है।
• प्रभाव: क्योंकि मोहल्ले इस एक टेस्ट को साझा करते हैं, इसलिए एक एकल ग्लिच वाला टेस्ट एक साथ कई जगहों पर प्रगति को रोक देता है। शोधकर्ताओं ने पाया कि OpenStack के सभी मोहल्लों में से 55% इन छूत वाली गड़बड़ियों से प्रभावित हैं। यह एक खराब सेब की तरह है जो पूरे बैरल को सड़ा देता है, लेकिन यहाँ वह सेब वास्तव में एक टेस्ट है जिसे हर कोई उपयोग कर रहा है।

2. "अपनी पसंद का चुनने वाली" गड़बड़ी (Inconsistent Flakiness)
अब, उसी लॉक-चेक की कल्पना करें जिसका उपयोग Cinder मोहल्ले और Nova मोहल्ले में किया जाता है।

• समस्या: Cinder में, वह टेस्ट पूरी तरह से विश्वसनीय है (हमेशा हरा)। लेकिन Nova में, वही टेस्ट "मूड वाला" है (लाल और हरे के बीच झूल रहा है)।
• प्रभाव: यह भ्रमित करने वाला है! इसका मतलब है कि टेस्ट खुद टूटा हुआ नहीं है; बल्कि Nova में कुछ वातावरण (environment) के कारण समस्या हो रही है। यह एक ऐसी कार की तरह है जो आपके घर के ड्राइववे में तो ठीक स्टार्ट होती है, लेकिन हर बार जब आप अपने दोस्त के घर पर इसे स्टार्ट करने की कोशिश करते हैं, तो यह झटके लेने लगती है। शोधकर्ताओं ने ऐसे 1,100 से अधिक "अपनी पसंद का चुनने वाले" ग्लिच पाए।

सबसे बड़ा आश्चर्य: "यूनिट" टेस्ट भी बीमार हो रहे हैं

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

शोध पत्र का चौंकाने वाला निष्कर्ष:
शोधकर्ताओं ने पाया कि इन "सूक्ष्मदर्शी" टेस्ट्स में से 70% वास्तव में उन "छूत वाली" गड़बड़ियों में शामिल हैं।

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

यह क्यों होता है? (कारण)

टीम ने लॉग्स की जांच की ताकि यह पता लगाया जा सके कि टेस्ट कुछ जगहों पर क्यों और कुछ जगहों पर क्यों अजीब व्यवहार कर रहे थे। उन्हें तीन मुख्य अपराधी मिले:

1. "रेस कंडीशन" (89% का हत्यारा): यह सबसे आम कारण है। कल्पना कीजिए कि दो कार्यकर्ता ठीक उसी मिलीसेकंड में एक ही उपकरण को पकड़ने की कोशिश कर रहे हैं। कभी वर्कर A उसे पाता है; कभी वर्कर B उसे पाता है। यदि टेस्ट किसी संसाधन (जैसे सर्वर या फ़ाइल) को पकड़ने की कोशिश करता है जो पहले से ही किसी और चीज़ द्वारा उपयोग किया जा रहा है, तो वह विफल हो जाता है। यदि उसे वह मिल जाता है, तो वह पास हो जाता है। यह यादृच्छिकता (randomness) "रेस कंडीशन" कहलाती है।
2. मेल न खाने वाले कॉन्फ़िगरेशन (Mismatched Configurations): यह एक देश की रेसिपी का उपयोग करके दूसरे देश की सामग्री के साथ केक बनाने जैसा है। टेस्ट एक विशिष्ट सेटअप (जैसे लाइब्रेरी का एक विशिष्ट संस्करण या एक विशिष्ट सर्वर गति) की अपेक्षा करता है, लेकिन वातावरण मेल नहीं खाता।
3. निर्भरता के मुद्दे (Dependency Issues): एक मोहल्ले ने अपना "पावर ग्रिड" (एक सॉफ्टवेयर लाइब्रेरी) अपडेट किया होगा, जबकि पड़ोसी शहर ने नहीं किया होगा। टेस्ट अपडेटेड शहर में काम करता है लेकिन पुराने वाले में विफल हो जाता है।

"इंतजार करो और देखो" दृष्टिकोण की लागत

जब कोई टेस्ट विफल होता है, तो OpenStack में मानक प्रतिक्रिया यह होती है कि, "ओह, यह जरूर एक ग्लिच होगा। चलो इसे बस फिर से चलाते हैं (recheck) और इंतजार करते हैं।"

• लागत: शोधकर्ताओं ने गणना की कि इस "recheck और इंतजार" की आदत ने कंप्यूटिंग समय और पैसे के 1,156 दिन बर्बाद कर दिए हैं।
• उपमा: यह एक ट्रैफिक पुलिसकर्मी को देखने जैसा है जो लाल बत्ती देखता है, मान लेता है कि सेंसर खराब है, और कारों को जाने का इशारा करता है, फिर दोबारा चेक करता है, और फिर से जाने का इशारा करता है, और फिर से करता है। यह ईंधन (कंप्यूटिंग संसाधन) बर्बाद करता है और सभी की यात्रा (कोड रिव्यू) में देरी करता है।

श्रमिक क्या कहते हैं? (डेवलपर फीडबैक)

शोधकर्ताओं ने वास्तविक बिल्डर्स (डेवलपर्स) से इस बारे में पूछा।

• हताशा: कई डेवलपर्स असहाय महसूस करते हैं। वे कहते हैं, "मैं नया हूँ, मुझे नहीं पता कि किससे पूछना है, इसलिए मैं बस तब तक 'recheck' दबाता रहता हूँ जब तक कि यह पास न हो जाए।"
• वास्तविकता: वे स्वीकार करते हैं कि इन मुद्दों को ठीक करना कठिन है क्योंकि इसके लिए कई टीमों से बात करने की आवश्यकता होती है। यदि एक टेस्ट Nova में इसलिए विफल होता है क्योंकि Cinder में कोई समस्या है, तो Nova डेवलपर को Cinder टीम द्वारा इसे ठीक करने तक इंतजार करना होगा।
• टूल गैप: उन्होंने उल्लेख किया कि हालांकि उपकरण मौजूद हैं, लेकिन वे अक्सर टूट जाते हैं या छोड़ दिए जाते हैं क्योंकि किसी के पास उनका रखरखाव करने का समय नहीं होता। उन्हें CI सिस्टम के लिए एक समर्पित "मैकेनिक" की आवश्यकता है, न कि केवल स्वयंसेवकों की जो इसे साइड में करते हैं।

निष्कर्ष (The Takeaway)

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

• डेवलपर्स के लिए: केवल "recheck" करने और इंतजार करने से बचें। जांचें कि एक टेस्ट क्यों विफल हुआ, भले ही वह आपके कोड से असंबंधित लगे।
• टीम लीड्स के लिए: आपको सभी मोहल्लों में टेस्ट चलाने के तरीके को मानकीकृत (standardize) करने की आवश्यकता है। यदि एक शहर एक विशिष्ट उपकरण का उपयोग करता है, तो सभी को वही करना चाहिए। आपको इन गड़बड़ियों को ट्रैक करने के लिए भी केंद्रीकृत प्रणाली की आवश्यकता है ताकि सभी को पता चल सके कि कौन से "पेंच" ढीले हैं।
• भविष्य के लिए: हमें बेहतर उपकरणों की आवश्यकता है जो स्वचालित रूप से हमें बता सकें कि टेस्ट क्यों "फ्लैकी" (flaky) है (उदाहरण के लिए, "यह इसलिए विफल हुआ क्योंकि सर्वर डाउन था," न कि केवल "यह विफल हुआ")।

संक्षेप में, शोध पत्र तर्क देता है कि OpenStack शहर को सुचारू रूप से चलाने के लिए, हमें टेस्ट विफलताओं को केवल "खराब किस्मत" के रूप में नहीं, बल्कि एक व्यवस्थित समन्वय समस्या (systemic coordination problem) के रूप में देखना होगा जो पूरे शहर को प्रभावित करती है।