कैच ऑल इनबॉक्स स्टेजिंग की समस्या का सबसे सीधा जवाब है: किसी एनवायरनमेंट को जितने पतों की ज़रूरत पड़ सकती है, उन सबके लिए अलग इनबॉक्स बनाने के बजाय आप डोमेन से कह देते हैं कि सब कुछ एक ही जगह पहुंचा दो। कोई भी लोकल पार्ट स्वीकार हो जाता है, पहले से कुछ तैयार करना नहीं पड़ता, और ऐसा फिक्स्चर भी चल जाता है जो मौक़े पर ही कोई पता गढ़ ले। सुविधा सचमुच है, और क़ीमत भी — जो आम तौर पर स्विच दबाने के कुछ हफ़्ते बाद दिखने लगती है।
कैच ऑल इनबॉक्स असल में करता क्या है
हर डोमेन को ऐसा रिकॉर्ड प्रकाशित करना पड़ता है जो बताए कि उसकी मेल कौन सा सर्वर लेता है। यह बात सब मेल पर लागू होती है। कैच ऑल उसमें लेने वाली तरफ़ एक नियम जोड़ देता है: जब ऐसे लोकल पार्ट के लिए संदेश आए जिसका कोई इनबॉक्स नहीं है, तो उसे ठुकराने के बजाय तय किए गए इनबॉक्स में पहुंचा दो।
असली फ़र्क़ वाइल्डकार्ड और डिफ़ॉल्ट के बीच का है। कुछ सिस्टम सब कुछ लेकर बाद में छांटते हैं; कुछ सब कुछ तभी लेते हैं जब कोई ज़्यादा सटीक नियम मेल न खाए। टेस्ट जब नया पता गढ़ता है तब दोनों एक जैसे बर्ताव करते हैं, और जब संदेश ऐसे पते के लिए आता है जिसे आपने जानबूझकर रोका था, तब दोनों का बर्ताव बिल्कुल अलग होता है।
स्टेजिंग टीमें इसकी ओर क्यों भागती हैं?
वजह लगभग हमेशा रगड़ होती है। देखिए कि कैच ऑल क्या-क्या हटा देता है:
- टेस्ट चलाने से पहले कोई तैयारी का क़दम नहीं, इसलिए नए केस के लिए नया इनबॉक्स बनवाना नहीं पड़ता।
- टीमों के बीच कोई तालमेल नहीं, क्योंकि उस डोमेन का कोई भी पता किसी के भी काम आ जाता है।
- बाहरी मेल सेवा पर कोई निर्भरता नहीं, क्योंकि पूरा डोमेन आपके नियंत्रण में है।
- टेस्ट जब किसी बेतरतीब लेबल वाला पता बनाता है, तब कोई मेल खोती नहीं — और टेस्ट ठीक यही करते हैं।
जो टीम अपना पूरा दिन गुम इनबॉक्स से पैदा हुई नाकामियां सुलझाने में बिताती है, उसके लिए कैच ऑल शोर की एक पूरी श्रेणी का इलाज लगता है। पूछने लायक सवाल यह है कि इसके बदले में वह कौन सा शोर मोल लेता है।
सब कुछ एक इनबॉक्स में आने पर क्या बिगड़ता है?
ज़्यादातर मात्रा और संवेदनशीलता, और ये दोनों एक-दूसरे को बढ़ाते हैं।
| ख़तरा | ऐसा क्यों होता है | इसकी क़ीमत |
|---|---|---|
| बेलगाम मात्रा | डोमेन का कोई भी पता स्वीकार हो जाता है | भंडारण भर जाता है और इनबॉक्स पढ़ने लायक नहीं रहता |
| असंबंधित ट्रैफ़िक एक साथ | टेस्ट और सेवाएं एक ही जगह भेजती हैं | नाकामी की वजह पकड़ना मुश्किल हो जाता है |
| असली मेल का ग़लती से पकड़ा जाना | डोमेन दोबारा इस्तेमाल होता है या टाइपो रह जाता है | किसी असली व्यक्ति का संदेश टेस्ट की ट्रे में पड़ा रहता है |
| बिना मालिक वाली रखवाली | साझा इनबॉक्स का कोई मालिक नहीं होता | डेटा रन ख़त्म होने के बाद भी पड़ा रहता है |
तीसरी पंक्ति को गंभीरता से लेना चाहिए। स्टेजिंग में इस्तेमाल हुआ डोमेन आगे कभी न कभी कॉन्फ़िगरेशन में, स्क्रीनशॉट में, सहायता टिकट में या किसी बाउंस में दिखेगा ही। जिस पल उस इनबॉक्स तक कोई असली संदेश पहुंच सकता है, उसी पल कैच ऑल टेस्टिंग की सुविधा नहीं रह जाता और किसी और का पत्र-व्यवहार थामे हुए एक बिना मालिक इनबॉक्स बन जाता है।
एक चौथी नाकामी बाक़ी सब से ख़ामोश है: ग़लत ज़ोन पर सेट किया गया कैच ऑल। अगर वह नियम स्टेजिंग-विशेष सबडोमेन के बजाय किसी साझा डोमेन पर लगा दिया जाए, तो आंतरिक सूचनाएं और प्रशासनिक मेल भी ऐसी ट्रे में पहुंच सकती हैं जिसे कोई नहीं देख रहा — यह गोपनीयता की समस्या भी है और भरोसे की भी, क्योंकि वह संदेश कहीं असली जगह जाना चाहिए था।
प्रोडक्शन की मेल को स्टेजिंग इनबॉक्स से बाहर रखना
जिस नियम को ध्यान में रखकर डिज़ाइन बनाना है वह एक वाक्य का है: स्टेजिंग तक ऐसी मेल कभी न पहुंचे जो किसी प्रोडक्शन उपयोगकर्ता के नाम पर भेजी गई हो। बाक़ी सब कार्यान्वयन है।
उस नियम की व्यवहारिक शक्ल है एक समर्पित डोमेन या समर्पित सबडोमेन जिसका इकलौता मक़सद टेस्ट ट्रैफ़िक हो, साथ में यह समीक्षा कि वह डोमेन कहां-कहां उल्लिखित है। अलर्ट, बिलिंग और सूचना का कॉन्फ़िगरेशन ख़ास तौर पर इस डोमेन के पतों की ओर सिर्फ़ स्टेजिंग एनवायरनमेंट में इशारा करना चाहिए, और एनवायरनमेंट के बीच फ़र्क़ कॉन्फ़िगरेशन से आना चाहिए, न कि किसी ऐसे हाथ के क़दम से जिसे किसी को याद रखना पड़े।
रखे जाने की अवधि और सफ़ाई यहां डिज़ाइन का हिस्सा है, अगली बार की ठीक-ठाक नहीं। जिस इनबॉक्स में जो आता रहे, वह धीरे-धीरे ऐसा ढेर बन जाता है जिसे कोई पढ़ नहीं सकता और कोई मिटाने की हिम्मत नहीं करता। अस्थायी मेल कैसे काम करता है वाला लेख इसी सिद्धांत को संदेश की उम्र के नज़रिए से खोलता है।
रखवाली और सफ़ाई: एक डिज़ाइन का फ़ैसला
पहले से दो बातें तय करें: पकड़ा गया संदेश कितनी देर रुकता है, और उस अवधि के बाद होता क्या है।
छोटी अवधि सबके लिए बेहतर है। जो ट्रे ख़ुद ख़ाली हो जाती है, वह मात्रा सीमित रखती है, संवेदनशील सामग्री को पड़े रहने से रोकती है, और शोर भरे हफ़्ते के बाद इनबॉक्स को फिर पढ़ने लायक बना देती है। वह अवधि जो भी हो, उसे स्टेजिंग एनवायरनमेंट का लिखित गुण होना चाहिए, न कि डिस्क भर जाने का हादसा। अगर आप यह नहीं बता सकते कि कोई संदेश कितनी देर जीवित रहता है, तो आपकी कोई नीति अभी है ही नहीं।
डेवलपर्स के लिए: प्रीफ़िक्स से रूटिंग और स्विच का दायरा
कैच ऑल में सबसे सस्ता सुधार यह है कि उसे एक अनछुआ बाल्टी मानना बंद कर दिया जाए। चूंकि संदेश के साथ पाने वाले का लोकल पार्ट भी दर्ज होता है, आप उसी पर रूटिंग कर सकते हैं: हर टेस्ट या हर सेवा को अपना प्रीफ़िक्स दें, और पढ़ने वाला कोड आने के क्रम पर नहीं, उसी प्रीफ़िक्स पर छान ले।
फिर वाइल्डकार्ड का दायरा सीमित करें। ऐसा नियम चुनें जो ज्ञात आकारों का एक तय समूह स्वीकार करे और बाक़ी सब ठुकरा दे, उस नियम के बजाय जो सब कुछ ले लेता है। अनुमति सूची में हर नए उपभोक्ता के लिए कॉन्फ़िगरेशन की एक पंक्ति लगती है और ग़लती से पकड़े जाने की पूरी श्रेणी हट जाती है, क्योंकि जिस पते को किसी ने रजिस्टर ही नहीं किया, वह सोखा नहीं जाता, ठुकरा दिया जाता है।
आख़िर में, कैच ऑल को एनवायरनमेंट की सेटिंग मानें, मेल सिस्टम का स्थायी गुण नहीं। अगर वही कॉन्फ़िगरेशन हर जगह लगा दिया जाए क्योंकि बदलने से ज़्यादा आसान है, तो स्टेजिंग का इंतज़ाम देर-सबेर वहां भी लागू हो जाएगा जहां उसे नहीं होना चाहिए।
जो भी इस तरीक़े को इस्तेमाल करे, उसे मक़सद नज़र से ओझल नहीं होने देना चाहिए। यहां कैच ऑल टेस्ट ट्रैफ़िक के लिए इंजीनियरिंग की पाइपलाइन है, कोई पहचान नहीं, और इसे कभी किसी असली व्यक्ति का इनबॉक्स नहीं मानना चाहिए।
अगले क़दम
उस कॉन्फ़िगरेशन को खोलें जो आपका स्टेजिंग डोमेन तय करता है, और एक सवाल का जवाब दें: ऐसे पते के लिए आया संदेश कहां जाता है जिसे किसी टेस्ट ने कभी इस्तेमाल नहीं किया? अगर जवाब यह है कि वह साझा इनबॉक्स में पहुंच जाता है, तो नियम संकरा करें। जब पूरे डोमेन के बजाय एक ही फेंकने वाला इनबॉक्स चाहिए, तो टेम्प मेल पेज मांग पर एक बना देता है, और पाइपलाइन के अंदर मेल पकड़ने वाला लेख वह रूप समझाता है जो बिल्ड मशीन से बाहर निकलता ही नहीं।