आउटसोर्सिङदेखि विकाससम्म (भाग २)

В अघिल्लो लेख, मैले Veliam को सिर्जनाको पृष्ठभूमि र SaaS प्रणाली मार्फत वितरण गर्ने निर्णयको बारेमा कुरा गरें। यस लेखमा, म उत्पादनलाई स्थानीय नभई सार्वजनिक बनाउन मैले के गर्नुपर्‍यो भन्ने बारे कुरा गर्नेछु। वितरण कसरी सुरु भयो र उनीहरूले के कस्ता समस्याहरू सामना गरे भन्ने बारे।

योजना

प्रयोगकर्ताहरूको लागि हालको ब्याकइन्ड लिनक्समा थियो। लगभग हरेक संस्थासँग विन्डोज सर्भरहरू छन्, जुन लिनक्सको बारेमा भन्न सकिँदैन। Veliam को मुख्य शक्ति NAT पछि सर्भर र नेटवर्क उपकरणहरूमा रिमोट जडानहरू छन्। तर यो कार्यक्षमता राउटर Mikrotik हुनु पर्छ भन्ने तथ्यसँग धेरै कडा रूपमा बाँधिएको थियो। र यसले स्पष्ट रूपमा धेरैलाई सन्तुष्ट पार्दैन। मैले सबैभन्दा पहिले सामान्य विक्रेताहरूबाट राउटरहरूको लागि समर्थन थप्ने बारे सोच्न थालें। तर मैले बुझें कि यो समर्थित कम्पनीहरूको सूची विस्तार गर्न अनन्त दौड थियो। यसबाहेक, पहिले नै समर्थित भएकाहरूसँग NAT नियमहरू मोडेलबाट मोडेलमा परिवर्तन गर्न आदेशहरूको फरक सेट हुन सक्छ। अवस्थाबाट बाहिर निस्कने एउटै बाटो VPN जस्तो देखिन्थ्यो।

हामीले उत्पादन वितरण गर्ने निर्णय गरेकोले, तर खुला स्रोतको रूपमा होइन, GPL जस्ता खुला इजाजतपत्रहरू भएका विभिन्न पुस्तकालयहरू समावेश गर्न असम्भव भयो। यो सामान्यतया एउटा छुट्टै विषय हो; उत्पादन बेच्ने निर्णय गरेपछि, मैले आधा पुस्तकालयहरू पार गर्नुपर्‍यो किनभने तिनीहरू GPL थिए। जब तिनीहरूले आफ्नो लागि लेखे, यो सामान्य थियो। तर वितरणको लागि उपयुक्त छैन। दिमागमा आउने पहिलो VPN OpenVPN हो। तर यो GPL हो। अर्को विकल्प जापानी SoftEther VPN प्रयोग गर्नु थियो। उसको लाइसेन्सले उसलाई आफ्नो उत्पादनमा समावेश गर्न अनुमति दियो। प्रयोगकर्ताले कुनै पनि कुरा कन्फिगर गर्नु नपर्ने र SoftEther VPN बारे जान्न नपर्ने गरी यसलाई कसरी एकीकृत गर्ने भन्ने बारे केही दिनको विभिन्न परीक्षणहरू पछि, एउटा प्रोटोटाइप प्राप्त भयो। सबै कुरा जस्तो हुनुपर्छ त्यस्तै थियो। तर केही कारणले गर्दा यो योजनाले हामीलाई अझै अलमलमा पार्यो र हामीले अन्ततः यसलाई त्याग्यौं। तर स्वाभाविक रूपमा तिनीहरूले अर्को विकल्पको साथ आए पछि अस्वीकार गरे। अन्तमा, सबै कुरा नियमित TCP जडानहरूमा गरिएको थियो। केही जडानहरू एक संयोजक मार्फत काम गर्छन्, केही सीधा नेट होल पंचिंग (NHP) प्रविधि मार्फत, जुन फ्री पास्कलमा पनि लागू गरिएको थियो। मैले भन्नै पर्छ कि मैले NHP को बारेमा पहिले कहिल्यै सुनेको थिइनँ। र यो मलाई 2 नेटवर्क यन्त्रहरू जडान गर्न सम्भव छ भनेर कहिल्यै देखा परेन, जुन दुवै सीधा NAT पछाडि छन्। मैले विषय अध्ययन गरें, सञ्चालनको सिद्धान्त बुझे र लेख्न बसे। योजना साकार भएको छ, प्रयोगकर्ताले पासवर्ड प्रविष्ट नगरी वा VPN सेटअप नगरिकन RDP, SSH वा Winbox मार्फत NAT पछाडिको इच्छित उपकरणमा एक क्लिकमा जडान गर्दछ। यसबाहेक, यी धेरै जसो जडानहरू हाम्रा संयोजकहरू भन्दा बाहिर जान्छन्, जसले पिङमा राम्रो प्रभाव पार्छ र यी जडानहरू सेवा गर्ने लागत।

