प्रोड में काम करता है: यह क्या है, क्यों होता है और क्यों खतरनाक है

“प्रोड में काम करता है” का क्या मतलब है

“प्रोड में काम करता है” डेवलपरों के बीच एक स्थिर वाक्य है जो एक ऐसी स्थिति का वर्णन करता है जहां कोड प्रोडक्शन सर्वर पर काम करता है लेकिन परीक्षण परिवेश या सहकर्मी की स्थानीय मशीन पर काम करने से इनकार कर देता है। बाहरी तौर पर यह “कोई समस्या नहीं” जैसा लगता है, हालाँकि वास्तव में समस्या मौजूद है — बस प्रोडक्शन परिवेश में इसे दोबारा उत्पन्न नहीं किया जा सकता। अंतर का मूल परिवेशों के बीच कॉन्फ़िगरेशन, संस्करणों और डेटा में अंतर है।

यह वाक्य एक और ज्ञात बहाने के विरोधी के रूप में उत्पन्न हुआ — “मेरी मशीन पर काम करता है”। यदि डेवलपर “स्थानीय रूप से काम करता है” कहता है, तो बग केवल दूसरों के लिए मौजूद है। लेकिन यदि “प्रोड में काम करता है”, तो बग केवल स्टेजिंग या परीक्षण परिवेश में दिखाई देता है, जबकि प्रोडक्शन सफ़ है। भाग्य की विडंबना: दोनों ही मामलों में समस्या असली है, बस यह देखने वाले व्यक्ति में प्रकट नहीं होती। DevOps Research and Assessment (DORA) 2023 अध्ययन के अनुसार, उच्च स्तर की परिनियोजन स्वचालन वाली टीमें ऐसे अंतरों का सामना 3 गुना कम करती हैं।

कारोबार के नज़रिये से, “प्रोड में काम करता है” की स्थिति जितनी दिखती है उससे कैही अधिक खतरनाक है। यदि स्टेजिंग पर कोई बग है लेकिन प्रोड पर नहीं, तो डेवलपर इसे नज़रंदाज़ कर सकता है — और फिर अगले परिनियोजन के साथ त्रुटि प्रोडक्शन में चली जाएगी। अस्थायी राहत एक भविष्य की समस्या में बदल जाती है जिसे उपयोगकर्ताओं के दबाव में ठीक करना होगा।

डेवलपर “प्रोड में काम करता है” क्यों कहते हैं

इस वाक्य के बने रहने का मनोवैज्ञानिक कारण एक बचाव प्रतिक्रिया है। जो डेवलपर स्टेजिंग पर एक बग देखता है लेकिन प्रोडक्शन पर नहीं, वह अवचेतन रूप से समस्या को कम आँक सकता है: “जब प्रोडक्शन में सब कुछ ठीक है, तो यह अत्यावश्यक नहीं है”। एक क्लासिक संज्ञानात्मक पक्षपात — उत्तरजीवी पक्षपात, जहां प्रोडक्शन की दिखनी सफलता भविष्य की विफलता के संभावित खतरे से अधिक महत्वपूर्ण हो जाती है।

दूसरा कारण है धुंधली जिम्मेदारी। यदि प्रोडक्शन काम करता है लेकिन स्टेजिंग नहीं, तो दोषी परिवेश है, कोड नहीं। डेवलपर बग की जिम्मेदारी से मुक्त हो जाता है और इसे DevOps इंजीनियर या प्रशासक पर डाल देता है। Atlassian State of DevOps 2022 के अनुसार, बिना एकीकृत परिनियोजन परिवेश (Docker, Kubernetes) के टीमों में, ऐसे स्थानांतरण 60% अधिक बार होते हैं।

तीसरा कारण है ज़ीरो-डाउनटाइम रिलीज़ का डर। यदि डेवलपर स्टेजिंग पर बग को ठीक करता है और सुधार जारी करता है, तो इसके लिए एक और कोड समीक्षा, परीक्षण और परिनियोजन की आवश्यकता होती है। “प्रोड में काम करता है” वाक्य सुधार को अगले रिलीज़ तक टालने की अनुमति देता है, जिससे वर्तमान कार्यभार कम होता है। विलंबित सुधार टीमों में तकनीकी ऋण के संचय के मुख्य कारणों में से एक है।

डेवलपमेंट और प्रोडक्शन परिवेशों के बीच अंतर

