व्यवहारिक साक्षात्कार: आप पुराने इंसिडेंट रनबुक को सुरक्षित रूप से कैसे रिटायर करते हैं?

प्रॉम्प्ट और संदर्भ

आपको पता चलता है कि अक्सर उपयोग की जाने वाली इंसिडेंट रनबुक में हटाई गई सर्विस के चरण शामिल हैं और इससे आउटेज की स्थिति और बिगड़ सकती है। बताएं कि आप वर्तमान कवरेज को बाधित किए बिना ऑन-कॉल टीम की सुरक्षा कैसे करेंगे, उसके विकल्प को मान्य कैसे करेंगे, रनबुक को रिटायर या दोबारा कैसे लिखेंगे, और यह कैसे साबित करेंगे कि सुधार को अपना लिया गया है।

इंटरव्यूअर क्या जांच रहा है

डॉक्यूमेंटेशन का स्वामित्व किसका है, इस पर बहस करने से पहले असुरक्षित कार्यों के जोखिम को कम करना।
"डॉक्यूमेंट पुराना है" की स्थिति को एक पुनरुत्पादक (reproducible) और सत्यापन योग्य माइग्रेशन योजना में बदलना।
प्रभाव, सहयोग, ट्रेड-ऑफ और फॉलो-अप मेट्रिक्स को समझाने के लिए STAR फ्रेमवर्क का उपयोग करना।

पहले स्पष्ट करने योग्य प्रश्न

कौन से चरण अमान्य हैं, और क्या वे डेटा हटा सकते हैं, ट्रैफ़िक बढ़ा सकते हैं, या रिकवरी को रोक सकते हैं?
कैश्ड लिंक और बॉट्स सहित ऑन-कॉल इंजीनियर्स वास्तव में रनबुक कहाँ से खोलते हैं?
इसके विकल्प का मालिक कौन है, कौन सा सैंडबॉक्स उपलब्ध है, और आपातकालीन रोलबैक कैसे काम करेगा?

एक 30-सेकंड का उत्तर

मैं रनबुक के शीर्ष पर जोखिम को चिह्नित करूंगा, ऑन-कॉल और इंसिडेंट ओनर को सूचित करूंगा, और एक सत्यापित अस्थायी पाथ प्रदान करूंगा ताकि कोई भी अमान्य चरण को न दोहराए। मैं सैंडबॉक्स में विकल्प का परीक्षण करूंगा, सर्विस ओनर के साथ लिंक, अनुमतियों और रोलबैक गाइडेंस को अपडेट करूंगा, फिर नए वर्ज़न को प्रकाशित करूंगा और पुराने वर्ज़न को डिप्रिकेट (deprecate) करूंगा। इसे अपनाए जाने को केवल मर्ज किए गए डॉक्यूमेंटेशन बदलाव से नहीं, बल्कि लिंक एक्सेस, ड्रिल की सफलता, गलत कार्यों और पूरे किए गए फॉलो-अप्स के माध्यम से मापा जाएगा।

चरण-दर-चरण गहन विश्लेषण

1. खतरनाक चरणों को अलग करें

अपरिवर्तनीय (irreversible) प्रभाव वाले कमांड्स या निर्णयों की पहचान करें। एक स्पष्ट चेतावनी जोड़ें, स्वचालित लिंक को अक्षम करें, या ऑन-कॉल ओनर द्वारा अनुमोदित अस्थायी पाथ को बनाए रखते हुए पुराने वर्ज़न को एक स्पष्ट संग्रह (archive) में ले जाएं।

2. वास्तविक एक्सेस पाथ का पुनर्निर्माण करें

इंजीनियर्स वास्तव में जिस वर्ज़न का उपयोग करते हैं उसे खोजने के लिए ऑन-कॉल इंडेक्स, सर्च रिजल्ट्स, बॉट संदेशों, अनुमतियों और कैश्ड बुकमार्क की जांच करें। केवल सोर्स रिपॉजिटरी को एडिट करने से कॉपी किए गए लिंक प्रचलन में बने रहते हैं।