Linux बाट Windows मा सर्भर भाग स्थानान्तरण

विन्डोजमा स्विच गर्दा धेरै समस्याहरू थिए। पहिलो हो कि विन्डोजमा निर्मित wmic ले तपाईंलाई WQL प्रश्नहरू बनाउन अनुमति दिँदैन। र हाम्रो प्रणालीमा सबै कुरा पहिले नै तिनीहरूमा निर्माण गरिएको थियो। र त्यहाँ अरू केहि थियो, तर अब मैले बिर्सेको छु किन तिनीहरूले अन्ततः यसको प्रयोग त्यागे। सम्भवतः Windows संस्करणहरू बीच भिन्नताहरू। र दोस्रो समस्या मल्टिथ्रेडिङ हो। हाम्रो लागि "स्वीकार्य" इजाजतपत्र अन्तर्गत राम्रो तेस्रो-पक्ष उपयोगिता फेला परेन, मैले फेरि लाजरस IDE सुरु गरें। र मैले आवश्यक उपयोगिता लेखें। इनपुट भनेको वस्तुहरूको आवश्यक सूची हो र कुन विशेष प्रश्नहरू गर्न आवश्यक छ, र प्रतिक्रियामा मैले डाटा प्राप्त गर्छु। र यो सबै बहु-थ्रेडेड मोडमा। महान।

मैले PHP विन्डोजको लागि pthreads सेटअप गरेपछि, मैले सोचें कि सबै कुरा तुरुन्तै सुरु हुनेछ, तर त्यो मामला थिएन। डिबगिङको केहि समय पछि, मैले महसुस गरें कि pthreads ले काम गरेको देखिन्छ, तर यसले हाम्रो प्रणालीमा काम गर्दैन। यो स्पष्ट भयो कि विन्डोज मा pthreads संग काम मा केहि विशिष्टता छ। र त्यस्तै भयो। मैले कागजातहरू पढें, र त्यहाँ लेखिएको थियो कि विन्डोजको लागि थ्रेडहरूको संख्या सीमित छ, र जहाँसम्म मलाई याद छ, स्पष्ट रूपमा। यो समस्या बन्यो। किनभने जब मैले एप्लिकेसन चलेको थ्रेडहरूको संख्या घटाउन थालें, यसले काम धेरै बिस्तारै गर्यो। मैले IDE फेरि खोलें र वस्तुहरूको बहु-थ्रेडेड पिंगिङको लागि कार्यक्षमता समान उपयोगितामा थपियो। खैर, त्यहाँ पहिले नै धेरै पोर्ट स्क्यानिङ पनि छ। वास्तवमा, यस पछि, PHP को लागि pthreads को आवश्यकता गायब भयो, र यो अब प्रयोग गरिएको छैन। यसबाहेक, यस उपयोगितामा धेरै थप कार्यक्षमताहरू थपिएका थिए र यो अझै पनि काम गर्दछ। यस पछि, विन्डोजको लागि एक स्थापनाकर्ता भेला भयो, जसमा Apache, PHP, MariaDB, PHP अनुप्रयोग आफैं र प्रणालीसँग अन्तरक्रिया गर्नका लागि उपयोगिताहरूको सेट समावेश थियो, नि: शुल्क पास्कलमा लेखिएको। स्थापनाकर्ताको लागि, मैले सोचे कि म यो समस्या छिट्टै समाधान गर्नेछु, किनकि ... यो एक धेरै सामान्य कुरा हो र लगभग हरेक सफ्टवेयर को लागी आवश्यक छ। या त म गलत ठाउँमा हेरिरहेको थिएँ, वा अरू केहि। तर मैले लगातार उत्पादनहरू भेटें जुन या त पर्याप्त लचिलो थिएनन्, वा महँगो र लचिलो पनि थिए। र अझै, मैले एक नि: शुल्क स्थापनाकर्ता फेला पारे जसमा कुनै पनि इच्छाहरू प्रदान गर्न सम्भव हुनेछ। यो InnoSetup हो। म यस बारे यहाँ लेख्दैछु किनकि मैले कसैको समय बचत गरेको खण्डमा यसलाई हेर्नुपर्‍यो।

तपाईंको ग्राहकको पक्षमा प्लगइनको अस्वीकार

