उत्पादन में कोई छोटी-मोटी गड़बड़ी पैदा किए बिना विश्वसनीय क्रॉन जॉब्स को कैसे शेड्यूल करें

उत्पादन में कोई छोटी-मोटी गड़बड़ी पैदा किए बिना विश्वसनीय क्रॉन जॉब्स को कैसे शेड्यूल करें

क्रॉन जॉब उन छोटे-छोटे उबाऊ कामों में से एक है जो चुपचाप सिस्टम को सुचारू रूप से चलाते हैं। बैकअप, रिपोर्ट ईमेल, इनवॉइस सिंक, कैश वार्मअप, लॉग क्लीनअप, डेटा इंपोर्ट, सर्टिफिकेट चेक, ये सभी काम जिन्हें कोई भी रोज़ाना मैन्युअल रूप से करना नहीं चाहता। और क्योंकि क्रॉन देखने में सरल लगता है, लोग अक्सर इसे सर्वर पर चिपके हुए एक नोट की तरह समझते हैं। पाँच फ़ील्ड, एक कमांड। बस।

फिर यह दो बार चलती है। या बिल्कुल नहीं चलती। या फिर एकदम गलत समय पर चलती है क्योंकि डेलाइट सेविंग टाइम कीचड़ भरे जूते पहनकर कमरे में आ गया है।

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

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

चरण 1: नौकरी की जिम्मेदारियों को लिख लें।

crontab को छूने से पहले, दो मिनट के लिए इसे सरल भाषा में लिखें। कार्य का उद्देश्य सरल शब्दों में लिखें। "sync.sh चलाएँ" जैसे वाक्य न लिखें। बल्कि यह लिखें, "वेयरहाउस API से कल के पूरे हुए ऑर्डर आयात करें और असफल आयातों को मैन्युअल समीक्षा के लिए चिह्नित करें।" यह छोटा सा वाक्य आपको शेड्यूल, लॉगिंग, टाइमआउट और अलर्टिंग चुनने में मदद करेगा।

साथ ही, यह भी तय करें कि इसका मालिक कौन है। क्रॉन जॉब्स बहुत जल्दी ही अनाथ जैसी बन जाती हैं। छह महीने बाद किसी को याद नहीं रहता कि कोई स्क्रिप्ट हर 17 मिनट में क्यों चलती है, लेकिन उसे डिलीट करने से भी डर लगता है। मालिक का नाम कमेंट, README फ़ाइल या रनबुक में लिखें।

चरण 2: व्यवसाय की आवश्यकता के आधार पर समय सारिणी का चयन करें, न कि आदत के आधार पर।

क्रॉन शेड्यूल के कई उदाहरण पुराने ही हैं। आधी रात। हर घंटे। हर पांच मिनट। यह तब तक ठीक लगता है जब तक दस जॉब एक ही समय पर जागकर डेटाबेस पर ऐसे झगड़ने न लगें जैसे कबूतर सैंडविच पर।

कुछ बुनियादी सवाल पूछें:

• परिणाम कितना ताजा होना चाहिए?
• इस काम में सामान्यतः कितना समय लगता है?
• अगर इसमें देरी हो जाए तो क्या होगा?
• अगर यह दो बार चले तो क्या होगा?
• क्या ऐसे भी कुछ समय होते हैं जब काम का बोझ कम होता है?

यदि कोई रिपोर्ट सुबह 9:00 बजे प्रबंधकों द्वारा पढ़ी जाती है, तो शायद उसे रात भर हर 10 मिनट में चलाने की आवश्यकता नहीं है। यदि कोई क्लीनअप जॉब अस्थायी फ़ाइलों को हटाता है, तो शायद दैनिक रूप से चलाना पर्याप्त है। और यदि किसी क्यू प्रोसेसर को बार-बार काम करने की आवश्यकता होती है, तो क्रॉन शायद सही टूल भी न हो, एक वर्कर प्रोसेस अधिक बेहतर हो सकता है।

चरण 3: धीरे-धीरे पांच क्रॉन फ़ील्ड को समझें

अधिकांश मानक क्रॉन एक्सप्रेशन में पाँच समय फ़ील्ड का उपयोग होता है: मिनट, घंटा, महीने का दिन, महीना और सप्ताह का दिन। तो यह इस प्रकार है:

