प्रश्न और संदर्भ
यह प्रश्न परीक्षण करता है कि क्या आप एक महत्वपूर्ण तकनीकी ट्रेड-ऑफ को खोजने योग्य, समीक्षा योग्य और विकसित होने वाली टीम मेमोरी में बदल सकते हैं। इसमें शामिल करें कि ADR कब आवश्यक होता है, खारिज किए गए विकल्पों को कैसे रिकॉर्ड किया जाए, यह रिकॉर्ड कोड समीक्षा और समस्या निवारण (troubleshooting) में कैसे मदद करता है, और नए निर्णय द्वारा प्रतिस्थापित (superseded) किए गए निर्णय को कैसे संभाला जाए।
यह बैकएंड, प्लेटफॉर्म, SRE, स्टाफ इंजीनियर और क्रॉस-फंक्शनल भूमिकाओं के लिए उपयुक्त है। मान लें कि टीम के पास एक रिपॉजिटरी और समीक्षा प्रक्रिया है लेकिन कोई साझा निर्णय-रिकॉर्ड परिपाटी नहीं है; यह विकल्प विश्वसनीयता, सुरक्षा, इंटरफेस, निर्भरता या एक अपरिवर्तनीय लागत ट्रेड-ऑफ से संबंधित हो सकता है।
साक्षात्कारकर्ता क्या मूल्यांकन कर रहा है
पहला, क्या आप प्रत्येक कार्यान्वयन विवरण का दस्तावेजीकरण करने के बजाय आर्किटेक्चरल रूप से महत्वपूर्ण निर्णय की पहचान कर सकते हैं? दूसरा, क्या आप तटस्थ संदर्भ, बाधाओं, विकल्पों और परिणामों के साथ पसंद की व्याख्या कर सकते हैं? तीसरा, क्या आप ADR को proposed, reviewed, accepted और superseded जीवनचक्र में रख सकते हैं? चौथा, क्या आप रिकॉर्ड को कोड समीक्षा, ऑनबोर्डिंग और घटना प्रतिक्रिया (incident response) में उपयोगी बना सकते हैं?
पूछने के लिए स्पष्टीकरण प्रश्न
- क्या यह निर्णय सिस्टम संरचना, प्रमुख गुणवत्ता विशेषताओं, किसी सार्वजनिक इंटरफ़ेस को प्रभावित करता है, या केवल स्थानीय कार्यान्वयन को?
- कौन सी सख्त बाधाएं लागू होती हैं: विलंबता (latency), उपलब्धता, अनुपालन, कौशल, माइग्रेशन विंडो, या लागत?
- क्या विकल्प पहले ही तैनात (deployed) है, या ADR अभी भी Proposed स्थिति में है? इसे कौन स्वीकार या अस्वीकार कर सकता है?
- क्या ADR रिपॉजिटरी में रहेंगे, दस्तावेज़ीकरण प्रणाली में, या दोनों में? प्रभावित टीमों को अपडेट कैसे मिलेंगे?
- कौन से संकेत पुनर्मूल्यांकन को ट्रिगर करेंगे: ट्रैफ़िक, विफलता दर, लागत, या नियामक परिवर्तन?
30-सेकंड का उत्तर ढांचा
"मैं पहले यह जांचता हूं कि क्या यह विकल्प सिस्टम संरचना, प्रमुख गुणवत्ता विशेषताओं या किसी ऐसे इंटरफ़ेस को बदलता है जिसे उलटना कठिन हो। यदि ऐसा है, तो मैं एक संक्षिप्त ADR बनाता हूं। यह संदर्भ, बाधाओं, विचार किए गए विकल्पों, अस्वीकार किए गए विकल्पों, निर्णय, ट्रेड-ऑफ, जोखिमों और स्थिति को रिकॉर्ड करता है, फिर प्रभावित टीमें Proposed स्थिति के दौरान इसकी समीक्षा करती हैं। स्वीकृति के बाद मैं इसे अपरिवर्तनीय इतिहास मानता हूं; जब आवश्यकताएं बदलती हैं, तो मैं एक प्रतिस्थापित (superseding) ADR बनाता हूं, पुराने रिकॉर्ड को लिंक करता हूं और इंडेक्स को अपडेट करता हूं। मैं रिकॉर्ड को एक सुलभ वर्शन-नियंत्रित रिपॉजिटरी में रखता हूं और डिज़ाइन समीक्षाओं, कोड समीक्षाओं, ऑनबोर्डिंग और समस्या निवारण में इसका संदर्भ देता हूं।"
चरण-दर-चरण उत्तर
चरण 1: रिकॉर्डिंग थ्रेशोल्ड सेट करें
जब कोई विकल्प सिस्टम संरचना, प्रमुख गुणवत्ता विशेषताओं, सार्वजनिक इंटरफ़ेस, महत्वपूर्ण निर्भरताओं या उलटने में कठिन लागत को प्रभावित करता है, तो एक ADR बनाएं। नामकरण, एक बार के रीफैक्टर विवरण, या पहले से ही स्पष्ट मानक द्वारा शासित विकल्प के लिए आमतौर पर अपने स्वयं के रिकॉर्ड की आवश्यकता नहीं होती है। यह थ्रेशोल्ड उन निर्णयों को सुरक्षित रखता है जो दस्तावेज़ीकरण का शोर पैदा किए बिना भविष्य के तर्कों को बदल देंगे।
चरण 2: समस्या का तटस्थ रूप से वर्णन करें
समस्या, उपयोगकर्ता या व्यावसायिक प्रभाव, कार्यात्मक और गैर-कार्यात्मक आवश्यकताओं, समय सीमा और गैर-परक्राम्य बाधाओं का उल्लेख करें। संदर्भ में किसी पसंदीदा विकल्प को गुप्त रूप से शामिल न करें या तथ्यों को "टीम X ने आग्रह किया था" से न बदलें। एक नए योगदानकर्ता को यह समझ आना चाहिए कि अभी निर्णय की आवश्यकता क्यों है।
चरण 3: विकल्पों और ट्रेड-ऑफ की तुलना करें
वास्तव में विचार किए गए विकल्पों की सूची बनाएं, जिसमें अस्वीकार किए गए विकल्प और उन्हें अस्वीकार करने का कारण शामिल हो। विलंबता, उपलब्धता, ब्लास्ट रेडियस, सुरक्षा, माइग्रेशन लागत, परिचालन भार और टीम क्षमता की तुलना करें; जहां मान अनिश्चित हों, वहां धारणाएं और विश्वास का स्तर बताएं। ADR को निर्णय पर केंद्रित रखें और विस्तृत स्पाइक्स या डिज़ाइनों को अलग से लिंक करें।
चरण 4: निर्णय और परिणाम बताएं
एक ऐसा निर्णय लिखें जो अपने आप में स्पष्ट हो, जैसे "हम एक क्षेत्रीय कतार का उपयोग करेंगे और क्रॉस-रीजन फेलओवर के लिए मैन्युअल अनुमोदन स्वीकार करेंगे।" फिर अपेक्षित लाभ, लागत, जोखिम, आवश्यक नियंत्रण और प्रभावित घटकों को रिकॉर्ड करें। "विकल्प A चुनें" पर्याप्त नहीं है क्योंकि भविष्य के समीक्षक कारण या चुकाई गई कीमत को नहीं देख सकते हैं।
चरण 5: स्थिति, स्वामित्व और समीक्षा निर्धारित करें
Proposed, Accepted, Rejected, Deprecated और Superseded जैसी स्थितियों का उपयोग करें। एक स्वामी असाइन करें और Proposed स्थिति के दौरान प्रभावित टीमों को पढ़ने और टिप्पणी करने के लिए आमंत्रित करें; स्वीकृति पर तिथि, हितधारक और संस्करण जोड़ें। समीक्षा यह पुष्टि करती है कि तथ्य, बाधाएं, विकल्प और परिणाम स्पष्ट हैं, यह नहीं कि हर कोई हमेशा के लिए सहमत होगा।
चरण 6: ADR को इंजीनियरिंग वर्कफ़्लो में शामिल करें
रिपॉजिटरी या दस्तावेज़ीकरण प्रणाली के साथ ADR को वर्शन करें और एक खोजने योग्य इंडेक्स बनाए रखें। जब कोई डिज़ाइन या कोड समीक्षा स्वीकृत निर्णय के साथ विरोध करने वाले परिवर्तन को पाती है, तो ADR को लिंक करें और एक स्पष्ट परिवर्तन रिकॉर्ड की मांग करें। ऑनबोर्डिंग, हैंडऑफ़ और घटना प्रतिक्रिया को भी "इस तरह क्यों" का उत्तर देने के लिए ADR का उपयोग करना चाहिए, जिससे बार-बार होने वाली बहस कम हो सके।
चरण 7: निर्णय बदलने पर नया रिकॉर्ड जोड़ें
स्वीकृत या अस्वीकृत ADR को अपरिवर्तनीय रखें। यदि नए साक्ष्य, पैमाना, लागत या विनियमन निष्कर्ष को बदलते हैं, तो नए संदर्भ, पुरानी सीमा और नए ट्रेड-ऑफ का वर्णन करते हुए एक नया ADR लिखें। स्वीकृत होने के बाद, पुराने रिकॉर्ड को Superseded के रूप में चिह्नित करें और दोनों रिकॉर्ड को लिंक करें। यह वर्तमान निर्णय को खोजना आसान बनाते हुए इतिहास को सुरक्षित रखता है।
एक मजबूत उत्तर का उदाहरण
"मैं पहले यह जांचता हूं कि क्या यह सिस्टम संरचना, प्रमुख गुणवत्ता विशेषताओं, किसी इंटरफ़ेस या किसी अपरिवर्तनीय लागत को प्रभावित करता है; यदि यह केवल स्थानीय कार्यान्वयन है, तो मैं ADR नहीं जोड़ूंगा। एक बार जब यह थ्रेशोल्ड पूरा कर लेता है, तो मैं समस्या संदर्भ, उपयोगकर्ता और गैर-कार्यात्मक आवश्यकताओं, बाधाओं, विकल्पों, अस्वीकार किए गए विकल्पों, निर्णय, ट्रेड-ऑफ, जोखिमों और विश्वास के साथ एक Proposed रिकॉर्ड लिखता हूं।
मैं समीक्षा चर्चा से पहले प्रभावित टीमों को पढ़ने के लिए आमंत्रित करता हूं, और स्थिति, स्वामी, तिथि और हितधारकों को रिकॉर्ड करता हूं। स्वीकृति के बाद, मैं ADR को एक खोजने योग्य वर्शन-नियंत्रित रिपॉजिटरी में रखता हूं और डिज़ाइन समीक्षाओं, कोड समीक्षाओं, ऑनबोर्डिंग और समस्या निवारण में इसका संदर्भ देता हूं। यह एक संपूर्ण डिज़ाइन दस्तावेज़ को बदलने के बजाय संक्षिप्त और तथ्यात्मक रहता है।
यदि आवश्यकताएं या साक्ष्य बदलते हैं, तो मैं स्वीकृत रिकॉर्ड को संपादित नहीं करता हूं। मैं एक नया ADR बनाता हूं जिसमें बताया जाता है कि पुराना निर्णय अब उपयुक्त क्यों नहीं है, नए विकल्प क्या हैं और उनके परिणाम क्या हैं। स्वीकृति के बाद मैं पुराने रिकॉर्ड को Superseded के रूप में चिह्नित करता हूं और दोनों को लिंक करता हूं, ताकि टीम तर्क के इतिहास को खोए बिना वर्तमान विकल्प को देख सके।"
सामान्य गलतियाँ
- एक संपूर्ण डिज़ाइन गाइड लिखना → निर्णय खोजना कठिन हो जाता है → संदर्भ, विकल्प, निर्णय और परिणाम रखें; विवरणों को लिंक करें।
- केवल विजेता विकल्प को रिकॉर्ड करना → बहस बाद में दोहराई जाती है → अस्वीकार किए गए विकल्पों और उस समय की बाधाओं को शामिल करें।
- बाधाओं को व्यक्तिगत पसंद से बदलना → रिकॉर्ड की समीक्षा नहीं की जा सकती → तटस्थ, अवलोकन योग्य तथ्यों और धारणाओं का उपयोग करें।
- स्वीकृत रिकॉर्ड को सीधे संपादित करना → इतिहास गायब हो जाता है → एक नया रिकॉर्ड जोड़ें और पुराने को Superseded के रूप में चिह्नित करें।
- स्थिति और स्वामी को छोड़ना → किसी को पता नहीं होता कि यह लागू होता है या नहीं → जीवनचक्र, स्वामी और स्वीकृति तिथि को ट्रैक करें।
- ADR का कभी उल्लेख न करना → दस्तावेज़ीकरण का कोई परिचालन मूल्य नहीं रह जाता → इसे डिज़ाइन समीक्षा, कोड समीक्षा, ऑनबोर्डिंग और घटना प्रतिक्रिया से जोड़ें।
अनुवर्ती प्रश्न और उत्तर
अनुवर्ती 1: क्या असहमति होने पर भी कोई टीम ADR स्वीकार कर सकती है?
हाँ। अनसुलझे आक्षेपों, जोखिमों और निर्णय को कौन स्वीकार कर सकता है, इसे रिकॉर्ड करें। समीक्षा विकल्प और उसकी लागत को दृश्यमान बनाती है; यह स्थायी आम सहमति का निर्माण नहीं करती है। यदि साक्ष्य गायब हैं, तो ADR को Proposed रखें और एक सत्यापन कार्य निर्धारित करें।
अनुवर्ती 2: आपको ADR को बैकफ़िल कब करना चाहिए?
जब कोई मौजूदा संरचना, इंटरफ़ेस या गुणवत्ता ट्रेड-ऑफ महत्वपूर्ण हो लेकिन कोई इसे समझा न सके, तब बैकफ़िल करें। कमिट, घटना डेटा और मेंटेनर साक्षात्कारों का उपयोग करें, और परिणाम को पूर्वव्यापी (retrospective) रिकॉर्ड के रूप में लेबल करें ताकि अनुमान को समकालीन तथ्य के रूप में प्रस्तुत न किया जाए।
अनुवर्ती 3: रिपॉजिटरी या विकी?
प्रभावित कोड के पास वर्शन-नियंत्रित रिपॉजिटरी को प्राथमिकता दें ताकि रिकॉर्ड की समीक्षा कार्यान्वयन के साथ की जा सके। यदि व्यावसायिक या सुरक्षा हितधारकों को व्यापक पहुंच की आवश्यकता है, तो विचलन को रोकने के लिए एकल आधिकारिक स्रोत को बनाए रखते हुए एक इंडेक्स या सारांश को मिरर करें।
अनुवर्ती 4: आप ADR का मूल्य कैसे दिखाते हैं?
नए सदस्यों द्वारा प्रमुख विकल्पों को समझने में लगने वाले समय, दोहराई गई बहसों, समीक्षा में पाए गए स्वीकृत-निर्णय के उल्लंघनों और घटना उत्तरदाताओं को संदर्भ कितनी जल्दी मिलता है, इसे ट्रैक करें। मेट्रिक्स कमियों को उजागर करते हैं; दस्तावेज़ों की संख्या लक्ष्य नहीं है।