3. विकल्प को मान्य करें

एक सैंडबॉक्स या कम जोखिम वाली विंडो में नए चरणों को चलाएं और आवश्यक पूर्वापेक्षाओं (prerequisites), संकेतों, स्टॉप कंडीशंस और रोलबैक को रिकॉर्ड करें। GitLab रनबुक को प्रारंभिक पहचान और नियमित हैंडलिंग के रूप में वर्णित करता है, जिसमें अधिक जटिल मामलों के लिए प्लेबुक या एस्केलेशन पाथ होते हैं; डॉक्यूमेंट की सीमा वास्तविक ज़िम्मेदारी से मेल खानी चाहिए।

4. स्वामित्व वाली टीमों के साथ दोबारा लिखें

सर्विस ओनर, ऑन-कॉल प्रतिनिधि, और सुरक्षा या अनुपालन समीक्षकों से बदलाव की जांच करने के लिए कहें। मेमोरी से महत्वपूर्ण कमांड्स को फिर से लिखने के बजाय तथ्यों, मान्यताओं और खुली जांचों को अलग करें। प्रत्येक चरण में दायरा (scope) और विफल होने पर एस्केलेशन एंट्री पॉइंट का उल्लेख होना चाहिए।

5. प्रकाशन और रिटायरमेंट की योजना बनाएं

नए वर्ज़न को कैंडिडेट के रूप में प्रकाशित करें और पुराने वर्ज़न को एक डिप्रिकेशन तिथि और प्रतिस्थापन लिंक दें। यदि पुराना पाथ गंभीर नुकसान पहुंचा सकता है, तो परिवर्तन प्रक्रिया का पालन करने से पहले निष्पादन (execution) अनुमति हटा दें या इसे केवल पढ़ने के लिए (read-only) बना दें। रोलबैक को डिप्लॉयमेंट अनुमतियों और नवीनतम उपयोग योग्य वर्ज़न के साथ संरेखित रखें।

6. एक ड्रिल के साथ अपनाने का परीक्षण करें

जिस व्यक्ति ने रनबुक नहीं लिखी है, उससे एक ड्रिल पूरी करवाएं। निरीक्षण करें कि क्या वे एंट्री पॉइंट ढूंढ पाते हैं, पूर्वापेक्षाओं को पहचानते हैं, और स्टॉप कंडीशन पर एस्केलेट करते हैं। वास्तविक उपयोग के स्थान पर लेखक के स्व-परीक्षण पर निर्भर रहने के बजाय समय, गलत चरणों और प्रश्नों को रिकॉर्ड करें।

7. रखरखाव ट्रिगर्स जोड़ें

एक ओनर, समीक्षा तिथि, और टोपोलॉजी, अलर्ट-नाम या अनुमति परिवर्तन जैसे ट्रिगर्स सेट करें। पुराना डॉक्यूमेंटेशन यह संकेत दे सकता है कि चेंज रिव्यू में डॉक्यूमेंटेशन जांच का अभाव है; इसे रिलीज़ चेकलिस्ट और इंसिडेंट-रिव्यू एक्शन आइटम्स में जोड़ें।

मॉडल उत्तर

मैं अमान्य चरण के जोखिम की पुष्टि करूंगा, एक चेतावनी जोड़ूंगा, ऑन-कॉल और इंसिडेंट ओनर को सूचित करूंगा, और एक पुष्ट अस्थायी पाथ प्रदान करूंगा। मैं उन लिंक्स की जांच करूंगा जिनका लोग वास्तव में उपयोग करते हैं, पूर्वापेक्षाओं, स्टॉप कंडीशंस और रोलबैक के साथ एक सैंडबॉक्स में विकल्प का परीक्षण करूंगा, और सर्विस ओनर व ऑन-कॉल प्रतिनिधि के साथ इसकी समीक्षा करूंगा। फिर मैं नए वर्ज़न को प्रकाशित करूंगा, पुराने को डिप्रिकेट करूंगा, और एक ऐसे व्यक्ति के साथ ड्रिल चलाऊंगा जिसने इसे नहीं लिखा है। स्वीकृति मेट्रिक्स में एंट्री पॉइंट खोजना, गलत कार्य, एस्केलेशन का समय और माइग्रेशन का पूरा होना शामिल होगा, साथ ही चेंज प्रोसेस में रखरखाव ट्रिगर्स भी शामिल होंगे।

