1. प्रश्न और संदर्भ
एक प्लेटफ़ॉर्म टीम को फ़ायरवॉल नियम, भुगतान सीमाएँ या सर्विस रूटिंग बदलने की आवश्यकता है। अनुरोधकर्ता (रिक्वेस्टर) अपने स्वयं के परिवर्तन को मंज़ूरी नहीं दे सकता, अप्रूवल एक सटीक वर्ज़न के लिए होना चाहिए, और विफल निष्पादन के कारण आंशिक अपडेट नहीं छूटना चाहिए। इसका उद्देश्य एक सत्यापन योग्य, ऑडिट योग्य और पुनर्प्राप्ति योग्य वर्कफ़्लो तैयार करना है।
2. इंटरव्यूअर क्या मूल्यांकन कर रहा है
- क्या आप प्रस्ताव (प्रपोज़ल), मंज़ूरी (अप्रूवल), निष्पादन (एक्ज़ीक्यूशन) और रोलबैक की स्थितियों को अलग करते हैं।
- क्या अप्रूव करने वाले स्वतंत्र हैं और अप्रूव की गई सामग्री को चुपके से बदला नहीं जा सकता है।
- क्या आप समवर्ती अप्रूवल, डुप्लिकेट अनुरोधों, टाइमआउट, रिवोकेशन और अनुमति परिवर्तनों को संभालते हैं।
- क्या आप जोखिम को नियंत्रित करते हुए छोटे दायरे में रोलआउट और स्थिर रिकवरी प्रदान करते हैं।
NIST SP 800-128 के अनुसार कॉन्फ़िगरेशन परिवर्तनों की समीक्षा अनुरोधकर्ता से स्वतंत्र किसी अधिकृत व्यक्ति द्वारा की जानी चाहिए। Google SRE कॉन्फ़िगरेशन वर्ज़न के लिए कोड समीक्षा करने और नए वर्ज़न की जाँच विफल होने पर पिछले कॉन्फ़िगरेशन को चालू रखने पर ज़ोर देता है। इन सिद्धांतों को डेटा और स्टेट ट्रांज़िशन में लागू करें।
3. उत्तर देने से पहले स्पष्ट करने वाले प्रश्न
- कौन से संसाधन और फ़ील्ड हाई-रिस्क हैं, और क्या परिवेश (एनवायरनमेंट) या टेनेंट में अंतर है?
- क्या अप्रूवल एक व्यक्ति द्वारा, कइयों में से किसी एक द्वारा, या विभिन्न भूमिकाओं और लोगों के बीच एक थ्रेशोल्ड द्वारा होता है?
- क्या निष्पादन पूर्ण स्विच, बैच रोलआउट, या टारगेट-इंस्टेंस पुष्टिकरण है?
- क्या रोलबैक अंतिम ज्ञात-सही (लास्ट नोन-गुड) वर्ज़न पर होता है या अनुरोधकर्ता द्वारा चुने गए वर्ज़न पर?
4. 30-सेकंड का उत्तर ढाँचा
अपरिवर्तनीय (इम्यूटेबल) प्रपोज़ल, पॉलिसी मैच, अप्रूवल आइसोलेशन, एक्ज़ीक्यूटर, रोलबैक और ऑडिट का उपयोग करें।
मैं प्रत्येक परिवर्तन को एक इम्यूटेबल वर्ज़न के रूप में फ़्रीज़ करता हूँ, और एक पॉलिसी संसाधन, जोखिम और एनवायरनमेंट के आधार पर स्वतंत्र अप्रूवर्स का चयन करती है। अप्रूवल में वर्ज़न डाइजेस्ट और पॉलिसी वर्ज़न रिकॉर्ड होता है, और रिक्वेस्टर अप्रूवल थ्रेशोल्ड को पूरा नहीं कर सकता। एक इडेम्पोटेंट एक्ज़ीक्यूटर हेल्थ चेक के साथ बैचों में परिवर्तन लागू करता है। कोई भी विफलता आगे के रोलआउट को रोक देती है और अंतिम सत्यापित वर्ज़न को पुनर्स्थापित करती है, जबकि प्रत्येक स्थिति और निर्णय केवल जोड़ने योग्य (अपेंड-ओनली) ऑडिट स्टोरेज में जाता है।
5. चरण-दर-चरण गहन विश्लेषण
चरण 1: एंटिटीज़ और स्टेट मशीन को परिभाषित करें
एक प्रपोज़ल में संसाधन, diff, लेखक, वर्ज़न डाइजेस्ट, टारगेट एनवायरनमेंट और एक्सपायरी शामिल होती है। एक अप्रूवल में अप्रूवर, भूमिका, निर्णय, समय, पॉलिसी वर्ज़न और प्रपोज़ल डाइजेस्ट शामिल होता है। एक निष्पादन रिकॉर्ड में बैच, टारगेट, परिणाम और रोलबैक वर्ज़न शामिल होता है। स्थितियाँ DRAFT, PENDING_APPROVAL, APPROVED, EXECUTING, SUCCEEDED, FAILED, REVOKED, या EXPIRED हो सकती हैं; केवल सर्वर-साइड नियम ही इन्हें बदल सकते हैं।
चरण 2: अप्रूवल को स्वतंत्र और वर्ज़न-बाउंड बनाएँ
पॉलिसी सर्विस आवश्यक भूमिकाओं, लोगों, स्व-अनुमोदन निषेध (सेल्फ़-अप्रूवल प्रोहिबिशन) और अप्रूवल की जीवन अवधि की गणना करती है। अप्रूवर को दिखाया गया diff निष्पादन वर्ज़न के हैश से मेल खाना चाहिए; प्रपोज़ल में कोई भी संपादन अप्रूवल को अमान्य कर देता है और एक नई समीक्षा शुरू करता है। अप्रूवल और निष्पादन के समय अनुमतियों की पुनः जाँच करें ताकि बाद में भूमिका निरस्तीकरण को बायपास न किया जा सके।
चरण 3: एक इडेम्पोटेंट एक्ज़ीक्यूटर के साथ रिलीज़ को नियंत्रित करें
प्रत्येक प्रपोज़ल और टारगेट के लिए एक इडेम्पोटेन्सी की (key) जनरेट करें, और बाहरी पावती (एक्नॉलेजमेंट) रिकॉर्ड करें। सिंटैक्स, निर्भरता और सुरक्षा जाँच के बाद छोटे बैच लागू करें, फिर हेल्थ सिग्नलों की निगरानी करें। केवल अज्ञात परिणामों का पुनः प्रयास करें; गैर-इडेम्पोटेंट ऑपरेशन को कभी भी आँख मूंदकर न दोहराएं। एक कतार (क्यू) या वर्कफ़्लो इंजन टाइमआउट, रीट्राई और कन्करेंसी सीमाओं को संभालता है।
चरण 4: सुरक्षित रूप से रोलबैक करें और ऑडिट करें
रिलीज़ से पहले अंतिम सत्यापित वर्ज़न को सहेजें। विफलता पर, बाद के बैचों को रोकें और उस वर्ज़न को पुनर्स्थापित करें। रोलबैक के ऑपरेटर और कारण को रिकॉर्ड करें; हाई-रिस्क आपातकालीन रोलबैक के लिए अपने स्वयं के अप्रूवल की आवश्यकता हो सकती है। कम से कम प्रपोज़ल डाइजेस्ट, अप्रूवल चेन, निष्पादन बैच, कॉन्फ़िगरेशन वर्ज़न, विफलता का कारण और रोलबैक परिणाम का ऑडिट करें, जिसमें विलोपन और संशोधन प्रतिबंधित हों।
6. उच्च-गुणवत्ता वाला नमूना उत्तर
मैं सिस्टम को प्रपोज़ल API, पॉलिसी सर्विस, अप्रूवल सर्विस, एक्ज़ीक्यूशन कतार, कॉन्फ़िगरेशन एडेप्टर और ऑडिट स्टोरेज में विभाजित करूँगा। प्रपोज़ल इम्यूटेबल है और इसमें रिसोर्स diff, एनवायरनमेंट, लेखक और एक्सपायरी शामिल हैं। पॉलिसी सर्विस लेखक को छोड़कर, जोखिम के आधार पर आवश्यक भूमिकाओं और अप्रूवर की संख्या की गणना करती है।
>
अप्रूवर्स वर्ज़न डाइजेस्ट और diff देखते हैं, और अप्रूवल प्रपोज़ल हैश और पॉलिसी वर्ज़न से बंधा होता है। कोई भी संपादन प्रपोज़ल को लंबित अप्रूवल में वापस लौटा देता है। एक बार थ्रेशोल्ड पूरा हो जाने पर, एक्ज़ीक्यूटर प्रपोज़ल ID और टारगेट ID से एक इडेम्पोटेन्सी की बनाता है, स्टैटिक चेक चलाता है, फिर हेल्थ सिग्नलों को पढ़ते हुए छोटे बैच लागू करता है। एक डुप्लिकेट अनुरोध मौजूदा निष्पादन परिणाम लौटाता है; एक अज्ञात परिणाम समीक्षा के लिए जाता है।
>
प्रत्येक प्रपोज़ल अंतिम सत्यापित वर्ज़न रखता है। यदि कोई बैच विफल हो जाता है, तो बाद के बैच रुक जाते हैं, पुराना वर्ज़न पुनर्स्थापित हो जाता है, और कारण रिकॉर्ड किया जाता है; एक आपातकालीन हाई-रिस्क रोलबैक के लिए अभी भी स्वतंत्र अप्रूवल की आवश्यकता होती है। ऑडिट इवेंट अपेंड-ओनली होते हैं और यह रिकॉर्ड करते हैं कि किसने किस डाइजेस्ट को कब अप्रूव किया, कौन से टारगेट चले, और क्या रोलबैक हुआ। यह कर्तव्यों के पृथक्करण को लागू करता है और किसी अप्रूव्ड कॉन्फ़िगरेशन को चुपके से बदलने से रोकता है।
7. सामान्य विफलता मोड
- अप्रूवल को सटीक diff और वर्ज़न डाइजेस्ट के बजाय केवल एक रिसोर्स ID से बांधना।
- लेखक को दूसरी भूमिका के माध्यम से स्वयं अप्रूव करने की अनुमति देना।
- निष्पादन स्थिति या पावती के बिना सीधे कॉन्फ़िगरेशन स्टोर में अप्रूवल लिखना।
- विफलता के बाद रोलआउट का विस्तार करना या गैर-इडेम्पोटेंट ऑपरेशनों का अनिश्चित काल तक पुनः प्रयास करना।
- वर्ज़न, प्राधिकरण और ऑडिट साक्ष्य रिकॉर्ड किए बिना रोलबैक करना।
8. फॉलो-अप प्रश्न और उत्तर
फॉलो-अप 1: यदि अप्रूवल के बाद लेखक नौकरी छोड़ देता है तो क्या होगा?
निर्णय एक इम्यूटेबल प्रपोज़ल से बंधा होता है और इसके लिए लेखक का ऑनलाइन होना आवश्यक नहीं है। निष्पादन सर्विस अकाउंट और वर्तमान पॉलिसी का उपयोग करता है; लेखक के अधिकार रद्द करने से वैध ऑडिट श्रृंखला नहीं मिटती है।
फॉलो-अप 2: आप दो अप्रूवल फ़्लो को एक ही संसाधन पर निष्पादित होने से कैसे रोकते हैं?
संसाधन-और-एनवायरनमेंट लॉक या लीज़ का उपयोग करें, फिर निष्पादन से पहले वर्तमान कॉन्फ़िगरेशन वर्ज़न की पुनः जाँच करें। टकराव होने पर, नया प्रपोज़ल अपने diff और अप्रूवल की पुनर्गणना करता है।
फॉलो-अप 3: क्या कोई आपातकालीन परिवर्तन अप्रूवल को बायपास कर सकता है?
दो-व्यक्ति प्राधिकरण, न्यूनतम विशेषाधिकार, लघु जीवनकाल, परिवर्तन के बाद की समीक्षा और पूर्ण ऑडिट के साथ एक प्रतिबंधित ब्रेक-ग्लास पाथ को परिभाषित करें। यह सामान्य शॉर्टकट नहीं बनना चाहिए।