मैले पहिले लेखेको थिए कि क्लाइन्ट भाग "प्लगइन" को साथ ब्राउजर थियो। त्यसोभए त्यहाँ समयहरू थिए जब क्रोम अपडेट गरिएको थियो र लेआउट थोरै बाङ्गो थियो, त्यसपछि विन्डोज अद्यावधिक गरिएको थियो र अनुकूलन यूरी योजना गायब भयो। म वास्तवमै उत्पादनको सार्वजनिक संस्करणमा यी प्रकारका आश्चर्यहरू लिन चाहन्न। यसबाहेक, प्रत्येक विन्डोज अपडेट पछि अनुकूलन uri गायब हुन थाल्यो। माइक्रोसफ्टले आवश्यक खण्डमा सबै गैर-शाखाहरू मेटाइयो। साथै, गुगल क्रोमले अब तपाइँलाई कस्टम uri बाट एप्लिकेसन खोल्ने वा नगर्ने छनोट सम्झन अनुमति दिदैन, र तपाइँले अनुगमन गर्ने वस्तुमा क्लिक गर्दा यो प्रश्न सोध्छ। खैर, सामान्यतया, प्रयोगकर्ताको स्थानीय प्रणालीसँग सामान्य अन्तरक्रिया आवश्यक थियो, जुन ब्राउजरले प्रदान गर्दैन। यस योजनामा ​​​​सबैभन्दा सरल विकल्प भनेको तपाईको आफ्नै ब्राउजर बनाउनु जस्तो देखिन्छ, जस्तै धेरैले अहिले इलेक्ट्रोन मार्फत गरिरहेका छन्। तर धेरै कुराहरू पहिले नै नि: शुल्क पास्कलमा लेखिएको थियो, सर्भरको भाग सहित, त्यसैले हामीले ग्राहकलाई एउटै भाषामा बनाउने निर्णय गर्यौं, र चिडियाखाना सिर्जना नगर्ने निर्णय गर्यौं। यसरी बोर्डमा क्रोमियम भएको ग्राहक लेखिएको थियो। त्यस पछि, यो विभिन्न strappings प्राप्त गर्न थाले।

रिलिज

अन्तमा हामीले प्रणालीको लागि नाम रोज्यौं। स्थानीय संस्करणबाट SaaS मा रूपान्तरण गर्ने प्रक्रिया चलिरहेको बेला हामीले निरन्तर विभिन्न विकल्पहरू मार्फत गयौं। हामीले प्रारम्भिक रूपमा घरेलु बजारमा मात्र प्रवेश गर्ने योजना बनाएका छैनौं, नाम छनोट गर्ने मुख्य मापदण्ड ".com" क्षेत्रमा एक खाली वा धेरै महँगो डोमेनको उपस्थिति थियो। केही प्रकार्यहरू/मोड्युलहरू अझै स्थानीय संस्करणबाट Veliam मा पोर्ट गरिएको छैन, तर हामीले निर्णय गर्यौं कि हामी तिनीहरूलाई हालको कार्यक्षमतासँग जारी गर्नेछौं र बाँकीलाई अद्यावधिकको रूपमा पूरा गर्नेछौं। पहिलो संस्करणमा त्यहाँ कुनै हेल्पडेस्क, Veliam कनेक्टर थिएन, सूचना ट्रिगरहरू र अधिकका लागि थ्रेसहोल्डहरू परिवर्तन गर्न असम्भव थियो। हामीले कोड साइन प्रमाणपत्र किन्यौं र ग्राहक र सर्भर भागहरूमा हस्ताक्षर गर्यौं। हामीले उत्पादनको लागि वेबसाइट लेख्यौं, सफ्टवेयर दर्ता गर्ने प्रक्रिया सुरु गर्‍यौं, ट्रेडमार्क, आदि। सामान्यतया, हामी सुरु गर्न तयार छौं। गरेको कामबाट थोरै उत्साह र यस तथ्यबाट कि कसैले तपाइँको उत्पादन प्रयोग गर्नेछ, यद्यपि हामीलाई यस बारे कुनै शंका थिएन। र त्यसपछि रोक्नुहोस्। साझेदारले भने कि मेसेन्जर मार्फत सूचनाहरू बिना बजारमा प्रवेश गर्न असम्भव छ। यो धेरै अन्य चीजहरू बिना सम्भव छ, तर यो बिना होइन। केही बहस पछि, टेलिग्रामसँग एकीकरण थपियो, जुन हामीलाई उपयुक्त थियो। सबै हालको इन्स्ट्यान्ट मेसेन्जरहरू मध्ये, यो एक मात्र हो जसले यसको API हरूमा नि:शुल्क र कुनै जटिल अनुमोदन प्रक्रियाहरू बिना पहुँच प्रदान गर्दछ। उही व्हाट्सएपले आफ्ना सेवाहरू प्रयोग गर्नका लागि राम्रो पैसा लिने प्रदायकहरूलाई सम्पर्क गर्न सुझाव दिन्छ; ग्यास्केट बिना पहुँचको लागि सोध्ने सबै पत्रहरूलाई बेवास्ता गरियो। खैर, भाइबर... अहिले कसले प्रयोग गर्छ मलाई थाहा छैन, किनभने... स्प्याम र विज्ञापन त्यहाँ चार्ट बन्द छन्। डिसेम्बरको अन्त्यमा, साथीहरू बीचको आन्तरिक परीक्षण र परीक्षणहरूको श्रृंखला पछि, सबैका लागि दर्ता खोलियो र सफ्टवेयर डाउनलोडको लागि उपलब्ध गराइयो।

