प्रॉम्प्ट और संदर्भ
आप SDKs, collectors, डैशबोर्ड और अलर्ट द्वारा उपयोग किए जाने वाले एक क्रॉस-लैंग्वेज ऑब्जर्वेबिलिटी अनुबंध (contract) का रखरखाव करते हैं। टीम कन्वेन्शन्स को development से stable में ले जाना चाहती है ताकि डाउनस्ट्रीम उपयोगकर्ता उन पर निर्भर रह सकें; प्लेटफॉर्म टीम को अनसुलझे अर्थ, दोहरी राइटिंग (dual writes) और हाई-कार्डिनैलिटी लागत का डर है। मान लें कि तीन महीने की वास्तविक टेलीमेट्री और दो पायलट सेवाएँ उपलब्ध हैं।
इंटरव्यूअर क्या मूल्यांकन करता है
इंटरव्यूअर यह परीक्षण कर रहा है कि क्या आप "stable" को दस्तावेज़ीकरण की पूर्णता के बजाय एक कम्पैटिबिलिटी वादे के रूप में समझाते हैं। एक मजबूत उत्तर नामों, प्रकारों (types), इकाइयों (units), आवश्यकता स्तरों (requirement levels), enums और गोपनीयता सीमाओं की जाँच करता है; अपनाने, क्वेरी शुद्धता, कार्डिनैलिटी और माइग्रेशन लागत को मापता है; और असंगत परिवर्तनों के लिए एक ट्रांज़िशन पथ सुरक्षित रखता है।
पहले पूछे जाने वाले स्पष्टीकरण
- कौन से डाउनस्ट्रीम अलर्ट, बिलिंग रिपोर्ट या अनुपालन रिपोर्ट पहले से ही इन फ़ील्ड्स पर निर्भर हैं? अधिक निर्भरताओं के लिए एक उच्च स्थिरता मानक की आवश्यकता होती है।
- कौन से सिग्नल्स और भाषाएँ शामिल हैं? सभी SDKs में डिफ़ॉल्ट एक समान होने चाहिए।
- क्या कोई हाई-कार्डिनैलिटी मान, संवेदनशील डेटा या अस्पष्ट enums हैं? स्थिरीकरण (stabilization) से पहले इन्हें हल करें।
- कम्पैटिबिलिटी कितने समय तक रहनी चाहिए? मौजूदा collectors को वर्ज़न चयन या ऑप्ट-इन माइग्रेशन की आवश्यकता हो सकती है।
- सफलता का पैमाना क्या है: अपनाना, पुन: प्रयोज्य क्वेरीज़, या कम कस्टम फ़ील्ड्स? लक्ष्य के अनुसार पायलट मेट्रिक्स बदल जाते हैं।
30-सेकंड उत्तर ढाँचा
"मैं किसी कन्वेन्शन को केवल इसलिए प्रमोट नहीं करूँगा क्योंकि उसमें पर्याप्त फ़ील्ड्स हैं। मैं सेमेंटिक्स, प्रकारों, इकाइयों, आवश्यकता स्तरों, enums, गोपनीयता और क्रॉस-SDK व्यवहार का ऑडिट करूँगा, फिर वास्तविक डाउनस्ट्रीम क्वेरीज़ को मान्य करूँगा। मैं इसे तभी प्रमोट करूँगा जब पायलट सेवाएँ stable वर्ज़न का उपयोग करें, कम्पैटिबिलिटी परीक्षण पास हो जाएँ, कार्डिनैलिटी और लागत सुरक्षा सीमाओं (guardrails) के भीतर रहें, और माइग्रेशन व डेप्रिकेशन पथ स्पष्ट हों। अन्यथा मैं इसे development या alpha में रखूँगा और अगले निर्णय बिंदु को रिकॉर्ड करूँगा।"
चरण-दर-चरण विस्तृत उत्तर
- वादे को परिभाषित करें। OpenTelemetry कन्वेन्शन्स development, alpha, beta, release candidate और stable स्तरों का उपयोग करते हैं। Stable का अर्थ है कि डाउनस्ट्रीम उपयोगकर्ता कम्पैटिबिलिटी की गारंटियों पर भरोसा कर सकते हैं।
- सेमेंटिक्स का ऑडिट करें। संगति के लिए नामों, मान प्रकारों, इकाइयों, आवश्यकता स्तरों, enums और उदाहरणों की जाँच करें। जिन विशेषताओं के उपयोग के मामले उपयोगी लगते हैं लेकिन स्पष्ट नहीं हैं, उन्हें फिर से चर्चा के लिए भेजें।
- वास्तविक उपयोग को मान्य करें। तीन महीने के डेटा का नमूना लें और डैशबोर्ड, अलर्ट, लॉग सहसंबंधों (correlations) और क्रॉस-लैंग्वेज क्वेरीज़ को फिर से चलाकर देखें। अनुपलब्ध (missing) और अज्ञात मानों को रिकॉर्ड करें।
- लागत और गोपनीयता को नियंत्रित करें। नई विशेषताओं से कार्डिनैलिटी, स्टोरेज और क्वेरी लागत को मापें। विशेषताओं में कभी भी उपयोगकर्ता पहचानकर्ता, कच्ची सामग्री (raw content) या सीक्रेट्स न डालें; उपयुक्त होने पर हैशिंग या नियंत्रित श्रेणियों का उपयोग करें।
- वर्जनिंग डिज़ाइन करें। प्रयोगात्मक कन्वेन्शन्स को development नेमस्पेस में रखें। स्थिरीकरण के दौरान, वर्ज़न चयन या ऑप्ट-इन प्रदान करें, डुअल राइट के दौरान पुराने और नए परिणामों की तुलना करें, और एक डेप्रिकेशन तिथि प्रकाशित करें।
- गेट्स और रोलबैक सेट करें। इसे केवल तभी प्रमोट करें जब दो पायलट सेवाएँ दो रिलीज़ चक्रों के लिए कम्पैटिबिलिटी परीक्षणों, 99.9% क्वेरी शुद्धता, 1% से कम अनुपलब्ध दर, और 20% से कम कार्डिनैलिटी वृद्धि को पूरा करती हों। किसी भी उल्लंघन पर वापस ऑप्ट-इन पर आ जाएँ।
विकल्पों में पहले beta जारी करना, केवल एक मुख्य विशेषता सेट को स्थिर करना, प्रत्येक सिग्नल को अलग से वर्ज़न करना, या collector ट्रांसफ़ॉर्मेशन में पुराने फ़ील्ड्स को मैप करना शामिल है। स्थिरीकरण को अनसुलझी सैंपलिंग, ऑथराइजेशन या डेटा-क्वालिटी समस्याओं को छिपाना नहीं चाहिए।
मॉडल उत्तर
"मैं stable को एक कम्पैटिबिलिटी उत्पाद वादे के रूप में मानता हूँ। सबसे पहले मैं कन्वेन्शन पर निर्भर अलर्ट, रिपोर्ट, collectors और SDKs की सूची बनाता हूँ, फिर नामों, प्रकारों, इकाइयों, आवश्यकता स्तरों, enums और गोपनीयता का ऑडिट करता हूँ। मैं तीन महीने की वास्तविक टेलीमेट्री के आधार पर महत्वपूर्ण क्वेरीज़ को फिर से चलाता हूँ और विभिन्न भाषाओं की दो सेवाओं में अनुपलब्ध मानों, अज्ञात मानों, कार्डिनैलिटी और लागत की तुलना करता हूँ। इसे stable चिह्नित करने से पहले मुझे दो रिलीज़ चक्रों के लिए 99.9% क्वेरी शुद्धता, 1% से कम अनुपलब्ध दर, 20% से कम कार्डिनैलिटी वृद्धि, साथ ही एक डेप्रिकेशन तिथि, डुअल-राइट योजना और रोलबैक पथ की आवश्यकता होगी। यदि अर्थ पर अभी भी विवाद है, तो मैं इसे development या beta में रखता हूँ और अगली समीक्षा के लिए आवश्यक साक्ष्य दर्ज करता हूँ।"
सामान्य गलतियाँ
- गलती: अपनाने या फ़ील्ड की संख्या को स्थिरता के प्रमाण के रूप में उपयोग करना → यह क्यों विफल होता है: स्थिरता एक कम्पैटिबिलिटी का वादा है → सुधार: क्रॉस-SDK, क्वेरी और माइग्रेशन परीक्षण जोड़ें।
- गलती: हर व्यावसायिक फ़ील्ड को कन्वेन्शन में डालना → यह क्यों विफल होता है: कार्डिनैलिटी और गोपनीयता जोखिम तेजी से बढ़ते हैं → सुधार: केवल स्पष्ट उपयोग के मामलों और सीमित लागत वाली विशेषताओं को ही रखें।
- गलती: पुराने फ़ील्ड्स को तुरंत बदल देना → यह क्यों विफल होता है: डाउनस्ट्रीम क्वेरीज़ का अर्थ चुपचाप बदल सकता है → सुधार: वर्ज़न चयन, डुअल राइट, तुलना और डेप्रिकेशन प्रदान करें।
- गलती: अज्ञात और अनुपलब्ध मानों को अनदेखा करना → यह क्यों विफल होता है: निष्कर्ष अविश्वसनीय होने के बावजूद डैशबोर्ड पूर्ण दिखाई देते हैं → सुधार: डेटा गुणवत्ता को स्थिरीकरण का एक गेट बनाएँ।
फॉलो-अप प्रश्न और उत्तर
क्या कोई stable कन्वेन्शन नाम बदले गए मुख्य फ़ील्ड को रख सकता है?
यदि नाम बदलने से डाउनस्ट्रीम क्वेरी सेमेंटिक्स बदल जाते हैं, तो पुराना फ़ील्ड बनाए रखें, एक वर्ज़न जोड़ें, एक मैपिंग प्रकाशित करें और एक डेप्रिकेशन विंडो निर्धारित करें। कम्पैटिबिलिटी उपनाम (alias) पर केवल तभी विचार करें जब सेमेंटिक समानता और माइग्रेशन लागत प्रदर्शित की गई हो।
आप विभिन्न SDK डिफ़ॉल्ट्स को कैसे संभालते हैं?
समान इनपुट के साथ क्रॉस-लैंग्वेज अनुबंध परीक्षण बनाएँ और फ़ील्ड नामों, प्रकारों, इकाइयों और आवश्यकता स्तरों को सत्यापित करें। जब तक डिफ़ॉल्ट्स में असहमति हो, तब तक stable दायरे का विस्तार न करें।
क्या होगा यदि कार्डिनैलिटी बढ़ती है लेकिन व्यावसायिक क्वेरीज़ अधिक सटीक हो जाती हैं?
सटीकता के लाभों का स्टोरेज, क्वेरी लेटेंसी और लागत सीमाओं के साथ मिलकर मूल्यांकन करें। पहले उच्च-मूल्य वाली सेवाओं को ऑप्ट-इन करें और सैंपलिंग, एग्रीगेशन या डायमेंशनलिटी रिडक्शन जोड़ें।
स्थिरीकरण कब रोका जाना चाहिए?
जब सेमेंटिक विवाद बने रहें, अनुपलब्ध दर या कार्डिनैलिटी सीमाओं को पार कर जाए, गोपनीयता समीक्षा विफल हो जाए, या पायलट क्वेरीज़ को पुन: उत्पन्न न किया जा सके, तो प्रक्रिया को रोकें और development या beta पर लौटें। साक्ष्य की कमी को रिकॉर्ड करें।