2,000+ Discord सर्वरों पर बॉट चलाकर हमने क्या सीखा

तीन सर्वरों पर चलने वाला Discord बॉट और दो हज़ार से ज़्यादा सर्वरों पर चलने वाला वही बॉट, एक ही प्रोग्राम का बड़ा रूप नहीं हैं। कुछ धारणाएँ जो छोटे पैमाने पर पूरी तरह हानिरहित होती हैं, एक खास आकार के बाद ठीक वही बग बन जाती हैं जिन्हें ढूंढना सबसे मुश्किल होता है।

यहाँ ऐसी चार हैं, जिनकी वजह से हमें असली आउटेज झेलने पड़े।

1. खराबियाँ बराबर नहीं फैलतीं, वे छिप जाती हैं

AlphaCloud कई प्रोसेस में बँटकर चलता है, जिन्हें शार्ड कहते हैं। कौन सा सर्वर किस शार्ड पर जाएगा, यह Discord तय करता है, और हर शार्ड सिर्फ़ अपने सर्वरों को जानता है।

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

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

2. रीस्टार्ट कोई फ़िक्स नहीं, एक डेडलाइन है

जब तक हमें वजह नहीं पता थी, प्रभावित शार्ड को रीस्टार्ट करने से भरोसेमंद तरीके से मदद मिलती थी। रीस्टार्ट के साथ ठीक यही समस्या है: वे काम करते हैं, और इससे वजह ढूंढने का दबाव खत्म हो जाता है।

अब हम "क्या रीस्टार्ट से मदद मिलती है?" को इलाज नहीं, बल्कि निदान मानते हैं। अगर मिलती है, तो टूटी हुई स्थिति मेमोरी में रहती है, और कोड में कोई ऐसी जगह है जो उसे बनाती है और कभी हटाती नहीं।

उल्टी बात भी सच है: जो कुछ भी रीस्टार्ट के बाद बचा रहना चाहिए, वह डेटाबेस में होना चाहिए। अगर कोई कई चरणों वाला काम चल रहा है, जैसे हज़ारों सदस्यों पर रोल बदलना, और प्रोसेस बीच में ही बंद हो जाए, तो वह काम यूँ ही गायब नहीं होना चाहिए। अगली शुरुआत पर उसे पहचाना और आगे बढ़ाया जाना चाहिए।

3. Discord की सीमाएँ हर बॉट पर लागू होती हैं, हर प्रोसेस पर नहीं

Discord तय करता है कि एक बॉट प्रति सेकंड कितनी रिक्वेस्ट कर सकता है। ज़ाहिर धारणा: ज़्यादा प्रोसेस, ज़्यादा थ्रूपुट। गलत। सीमा बॉट पर है, प्रोसेस पर नहीं। तीन शार्ड, जिनमें से हर एक का पूरा बजट है, मिलकर अनुमति का तीन गुना हो जाते हैं, और तब Discord तीनों को धीमा कर देता है।

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

इससे जुड़ा एक जाल: बार-बार चलने वाले जॉब तय अंतराल पर चलते हैं, जैसे हर पाँच मिनट। अगर सभी शार्ड एक ही समय पर शुरू होते हैं, तो वे हमेशा के लिए अपने जॉब ठीक एक ही पल में चलाते हैं। तब से हर प्रोसेस को शुरू होते समय एक रैंडम ऑफ़सेट मिलता है।

4. लोग असल में जो कॉन्फ़िगर करते हैं, वह वैसा नहीं होता जैसा आप सोचते हैं

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

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

यही एक ऐसे फ़ैसले के पीछे की वजह भी है जो पहली नज़र में उल्टा लगता है: v1.8.0 से बॉट का भेजा लगभग हर संदेश आज़ादी से डिज़ाइन किया जा सकता है। लेकिन ज़रूरी ब्लॉक, जैसे चेतावनी वाले DM में कारण या टिकट पैनल में कैटेगरी मेन्यू, खिसकाए जा सकते हैं, हटाए नहीं जा सकते। डिज़ाइन की आज़ादी, हाँ, लेकिन इस हद तक नहीं कि कोई सर्वर गलती से ऐसी चीज़ बना दे जो काम करती दिखे और करे नहीं।

साझा धागा

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

इसलिए नए कोड के बारे में अब हम सबसे पहले यह नहीं पूछते कि "क्या यह काम करता है", बल्कि यह पूछते हैं कि "जब यह काम नहीं करता तब कैसा दिखता है, और क्या हमें पता चलेगा"।