वितरणको सुरुवात

सुरुदेखि नै, हामीले बुझ्यौं कि हामीलाई प्रणाली प्रयोगकर्ताहरूको सानो प्रवाह चाहिन्छ ताकि तिनीहरूले लडाई मोडमा उत्पादनको परीक्षण गर्न सकून् र केही पहिलो प्रतिक्रिया दिन सकून्। VK बोर फलमा धेरै खरिद गरिएका पोष्टहरू। पहिलो दर्ताहरू आइसकेका छन्।

यहाँ यो भन्नु पर्छ कि जब तपाइँको कम्पनी को एक प्रसिद्ध नाम छैन जब बजार मा प्रवेश गर्न को लागी, र एकै समयमा एजेन्टलेस निगरानी कार्यक्षमता प्रदान गर्दछ जसमा तपाइँ तपाइँको सर्भर र कार्यस्थानहरु बाट खाताहरू प्रविष्ट गर्न आवश्यक छ, धेरै गाह्रो छ। यसले धेरै मानिसहरूलाई डराउँछ। हामीले सुरुदेखि नै यससँग समस्याहरू हुनेछन् भन्ने बुझेका थियौं र प्राविधिक र नैतिक रूपमा यसका लागि तयार थियौं। सबै रिमोट जडानहरू, RDP र SSH पहिले नै पूर्वनिर्धारित रूपमा इन्क्रिप्ट गरिएको तथ्यको बावजुद, AES मानक प्रयोग गरेर हाम्रो सफ्टवेयरद्वारा थप रूपमा इन्क्रिप्ट गरिएको छ। स्थानीय सर्भरबाट सबै डाटा HTTPS मार्फत क्लाउडमा स्थानान्तरण गरिन्छ। खाताहरू इन्क्रिप्टेड फारममा भण्डारण गरिएका छन्। सबै उपप्रणालीहरूका लागि गुप्तिकरण कुञ्जीहरू सबै ग्राहकहरूको लागि व्यक्तिगत हुन्। रिमोट जडानहरूको लागि, सत्र इन्क्रिप्सन कुञ्जीहरू सामान्यतया प्रयोग गरिन्छ।

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

धेरैको लागि, सफ्टवेयरको सुविधा र कार्यक्षमताले डरलाई पछाडी पार्छ, र तिनीहरू दर्ता हुन्छन्। केही व्यक्तिहरूले VK मा प्रकाशित पोष्टहरूमा लेखेका थिए कि यो सफ्टवेयर प्रयोग गर्न सकिँदैन किनभने यो तिनीहरूको पासवर्डहरूको सङ्कलन हो र सामान्यतया कुनै नाम नभएको कम्पनी हो। यो भन्नु पर्छ कि एक भन्दा बढी व्यक्तिहरु यो राय थियो। धेरै मानिसहरूले सजिलै बुझ्दैनन् कि तिनीहरूले सेवाको रूपमा चल्ने सर्भरमा अन्य स्वामित्व सफ्टवेयर स्थापना गर्दा, यसको प्रणालीमा पूर्ण अधिकारहरू पनि छन् र उनीहरूलाई कुनै गैरकानूनी गर्नका लागि खाताहरू आवश्यक पर्दैन (यो स्पष्ट छ कि तपाइँ परिवर्तन गर्न सक्नुहुन्छ। प्रयोगकर्ता जसबाट सेवा सुरु गरिएको छ, तर यहाँ पनि, तपाइँ कुनै पनि खाता प्रविष्ट गर्न सक्नुहुन्छ)। वास्तवमा, मानिसहरूको डर बुझ्न सकिन्छ। सर्भरमा सफ्टवेयर स्थापना गर्नु सामान्य कुरा हो, तर खाता प्रविष्ट गर्नु अलि डरलाग्दो र घनिष्ट छ, किनकि राम्रो आधा मानिसहरूसँग सबै सेवाहरूको लागि एउटै पासवर्ड हुन्छ, र परीक्षणको लागि पनि छुट्टै खाता बनाउन अल्छी हुन्छ। तर यस समयमा त्यहाँ धेरै संख्यामा सेवाहरू छन् जुन मानिसहरूले उनीहरूको प्रमाणहरू र थपको साथ विश्वास गर्छन्। र हामी ती मध्ये एक बन्न कोसिस गर्छौं।

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