30 2 * * *

इसका मतलब है हर दिन सुबह 2:30 बजे। हर 30 मिनट में नहीं। आज से 2 घंटे 30 मिनट बाद भी नहीं। बल्कि हर उस दिन जब मिनट 30 बजे और घंटा 2 बजे।

रेंज और स्टेप्स उपयोगी तो होते हैं, लेकिन इन्हें समझने में गलती हो सकती है। */15 * * * * का मतलब है हर 15 मिनट में। 0 9-17 * * 1-5 का मतलब है सोमवार से शुक्रवार तक सुबह 9 बजे से शाम 5 बजे तक हर घंटे के शुरू में, यह मानते हुए कि आपका क्रॉन सोमवार से शुक्रवार के लिए 1-5 का उपयोग करता है, जो कि ज्यादातर करते हैं, लेकिन अपने वातावरण की जांच कर लें क्योंकि विवरण भिन्न हो सकते हैं।

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

चरण 4: समय क्षेत्रों के बारे में बहुत सोच-समझकर निर्णय लें।

समय क्षेत्र संबंधी समस्याएं कोई दुर्लभ अपवाद नहीं हैं। ये तो आम बात है।

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

अधिकांश बैकएंड कार्यों के लिए, UTC सबसे कम चौंकाने वाला विकल्प है। इसका लगातार उपयोग करें, इसे दस्तावेज़ में दर्ज करें और मनुष्यों से बात करते समय इसे परिवर्तित करें। यदि कोई कार्य "न्यूयॉर्क समय के अनुसार सुबह 8 बजे" चलना आवश्यक है, तो इसे लिख लें और समझें कि डेलाइट सेविंग के दौरान क्या होता है। कुछ स्थानीय समय वर्ष में एक बार ही होते हैं। कुछ दो बार होते हैं। यह उतना ही मजेदार है जितना किसी प्लग पर पैर रख देना।

चरण 5: ओवरलैपिंग रन को रोकें

यह क्रॉनोग्राफी की सबसे बड़ी वास्तविक गलतियों में से एक है। एक जॉब हर 10 मिनट में निर्धारित की जाती है, लेकिन कभी-कभी API के धीमे होने के कारण एक ही रन में 18 मिनट लग जाते हैं। अब दो कॉपी चल रही हैं। हो सकता है कि दोनों एक ही पंक्तियों को अपडेट कर रही हों। हो सकता है कि दोनों ईमेल भेज रही हों। हो सकता है कि दोनों एक ही नाम से फाइलें बना रही हों और एक फाइल दूसरी को ओवरराइट कर दे।

लॉक का इस्तेमाल करें। आपके सेटअप के आधार पर, यह फ्लॉक , डेटाबेस एडवाइजरी लॉक, सावधानीपूर्वक क्लीनअप वाली लॉक फाइल, या सिंगल एग्जीक्यूशन की गारंटी देने वाला जॉब सिस्टम हो सकता है। सटीक टूल से ज़्यादा ज़रूरी नियम है: अगर ओवरलैपिंग नुकसानदायक हो, तो उसे जानबूझकर रोकें।

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

चरण 6: नौकरियों को पुनः प्रयास करने के लिए सुरक्षित बनाएं

विश्वसनीय शेड्यूल्ड वर्क आमतौर पर आइडम्पोटेंट (दोहरा कार्य) के रूप में डिज़ाइन किया जाता है, जिसका अर्थ है कि आप इसे बिना किसी दोहराव के दोबारा चला सकते हैं। यह शब्द सुनने में थोड़ा जटिल लगता है, लेकिन इसका मतलब सीधा-सादा है। यदि जॉब ने पहले ही इनवॉइस 123 को प्रोसेस कर दिया है, तो इसे दोबारा चलाने पर यह बात ध्यान में आ जानी चाहिए और इसे छोड़ देना चाहिए, न कि ग्राहक से दो बार शुल्क लेना या वही ईमेल दोबारा भेजना।

