प्रॉम्प्ट और संदर्भ
मल्टीपल टीमों के लिए एक इंसिडेंट कमांड प्लेटफ़ॉर्म डिज़ाइन करें। इसे अलर्ट प्राप्त करने, इंसिडेंट बनाने, रिस्पॉन्स रोल सौंपने, आंतरिक और बाहरी कम्युनिकेशन में समन्वय करने और रिकवरी के बाद एक ऑडिट-योग्य टाइमलाइन बनाए रखने में सक्षम होना चाहिए। कंसिस्टेंसी, परमिशन, नोटिफिकेशन स्टॉर्म और रिकवरी ऑब्जेक्टिव्स के बारे में बताएं।
यह सिस्टम डिज़ाइन, SRE, प्लेटफ़ॉर्म और बैकएंड रोल के लिए उपयुक्त है। यह टेस्ट करता है कि दबाव में डिटेक्शन, कमांड, कोलैबोरेशन और रिव्यू किस तरह एक रिकवरेबल सिस्टम बनते हैं। यह प्लेटफ़ॉर्म केवल एक चैट नहीं है: यह जवाबदेह ओनर, स्टेट ट्रांज़िशन, साक्ष्य और डिग्रेडेशन पाथ वाला एक कंट्रोल प्लेन है। सामान्य और पीक अलर्ट रेट, समवर्ती (कंकरेंट) इंसिडेंट, प्रतिभागी, चैनल और रिटेंशन को स्पष्ट करें।
इंटरव्यूअर्स क्या आकलन करते हैं
- इंसिडेंट मैनेजमेंट को मॉनिटरिंग, चैट और टिकट सिस्टम से अलग करना।
- स्टेट, आइडेम्पोटेंसी, सोर्स ऑफ़ ट्रुथ और कंकरेंट-एडिट नियमों को परिभाषित करना।
- इंसिडेंट मैनेजर, टेक लीड, कम्युनिकेशंस लीड और स्क्राइब के कर्तव्यों को अलग करना।
- डुप्लीकेशन हटाने (डीडुप्लीकेशन), कोरिलेशन, नोटिफिकेशन स्टॉर्म और ऑथराइजेशन को संभालना।
- डिग्रेडेशन, रीजनल रिकवरी, ऑडिट इंटीग्रिटी और रिटेंशन प्रदान करना।
- MTTA, MTTR, अलर्ट नॉइज़ और कम्युनिकेशन डिले के साथ डिज़ाइन को वैलिडेट करना।
30-सेकंड का उत्तर
“मैं प्लेटफ़ॉर्म को अलर्ट इनटेक, इंसिडेंट ऑर्केस्ट्रेशन, रियल-टाइम कोलैबोरेशन, नोटिफिकेशन और रिव्यू स्टोरेज में विभाजित करूँगा। इनटेक लेयर सोर्स और टाइम विंडो के आधार पर डीडुप्लीकेट करती है; ऑर्केस्ट्रेशन इंसिडेंट को सोर्स ऑफ़ ट्रुथ मानता है और ऑडिट के लिए स्टेट और रोल परिवर्तनों का वर्ज़न बनाता है। इंसिडेंट मैनेजर कमांड करता है, टेक लीड डायग्नोस करता है, कम्युनिकेशंस लीड स्टेकहोल्डर्स को अपडेट करता है, और स्क्राइब टाइमलाइन बनाए रखता है। रीप्ले करने योग्य स्ट्रीम द्वारा अपडेट पुश किए जाने से पहले इवेंट्स को परसिस्ट किया जाता है। नोटिफिकेशन्स को प्राथमिकता दी जाती है और रेट-लिमिट किया जाता है। रीजनल फेलियर के दौरान, न्यूनतम कंट्रोल प्लेन और मैन्युअल फ़ॉलबैक उपलब्ध रहते हैं; रिकवरी टाइमलाइन से एक रिव्यू जेनरेट करती है।”
स्टेप-बाय-स्टेप समाधान
स्टेप 1: सीमाएं और उद्देश्य परिभाषित करें
सिग्नल मेट्रिक्स, लॉग्स, सिंथेटिक चेक, सपोर्ट एस्केलेशन या किसी इंसान से आ सकते हैं। प्लेटफ़ॉर्म सिग्नल्स को इंसिडेंट्स और रिस्पॉन्स वर्कफ़्लो में व्यवस्थित करता है; यह मॉनिटरिंग कंप्यूटेशन, चैट स्टोरेज या डिप्लॉयमेंट की जगह नहीं लेता है। इंसिडेंट-क्रिएशन लेटेंसी, क्रिटिकल-नोटिफिकेशन डिलीवरी, टाइमलाइन ड्यूरेबिलिटी, रीजनल रिकवरी टाइम और ऑडिट रिटेंशन के लिए उद्देश्य निर्धारित करें।
सामान्य लोड को बड़े आउटेज से अलग करें: प्रति मिनट हज़ारों अलर्ट, सैकड़ों समवर्ती इंसिडेंट, प्रति इंसिडेंट सैकड़ों प्रतिभागी, और एक साथ SMS, ईमेल, पुश और वेबहुक डिलीवरी। पीक के दौरान बैकप्रेशर और प्रायोरिटी की आवश्यकता होती है ताकि कम मूल्य वाले नोटिफिकेशन कमांड एक्शन को ब्लॉक न कर सकें।
स्टेप 2: अलर्ट्स को इंजेस्ट, डीडुप्लीकेट और कोरिलेट करें
प्रत्येक सिग्नल के लिए सोर्स, रूल वर्ज़न, टाइमस्टैम्प, फिंगरप्रिंट और रॉ पेलोड को सुरक्षित रखें। क्लाइंट रिट्राई और नेटवर्क रीप्ले के लिए आइडेम्पोटेंसी कीज़ की आवश्यकता होती है; एक यूनीक कंस्ट्रेंट या लीज एक फिंगरप्रिंट के लिए डुप्लीकेट इंसिडेंट को रोकता है। डीडुप्लीकेशन विंडो को हमेशा के लिए किसी नए आउटेज को छिपाना नहीं चाहिए, इसलिए इसे सर्विस, एनवायरनमेंट और समय के अनुसार कॉन्फ़िगर करें।
कोरिलेशन सर्विस टोपोलॉजी, डिप्लॉयमेंट वर्ज़न, रीजन और शेयर्ड लेबल्स के साथ शुरू हो सकता है, फिर इंसिडेंट मैनेजर को स्प्लिट या मर्ज करने की अनुमति दे सकता है। ऑटोमैटिक कोरिलेशन को अपने नियम और साक्ष्य रिकॉर्ड करने चाहिए; यह चुपचाप इंसिडेंट के दायरे (स्कोप) को नहीं बदल सकता। रॉ अलर्ट्स इम्यूटिएबल होते हैं, जबकि एग्रीगेशन एक डिराइव्ड स्टेट है।
स्टेप 3: स्टेट और रोल्स का मॉडल बनाएं
एक इंसिडेंट डिटेक्टेड, ट्रायज्ड, मिटिगेटिंग, मॉनिटरिंग, रिजॉल्व्ड और क्लोज्ड जैसे स्टेट्स का उपयोग कर सकता है। लीगल ट्रांज़िशन, एक्टर्स और आवश्यक साक्ष्य को परिभाषित करें। स्टेट कोई बूलियन नहीं है; इम्पैक्ट, वर्तमान परिकल्पना (हाइपोथिसिस), अगला एक्शन और अपडेट समय को एक साथ रिकॉर्ड करें।
रिस्पॉन्स रोल्स को पहचान (आइडेंटिटी) से अलग करें। इंसिडेंट मैनेजर प्राथमिकता और निर्णयों का ओनर होता है, टेक लीड जांच का ओनर होता है, कम्युनिकेशंस लीड आंतरिक और बाहरी अपडेट्स का ओनर होता है, और स्क्राइब टाइमलाइन बनाए रखता है। रोल परिवर्तन ऑडिट इवेंट्स को अपेंड करते हैं। लीज और वर्ज़न दो रिस्पॉन्डर्स को चुपचाप किसी कमांड को ओवरराइट करने से रोकते हैं।
स्टेप 4: एक ही सोर्स ऑफ़ ट्रुथ के इर्द-गिर्द कोलैबोरेशन का निर्माण करें
WebSocket, SSE, ईमेल और मोबाइल चैनलों पर बस (bus) के माध्यम से पब्लिश करने से पहले स्टेट, रोल्स, एक्शन आइटम्स और कम्युनिकेशन समरी को एक इवेंट लॉग या ट्रांजैक्शनल स्टोर में परसिस्ट करें। एक क्लाइंट आशावादी रूप से (ऑप्टिमिस्टिकली) रेंडर कर सकता है, लेकिन वर्ज़न कन्फ्लिक्ट के लिए एक नए सर्वर रीड की आवश्यकता होती है। ब्राउज़र मेमोरी कभी भी अंतिम सत्य नहीं होती है।
टाइमलाइन में एक्टर, सर्वर टाइम, इंसिडेंट वर्ज़न, एक्शन टाइप, समरी और संबंधित अलर्ट्स को स्टोर करें। लंबी चैट कहीं और रह सकती है, लेकिन निर्णय और रिकवरी साक्ष्य एक स्ट्रक्चर्ड टाइमलाइन में होते हैं। रीड मॉडल्स वर्तमान इंसिडेंट को रेंडर कर सकते हैं, जबकि रीप्ले अभी भी इसे रीकंस्ट्रक्ट कर सकता है।
स्टेप 5: नोटिफिकेशन स्टॉर्म और एक्सेस को नियंत्रित करें
इंसिडेंट की प्राथमिकता, ऑन-कॉल शेड्यूल, चैनल विश्वसनीयता और एक्नॉलेजमेंट के आधार पर रेट-लिमिट करें। कम प्राथमिकता वाले अलर्ट्स को संक्षेप में प्रस्तुत करें; उच्च प्राथमिकता वाले नोटिफिकेशन्स के लिए बैकऑफ़, एस्केलेशन और एक्नॉलेजमेंट टाइमआउट का उपयोग करें। एक ही इंसिडेंट को एक रिस्पॉन्डर को सैकड़ों डुप्लीकेट मैसेज नहीं भेजने चाहिए। नोटिफिकेशन कतारों (क्यूज़) को कंट्रोल प्लेन से अलग रखें ताकि प्रोवाइडर का आउटेज स्टेट परिवर्तनों को ब्लॉक न कर सके।
ऑब्जर्वर, रिस्पॉन्डर, इंसिडेंट मैनेजर, कम्युनिकेशंस लीड और एडमिनिस्ट्रेटर को टेनेंट, सर्विस और एनवायरनमेंट के अनुसार ऑथराइज करें। एक बाहरी स्टेटस पेज इम्पैक्ट और प्रोग्रेस का एक रिडैक्टेड रीड प्रोजेक्शन होता है; इसे हाइपोथिसिस, ग्राहक डेटा या क्रेडेंशियल्स को उजागर नहीं करना चाहिए। रीड्स और एक्सपोर्ट्स को रिकॉर्ड करें, और आपातकालीन ब्रेक-ग्लास एक्सेस के लिए कारण और बाद में समीक्षा अनिवार्य करें।
स्टेप 6: डिग्रेड, रिकवर और रिव्यू करें
यदि प्लेटफ़ॉर्म फ़ेल हो जाता है, तो फ़ोन ब्रिज, स्टैटिक रनबुक या बैकअप इंसिडेंट लॉग बनाए रखें। इंसिडेंट क्रिएशन, रोल क्लेमिंग और टाइमलाइन राइट्स को पहले सुरक्षित रखें; एनालिटिक्स, सर्च और हिस्टोरिकल रिपोर्ट्स अनुपलब्ध हो सकते हैं। रीजनल डिप्लॉयमेंट एसिंक्रोनस रेप्लिकेशन या शर्डेड राइट्स के साथ प्राइमरी राइटर का उपयोग कर सकता है, लेकिन फेलओवर के दौरान कन्फ्लिक्ट हैंडलिंग और लीज री-एक्विजिशन का दस्तावेजीकरण करें।
रिकवरी के बाद, डिटेक्शन, कन्फर्मेशन, मिटिगेशन, रिकवरी और क्लोज़र टाइमस्टैम्प्स, निर्णयों, अलर्ट क्वालिटी, कम्युनिकेशन और फॉलो-अप वर्क से एक रिव्यू ड्राफ़्ट करें। मूल टाइमलाइन को ओवरराइट न करें; रिवीज़न वर्ज़न्स को अपेंड करते हैं। MTTA, MTTM, MTTR, डुप्लीकेट-अलर्ट रेश्यो, रोल-क्लेम लेटेंसी, नोटिफिकेशन डिलीवरी और एक्शन-आइटम कम्प्लीशन को ट्रैक करें।
इंफॉर्मेशन गेन और सीमाएं
इंसिडेंट कमांड प्लेटफ़ॉर्म का मूल्य ओनरशिप, स्टेट और साक्ष्य को स्ट्रक्चर करने से आता है, न कि हर बातचीत को एक पेज पर ले जाने से। यह सही रूट कॉज़ की गारंटी नहीं दे सकता है या मॉनिटरिंग क्वालिटी और रिस्पॉन्डर ट्रेनिंग की जगह नहीं ले सकता है। नोटिफिकेशन्स, आइडेंटिटी, रीजनल नेटवर्क और प्लेटफ़ॉर्म खुद एक साथ फ़ेल हो सकते हैं, इसलिए डिज़ाइन को एक न्यूनतम कंट्रोल प्लेन और मैन्युअल फ़ॉलबैक की आवश्यकता होती है।
मॉडल उत्तर
“मैं पहले सीमा परिभाषित करूँगा: प्लेटफ़ॉर्म अलर्ट्स और रिस्पॉन्स को व्यवस्थित करता है, जबकि मॉनिटरिंग, डिप्लॉयमेंट और सामान्य चैट अलग रहते हैं। उद्देश्य क्रिएशन लेटेंसी, क्रिटिकल नोटिफिकेशन डिलीवरी, टाइमलाइन ड्यूरेबिलिटी, रीजनल रिकवरी और ऑडिट रिटेंशन हैं। इनटेक रॉ अलर्ट्स को सुरक्षित रखता है और डीडुप्लीकेशन के लिए सोर्स फिंगरप्रिंट्स और आइडेम्पोटेंसी कीज़ का उपयोग करता है। सर्विस, रीजन, वर्ज़न और टोपोलॉजी द्वारा कोरिलेशन व्याख्या योग्य और प्रतिवर्ती (रिवर्सिबल) है।
ऑर्केस्ट्रेशन लेयर एक वर्ज़न वाली स्टेट मशीन है जिसके स्टेट और रोल परिवर्तन एक ड्यूरेबल लॉग में अपेंड होते हैं। इंसिडेंट मैनेजर निर्णयों का ओनर होता है, टेक लीड जांच करता है, कम्युनिकेशंस लीड स्टेकहोल्डर्स को अपडेट करता है, और स्क्राइब साक्ष्य बनाए रखता है। क्लाइंट्स रीप्ले करने योग्य अपडेट्स प्राप्त करते हैं और वर्ज़न कन्फ्लिक्ट पर फिर से पढ़ते हैं; ब्राउज़र कैश ऑथॉरिटेटिव नहीं है। कंट्रोल एक्शन्स और नोटिफिकेशन्स प्राथमिकता, ऑन-कॉल और एक्नॉलेजमेंट सीमाओं के साथ अलग कतारों का उपयोग करते हैं।
एक्सेस टेनेंट, सर्विस और एनवायरनमेंट द्वारा अलग किया जाता है, और बाहरी प्रोजेक्शन रिडैक्टेड होता है। रीजनल फेलियर के दौरान, क्रिएशन, रोल क्लेमिंग और टाइमलाइन राइट्स उपलब्ध रहते हैं जबकि सर्च और रिपोर्ट्स रीड-ओनली या ऑफ़लाइन में डिग्रेड हो जाते हैं। रिकवरी एक इम्यूटिएबल टाइमलाइन से रिव्यू बनाती है और MTTA, MTTR, अलर्ट नॉइज़ और एक्शन कम्प्लीशन की गणना करती है। यदि प्लेटफ़ॉर्म अनुपलब्ध है, तो एक फ़ोन ब्रिज और स्टैटिक रनबुक कमांड को संभव बनाए रखते हैं।”
सामान्य गलतियां
- प्लेटफ़ॉर्म को चैट की तरह मानना → महत्वपूर्ण स्टेट ऑडिट-योग्य नहीं रह जाता → एक स्ट्रक्चर्ड स्टेट मशीन और टाइमलाइन का उपयोग करें।
- प्रत्येक अलर्ट को ब्रॉडकास्ट करना → नोटिफिकेशन स्टॉर्म कमांड को ब्लॉक कर देते हैं → डीडुप्लीकेट करें, प्राथमिकता दें, एक्नॉलेज करें और रेट-लिमिट करें।
- रोल्स को केवल UI में रखना → समवर्ती रिस्पॉन्डर्स एक-दूसरे को ओवरराइट कर देते हैं → सर्वर लीज, वर्ज़न और ऑडिट इवेंट्स का उपयोग करें।
- ऑटोमैटिक कोरिलेशन को छिपाना → खराब स्कोप की व्याख्या नहीं की जा सकती → रॉ अलर्ट्स और कोरिलेशन साक्ष्य को सुरक्षित रखें।
- केवल स्वस्थ रीजन को डिज़ाइन करना → प्लेटफ़ॉर्म आउटेज कमांड को हटा देता है → एक न्यूनतम कंट्रोल प्लेन और मैन्युअल फ़ॉलबैक प्रदान करें।
- रिव्यू साक्ष्य को ओवरराइट करना → निर्णयों और टाइमस्टैम्प्स को सत्यापित नहीं किया जा सकता → रॉ लॉग को इम्यूटिएबल रखें और रिवीज़न्स को अपेंड करें।
फ़ॉलो-अप प्रश्न
क्या होगा यदि दो इंसिडेंट मैनेजर एक साथ नियंत्रण का दावा (कंट्रोल क्लेम) करते हैं?
एक एक्सपायर होने वाले टेकओवर लीज और मोनोटोनिक वर्ज़न का उपयोग करें। सर्वर केवल वर्तमान लीज होल्डर से कंट्रोल राइट्स स्वीकार करता है। हारने वाला रिस्पॉन्डर फिर से पढ़ता है और ओनर को प्रदर्शित करता है; इमरजेंसी ब्रेक-ग्लास के लिए ऑथराइजेशन, कारण और ऑडिट की आवश्यकता होती है।
क्या नोटिफिकेशन-प्रोवाइडर का आउटेज इंसिडेंट स्टेट को प्रभावित कर सकता है?
इसे स्टेट राइट्स के लिए नोटिफिकेशन डिलीवरी को पूर्व-आवश्यकता (प्रिरिक्विजिट) नहीं बनाना चाहिए। पहले इंसिडेंट और पेंडिंग नोटिफिकेशन को परसिस्ट करें, फिर एक अलग वर्कर को पुनः प्रयास करने, चैनल बदलने या फ़ोन प्रक्रिया को ट्रिगर करने दें, जबकि कंट्रोल प्लेन उपयोग करने योग्य बना रहे।
आप कोरिलेशन को किसी नए इंसिडेंट को छिपाने से कैसे रोकते हैं?
कोरिलेशन एक संभावित संबंध बनाता है और रॉ सिग्नल को सुरक्षित रखता है। समय, सर्विस, रीजन और टोपोलॉजी जैसे कई साक्ष्य आयामों का उपयोग करें। उच्च प्रभाव या कम विश्वास वाले सिग्नल्स के लिए मानव पुष्टि की आवश्यकता होती है, और रूल वर्ज़न्स और स्प्लिट्स टाइमलाइन में दर्ज होते हैं।
बाहरी स्टेटस पेज पर क्या होना चाहिए?
केवल इम्पैक्ट, वर्तमान चरण, अगले अपडेट का समय और रिकवरी प्रोग्रेस का एक गोपनीयता-फ़िल्टर किया गया प्रोजेक्शन। आंतरिक परिकल्पनाओं, ग्राहक पहचानकर्ताओं, क्रेडेंशियल्स, अपुष्ट मूल कारणों और विस्तृत लॉग्स को नियंत्रित आंतरिक दृश्यों (व्यूज़) में रखें।