हामीले अब EV कोड साइन प्रमाणपत्र प्राप्त गर्ने प्रक्रिया पूरा गरेका छौं। यसलाई प्राप्त गर्नको लागि, तपाईंले चेकहरूको एक श्रृंखला मार्फत जानु पर्छ र कम्पनीको बारेमा कागजातहरूको गुच्छा पठाउनु पर्छ, जसमध्ये केही वकिलद्वारा प्रमाणित हुनुपर्छ। महामारीको बेला EV कोड साइन प्रमाणपत्र प्राप्त गर्नु एउटा लेखको लागि छुट्टै विषय हो। प्रक्रिया एक महिना लाग्यो। र यो प्रतिक्षाको महिना होइन, तर थप कागजातहरूको लागि निरन्तर अनुरोधहरूको थियो। सायद महामारीसँग यसको कुनै सरोकार थिएन, र प्रक्रियाले सबैको लागि यति लामो समय लियो? सेयर गर्नुहोस्।

FSTEC सर्टिफिकेट नभएकाले हामी यसलाई प्रयोग गर्दैनौं भनी केही भन्छन्। हामीले यसलाई प्राप्त गर्न सक्दैनौं र यो प्रमाणपत्र प्राप्त गर्न सक्दैनौं भनेर व्याख्या गर्नुपर्दछ, इन्क्रिप्सन GOST अनुसार हुनुपर्छ, र हामीले सफ्टवेयरलाई रूसमा मात्र वितरण गर्ने र AES प्रयोग गर्ने योजना बनाएका छौं।

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

कर्मचारीहरूको लागि रिमोट पहुँच कार्यक्षमता थप्दै

ग्राहकहरुबाट बारम्बार कार्यहरू मध्ये एक "वान्यालाई घरबाट आफ्नो कम्प्युटरमा पहुँच दिनुहोस्।" हामीले Mikrotik मा VPN उठायौं र प्रयोगकर्ताहरूको लागि खाताहरू सिर्जना गर्यौं। तर यो एक वास्तविक समस्या हो। प्रयोगकर्ताहरूले निर्देशनहरू हेर्न र VPN मार्फत जडान गर्न चरण-दर-चरण पालना गर्न सक्षम छैनन्। विन्डोजको विभिन्न संस्करणहरू। एउटा विन्डोजमा सबै कुरा राम्रोसँग जडान हुन्छ, अर्कोमा फरक प्रोटोकल चाहिन्छ। र सामान्यतया, यो सँधै नेटवर्क उपकरणको पुन: कन्फिगरेसनसँग सम्बन्धित थियो, जसले VPN सर्भरको रूपमा काम गर्‍यो, र सबै कर्मचारीहरूले यसमा पहुँच गर्दैनन् र यो असुविधाजनक थियो।

तर हामीसँग पहिले नै सर्भर र नेटवर्क उपकरणहरूमा टाढाको जडानहरू छन्। किन तयार पारिएको यातायात प्रयोग नगर्नुहोस् र एक अलग सानो उपयोगिता बनाउनुहोस् जुन तपाईले प्रयोगकर्तालाई जडान गर्न दिन सक्नुहुन्छ। म केवल यो सुनिश्चित गर्न चाहान्छु कि प्रयोगकर्ताले त्यहाँ कुनै पनि अप्रत्याशित प्रविष्टि गरेको छैन। केवल एक बटन "जडान"। तर यो उपयोगिताले एक बटन मात्र छ भने कहाँ जडान गर्ने भनेर कसरी बुझ्छ? हाम्रो सर्भरहरूमा आवश्यक अनुप्रयोग अनलाइन निर्माण गर्ने विचार थियो। प्रणाली प्रशासकले "डाउनलोड सर्टकट" बटनमा क्लिक गर्दछ, र RDP मार्फत वांछित सर्भर/कम्प्युटरमा जडान गर्नको लागि हार्डवायर जानकारीको साथ व्यक्तिगत बाइनरी निर्माण गर्न हाम्रो क्लाउडमा आदेश पठाइन्छ। सामान्य मा, यो गर्न सकिन्छ। तर यसले लामो समय लिन्छ; बाइनरी कम्पाइल र त्यसपछि डाउनलोड नभएसम्म प्रशासकले पहिले कुर्नु पर्छ। अवश्य पनि, कन्फिगरेसनको साथ दोस्रो फाइल थप्न सम्भव हुनेछ, तर यो पहिले नै २ फाइलहरू छन्, र सरलताका लागि प्रयोगकर्तालाई एउटा चाहिन्छ। एउटा फाइल, एउटा बटन र कुनै स्थापनाकर्ताहरू छैनन्। गुगलमा थोरै पढेपछि, म निष्कर्षमा पुगें कि यदि तपाईंले कम्पाइल गरिएको ".exe" को अन्त्यमा केही जानकारी थप्नुभयो भने, यो बिग्रदैन (राम्रो, लगभग)। तपाईं कम्तिमा त्यहाँ युद्ध र शान्ति थप्न सक्नुहुन्छ, र यो पहिले जस्तै काम गर्नेछ। यसको फाइदा नलिनु पाप हो। अब तपाइँ केवल क्लाइन्टमा नै, यसलाई Veliam Connector भनिन्छ, र अन्तमा जडान गर्नको लागि आवश्यक जानकारी थप्नको लागि, क्लाइन्टमा नै अनुप्रयोगलाई अनप्याक गर्न सक्नुहुन्छ। र अनुप्रयोग आफैलाई थाहा छ यसको साथ के गर्ने। मैले किन अलि माथि कोष्ठकहरूमा "लगभग राम्रो" लेखें? किनकी तपाईले यस सुविधाको लागि तिर्नुपर्नेछ कि अनुप्रयोगले यसको डिजिटल हस्ताक्षर गुमाउँछ। तर यस चरणमा, हामी विश्वास गर्छौं कि यस्तो सुविधाको लागि भुक्तान गर्न यो सानो मूल्य हो।

