प्रोग्रामरहरू, डेभोप्स र श्रोडिङगरका बिरालाहरू

नेटवर्क इन्जिनियरको वास्तविकता (नूडल्स र... नुन संग?)

भर्खरै, इन्जिनियरहरूसँग विभिन्न घटनाहरू छलफल गर्दा, मैले एक रोचक ढाँचा देखे।

यी छलफलहरूमा, "मूल कारण" को प्रश्न सधैं आउँछ। विश्वासी पाठकहरूलाई थाहा छ कि मसँग छ धेरै विचारहरू मा यो बारेमा। धेरै संस्थाहरूमा, घटना विश्लेषण पूर्ण रूपमा यस अवधारणामा आधारित छ। तिनीहरू कारण-र-प्रभाव सम्बन्धहरू पहिचान गर्न विभिन्न प्रविधिहरू प्रयोग गर्छन्, जस्तै "पाँच किन"। यी विधिहरूले तथाकथित "घटनाहरूको रेखीयता" लाई निर्विवाद सिद्धान्तको रूपमा मान्छन्।

जब तपाइँ यो विचारलाई चुनौती दिनुहुन्छ र बताउनुहुन्छ कि जटिल प्रणालीहरूमा रैखिकता आश्वासनपूर्ण रूपमा भ्रामक छ, एक आकर्षक छलफल जन्मन्छ। विवादकर्ताहरू जोशका साथ जोड दिन्छन् कि "मूल कारण" को ज्ञानले हामीलाई के भइरहेको छ भनेर बुझ्न अनुमति दिन्छ।

मैले एउटा चाखलाग्दो ढाँचा देखेँ: विकासकर्ताहरू र डेभपहरूले यस विचारमा फरक प्रतिक्रिया दिन्छन्। मेरो अनुभवमा, विकासकर्ताहरूले तर्क गर्ने सम्भावना बढी हुन्छ कि मूल कारण महत्त्वपूर्ण हुन्छ र त्यो कारण र प्रभाव सम्बन्धहरू जहिले पनि घटनाहरूमा स्थापित गर्न सकिन्छ। अर्कोतर्फ, DevOps प्रायः सहमत हुन्छन् कि जटिल संसारले सधैं रेखीयता पालन गर्दैन।

म सधैं सोच्छु किन यस्तो ? के बनाउँछ प्रोग्रामरहरूले "मूल कारण मिथक हो" भन्ने विचारको आलोचना गर्ने? एक प्रतिरक्षा प्रणाली जस्तै कि एक विदेशी एजेन्ट पहिचान। तिनीहरू किन यसरी प्रतिक्रिया गर्छन्, जबकि डेभप्स बरु झुकाव यो विचार विचार गर्नुहोस्?

म पूर्णतया निश्चित छैन, तर मसँग यस बारे केही विचारहरू छन्। यो विभिन्न सन्दर्भहरूसँग सम्बन्धित छ जसमा यी पेशेवरहरूले आफ्नो दैनिक काम गर्छन्।

विकासकर्ताहरू प्राय: निर्धारक उपकरणहरूसँग काम गर्छन्। निस्सन्देह, कम्पाइलरहरू, लिङ्करहरू, अपरेटिङ सिस्टमहरू - यी सबै जटिल प्रणालीहरू हुन्, तर हामी यस तथ्यमा अभ्यस्त छौं कि तिनीहरूले एक निर्णायक परिणाम दिन्छन्, र हामी तिनीहरूलाई निर्णायकको रूपमा कल्पना गर्छौं: यदि हामीले उही इनपुट डेटा प्रदान गर्दछौं, तब हामी सामान्यतया अपेक्षा गर्दछौं। यी प्रणालीहरूबाट समान आउटपुट। र यदि त्यहाँ आउटपुट ("बग") मा समस्या छ, तब विकासकर्ताहरूले इनपुट डेटा (या त प्रयोगकर्ताबाट वा विकास प्रक्रियाको क्रममा उपकरणहरूको सेटबाट) विश्लेषण गरेर समाधान गर्छन्। तिनीहरूले "त्रुटि" खोज्छन् र त्यसपछि इनपुट डेटा परिवर्तन गर्छन्। यसले "बग" फिक्स गर्छ।

सफ्टवेयर विकासको आधारभूत धारणा: उही इनपुट डेटा विश्वसनीय र निश्चित रूपमा उही आउटपुट उत्पादन गर्दछ।

वास्तवमा, एक गैर-निर्धारित परिणाम आफैलाई बग मानिन्छ: यदि अप्रत्याशित वा गलत आउटपुट पुन: उत्पादन गरिएको छैन भने, त्यसपछि विकासकर्ताहरूले स्ट्याकको अन्य भागहरू (अपरेटिङ सिस्टम, नेटवर्क, आदि) मा अनुसन्धान विस्तार गर्न खोज्छन्, जसले व्यवहार पनि गर्दछ। अधिक वा कम निश्चित रूपमा, समान इनपुट डेटाको साथ समान परिणाम उत्पादन गर्दै... र यदि यो मामला होइन, त्यसपछि यो अझै पनि एक बग मानिन्छ। यो भर्खरै अपरेटिङ सिस्टम वा नेटवर्क बग हो।

जे भए पनि, निश्चयवाद एक आधारभूत हो, प्राय जसो प्रोग्रामरहरूले गर्ने कामका लागि प्रायः लिइएको मान्यता हो।

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

त्यसैले अनुभवी इन्जिनियरहरूलाई शंका गर्न सजिलो छ कि सबै घटनाहरूको एउटै मूल कारण छ, र "पाँच किन" जस्ता प्रविधिहरूले सही रूपमा (र दोहोर्याएर!) त्यो मूल कारणलाई नेतृत्व गर्नेछ। वास्तवमा, यो तिनीहरूको आफ्नै अनुभवको विरोधाभास हो, जहाँ पजल टुक्राहरू व्यवहारमा यति सफासँग फिट हुँदैनन्। त्यसैले, तिनीहरूले यो विचार अझ सजिलै स्वीकार्छन्।

निस्सन्देह, म विकासकर्ताहरू भोली, मूर्ख, वा रेखीयता कसरी भ्रामक हुन सक्छ भनेर बुझ्न असक्षम छन् भनेर भनिरहेको छैन। अनुभवी प्रोग्रामरहरूले पनि उनीहरूको समयमा धेरै गैर-निर्धारितता देखेका छन्।

तर मलाई लाग्छ कि यी बहसहरूमा विकासकर्ताहरूबाट एक साझा प्रतिक्रिया प्रायः तथ्यसँग सम्बन्धित छ कि दृढतावादको अवधारणा। तिनीहरूलाई समग्रमा राम्रोसँग सेवा गर्दछ दैनिक काममा। ईन्जिनियरहरूले आफ्नो पूर्वाधारमा श्रोडिङगरको बिरालाहरू समात्नु पर्ने जति पटक तिनीहरूले गैर-निर्धारितताको सामना गर्दैनन्।

यसले अवलोकन गरिएका विकासकर्ता प्रतिक्रियाहरूलाई पूर्ण रूपमा व्याख्या नगर्न सक्छ, तर यो एक शक्तिशाली रिमाइन्डर हो कि हाम्रा प्रतिक्रियाहरू धेरै कारकहरूको जटिल मिश्रण हो।

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

स्रोत: www.habr.com