प्रॉम्प्ट और संदर्भ
यह प्लेटफ़ॉर्म सिस्टम-डिज़ाइन प्रश्न रिपॉजिटरी, डिप्लॉयमेंट सिस्टम और मानवीय घोषणाओं से कंपोनेंट्स, सिस्टम्स, डोमेन्स, APIs, ओनर्स और डिपेंडेंसी किनारों (edges) को स्टोर करता है। यह डिस्कवरी, इंसिडेंट रिस्पॉन्स और गवर्नेंस का काम करता है; इसे एक ऐसा हाथ से मेंटेन किया जाने वाला CMDB नहीं बनना चाहिए जिस पर कोई भरोसा न करे।
इंटरव्यूअर क्या मूल्यांकन करता है
- "सर्विस ओनर खोजें" को एक एंटिटी मॉडल, सोर्स ट्रस्ट पॉलिसी और खोजने योग्य अनुभव में बदलना।
- डिक्लेरेटिव मेटाडेटा और ऑटोमेटेड स्कैन के बीच कॉन्फ्लिक्ट्स, समाप्ति (expiry) और डिलीशन को संभालना।
- डिपेंडेंसी क्वेरीज़, परमिशन आइसोलेशन, टेनेंट सीमाओं और फ्रेशनेस SLOs की व्याख्या करना।
- एक चरणबद्ध प्लेटफ़ॉर्म रोलआउट चुनना जो मेंटेनेंस लागत के मुकाबले वैल्यू को संतुलित करता है।
पूछने के लिए स्पष्टीकरण प्रश्न
एंटिटी की संख्या, दैनिक परिवर्तन की मात्रा, मेटाडेटा विलंब, क्वेरी पीक्स, संगठन या ग्राहक आइसोलेशन, क्या डिपेंडेंसीज़ स्थिर हैं या रनटाइम-अवलोकित हैं, और ओनरशिप कौन घोषित कर सकता है, इसकी पुष्टि करें। उच्च-जोखिम वाले इंसिडेंट उपयोग के लिए सोर्स स्तर, पुराने (stale) मार्कर और ऑडिट की आवश्यकता होती है; एक डेवलपर डायरेक्टरी कम सख्त फ्रेशनेस के साथ शुरू हो सकती है।
30-सेकंड उत्तर ढांचा
मैं एक डिक्लेरेटिव एंटिटी ग्राफ़ को मॉडल करूँगा: कंपोनेंट्स, सिस्टम्स, डोमेन्स, APIs, टीमों और संबंधों की स्थिर पहचान होती है। रिपॉजिटरी कैटलॉग फ़ाइलें मंशा (intent) प्रदान करती हैं; डिप्लॉयमेंट और रनटाइम सिग्नल वर्जन्स और देखे गए किनारों (edges) को जोड़ते हैं; कलेक्टर्स वर्जन्ड इवेंट्स लिखते हैं। एक क्वेरी सर्विस सोर्स और अपडेट समय दिखाते हुए ओनर्स, रिवर्स डिपेंडेंसीज़ और खोज प्रदान करती है। कॉन्फ्लिक्ट्स चुपचाप ओवरराइट होने के बजाय कार्रवाई योग्य स्थिति (actionable status) बन जाते हैं। अनुमतियाँ एंटिटीज़ और फ़ील्ड्स पर लागू होती हैं, और बासी एंटिटीज़ ऐतिहासिक बनी रहती हैं लेकिन डिफ़ॉल्ट परिणामों से गायब हो जाती हैं।
चरण-दर-चरण विस्तृत उत्तर
1. एंटिटीज़ और संबंधों को मॉडल करें
Backstage का एंटिटी मॉडल एक उपयोगी संदर्भ है: कंपोनेंट्स सिस्टम्स से संबंधित होते हैं, सिस्टम्स डोमेन्स से, APIs कंपोनेंट्स द्वारा प्रदान या उपयोग किए जाते हैं, और टीमें कंपोनेंट्स की ओनर होती हैं। प्रत्येक एंटिटी को एक स्थिर नाम, नेमस्पेस और वर्जन की दें। संबंध किनारों (relation edges) में सोर्स, डिस्कवरी समय और विश्वास (confidence) शामिल होता है। ओनरशिप को एक हल करने योग्य (resolvable) टीम प्रिंसिपल को संदर्भित करना चाहिए, न कि फ्री टेक्स्ट को, ताकि इंसिडेंट रूटिंग को स्वचालित किया जा सके।
2. क्षमता और SLOs सेट करें
प्रत्येक 20 संबंधों वाली 10,000 एंटिटीज़ मान लें, लगभग 200,000 किनारे (edges), और 5% दैनिक एंटिटी परिवर्तन, लगभग 500 इम्पोर्ट्स। एक इवेंट कतार के माध्यम से लिखें और ओनर और एडजैसेंसी इंडेक्स के साथ एक रीड मॉडल बनाए रखें। एक शुरुआती लक्ष्य मिनटों के भीतर इम्पोर्ट दृश्यता, 300 मिलीसेकंड से नीचे सर्च P95, और एक सेकंड के भीतर तीन-हॉप डिपेंडेंसी क्वेरीज़ हो सकता है; उच्च-जोखिम वाले दृश्य डेटा की आयु भी दिखाते हैं।
3. इनजेशन और सोर्स वरीयता डिज़ाइन करें
रिपॉजिटरी घोषणाएं मंशा और ओनरशिप प्रदान करती हैं, डिप्लॉयमेंट सिस्टम वास्तविक वर्जन्स और परिवेश प्रदान करते हैं, और रनटाइम टेलीमेट्री हाल के कॉल किनारों की आपूर्ति करती है। प्रत्येक इम्पोर्ट सोर्स, कमिट वर्जन और वैलिडेशन परिणाम संग्रहीत करता है और एक आइडमपोटेंसी (idempotency) की का उपयोग करता है। फ़ील्ड पॉलिसी द्वारा कॉन्फ्लिक्ट्स को मर्ज करें: एक रनटाइम अवलोकन घोषित ओनरशिप को फिर से नहीं लिख सकता है, और एक रनटाइम किनारा यह साबित नहीं कर सकता है कि कोई डिपेंडेंसी मौजूद नहीं है। कॉन्फ्लिक्ट्स को एक कतार में रखें और ओनर्स को सूचित करें।
4. फ्रेशनेस और डिलीशन सिमेंटिक्स परिभाषित करें
प्रति एंटिटी lastSeenAt, डिक्लेरेशन वर्जन और समाप्ति नीति स्टोर करें। किसी एंटिटी के सोर्स द्वारा अपडेट करना बंद करने के बाद उसे बासी (stale) चिह्नित करें; इंसिडेंट रीप्ले के लिए इतिहास को संरक्षित करते हुए इसे डिफ़ॉल्ट खोज में छिपाएं या डिमोट करें। रिपॉजिटरी डिलीशन, सर्विस रिटायरमेंट और अल्पकालिक परिवेशों के लिए अलग-अलग स्थितियों की आवश्यकता होती है। तत्काल डिलीशन इतिहास को नष्ट कर देता है; कभी डिलीट न करना खोज को प्रदूषित करता है। एक आवधिक समाधानकर्ता (reconciler) विफल इम्पोर्ट्स का पुन: प्रयास करता है और अनाथ किनारों को हटाता है।
5. क्वेरी, परमिशन और सुरक्षा पथ बनाएं
नाम, टीम, डोमेन, परिवेश, टैग और ओनर द्वारा खोज का समर्थन करें। डिपेंडेंसी गहराई और परिणाम गणना को सीमित करें ताकि ग्राफ़ ट्रैवर्सल सर्विस को ओवरलोड न कर सके। एंटिटीज़ और फ़ील्ड्स से संगठनात्मक दायरा (scope) संलग्न करें; संवेदनशील रिपॉजिटरी पथों, आंतरिक एंडपॉइंट्स और ग्राहक-टेनेंट विवरणों को फ़ील्ड द्वारा संपादित (redact) करें। ओनरशिप परिवर्तनों और अस्वीकृत पहुंच का ऑडिट करें; ब्राउज़र में डेटा छिपाना प्राधिकरण (authorization) नहीं है।
6. क्रमिक रूप से शिप करें और विकल्प बनाए रखें
पहला चरण सोर्स और फ्रेशनेस आवश्यकताओं के साथ महत्वपूर्ण सर्विसेज और ओनर खोज को कवर करता है। दूसरा चरण डिपेंडेंसी ग्राफ़, डिप्लॉयमेंट वर्जन्स और इंसिडेंट रूटिंग जोड़ता है। तीसरा चरण स्वचालित गवर्नेंस का मूल्यांकन करता है। यदि टीमें घोषणाओं को बनाए नहीं रखती हैं, तो कंपनी-व्यापी कैटलॉग के बजाय रिपॉजिटरी टेम्प्लेट और CI चेक से शुरुआत करें। Amazon का PM मार्गदर्शन ग्राहक समस्याओं और योग्यता के साक्ष्यों पर जोर देता है; खोज की सफलता, इंसिडेंट स्थानीयकरण समय और मेटाडेटा रखरखाव दर द्वारा अपनाए जाने को साबित किया जाना चाहिए।
मॉडल उच्च-गुणवत्ता वाला उत्तर
मैं कैटलॉग को एक स्प्रेडशीट के रूप में नहीं, बल्कि सोर्स और फ्रेशनेस के साथ एक एंटिटी ग्राफ़ के रूप में मानूँगा। कंपोनेंट्स, सिस्टम्स, डोमेन्स, APIs, टीमों और संबंधों में स्थिर कीज़ होती हैं; रिपॉजिटरी घोषणाएं मंशा को परिभाषित करती हैं, डिप्लॉयमेंट परिवेश वर्जन्स जोड़ता है, और रनटाइम सिग्नल हालिया डिपेंडेंसीज़ जोड़ते हैं। कलेक्टर्स इवेंट-संचालित और आइडमपोटेंट होते हैं और कमिट वर्जन्स को बनाए रखते हैं। एक रीड मॉडल ओनर्स, रिवर्स डिपेंडेंसीज़ और सीमित ग्राफ़ क्वेरीज़ को सर्व करता है। कॉन्फ्लिक्ट्स एक कतार बन जाते हैं, बासी एंटिटीज़ ऐतिहासिक बनी रहती हैं लेकिन डिफ़ॉल्ट खोज से गायब हो जाती हैं, और अनुमतियाँ संगठन और फ़ील्ड द्वारा लागू होती हैं। मैं विस्तार करने से पहले महत्वपूर्ण सर्विसेज पर खोज सफलता, इंसिडेंट स्थानीयकरण समय और रखरखाव दर को साबित करूँगा।
सामान्य गलतियाँ
- हाथ से मेंटेन किया जाने वाला CMDB बनाना → यह जल्दी बासी हो जाता है → रिपॉजिटरी घोषणाओं और स्वचालित संग्रह को तथ्यों के रूप में उपयोग करें।
- ओनर स्ट्रिंग्स को स्टोर करना → सूचनाओं और ऑफबोर्डिंग को मान्य नहीं किया जा सकता है → हल करने योग्य टीम प्रिंसिपल्स को संदर्भित करें।
- नवीनतम सोर्स को सब कुछ ओवरराइट करने देना → रनटाइम का शोर गवर्नेंस के तथ्यों को दोबारा लिख देता है → सोर्स को रैंक करें और कॉन्फ्लिक्ट्स को सुरक्षित रखें।
- रिटायर्ड सर्विसेज को डिलीट करना → इंसिडेंट रीप्ले डिपेंडेंसीज़ खो देता है → लाइफसाइकिल स्टेट्स और ऐतिहासिक वर्जन्स का उपयोग करें।
- असीमित डिपेंडेंसी ट्रैवर्सल → एक क्वेरी पूरे ग्राफ़ में फैल जाती है → गहराई और परिणामों को सीमित करें और एडजैसेंसी इंडेक्स का उपयोग करें।
फॉलो-अप प्रश्न और उत्तर
क्या होगा यदि घोषित ओनरशिप डिप्लॉयमेंट डेटा के साथ विरोध करती है?
उन्हें अलग-अलग सोर्स विशेषताओं के रूप में प्रस्तुत करें, फ़ील्ड पॉलिसी द्वारा मर्ज करें, और कॉन्फ्लिक्ट दिखाएं। नियंत्रित घोषणाएं ओनर फ़ील्ड की मालिक हैं; डिप्लॉयमेंट सिस्टम परिवेश फ़ील्ड्स का मालिक है। दोनों पक्षों को सूचित करें और एक सुधारात्मक कमिट के माध्यम से समाधान करें।
आप कम समय तक चलने वाले प्रिव्यू परिवेशों को कैसे संभालते हैं?
एंटिटीज़ को एक परिवेश और समाप्ति प्रदान करें। प्रिव्यू प्रविष्टियों को कम डिफ़ॉल्ट वेट मिलता है और वे स्वचालित रूप से संग्रहीत (archived) हो जाती हैं। यदि प्रोडक्शन किसी एक पर निर्भर करता है, तो रनटाइम किनारे एक अलर्ट उठा सकते हैं, लेकिन ओनरशिप और टेनेंट प्राधिकरण अभी भी लागू होते हैं।
यदि किसी इंसिडेंट के दौरान कैटलॉग अनुपलब्ध हो तो क्या होगा?
महत्वपूर्ण सर्विसेज के लिए निर्यात योग्य स्नैपशॉट और हालिया ओनर कैश रखें और उनकी आयु प्रदर्शित करें। इंसिडेंट टूलिंग एक स्नैपशॉट पढ़ सकती है, लेकिन समाप्त हो चुके स्नैपशॉट को लाइव सत्य के रूप में प्रस्तुत नहीं करना चाहिए।
आप टीमों को कैटलॉग को रिलीज़ अप्रूवल गेट के रूप में मानने से कैसे रोकते हैं?
डिस्कवरी और इंसिडेंट रिस्पॉन्स से शुरुआत करें और खोज और स्थानीयकरण समय को मापें। मेटाडेटा और अनुमतियों के स्थिर होने के बाद ही गवर्नेंस चेक कनेक्ट करें; एक विफल चेक को प्रत्येक रिलीज़ को अवरुद्ध करने के बजाय एक मरम्मत पथ प्रदान करना चाहिए।