Zapier या Make ऑटोमेशन को नए जियोकोडिंग होस्ट पर माइग्रेट करना
जियोकोडिंग चरण पर बने नो-कोड ऑटोमेशन के लिए कस्टम कोड से अलग माइग्रेशन तरीका चाहिए। यह बदलाव कैसे संभालें, यहाँ बताया गया है।
अपना API होस्ट बदलने के लिए ज़ीरो-डाउनटाइम चेकलिस्ट
production में API होस्ट को बिना आउटेज के बदलना संभव है, लेकिन इसके लिए बदलाव को सीधे production में भेजे गए एक लाइन के कॉन्फ़िगरेशन बदलाव की तरह नहीं, बल्कि अपने जोखिम वाले एक डिप्लॉयमेंट की तरह लेना पड़ता है। सहज कटओवर और किसी घटना के बीच का फ़र्क लगभग हमेशा तैयारी में होता है, असल स्विच के पल में नहीं।
कटओवर से पहले:
- नए होस्ट के क्रेडेंशियल काफ़ी पहले से तैयार करें, और पुष्टि करें कि वे staging या टेस्ट वातावरण में असली अनुरोध पैटर्न के साथ काम करते हैं, सिर्फ़ एक मैन्युअल टेस्ट कॉल के साथ नहीं
- अपने एप्लिकेशन में यह लॉग करने की व्यवस्था करें कि हर अनुरोध को किस होस्ट ने संभाला, भले ही अस्थायी रूप से, ताकि आप रोलआउट की प्रगति की पुष्टि कर सकें और बाद में किसी भी समस्या का होस्ट के अनुसार निदान कर सकें
- पुष्टि करें कि आपका कॉन्फ़िगरेशन सिस्टम पूरे एप्लिकेशन को दोबारा डिप्लॉय किए बिना होस्ट का मान बदलने की सुविधा देता है, चाहे वह एनवायरनमेंट वेरिएबल हो, फ़ीचर फ़्लैग हो या रिमोट कॉन्फ़िगरेशन सेवा, क्योंकि हर बदलाव पर दोबारा डिप्लॉय वाली प्रक्रिया कटओवर के बीच कुछ गलत होने पर प्रतिक्रिया देने में धीमी होती है
कटओवर के दौरान:
- अगर आपका इन्फ्रास्ट्रक्चर इसकी सुविधा देता है, तो बदलाव को एक साथ के बजाय धीरे-धीरे लागू करें: ट्रैफ़िक का एक प्रतिशत, एक बार में एक सर्वर या क्षेत्र, या बाकियों से पहले एक गैर-ज़रूरी एंडपॉइंट
- रोलआउट के दौरान एरर दर और रिस्पॉन्स समय पर रियल टाइम में नज़र रखें, और उनकी तुलना किसी मान ली गई स्वीकार्य सीमा के बजाय सीधे कटओवर से पहले के अपने बेसलाइन से करें
- इस दौरान पिछले होस्ट के क्रेडेंशियल सक्रिय और तैयार रखें, ताकि वापस लौटना नया डिप्लॉयमेंट नहीं, बल्कि कॉन्फ़िगरेशन का बदलाव हो
कटओवर के बाद:
- माइग्रेशन को पूरा मानने से पहले नए होस्ट को एक तय निगरानी अवधि तक पूरे ट्रैफ़िक पर चलने दें, क्योंकि कुछ समस्याएँ केवल लगातार लोड में या दिन के खास समय पर ही दिखती हैं
- अगर आपने दोनों को लॉग किया है, तो एक जैसे अनुरोधों के एक नमूने के लिए पुराने और नए होस्ट के असली रिस्पॉन्स डेटा की तुलना करें, ताकि डेटा के ऐसे बारीक अंतर पकड़ में आएँ जो सिर्फ़ एरर दर से सामने नहीं आते
- पुराने होस्ट के क्रेडेंशियल तभी हटाएँ जब निगरानी अवधि बिना समस्या के बीत जाए, और "कभी न कभी" नहीं, बल्कि एक तय की गई खास तारीख पर
चूँकि My Geocode के कम्पैटिबिलिटी होस्ट किसी प्रोवाइडर के अनुरोध और रिस्पॉन्स की सटीक संरचना दोहराते हैं, कम्पैटिबिलिटी आधारित माइग्रेशन में कोड के स्तर पर असल बदलाव अक्सर होस्ट नाम और ऑथेंटिकेशन क्रेडेंशियल तक सीमित रहता है, जिससे कटओवर के सबसे जोखिम भरे हिस्से में आने वाला नया कोड कम हो जाता है। ऑथेंटिकेशन खुद चार तरीकों को सपोर्ट करता है, X-API-Key हेडर, Authorization: Bearer, HTTP Basic ऑथ, या क्वेरी पैरामीटर, इसलिए बदलाव का यह हिस्सा अक्सर कोड बदलाव के बजाय केवल कॉन्फ़िगरेशन अपडेट हो सकता है, यह इस पर निर्भर करता है कि आपकी मौजूदा क्लाइंट लाइब्रेरी की संरचना कैसी है।
ज़ीरो-डाउनटाइम माइग्रेशन चतुर इन्फ्रास्ट्रक्चर से कम और अनुशासन से ज़्यादा जुड़ा है: पूरी तैयारी करें, धीरे-धीरे लागू करें, ध्यान से नज़र रखें, और वापस लौटने का रास्ता तब तक रखें जब तक आपको इतना भरोसा न हो जाए कि उसकी ज़रूरत नहीं है।