तेस्रो पक्ष मोड्युल इजाजतपत्रहरू

मैले पहिले नै माथि लेखेको छु कि उत्पादनलाई सार्वजनिक रूपमा उपलब्ध गराउने निर्णय गरिसकेपछि, र हाम्रो आफ्नै प्रयोगको लागि मात्र होइन, हामीले कडा परिश्रम गर्नुपर्‍यो र केही मोड्युलहरूका लागि प्रतिस्थापनहरू खोज्नुपर्‍यो जसले हामीलाई हाम्रो उत्पादनमा समावेश गर्न अनुमति दिँदैन। तर रिलीज पछि, एक धेरै अप्रिय कुरा संयोगवश पत्ता लाग्यो। Veliam सर्भर, जुन ग्राहक पक्षमा थियो, मारियाडीबी DBMS समावेश थियो। र यो GPL लाइसेन्स छ। GPL इजाजतपत्रले सफ्टवेयर खुला स्रोत हुनुपर्छ भनेर संकेत गर्छ, र यदि हाम्रो उत्पादनमा MariaDB समावेश छ, जसमा यो इजाजतपत्र छ भने, हाम्रो उत्पादन यो इजाजतपत्र अन्तर्गत हुनुपर्छ। तर सौभाग्यवश, यस इजाजतपत्रको उद्देश्य खुला स्रोत हो, अदालतमा गल्तिले गल्ती गर्नेहरूलाई सजाय दिनु होइन। यदि प्रतिलिपि अधिकार धारकसँग दावी छ भने, उसले उल्लङ्घनकर्तालाई लिखित रूपमा सूचित गर्दछ र उसले 30 दिन भित्र उल्लङ्घन हटाउनु पर्छ। हामीले हाम्रो गल्ती आफैं पत्ता लगायौं र कुनै पत्र प्राप्त गरेनौं र तुरुन्तै समस्या कसरी समाधान गर्ने भन्ने विकल्पहरू विचार गर्न थाल्यौं। समाधान स्पष्ट भयो - SQLite मा स्विच गर्नुहोस्। यस डाटाबेसमा कुनै इजाजतपत्र प्रतिबन्ध छैन। धेरैजसो आधुनिक ब्राउजरहरूले SQLite र अन्य कार्यक्रमहरूको गुच्छा प्रयोग गर्छन्। मैले इन्टरनेटमा जानकारी फेला पारे कि SQLite संसारमा सबैभन्दा व्यापक DBMS मानिन्छ, ठीक ब्राउजरहरूको कारणले, तर मैले प्रमाण खोजेको छैन, त्यसैले यो गलत जानकारी हो। मैले SQLite मा स्विच गर्ने खतराहरू अध्ययन गर्न थाले।

यो एक गैर-तुच्छ कार्य हुन्छ जब क्लाइन्टहरूसँग मारियाडीबी र यसमा डाटासँग धेरै सय सर्भरहरू स्थापना हुन्छन्। केही MariaDB सुविधाहरू SQLite मा उपलब्ध छैनन्। खैर, उदाहरण को लागी, कोड मा हामीले प्रश्नहरु जस्तै प्रयोग गर्यौं

Select * FROM `table` WHERE `id`>1000 FOR UPDATE

