एक VPN डिज़ाइन ब्रीफ़ लिखें जिसकी कोई वास्तव में समीक्षा कर सके

अधिकांश डिज़ाइन समीक्षाएँ पहले प्रश्न पर अटक जाती हैं, क्योंकि अनुरोध निर्णय नहीं बल्कि उत्पाद का वर्णन करता है। जो ब्रीफ़ प्रवाह, स्वामी और विफलता व्यवहार के नाम बताती है, उसका उत्तर एक बैठक में दिया जा सकता है। जो ब्रीफ़ कहती है सुरक्षित VPN बनाएँ, उसका उत्तर ही नहीं दिया जा सकता। कुछ भी भेजने से पहले नीचे दी छह जाँचें पूरी करें, और समीक्षा बहस के बजाय तुलना बन जाती है।

पहला, क्या प्रश्न निर्णय है या इच्छा

निर्णय के पास विकल्प होते हैं और उनके बीच चुनने वाला एक अवलोकन होता है। अगर आप बता नहीं सकते कि एक चुनने के लिए आप क्या देखेंगे, तो प्रश्न अभी भी इच्छा है। पहले विकल्प लिखें, भले ही सूची में केवल दो मदें हों। फिर वह समझौता लिखें जो उन्हें अलग करता है।

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

अगर उत्तर कोई नहीं है तो यहीं रुकें, क्योंकि स्वामी के बिना निर्णय को वही फिर से बनाएगा जो सबसे ज़ोर से शिकायत करता है। यह शासन की समस्या है, डिज़ाइन की समस्या नहीं।

दूसरा, प्रवाहों और अस्वीकृतियों के नाम बताएँ

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

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

क्लाइंट और उनकी प्रबंधन स्थिति भी नोट करें, क्योंकि एजेंट वाला प्रबंधित उपकरण वे काम कर सकता है जो अपना लैपटॉप लाए उपयोगकर्ता नहीं कर सकता।

सूची को परखने के लिए इतनी छोटी रखें। दस प्रवाह जिन्हें आप सत्यापित कर सकते हैं, उन चालीस से बेहतर हैं जिन्हें नहीं कर सकते।

जाँच 3: तथ्यों को मान्यताओं से अलग करें

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

एक उदाहरण नेटवर्क ठीक है जब तक उसे लेबल किया गया हो। समस्या एक काल्पनिक शाखा है जो चुपचाप दूसरा ऊपरी लिंक या सार्वजनिक पता ब्लॉक पा लेती है जो उसके पास कभी नहीं था।

समीक्षा से पहले वह मान्यता जाँचें जिसे आप जाँच सकते हैं, क्योंकि एक मापा तथ्य चर्चा की पूरी शाखा हटा देता है।

ip route get 10.50.0.10
traceroute -n -m 6 10.50.0.10
nc -vz 10.50.0.10 443

चौथा, विफलता अनुबंध लिखें

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

फिर वैकल्पिक मार्ग तय करें: ट्रैफ़िक रोकें, उसे किसी और स्वीकृत रास्ते से भेजें, या हर अनुप्रयोग के लिए कुछ अलग करें। सीधे रास्ते पर चुपचाप लौटना एक डिज़ाइन निर्णय है, भले ही किसी ने उसे लिखा न हो।

पुनर्प्राप्ति लक्ष्य सरल भाषा में जोड़ें, जैसे कोई साइट कितने समय तक गिरी हुई स्थिति में चल सकती है और घटना की घोषणा कौन करता है।

जाँच 5 और 6: सीम चुनें और बदलाव दर्ज करें

बहस के लिए एक सीम चुनें, क्योंकि सब कुछ सुलझाने वाली समीक्षा कुछ नहीं सुलझाती। रूटिंग, प्राधिकरण और एन्क्रिप्शन तीन अलग सीम हैं, और ब्रीफ़ को बताना चाहिए कि प्रश्न किसके बारे में है। RFC 4301 यहाँ उपयोगी स्मरण है, क्योंकि यह नीति निर्णयों, संरक्षित ट्रैफ़िक और सुरक्षा संबंधों को एक वस्तु मानने के बजाय अलग करता है।

फिर निर्णय के बाद क्या बदला दर्ज करें, जिसमें संशोधित मान्यताएँ शामिल हैं। वही रिकॉर्ड अगली समीक्षा को छोटा बनाता है।

git diff --stat design/vpn-brief.md
grep -n 'assumption' design/vpn-brief.md
ip route get 10.50.0.10

जो ब्रीफ़ छहों जाँचें पार करती है वह उत्तर वाला प्रश्न बनाती है: डिज़ाइन बताए गए प्रवाहों और विफलता अनुबंध को पूरा करता है, या कोई नामित बाधा उसे रोकती है। जब बाधा बाद में बदलती है, तो रिकॉर्ड दिखाता है कि कौन सा निर्णय फिर से देखना है और कौन सा रह सकता है। यही अभ्यास को एकबारगी बहस के बजाय पुनः प्रयोग योग्य बनाता है।