प्रॉम्प्ट और दायरा
एक कंपनी 12 महीनों में अपने v1 API को रिटायर करने और v2 लॉन्च करने जा रही है। v1 के 3,000 ग्राहक हैं, लगभग 40% अनुरोध (requests) अभी भी लेगेसी फ़ील्ड्स का उपयोग करते हैं, और 200 ग्राहक उच्च-राजस्व वाले एंटरप्राइज हैं। नई क्षमताओं, संगतता, डेवलपर अनुभव, राजस्व जोखिम और रिटायरमेंट के बीच संतुलन बनाते हुए माइग्रेशन की योजना बनाएं।
यह इस बात का परीक्षण करता है कि क्या एक product manager तकनीकी माइग्रेशन को एक सीमाबद्ध ग्राहक उत्पाद में बदल सकता है: यह पहचानना कि कौन प्रभावित है, यह कदम क्यों मायने रखता है, और कौन से व्यवहार बिल्कुल नहीं टूटने चाहिए; फिर संगतता, टूलींग, संचार, चरणबद्ध रोलआउट और निकास मानदंड डिजाइन करना। GitHub का API version मार्गदर्शन ब्रेकिंग परिवर्तनों, Deprecation/Sunset हेडर, सपोर्ट विंडो और माइग्रेशन परीक्षण को वर्जन गवर्नेंस सीमाओं के रूप में मानता है।
इंटरव्यूअर क्या जांच रहा है
पहला, क्या आप केवल एक तारीख की घोषणा करने के बजाय ग्राहकों को विभाजित (segment) कर सकते हैं और जोखिम को रैंक कर सकते हैं? उच्च-राजस्व, विनियमित (regulated), कम-गतिविधि वाले और सेल्फ-सर्विस ग्राहकों का माइग्रेशन प्रतिरोध अलग-अलग होता है।
दूसरा, क्या आप संगतता, माइग्रेशन और रिटायरमेंट में अंतर कर सकते हैं? पुराने वर्जन को बनाए रखना, अडैप्टर जोड़ना, या बैच रूपांतरण प्रदान करना जोखिम को कम करता है लेकिन ग्राहक पुष्टि या निकास मानक की जगह नहीं लेता है।
तीसरा, क्या आप अवलोकनीय संकेतों (observable signals) के आधार पर निर्णय ले सकते हैं? अनुरोधों की मात्रा कम होना माइग्रेशन को साबित नहीं करता; सक्रिय ऍप्लिकेशन्स, एरर, फ़ील्ड उपयोग, पूर्ण माइग्रेशन और सपोर्ट के बोझ को भी ट्रैक करें।
उत्तर देने से पहले स्पष्ट करने योग्य प्रश्न
- v2 का मुख्य मूल्य क्या है? सुरक्षा, प्रदर्शन, अनुपालन, लागत, या एक नया संसाधन मॉडल?
- v1 के कौन से व्यवहार टूटते हैं? हटाए गए फ़ील्ड, प्रकार (type) परिवर्तन, प्रमाणीकरण परिवर्तन और एरर सिमेंटिक्स की सूची बनाएं।
- क्या ग्राहक देख सकते हैं कि वे क्या उपयोग करते हैं? क्या टोकन, एप्लिकेशन या संगठन द्वारा उपयोग उपलब्ध है?
- क्या 12 महीने एक सख्त समय सीमा है या एक लक्ष्य? कौन से साक्ष्य विस्तार (extension) या चरणबद्ध समापन को ट्रिगर कर सकते हैं?
- क्या दोनों वर्जन या कोई अडैप्टर एक साथ चल सकते हैं? लागत, विलंबता (latency) और निरंतरता (consistency) की सीमाएं क्या हैं?
- रिटायरमेंट के बाद सपोर्ट का क्या वादा है? 410 प्रतिक्रियाएं, दस्तावेज़, अपील और सुरक्षा अपवाद कैसे काम करते हैं?
30-सेकंड उत्तर ढांचा
"मैं v1 उपयोग की बेसलाइन और ग्राहक सेगमेंट स्थापित करूंगा, फिर हर ब्रेकिंग बदलाव और v2 के लाभ को सूचीबद्ध करूंगा। मैं उच्च-मूल्य वाले ग्राहकों और आंतरिक इंटीग्रेशन से शुरुआत करते हुए संगतता मार्गदर्शन, एक अंतर (diff) सूची, सत्यापन उपकरण और एप्लिकेशन-स्तरीय उपयोग डैशबोर्ड प्रकाशित करूंगा। माइग्रेशन के दौरान मैं डॉक्स, कंसोल नोटिस, ईमेल और प्रत्यक्ष संपर्क के साथ-साथ Deprecation/Sunset हेडर और चरणबद्ध एरर ड्रिल का उपयोग करूंगा। प्रत्येक चरण को एडॉप्शन, एरर, सक्रिय-एप्लिकेशन माइग्रेशन और सपोर्ट टिकटों के लिए थ्रेसहोल्ड दिए जाएंगे; v1 को निकास मानदंड पूरे होने के बाद ही रिटायर करें, जिसमें सुरक्षा अपवाद और एक छोटी रोलबैक विंडो शामिल हो।"
चरण-दर-चरण गहन विश्लेषण
चरण 1: लक्ष्य और ऐसे व्यवहार परिभाषित करें जो टूटने नहीं चाहिए
लक्ष्यों को ग्राहक मूल्य और प्लेटफ़ॉर्म सीमाओं में विभाजित करें। उदाहरण के लिए, v2 अधिक सूक्ष्म अनुमतियां प्रदान कर सकता है जबकि v1 के मुख्य रीड और राइट सिमेंटिक्स संक्रमण के दौरान स्थिर रहते हैं। हटाए गए या बदले गए फ़ील्ड, नए आवश्यक पैरामीटर, प्रकार और enum परिवर्तन, और प्रमाणीकरण आवश्यकताओं की सूची बनाएं। केवल एक 200 प्रतिक्रिया संगतता साबित नहीं करती है।
चरण 2: उपयोग बेसलाइन और जोखिम स्तर स्थापित करें
संगठन, एप्लिकेशन, टोकन, वर्जन, एंडपॉइंट, फ़ील्ड, अनुरोध मात्रा, राजस्व, अनुपालन और तकनीकी स्वामी द्वारा सेगमेंट करें। प्रत्येक एप्लिकेशन की 90-दिन की गतिविधि, प्रभावित-फ़ील्ड शेयर, माइग्रेशन जटिलता और ग्राहक मूल्य की गणना करें। उच्च-राजस्व वाले कम-मात्रा वाले ग्राहक को अभी भी स्पष्ट पुष्टि की आवश्यकता होती है; बिना स्वामी वाला एप्लिकेशन जोखिम कतार में जल्दी प्रवेश करता है।
चरण 3: माइग्रेशन पथ और संगतता सीमाएं डिज़ाइन करें
योगात्मक (additive) माइग्रेशन को प्राथमिकता दें: वैकल्पिक फ़ील्ड, समानांतर प्रतिक्रियाएं, या एक v1-से-v2 अडैप्टर। असंगत फ़ील्ड के लिए, समकक्ष मैपिंग, उदाहरण अनुरोध और सिमेंटिक अंतर प्रदान करें। अडैप्टर को एक समय सीमा, लागत और अवलोकनीयता दें; इसे ग्राहक के अपूर्ण माइग्रेशन को स्थायी रूप से छिपाना नहीं चाहिए।
चरण 4: टूल्स और डॉक्स को एक उत्पाद बनाएं
एक अंतर (diff) सूची, एप्लिकेशन उपयोग रिपोर्ट, स्टेटिक जांच या SDK माइग्रेशन संकेत, सैंडबॉक्स सत्यापन, नमूना कोड और रोलबैक निर्देश प्रदान करें। प्रत्येक ब्रेकिंग बदलाव को प्रतिस्थापन सिंटैक्स और परीक्षण चरण से लिंक करें। टूल का आउटपुट दोहराने योग्य होना चाहिए ताकि ग्राहकों को लंबी घोषणा से अनुमान न लगाना पड़े।
inventory -> classify risk -> test v2 -> dual-run -> migrate -> verify -> retire v1चरण 5: रोलआउट और संचार को चरणबद्ध करें
आंतरिक और डिज़ाइन भागीदारों से शुरुआत करें, फिर सेल्फ-सर्विस माइग्रेशन, फिर उच्च-मूल्य या जटिल ग्राहक। हर चरण में चेंजलॉग, डेवलपर डॉक्स, कंसोल बैनर, ईमेल और अकाउंट-मैनेजर आउटरीच का उपयोग करें। तिथि, प्रभाव, कार्रवाई, सपोर्ट प्रवेश बिंदु और अपवाद शर्तों को एक माइग्रेशन अनुबंध में रखें ताकि चैनल परस्पर विरोधी वादे न करें।
चरण 6: संकेतों पर शर्तें तय करें, केवल एक एडॉप्शन दर पर नहीं
साप्ताहिक रूप से v1 अनुरोधों, सक्रिय v1 ऍप्लिकेशन्स, प्रभावित-फ़ील्ड कॉल्स, v2 सफलता दर, माइग्रेशन के बाद रोलबैक दर, डेप्रिकेशन-हेडर कवरेज, सपोर्ट टिकट और उच्च-मूल्य वाले ग्राहकों की पुष्टि की समीक्षा करें। माइग्रेशन तभी पूरा होता है जब एप्लिकेशन स्विच हो जाता है, महत्वपूर्ण परिदृश्य पास हो जाते हैं, एरर सामान्य होते हैं और स्वामी ने इसकी पुष्टि की हो।
चरण 7: रिटायरमेंट, विस्तार और अपवाद नियम परिभाषित करें
रिटायरमेंट से पहले, परीक्षण परिवेश में 410 या समकक्ष एरर का अनुकरण करें और सत्यापित करें कि ग्राहक एक कार्रवाई योग्य मार्गदर्शिका देखते हैं। विस्तार के लिए साक्ष्य की आवश्यकता होती है जैसे कि अधूरा सुरक्षा फिक्स, एक महत्वपूर्ण विनियमित ग्राहक जो अभी भी माइग्रेट कर रहा है, या एक पुष्ट v2 रिग्रेशन। सुरक्षा जोखिम समय से पहले बंद करने को उचित ठहरा सकता है, लेकिन प्रभाव, विकल्पों और सपोर्ट का दस्तावेजीकरण करें। प्रत्येक अपवाद की एक समाप्ति तिथि होती है।
चरण 8: माइग्रेशन की समीक्षा करें और वर्जन गवर्नेंस को संस्थागत बनाएं
रिटायरमेंट के बाद, एरर पीक, रिटेंशन, सपोर्ट लागत, इंफ्रास्ट्रक्चर की बचत और अप्रत्याशित उपयोग का निरीक्षण करें। v1/v2 के अंतर, संचार, निर्णय लॉग और घटना समयसीमा को सुरक्षित रखें। अगले रिलीज़ टेम्पलेट में सपोर्ट विंडो, ब्रेकिंग-चेंज समीक्षा, डेप्रिकेशन हेडर, माइग्रेशन परीक्षण और ग्राहक नोटिस जोड़ें।
ट्रेड-ऑफ और सीमाएं
ट्रेड-ऑफ 1: अडैप्टर या तेज़ स्विच
एक अडैप्टर अल्पकालिक जोखिम को कम करता है लेकिन रखरखाव, विलंबता और सिमेंटिक अस्पष्टता को बढ़ाता है। इसे केवल तभी रखें जब माइग्रेशन मूल्य स्पष्ट हो, सीमा अवलोकनीय हो, और निकास तिथि मौजूद हो; अन्यथा v1 को अनिश्चित काल तक बढ़ाने के बजाय एक स्पष्ट v2 विंडो प्रदान करें।
ट्रेड-ऑफ 2: एक समय सीमा या ग्राहक तरंगें (waves)
एक तारीख को संचालित करना आसान है; तरंगें जोखिम को नियंत्रित करती हैं और जटिल ग्राहकों को समय देती हैं। जोखिम-आधारित मील के पत्थर और चेकपॉइंट सेट करते हुए एक सार्वजनिक अंतिम तिथि रखें ताकि उच्च-राजस्व वाले ग्राहक अंतिम सप्ताह में समस्याओं को सामने न लाएं।
ट्रेड-ऑफ 3: कम अनुरोध या वास्तविक एप्लिकेशन माइग्रेशन
व्यावसायिक गिरावट, कैशिंग या निष्क्रियता के कारण अनुरोध गिर सकते हैं। केवल कुल ट्रैफ़िक के बजाय सक्रिय ऍप्लिकेशन्स, सफल महत्वपूर्ण एंडपॉइंट्स, पूर्ण फ़ील्ड प्रतिस्थापन और स्वामी की पुष्टि के साथ माइग्रेशन का आकलन करें।
विफलता अभ्यास (Failure Drills) और विकास योजना
ड्रिल 1: एक छूटा हुआ ब्रेकिंग फ़ील्ड
v2 के विरुद्ध नमूना वास्तविक अनुरोधों को फिर से चलाएं और स्टेटस कोड, एरर ऑब्जेक्ट, पेजिनेशन, समय क्षेत्र और धन सिमेंटिक्स की तुलना करें। गंभीरता के आधार पर अंतरों को वर्गीकृत करें; किसी भी अस्पष्टीकृत महत्वपूर्ण फ़ील्ड के लिए व्यापक ट्रैफ़िक को ब्लॉक करें।
ड्रिल 2: एक उच्च-मूल्य वाला ग्राहक अभी भी v1 पर है
90 दिन पहले ग्राहक सूची तैयार करें और सत्यापित करें कि खाता प्रबंधन, सहायता और उत्पाद में स्वामी मौजूद हैं। अंतिम दिन बंद करने के बजाय एक तकनीकी निदान और समय-सीमित अपवाद की पेशकश करें।
ड्रिल 3: रिटायरमेंट के बाद एरर स्पाइक
एक छोटे कोहॉर्ट या सैंडबॉक्स में माइग्रेशन लिंक के साथ 410 लौटाएं। सत्यापित करें कि SDK, निगरानी और डॉक्स समाधान का मार्गदर्शन करते हैं। स्पष्ट ट्रिगर्स के साथ एक छोटी पुनर्स्थापना (restore) विंडो सेट करें और प्रत्येक सक्रियण को रिकॉर्ड करें।
सामान्य गलतियाँ और फॉलो-अप
गलती 1: एक ही डेप्रिकेशन ईमेल भेजना
अधिसूचना उपयोग सूची, कोड उदाहरण, परीक्षण परिवेश या सपोर्ट प्रवेश बिंदु की जगह नहीं लेती है। माइग्रेशन ग्राहक वर्कफ़्लो में निष्पादन योग्य होना चाहिए।
गलती 2: वर्जन नंबर को ही पूरी संगतता मानना
एक ही वर्जन के भीतर फ़ील्ड, एरर और प्रमाणीकरण बदल सकते हैं। एक मदवार अंतर सूची (diff) और अनुबंध परीक्षण बनाए रखें।
गलती 3: पुराने वर्जन को हमेशा के लिए रखना
निकास तिथि के बिना एक अडैप्टर डॉक्स को विभाजित करता है, इंफ्रास्ट्रक्चर पर बोझ डालता है और सुरक्षा सतह का विस्तार करता है। प्रत्येक अपवाद को एक स्वामी और समय सीमा दें।
गलती 4: ग्राहकों को केवल कुल अनुरोधों के आधार पर रैंक करना
कम मात्रा वाले एप्लिकेशन महत्वपूर्ण लेखांकन या अनुपालन प्रवाह चला सकते हैं। मूल्य, प्रभाव और तकनीकी जटिलता के आधार पर सेगमेंट करें।
गलती 5: बिना वर्जन वाली कॉल्स को अनदेखा करना
डिफ़ॉल्ट वर्जन पर निर्भर ग्राहकों को रिटायरमेंट के बाद व्यवहार में बदलाव दिख सकता है। बिना वर्जन हेडर वाले अनुरोधों की पहचान करें और संक्रमण के दौरान चेतावनी दें।
गलती 6: रोलबैक या विस्तार का परीक्षण न करना
केवल-सफलता का पूर्वाभ्यास यह साबित नहीं करता कि जोखिम नियंत्रित है। एरर मार्गदर्शन, अपवाद अनुमोदन, पुनर्स्थापना विंडो और विस्तार मानदंडों का पहले से परीक्षण करें।