प्रोडक्शन और स्टेजिंग कभी भी पूर्णतरह समान नहीं होते — यह पैमाने, भार और डेटा में अंतर के कारण तकनीकी रूप से असंभव है। हालाँकि, मुख्य पैरामीटर मेल खाने चाहिए: ऑपरेटिंग सिस्टम संस्करण, कंपाइलर, इंटरप्रेटर, डेटाबेस, वेब सर्वर और परियोजना की सभी निर्भरताएँ। यदि एक भी पैरामीटर अलग है, तो कोड का व्यवहार बदल सकता है।

परिवेशों के बीच मुख्य अंतर में शामिल हैं:

• हार्डवेयर — प्रोसेसर, RAM का आकार, डिस्क प्रकार (SSD बनाम HDD) समय और मल्टीथ्रेडिंग प्रदर्शन को प्रभावित कर सकते हैं
• नेटवर्क परिवेश — फ़ायरवॉल, DNS, प्रॉक्सी, लोड बैलैन्सर केवल प्रोड पर मौजूद होते हैं
• डेटाबेस में डेटा — स्टेजिंग में आमतौर पर परीक्षण डेटा होता है, जबकि असली उपयोगकर्ता रिकॉर्ड में अप्रत्याशित पैटर्न होते हैं
• निर्भरता संस्करण — एक मामूली लाइब्रेरी अपडेट भी कोड का व्यवहार बदल सकता है
• परिवेश चर — API कुंजीं, टोकन, फ़ीचर फ़्लैग परिवेशों के बीच भिन्न हो सकते हैं

कंटेनरीकरण इनमें से अधिकांश समस्याओं को हल करता है। प्रोडक्शन के लिए बनाई गई वही Docker इमेज स्टेजिंग पर भी इस्तेमाल होनी चाहिए। एकमात्र अंतर परिवेश चर और वॉल्यूम मांट है। Docker State of Application Development 2023 के अनुसार, सभी परिवेशों में एक इमेज का उपयोग करने वाली टीमें विसंगतियों को 74% कम करती हैं।

प्रोड पर व्यवहार बेमेल होने के विशिष्ट कारण

पहला और सबसे आम कारण है निर्भरताओं के विभिन्न संस्करण। डेवलपर स्थानीय रूप से --save फ़्लैग के साथ एक पैकेज स्थापित करता है लेकिन package.json या lock फ़ाइल को अपडेट करना भूल जाता है। प्रोडक्शन पर परिनियोजन के दौरान, एक अलग संस्करण स्थापित होता है जो अलग बेखावर करता है। npm इकोसिस्टम के लिए, lock फ़ाइल समस्या को पूर्णतरह हल करती है; अन्य पैकेज प्रबंधकों के लिए समान तंत्र मौजूद हैं (Gemfile.lock, Podfile.lock, pubspec.lock)।

दूसरा कारण है लापता या अतिरिक्त परिवेश चर। डेवलपर अपनी स्थानीय मशीन पर .env फ़ाइल का उपयोग करता है लेकिन CI/CD पाइपलाइन या सर्वर में संबंधित चर नहीं जोड़ता है। परिणाम: API या डेटाबेस संयोग त्रुटि के साथ कोड विफल हो जाता है। GitLab DevSecOps Survey 2023 के अनुसार, 27% प्रोडक्शन घटनाएँ गलत परिवेश चरों से संबंधित होती हैं।

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

चौथा कारण है क्षेत्रीय और भाषा सेटिंग्स। दिनांक स्वरूप, दशमलव विभाजक, टेक्स्ट एन्कोडिंग — ये सभी डेवलपर की स्थानीय मशीन और सर्वर पर भिन्न हो सकते हैं। यह अंतर्राष्ट्रीयकरण वाली परियोजनाओं के लिए विशेष रूप से प्रासंगिक है। हल है एप्लिकेशन कॉन्फ़िगरेशन में स्पष्ट रूप से locale निर्दिष्ट करना और सिस्टम सेटिंग्स पर निर्भर नहीं करना।

“प्रोड में काम करता है” समस्या का निदान कैसे करें