सामान्य गलतियां

सुरक्षित प्रतिस्थापन पाथ के बिना पुरानी रनबुक को हटाना।
कैश्ड लिंक, बॉट्स और बुकमार्क को अनदेखा करते हुए केवल रिपॉजिटरी को एडिट करना।
केवल लेखक द्वारा ड्रिल पूरी करने के बाद सफलता की घोषणा करना।
बिना प्लेबुक या एस्केलेशन सीमाओं के हर विफलता प्रक्रिया को एक ही रनबुक में डालना।
गलत कार्यों और ड्रिल के परिणामों के बजाय केवल डॉक्यूमेंटेशन मर्ज की गिनती करना।

फॉलो-अप प्रश्न और उत्तर

क्या होगा यदि कोई इंसिडेंट पहले से ही एक्टिव है?

इंसिडेंट लीड से अस्थायी पाथ और जोखिम की पुष्टि करवाएं, अमान्य चरण के प्रसार को रोकें, और डॉक्यूमेंटेशन सुधार को इंसिडेंट एक्शन लिस्ट में जोड़ें। समस्या निवारण (firefight) के दौरान एक अप्रमाणित बड़ा पुनर्लेखन न करें।

क्या होगा यदि सर्विस ओनर इस बात से इनकार करता है कि रनबुक पुरानी है?

सटीक चरण, हालिया बदलाव, और पुनरुत्पादक विफलता के साक्ष्य सामने लाएं, फिर एक छोटी ड्रिल का प्रस्ताव दें। चर्चा को व्यक्ति पर नहीं, बल्कि यूज़र जोखिम और रखरखाव के स्वामित्व पर केंद्रित करें।

क्या होगा यदि कई बाहरी टीमें पुरानी रनबुक का उपयोग करती हैं?

एक स्थिर रीडायरेक्ट या कम्पैटिबिलिटी नोट बनाए रखें, उपभोक्ताओं को सूचित करें और माइग्रेशन की समय सीमा निर्धारित करें। पहले उच्च जोखिम वाले कमांड की अनुमतियों को प्रतिबंधित करें, फिर टीम दर टीम माइग्रेशन की पुष्टि करें।

आपको पुराने वर्ज़न को पूरी तरह से कब हटाना चाहिए?

केवल तभी जब विकल्प ने एक ड्रिल पास कर ली हो, उसका कोई ओनर हो, सभी महत्वपूर्ण एंट्री पॉइंट्स स्थानांतरित हो गए हों, और रोलबैक उपलब्ध हो। जब सुरक्षा या अनुपालन की आवश्यकता हो तो अधिक सख्त रिटेंशन नियमों का पालन करें।

क्या होगा यदि विकल्प ड्रिल में विफल हो जाता है?

प्रकाशन रोकें, विफल पूर्वापेक्षाओं और संकेतों को रिकॉर्ड करें, प्रक्रिया को ठीक करें और ड्रिल को फिर से चलाएं। विफलता इस बात का प्रमाण है कि रिलीज़ गेट की शर्तें पूरी नहीं हुई हैं, न कि इसे टालने का कोई कारण।

आप STAR के साथ यह कहानी कैसे बताएंगे?

ठोस जोखिम और कार्य का वर्णन करें, फिर सूचनाएं, सत्यापन, सहयोग और प्रकाशन के चरणों की व्याख्या करें। गलत कार्यों में कमी, ड्रिल पास दर, या माइग्रेशन पूरा होने के साथ-साथ आपके द्वारा जोड़े गए रखरखाव तंत्र के साथ समाप्त करें।