Zapier या Make ऑटोमेशन को नए जियोकोडिंग होस्ट पर माइग्रेट करना
जियोकोडिंग चरण पर बने नो-कोड ऑटोमेशन के लिए कस्टम कोड से अलग माइग्रेशन तरीका चाहिए। यह बदलाव कैसे संभालें, यहाँ बताया गया है।
माइग्रेशन के बाद पुरानी API कुंजियों को सुरक्षित रूप से हटाना
पुराने प्रदाता की API कुंजी हटाना माइग्रेशन के अंत में एक छोटा, लगभग प्रशासनिक कदम लगता है, लेकिन किसी भी दिशा में समय ग़लत होने की वास्तविक कीमत होती है। बहुत जल्दी हटाएँ, इससे पहले कि हर निर्भर सिस्टम असल में स्थानांतरित हो चुका हो, तो पुरानी कुंजी को अब भी कॉल करने वाली कोई चीज़ अचानक टूट जाती है। बहुत देर से हटाएँ, या कभी न हटाएँ, तो एक अप्रयुक्त लेकिन अब भी वैध क्रेडेंशियल सुरक्षा जोखिम बनकर पड़ा रहता है, जिस पर कोई सक्रिय रूप से नज़र नहीं रख रहा।
सबसे सुरक्षित प्रक्रिया कुंजी हटाने को एक तय क्रम वाला अपने आप में छोटा प्रोजेक्ट मानती है, मुख्य माइग्रेशन काम के अंत में जोड़ी गई बाद की बात नहीं:
- पहले पुष्टि करें कि पुरानी कुंजी पर शून्य ट्रैफ़िक है, केवल यह विश्वास नहीं कि माइग्रेशन पूरा हो गया है। ज़्यादातर प्रदाता किसी कुंजी के उपयोग की कुछ जानकारी देते हैं; यह मानने के बजाय कि माइग्रेशन चेकलिस्ट पर पूरा का निशान लगने का मतलब है कि पुरानी कुंजी व्यवहार में सचमुच शांत हो गई है, इसे सीधे जाँचें।
- पुरानी कुंजी को एक तय निगरानी अवधि तक वैध लेकिन अप्रयुक्त रहने दें, जब आपको लगे कि माइग्रेशन पूरा हो गया है, बजाय इसके कि नए प्रदाता के लाइव होते ही उसे निष्क्रिय कर दें। यह अवधि, जो आपके ट्रैफ़िक पैटर्न और रिलीज़ चक्र के आधार पर आम तौर पर कुछ हफ़्तों की होती है, किसी भूली हुई कॉल साइट, देर से आए मोबाइल ऐप अपडेट, या कभी-कभार चलने वाले बैच जॉब को पकड़ लेती है जो अब भी पुराने क्रेडेंशियल का उपयोग करता है।
- अगर आपका प्रदाता यह अंतर करने देता है, तो पुरानी कुंजी को पहले हटाने के बजाय निष्क्रिय करें। एक निष्क्रिय कुंजी जो अब भी रिकॉर्ड के रूप में मौजूद है, कुछ अप्रत्याशित सामने आने पर पूरी तरह हटाई गई कुंजी की तुलना में थोड़े समय के लिए फिर से सक्रिय करना आसान है, जिससे आपको निगरानी अवधि के दौरान उसे अनिश्चित काल तक बढ़ाए बिना सुरक्षा का एक मार्जिन मिलता है।
- पुरानी कुंजी को एक तय तारीख़ पर हटाएँ या पूरी तरह रद्द करें, और दर्ज करें कि ऐसा हुआ। अनिश्चित काल तक निष्क्रिय पड़ी कुंजी अब भी एक सुरक्षा जोखिम है जिसे खाते के कभी सेंध लगने पर कोई संभवतः फिर से सक्रिय कर सकता है; सचमुच हटाए गए क्रेडेंशियल को आख़िरकार हमेशा के लिए हटा दिया जाना चाहिए, स्थायी अधर में नहीं छोड़ा जाना चाहिए।
- जाँचें कि पुरानी कुंजी कहाँ-कहाँ सहेजी गई थी, जिसमें कॉन्फ़िगरेशन प्रबंधन सिस्टम, सीक्रेट मैनेजर, एनवायरनमेंट वेरिएबल फ़ाइलें और कोई भी दस्तावेज़ या ऑनबोर्डिंग सामग्री शामिल है जिसमें उसका ज़िक्र हो सकता है, क्योंकि हटाई गई कुंजी जो अब भी कहीं "API कुंजी" के रूप में लिखी हो, उस दस्तावेज़ को अगली बार पढ़ने वाले के लिए भ्रम पैदा करती है, कुंजी के काम करना बंद करने के काफ़ी बाद तक।
My Geocode पर माइग्रेशन के लिए, नई कुंजी का दायरा पहले दिन से तय किया जा सकता है और हर रिस्पॉन्स पर मौजूद कोटा हेडर से उस पर नज़र रखी जा सकती है, जैसे X-Quota-Used, X-Key-IPs-Used और दूसरे हेडर जिनका दस्तावेज़ /docs/rate-limits/ पर है। इससे पुरानी कुंजी हटाने की उलटी गिनती शुरू करने से पहले यह पुष्टि करना आसान हो जाता है कि नई कुंजी सचमुच वही ट्रैफ़िक संभाल रही है जिसकी आप उम्मीद करते हैं। क्रेडेंशियल हटाने को इतनी सोच-समझ के साथ करना थोड़ी अतिरिक्त प्रक्रिया है, जिसके बदले परिचालन जोखिम और बचे हुए सुरक्षा जोखिम, दोनों में सार्थक कमी आती है।