क्या दफ़्तर के VPN के लिए Raspberry Pi काफ़ी है? काम तय करें

चार गीगाबाइट का Raspberry Pi मशीन का विवरण है, दफ़्तर की ज़रूरत नहीं। यह कुछ दूर के उपयोगकर्ताओं की अच्छी सेवा कर सकता है, और जिस पहली दोपहर कोई टनल से बड़ी फ़ाइल कॉपी करेगा उसी में यह ढह सकता है। मेमरी का आँकड़ा नहीं बता सकता कि इन दोनों में से क्या होगा। ख़रीद को स्वीकृति परीक्षण में बदलना उस अनिश्चितता को ऐसे नतीजे से बदल देता है जिसका आप बचाव कर सकें।

सवाल को स्वीकृति परीक्षण में बदलें

स्वीकृति परीक्षण किसी भी हार्डवेयर के आने से पहले काम, शर्तें और पास होने की सीमा का नाम लेता है। VPN गेटवे के लिए काम साथ-साथ चलने वाली गतिविधियों का समूह है, और शर्तें उसमें शामिल रास्ते और सेवाएँ हैं। पास होने की सीमा वह है जिसे उपयोगकर्ता उपयोगी कहेगा, वह नहीं जो कोई बेंचमार्क बताता है। तीनों के बिना किसी आँकड़े के पीछे कोई दावा नहीं होता।

परीक्षण ऐसे लिखें कि कोई दूसरा उसे चला सके। यही एक सीमा उन अधिकांश धुँधले मानदंडों को हटा देती है जिनकी वजह से ये फ़ैसले हफ़्तों तक खिंचते हैं। यह नतीजे को तब तुलनीय भी बनाती है जब अगली समीक्षा आती है।

नतीजा Raspberry Pi, कोई और उपकरण या प्रबंधित सेवा को उचित ठहरा सकता है। तीनों एक ही सवाल के जायज़ जवाब हैं। परीक्षण इनके बीच फ़ैसला करता है, और विनिर्देश पत्रक नहीं।

काम लिखें, लोगों की संख्या नहीं

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

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

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

जोड़े गए उपकरण को मापें

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

उन सेवाओं को शामिल करें जो बोर्ड साझा करेंगी। DNS फ़िल्टरिंग, निगरानी या भंडारण सभी एक ही प्रोसेसर और मेमरी के लिए होड़ करते हैं, और अकेले मापा गया गेटवे वह गेटवे नहीं है जिसे आप चलाएँगे।

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

हार्डवेयर से पहले रुकावट का बजट तय करें

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

अगर व्यवस्थापक गेटवे तक सिर्फ़ उसी टनल से पहुँचता है, तो एक स्वतंत्र वापसी मार्ग की योजना बनाएँ। जिस अतिरिक्त बोर्ड की संरचना और कुंजियाँ बहाल नहीं की जा सकतीं और जिसका कोई मालिक नहीं, वह वापसी योजना नहीं है।

टीम का नहीं, व्यक्ति का नाम लें। जो वापसी किसी समूह पर निर्भर है वह ऐसी वापसी है जो समूह के उपलब्ध होने का इंतज़ार करती है। नाम ही योजना को जाँचने योग्य बनाता है।

पास होने वाली सबसे छोटी प्रणाली चुनें

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

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