प्रश्न
मुझे उस समय के बारे में बताएं जब आपको पता चला कि एक बिल्ड ने परीक्षण पास कर लिए हैं, लेकिन इसकी उत्पत्ति (provenance) या हस्ताक्षर (signature) को सत्यापित नहीं किया जा सका, और आपने रिलीज़ का निर्णय बदल दिया। साक्षात्कारकर्ता यह परीक्षण कर रहा है कि आप साक्ष्य का मूल्यांकन कैसे करते हैं, सीधे अधिकार के बिना टीमों को कैसे प्रभावित करते हैं, और डिलीवरी को सुरक्षित रूप से कैसे बहाल करते हैं।
संदर्भ और सीमाएं
किसी वास्तविक रिलीज़, डिपेंडेंसी अपग्रेड, या सप्लाई-चेन समीक्षा का उपयोग करें। बताएं कि क्या साक्ष्य मौजूद थे, क्या अज्ञात था, रिलीज़ विंडो कितनी तंग थी, और आपके पास क्या अधिकार था। किसी गायब हस्ताक्षर को दुर्भावनापूर्ण कोड के बराबर न समझें, और बाद में जोड़े गए साक्ष्य को इस तरह प्रस्तुत न करें जैसे कि वह उस समय मौजूद था।
साक्षात्कारकर्ता क्या परीक्षण कर रहा है
मुख्य कौशल साक्ष्य का निर्णय और जोखिम संचार है: "बिल्ड सफल रहा" को "बिल्ड एक अधिकृत प्रक्रिया के माध्यम से आया" से अलग करना, फिर एक सत्यापन योग्य डाइजेस्ट (digest), हस्ताक्षर, पहचान और टाइमस्टैम्प का उपयोग करके गेट्स को परिभाषित करना। GitHub सॉफ्टवेयर कहां और कैसे बनाया गया था यह स्थापित करने के तरीके के रूप में artifact attestations का दस्तावेजीकरण करता है, जिसमें हस्ताक्षर और हस्ताक्षरकर्ता पहचान का क्रिप्टोग्राफ़िक सत्यापन शामिल है; Google SRE तथ्यात्मक निर्णय रिकॉर्ड और सिस्टम को बेहतर बनाने वाले फॉलो-अप कार्य पर जोर देता है।
पहले इन बिंदुओं को स्पष्ट करें:
- क्या रिलीज़ एक आंतरिक सेवा, ग्राहक द्वारा डाउनलोड करने योग्य पैकेज, या एक कंटेनर इमेज है?
- क्या कमी हस्ताक्षर, बिल्ड पहचान, सोर्स लिंक, SBOM, या साक्ष्य के उन टुकड़ों के बीच बाइंडिंग में है?
- रिलीज़ को कौन मंज़ूरी दे सकता है, कौन सी कार्रवाइयां प्रतिवर्ती (reversible) हैं, और निर्णय कब तक लिया जाना है?
- क्या आप दायरे को सीमित कर सकते हैं, पिछले संस्करण को बनाए रख सकते हैं, या पहले एक ऑडिट योग्य रीबिल्ड तैयार कर सकते हैं?
30-सेकंड का उत्तर
STAR-L का उपयोग करें: Situation (स्थिति) रिलीज़ लक्ष्य और साक्ष्य के अंतर को बताती है; Task (कार्य) उस उपयोगकर्ता या अनुपालन परिणाम का नाम देता है जिसकी आपने रक्षा की; Action (कार्रवाई) बताती है कि आपने डाइजेस्ट, हस्ताक्षर और वर्कफ़्लो पहचान की जांच कैसे की, क्रमिक गेट्स का प्रस्ताव दिया, और साक्ष्य संग्रह का समन्वय कैसे किया; Result (परिणाम) देरी, दायरा और जोखिम परिवर्तन बताता है; Learning (सीख) बताती है कि नए प्रमाण की जांच ने पाइपलाइन में कैसे प्रवेश किया।
चरण-दर-चरण गहन विश्लेषण
- निष्कर्ष को फ्रीज करें: तथ्यों को परिकल्पनाओं से अलग करते हुए, उम्मीदवार आर्टिफैक्ट डाइजेस्ट, परीक्षण परिणाम, बिल्ड वर्कफ़्लो और मौजूदा प्रमाण रिकॉर्ड करें।
- न्यूनतम साक्ष्य परिभाषित करें: डाइजेस्ट रिलीज़ ऑब्जेक्ट से मेल खाना चाहिए, और प्रमाण को रिपॉजिटरी, कमिट, वर्कफ़्लो और हस्ताक्षरकर्ता पहचान को बांधना चाहिए; कोई भी लिंक गायब होने पर मामले को Unknown के रूप में चिह्नित करें।
- क्रमिक विकल्प पेश करें: उच्च जोखिम वाले आर्टिफैक्ट्स को ब्लॉक करें; कम जोखिम वाले आर्टिफैक्ट्स के लिए पुराने संस्करण को रखें या ऑडिट रिकॉर्ड को बायपास किए बिना, एक छोटे आंतरिक कैनरी (canary) का उपयोग करें।
- एक साथ सत्यापित करें: बिल्ड, रिलीज़, सुरक्षा और व्यावसायिक स्वामियों के साथ एक साक्ष्य चेकलिस्ट साझा करें, प्रत्येक आइटम के लिए एक स्वामी और समय सीमा सौंपें।
- पुनर्स्थापित करें और ट्रैक करें: सत्यापन के बाद केवल डाइजेस्ट-मिलान वाले आर्टिफैक्ट को रिलीज़ करें, अपवाद कारण, अनुमोदनकर्ता और फॉलो-अप कार्रवाइयों को रिकॉर्ड करें।
आदर्श उत्तर
"एक तत्काल सुधार (fix) ने हर परीक्षण पास कर लिया, लेकिन रिलीज़ सिस्टम कमिट SHA से बंधे हस्ताक्षर को पुनर्प्राप्त नहीं कर सका। मैंने पहले इमेज डाइजेस्ट, परीक्षण परिणाम और बिल्ड लॉग रिकॉर्ड किए, जिससे पुष्टि हुई कि समस्या डाइजेस्ट बेमेल के बजाय गायब प्रमाण थी। चूंकि संस्करण ग्राहकों के सामने आने वाला था, मैंने पुराने संस्करण को बनाए रखते हुए और एक आंतरिक कैनरी बनाते हुए बाहरी रिलीज़ को रोकने का प्रस्ताव रखा। मैंने वर्कफ़्लो पहचान और हस्ताक्षर जोड़ने के लिए बिल्ड टीम के साथ काम किया, सुरक्षा टीम से स्वतंत्र क्रेडेंशियल्स के साथ हस्ताक्षर सत्यापित करवाए, और रिलीज़ स्वामी के साथ नवीनतम पुनर्प्राप्ति समय पर सहमति व्यक्त की। रिलीज़ में 90 मिनट की देरी हुई; कैनरी और रोलबैक योजना के अनुसार पूरे हुए। इसके बाद हमने डाइजेस्ट मिलान, हस्ताक्षर सत्यापन और अपवाद अनुमोदन को अनिवार्य गेट बना दिया। मैंने संकट से पहले स्वचालित जांच के रूप में साक्ष्य गेट्स को कोड करना सीखा, जिससे मानवीय निर्णय केवल प्रलेखित अपवादों के लिए ही रह गया।"
सामान्य गलतियाँ
- हरे परीक्षण सूट (green test suite) को विश्वसनीय मूल के पर्याप्त प्रमाण के रूप में मानना।
- यह बताए बिना "हस्ताक्षर जोड़ें" कहना कि यह क्या बांधता है, कौन हस्ताक्षर करता है, या इसे कैसे सत्यापित किया जाता है।
- पुराने संस्करण, कैनरी, या समय सीमा के विकल्प के बिना व्यावसायिक लक्ष्य को रद्द करने के लिए सुरक्षा जोखिम का उपयोग करना।
- साझा सत्यापन पर संरेखित करने के बजाय बिल्ड टीम को अवरोधक (blocker) के रूप में वर्णित करना।
- केवल यह रिपोर्ट करना कि रिलीज़ सफल रही या नहीं, जिसमें देरी की लागत, दायरा, या फॉलो-अप गेट शामिल नहीं है।
एक मजबूत उत्तर में एक तथ्यात्मक समयरेखा होती है, जो आर्टिफैक्ट डाइजेस्ट, बिल्ड मूल और हस्ताक्षरकर्ता पहचान के बीच अंतर करती है, जोखिम से मेल खाने वाले एक प्रतिवर्ती विकल्प का प्रस्ताव करती है, अधिकार के बिना प्रभाव की व्याख्या करती है, और परिणाम की गणना करती है। एक कमजोर उत्तर "सुरक्षा में सुधार" पर रहता है या व्यक्तिगत अंतर्ज्ञान को साक्ष्य के रूप में मानता है।
फॉलो-अप प्रश्न और प्रतिक्रियाएं
क्या होगा यदि व्यवसाय स्वामी आपसे अभी शिप करने और बाद में प्रमाण जोड़ने के लिए कहे?
रिलीज़ दर्शकों और सबसे खराब स्थिति के प्रभाव की पुष्टि करें, फिर पुराने संस्करण को बनाए रखने, एक आंतरिक कैनरी, या संकीर्ण दायरे जैसे प्रतिवर्ती विकल्प का प्रस्ताव दें। यदि कोई अपवाद आवश्यक बना रहता है, तो असत्यापित आइटम, अनुमोदनकर्ता, समय सीमा और रोलबैक स्थिति रिकॉर्ड करें; अपवाद को अनुपालन योग्य लेबल न दें।
यदि हस्ताक्षर मान्य है लेकिन कमिट किसी अस्वीकृत रिपॉजिटरी या शाखा से है, तो क्या आप शिप कर सकते हैं?
अकेले हस्ताक्षर की वैधता से नहीं। नीति के विरुद्ध हस्ताक्षरकर्ता पहचान, रिपॉजिटरी, कमिट, वर्कफ़्लो और परिवेश को सत्यापित करें; कोई भी विफल बाइंडिंग समीक्षा के लिए जाती है या रिलीज़ को ब्लॉक करती है।
आप कैसे दिखाते हैं कि नया गेट अंतहीन प्रतीक्षा नहीं बनाता है?
प्रत्येक साक्ष्य आइटम को एक स्वचालित जांच, स्वामी और समय सीमा दें। ब्लॉक, औसत पुनर्प्राप्ति समय और अपवाद दर को ट्रैक करें; प्रत्येक अपवाद की समीक्षा करें और समय के साथ मैन्युअल प्रतीक्षा को कम करें।
साक्षात्कार चेकलिस्ट
एक-वाक्य का निष्कर्ष
"बिल्ड पास हो गया" से "आर्टिफैक्ट, मूल, पहचान और निर्णय सत्यापन योग्य हैं" में अपग्रेड करें, फिर डिलीवरी और जोखिम को संतुलित करने के लिए प्रतिवर्ती विकल्पों का उपयोग करें।