पहला कदम है दोनों परिवेशों के लॉग्स की तुलना करना। लॉगिंग स्तर में अंतर अक्सर कारण छुपाता है: प्रोडक्शन में INFO सक्रिय हो सकता है, जबकि स्टेजिंग में DEBUG। समान लॉगिंग स्तर कॉन्फ़िगर करें और सुनिश्चित करें कि दोनों परिवेश एक ऐसे फ़ॉर्मेट में लिखते हैं जो मशीन तुलना की अनुमति देता है। केंद्रीयकृत लॉग संग्रह प्रणालियों का उपयोग करें — Sentry, Datadog, ELK Stack।

दूसरा कदम है निर्भरता संस्करणों की जाँच करना। lock फ़ाइलों की तुलना करें, दोनों परिवेशों पर स्थापित पैकेजों की सूची बनाएँ। मामूली या पैच संस्करण में अंतर असंगति का सबसे संभावित कारण है। npm ls, pip freeze, mvn dependency:tree जैसे उपकरण असंगतियों की शीघ्र पहचान करने में मदद करते हैं।

तीसरा कदम है प्रोडक्शन परिवेश को स्थानीय रूप से दोबारा तैयार करना। प्रोडक्शन बुनियादी ढांचे की सटीक प्रतिलिपि बनाने के लिए Docker Compose या समान उपकरणों का उपयोग करें। यदि बग एक स्थानीय कंटेनर में दोबारा उत्पन्न होता है, तो समस्या कोड में है, परिवेश में नहीं। यदि यह दोबारा उत्पन्न नहीं होता है, तो कॉन्फ़िगरेशन में अंतर देखें।

चौथा कदम है फ़ीचर फ़्लैग और A/B परीक्षणों की जाँच करना। हो सकता है कि कोड प्रोडक्शन में एक अलग मोड में काम करता है क्योंकि गलत फ़्लैग सक्रिय है। LaunchDarkly State of Feature Management 2023 के अनुसार, 40% तक अप्रत्याशित व्यवहार प्रोडक्शन में गलत फ़ीचर फ़्लैग मानों से संबंधित होता है। सभी परिवेशों के लिए एक एकीकृत फ़्लैग घोषणपत्र इस समस्या को हल करता है।

परियोजना में परिवेशों के अंतर को रोकना

मुख्य रोकथाम उपकरण है Infrastructure as Code (IaC)। सभी परिवेशों का वर्णन कोड में किया जाना चाहिए: Dockerfile, docker-compose.yml, Terraform स्क्रिप्ट या Ansible प्लेबुक्स। सर्वर पर मैनुअल बदलाव प्रतिबंधित हैं — कोई भी कॉन्फ़िगरेशन परिवर्तन रिपोज़िटरी और कोड समीक्षा से गुजरता है। यह सुनिश्चित करता है कि सभी परिवेशों में समान कॉन्फ़िगरेशन है।

दूसरा सबसे महत्वपूर्ण उपकरण है एक एकीकृत CI/CD पाइपलाइन। बिल्ड, टेस्ट और पड़तैनात का वही स्क्रिप्ट सभी परिवेशों के लिए उपयोग किया जाना चाहिए। एकमात्र अंतर लक्ष्य चरों (URL, कुंजीं) में है। यदि स्टेजिंग और प्रोडक्शन के लिए पाइपलाइन चरणों में भिन्न है, तो असंगतियाँ अपरिहार्य हैं।

तीसरा उपकरण है स्वचालित डेटा सिंकरणिज़ेशन। नियमित रूप से (दैनिक या शेडूल के अनुसार) प्रोडक्शन डेटाबेस की एक अननामित प्रतिलिपि के साथ स्टेजिंग को अपडेट करें। यह संश्लेषित फ़िक्स्चर्स के बजाय असली डेटा पर कोड का परीक्षण करने की अनुमति देता है। उपकरण: PostgreSQL के लिए pg_dump/pg_restore, MySQL के लिए mysqldump, DataGrip जैसी विशेषित सेवाएँ।

चौथा उपकरण है असंगतियों की निगरानी। स्टेजिंग और प्रोडक्शन के बीच अंतर का पता लगने पर अलर्ट सेट करें। एक सरल स्क्रिप्ट जो कॉन्फ़िगरेशन फ़ाइलों के हैश या स्थापित पैकेजों के संस्करणों की तुलना करता है, डीबगिंग के घंटों को बचाएगा। रोकथाम हमेशा निदान से सस्ता है: परिवेशों के अंतर को रोकना “प्रोड में काम करता है” बग का कारण खोजने की तुलना में कम प्रयास लेता है।