यो निर्माणले तालिकाबाट मात्र चयन गर्दैन, तर पङ्क्ति डेटा लक पनि गर्दछ। र धेरै थप डिजाइनहरू पनि पुन: लेख्नु पर्यो। तर यस तथ्यको अतिरिक्त कि हामीले धेरै प्रश्नहरू पुन: लेख्नुपर्‍यो, हामीले एउटा मेकानिजम पनि ल्याउनुपर्‍यो जुन ग्राहकको Veliam सर्भर अपडेट गर्दा, सबै डाटालाई नयाँ DBMS मा पोर्ट गर्ने र पुरानो मेटाउनेछ। साथै, SQLite मा लेनदेन काम गरेन र यो एक वास्तविक समस्या थियो। तर वर्ल्ड वाइड वेबको विशालता पढेपछि, मैले कुनै समस्या बिना नै पत्ता लगाएँ कि SQLite मा लेनदेनहरू जडान गर्दा साधारण आदेश पास गरेर सक्षम गर्न सकिन्छ।

PRAGMA journal_mode=WAL;

नतिजाको रूपमा, कार्य पूरा भयो र अब ग्राहकको सर्भर भाग SQLite मा चल्छ। हामीले प्रणालीको सञ्चालनमा कुनै परिवर्तनहरू याद गरेनौं।

नयाँ हेल्पडेस्क

हेल्पडेस्क प्रणालीलाई आन्तरिक संस्करणबाट सास संस्करणमा पोर्ट गर्न आवश्यक थियो, तर केही परिवर्तनहरू सहित। मैले गर्न चाहेको पहिलो कुरा भनेको प्रणालीमा पारदर्शी प्रयोगकर्ता प्राधिकरणको सर्तमा ग्राहकको डोमेनसँग एकीकरण थियो। अब, हेल्पडेस्कमा लग इन गर्न र प्रणालीमा अनुरोध छोड्नको लागि, प्रयोगकर्ताले डेस्कटपमा सर्टकटमा क्लिक गर्दछ र ब्राउजर खुल्छ। प्रयोगकर्ताले कुनै पनि प्रमाणहरू प्रविष्ट गर्दैन। Apache SSPI को लागि मोड्युल, जो Veliam Server को भाग हो, स्वचालित रूपमा प्रयोगकर्तालाई डोमेन खाता अन्तर्गत अधिकृत गर्दछ। प्रयोगकर्ता कर्पोरेट नेटवर्क बाहिर हुँदा प्रणालीमा अनुरोध छोड्न, उसले बटनमा क्लिक गर्दछ र उसले आफ्नो इमेलमा एउटा लिङ्क प्राप्त गर्दछ जसको माध्यमबाट उसले पासवर्ड बिना हेल्पडेस्क प्रणालीमा लग इन गर्दछ। यदि कुनै प्रयोगकर्तालाई डोमेनमा असक्षम वा मेटाइएको छ भने, हेल्पडेस्क खाताले पनि काम गर्न छोड्नेछ। तसर्थ, प्रणाली प्रशासकले दुवै डोमेन र हेल्पडेस्क आफैंमा खाताहरू निगरानी गर्न आवश्यक छैन। एक कर्मचारीले छोड्छ - उसले डोमेनमा आफ्नो खाता विच्छेद गर्दछ र त्यो हो, उसले प्रणालीमा लग इन गर्ने छैन कर्पोरेट नेटवर्कबाट, लिङ्क मार्फत होइन। यो एकीकरणले काम गर्नको लागि, प्रणाली प्रशासकले एउटा GPO सिर्जना गर्न आवश्यक छ, जुन इन्ट्रानेट जोनमा आन्तरिक साइट थप्छ и डेस्कटपमा सबै प्रयोगकर्ताहरूलाई सर्टकट वितरण गर्दछ.

हामीले हेल्पडेस्क प्रणालीहरूका लागि अत्यन्त आवश्यक ठानेको दोस्रो कुरा, कम्तिमा आफ्नो लागि, एक क्लिकमा आवेदनबाट सिधै आवेदकसँग जडान हुनु हो। यसबाहेक, यदि प्रणाली प्रशासक फरक नेटवर्कमा छ भने जडानहरू पास हुनुपर्छ। आउटसोर्सिङको लागि यो अनिवार्य छ, पूर्ण-समय प्रणाली प्रशासकहरूको लागि यो अक्सर धेरै आवश्यक छ। त्यहाँ पहिले नै धेरै उत्पादनहरू छन् जुन रिमोट जडानहरूको उत्कृष्ट काम गर्दछ। र हामीले उनीहरूका लागि एकीकरण गर्ने निर्णय गर्यौं। हामीले अब VNC का लागि एकीकृत गरेका छौं, र भविष्यमा हामी Radmin र TeamViewer थप्ने योजनामा ​​छौं। रिमोट इन्फ्रास्ट्रक्चर जडानहरूको लागि हाम्रो नेटवर्क यातायात प्रयोग गरेर, हामीले NAT पछाडि टाढाको कार्यस्थानहरूमा VNC जडान बनायौं। Radmin को साथ पनि त्यस्तै हुनेछ। अब, प्रयोगकर्तासँग जडान हुनको लागि, तपाईंले आवेदनमा नै "आवेदकसँग जडान गर्नुहोस्" बटन क्लिक गर्न आवश्यक छ। तपाईं एउटै नेटवर्कमा हुनुहुन्छ वा चप्पल लगाएर घरमा बसिरहनुभएको भए तापनि VNC क्लाइन्ट खोल्छ र आवेदकसँग जडान हुन्छ। पहिले, GPO प्रयोग गरी प्रणाली प्रशासकले सबैको कार्यस्थानहरूमा VNC सर्भर स्थापना गर्नुपर्छ।