स्टेटस कॉलम, यूनिक आईडी, ट्रांजैक्शन बाउंड्री और "प्रोसेसिंग एट" टाइमस्टैम्प का उपयोग करें। फ़ाइल संबंधी कार्यों के लिए, पहले एक अस्थायी फ़ाइल में लिखें, फिर पूरा होने पर उसका नाम बदल दें। बाहरी API के लिए, अनुरोध आईडी या प्रतिक्रिया स्थिति को जहाँ संभव हो, स्टोर करें। ये सब चीज़ें पहली आंशिक विफलता तक अतिरिक्त झंझट लगती हैं, लेकिन फिर अचानक यही सब कुछ हो जाता है जिसकी सबको परवाह होती है।

चरण 7: प्रारंभ, समाप्ति और परिणाम दर्ज करें

बिना लॉग के क्रॉन जॉब लगभग एक अफवाह ही होती है। कम से कम, जॉब शुरू होने का समय, खत्म होने का समय, इसमें लगा समय और सफलता का रिकॉर्ड जरूर रखें। संख्याएँ भी शामिल करें: 481 रिकॉर्ड आयात किए गए, 12 छोड़े गए, 3 असफल रहे। संख्याएँ होने से समस्या का पता लगाना बहुत आसान हो जाता है।

सिर्फ़ विफलताओं को ही लॉग न करें। अगर कोई जॉब चुपचाप चलना बंद कर देती है, तो सफल लॉग ही यह साबित करते हैं कि पिछली बार वह सही ढंग से चली थी। आउटपुट को किसी स्थिर जगह पर भेजें, न कि किसी ऐसे टर्मिनल पर जिसे कोई देखता ही न हो। इसके लिए आप अपने ऐप लॉग, सिस्टम लॉग, रोटेशन वाली फ़ाइल या मॉनिटरिंग सेवा का इस्तेमाल कर सकते हैं।

चरण 8: विफलता होने पर चेतावनी दें, लेकिन हर छोटी-मोटी गड़बड़ी पर नहीं।

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

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

क्रॉन में होने वाली आम गलतियाँ जिनसे बचना चाहिए

• वातावरण को भूल जाना एक अलग बात है। क्रॉन आपके इंटरैक्टिव टर्मिनल के समान PATH, शेल प्रोफ़ाइल, भाषा संस्करण या पर्यावरण चर लोड नहीं कर सकता है।
• रिलेटिव पाथ का उपयोग न करें। स्क्रिप्ट, कॉन्फ़िगरेशन फ़ाइलों और आउटपुट डायरेक्टरी के लिए एब्सोल्यूट पाथ का उपयोग करें। क्रॉन को इस बात से कोई फर्क नहीं पड़ता कि आप कहाँ स्थित हैं।
• हर काम को घंटे के हिसाब से शेड्यूल करें। कामों को बांट लें। अगर उन्हें एक साथ निपटाने का कोई कारण नहीं है, तो घंटे के बाद के 7, 13, 42 मिनट का उपयोग करें।
• दिन के उजाले के समय को अनदेखा करना। विशेषकर स्थानीय समय के अनुसार चलने वाले व्यावसायिक कार्यक्रमों के लिए।
• कोई लॉकिंग नहीं। ओवरलैप तब तक शांत रहते हैं जब तक कि अचानक बहुत तेज़ आवाज़ न करने लगें।
• न कोई मालिक, न कोई दस्तावेज़। भविष्य में आपको याद नहीं रहेगा। भविष्य में आप थक चुके होंगे।

चरण 9: प्रोडक्शन कोड जैसे शेड्यूल की समीक्षा करें

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

और समय-समय पर पुराने कामों की जाँच करते रहें। ऐसे शेड्यूल देखें जिनका कोई मालिक नहीं है, ऐसी स्क्रिप्ट देखें जो अब मौजूद नहीं हैं, ऐसे काम देखें जो हमेशा विफल होते हैं, और ऐसे कार्य देखें जो 2021 में अस्थायी थे लेकिन किसी तरह सिस्टम का हिस्सा बन गए हैं। क्रॉन सरल है, हाँ। लेकिन सरल चीजें भी लंबे समय तक अनदेखी किए जाने पर गड़बड़ी पैदा कर सकती हैं।

सबसे अच्छा क्रॉन सेटअप जटिल नहीं होता। यह पूर्वानुमान योग्य, दस्तावेजीकृत, निगरानी में रहने वाला और थोड़ा सुरक्षात्मक होता है। यही चीज़ निर्धारित कार्य को नीरस बनाए रखती है, और नीरसता ही यहाँ सबसे ज़रूरी है।