अब हामी आफैं नयाँ हेल्पडेस्कमा स्विच गर्दैछौं र डोमेन र VNC सँग एकीकरण प्रयोग गर्दैछौं। यो हाम्रो लागि धेरै सुविधाजनक छ। अब हामी TeamViewer को लागी भुक्तान गर्नबाट बच्न सक्छौं, जुन हामीले हाम्रो समर्थन सेवा चलाउनको लागि तीन वर्ष भन्दा बढि प्रयोग गर्दै आएका छौं।

हामी अब के गर्ने योजनामा ​​छौं?

जब हामीले उत्पादन जारी गर्यौं, हामीले कुनै भुक्तान शुल्कहरू बनाएनौं, तर नि: शुल्क ट्यारिफलाई 50 निगरानी वस्तुहरूमा सीमित गर्यौं। पाँच दर्जन नेटवर्क उपकरणहरू र सर्भरहरू सबैका लागि पर्याप्त हुनुपर्छ, हामीले सोचे। र त्यसपछि सीमा बढाउन अनुरोधहरू आउन थाले। हामी अलिकति स्तब्ध भयौं भन्नु भनेको केही भन्नु हो। के धेरै सर्भरहरू भएका कम्पनीहरू हाम्रो सफ्टवेयरमा साँच्चै रुचि राख्छन्? हामीले त्यस्ता अनुरोध गर्नेहरूको लागि सित्तैमा सीमा बढाएका छौं। तिनीहरूको अनुरोधको जवाफमा, हामीले कसैलाई सोध्यौं किन उनीहरूलाई यति धेरै आवश्यक छ, के तिनीहरूसँग यति ठूलो संख्यामा सर्भरहरू र नेटवर्क उपकरणहरू छन्। र यो पत्ता लाग्यो कि प्रणाली प्रशासकहरूले हामीले योजना नगरेको तरिकामा प्रणाली प्रयोग गर्न थाले। सबै कुरा सरल भयो - हाम्रो सफ्टवेयरले सर्भर मात्र होइन, तर कार्यस्थानहरू पनि निगरानी गर्न थाल्यो। त्यसैले सीमा विस्तार गर्न धेरै अनुरोधहरू छन्। अब हामीले भुक्तान शुल्कहरू पेश गरिसकेका छौं र सीमाहरू स्वतन्त्र रूपमा विस्तार गर्न सकिन्छ।

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

Veliam Connector को आगमन संग, यो कर्पोरेट नेटवर्क मा VPN सर्भर तैनात गर्न को लागी अनावश्यक भयो, वा RDGW गर्न, वा केवल RDP मार्फत जडान गर्न को लागी आवश्यक मेशिनहरुमा पोर्टहरु लाई फर्वार्ड गर्न को लागी। धेरै मानिसहरूले यी रिमोट जडानहरूको लागि मात्र हाम्रो प्रणाली प्रयोग गर्छन्। Veliam Connector Windows को लागि मात्र उपलब्ध छ, र केहि कम्पनी प्रयोगकर्ताहरूले MacOS चलिरहेको घर ल्यापटपहरूबाट कार्यस्थान वा कर्पोरेट नेटवर्कमा टर्मिनलहरूमा जडान गर्छन्। र यो बाहिर जान्छ कि प्रणाली प्रशासक बाध्य छ, धेरै प्रयोगकर्ताहरूको कारण, अझै पनि फर्वार्डिङ वा VPN को मुद्दामा फर्कन। तसर्थ, हामी अब MacOS को लागि Veliam Connector को संस्करण बनाउन सकिरहेका छौं। आफ्नो मनपर्ने एप्पल प्रविधिका प्रयोगकर्ताहरूले एक क्लिकमा कर्पोरेट पूर्वाधारमा जडान गर्ने अवसर पनि पाउनेछन्।

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

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

स्रोत: www.habr.com