आउटसोर्सिंगपासून विकासापर्यंत (भाग २)

В मागील लेख, मी Veliam च्या निर्मितीची पार्श्वभूमी आणि SaaS प्रणालीद्वारे त्याचे वितरण करण्याच्या निर्णयाबद्दल बोललो. या लेखात, मी उत्पादन स्थानिक नसून सार्वजनिक करण्यासाठी मला काय करावे लागले याबद्दल बोलेन. वितरण कसे सुरू झाले आणि त्यांना कोणत्या समस्या आल्या याबद्दल.

नियोजन

वापरकर्त्यांसाठी सध्याचा बॅकएंड लिनक्सवर होता. जवळजवळ प्रत्येक संस्थेमध्ये विंडोज सर्व्हर असतात, जे लिनक्सबद्दल सांगता येत नाही. Veliam चे मुख्य सामर्थ्य NAT च्या मागे सर्व्हर आणि नेटवर्क उपकरणांना रिमोट कनेक्शन आहे. परंतु ही कार्यक्षमता अगदी घट्टपणे बांधली गेली होती की राउटर मिक्रोटिक असावा. आणि हे स्पष्टपणे अनेकांचे समाधान करणार नाही. मी प्रथम सर्वात सामान्य विक्रेत्यांकडून राउटरसाठी समर्थन जोडण्याचा विचार सुरू केला. परंतु मला समजले की समर्थित कंपन्यांची यादी विस्तृत करण्याची ही एक अंतहीन शर्यत आहे. शिवाय, जे आधीपासून समर्थित आहेत त्यांच्याकडे मॉडेल ते मॉडेल बदलण्यासाठी NAT नियमांचा भिन्न संच असू शकतो. परिस्थितीतून बाहेर पडण्याचा एकमेव मार्ग व्हीपीएन असल्याचे दिसत होते.

आम्ही उत्पादन वितरीत करण्याचा निर्णय घेतल्याने, परंतु मुक्त स्त्रोत म्हणून नाही, GPL सारख्या खुल्या परवान्यासह विविध लायब्ररी समाविष्ट करणे अशक्य झाले. हा साधारणपणे एक वेगळा विषय आहे; उत्पादन विकण्याचा निर्णय घेतल्यानंतर, मला अर्ध्या लायब्ररीतून जावे लागले कारण ते GPL होते. जेव्हा त्यांनी स्वतःसाठी लिहिले तेव्हा ते सामान्य होते. पण वितरणासाठी योग्य नाही. मनात येणारा पहिला VPN म्हणजे OpenVPN. पण ते GPL आहे. दुसरा पर्याय म्हणजे जपानी सॉफ्टइथर व्हीपीएन वापरणे. त्याच्या परवान्याने त्याला त्याच्या उत्पादनात समाविष्ट करण्याची परवानगी दिली. वापरकर्त्याला काहीही कॉन्फिगर करण्याची आणि SoftEther VPN बद्दल जाणून घेण्याची आवश्यकता नाही अशा प्रकारे ते कसे समाकलित करायचे याच्या काही दिवसांच्या विविध चाचण्यांनंतर, एक प्रोटोटाइप प्राप्त झाला. सर्व काही जसे असावे तसे होते. परंतु काही कारणास्तव या योजनेने अजूनही आम्हाला गोंधळात टाकले आणि अखेरीस आम्ही ते सोडून दिले. पण साहजिकच त्यांनी दुसरा पर्याय आणल्यानंतर त्यांनी नकार दिला. शेवटी, सर्व काही नियमित TCP कनेक्शनवर केले गेले. काही कनेक्शन्स समन्वयकाद्वारे, काही थेट नॅट होल पंचिंग (NHP) तंत्रज्ञानाद्वारे कार्य करतात, जे फ्री पास्कलमध्ये देखील लागू केले गेले होते. मला असे म्हणायचे आहे की मी यापूर्वी कधीही NHP बद्दल ऐकले नव्हते. आणि मला असे कधीच वाटले नाही की 2 नेटवर्क डिव्हाइसेस कनेक्ट करणे शक्य आहे, जे दोन्ही थेट NAT च्या मागे आहेत. मी विषयाचा अभ्यास केला, ऑपरेशनचे तत्त्व समजले आणि लिहायला बसलो. योजना साकार झाली आहे, वापरकर्ता पासवर्ड न टाकता किंवा VPN सेट न करता RDP, SSH किंवा Winbox द्वारे NAT च्या मागे असलेल्या इच्छित उपकरणाशी एका क्लिकवर कनेक्ट होतो. शिवाय, यापैकी बहुतेक कनेक्शन आमच्या समन्वयकाच्या पुढे जातात, ज्याचा पिंग आणि या कनेक्शनच्या सर्व्हिसिंगच्या खर्चावर चांगला परिणाम होतो.

Linux वरून Windows वर सर्व्हरचा भाग हस्तांतरित करणे

विंडोजवर स्विच करताना अनेक समस्या होत्या. पहिली गोष्ट म्हणजे विंडोजमधील अंगभूत wmic तुम्हाला WQL क्वेरी करू देत नाही. आणि आमच्या सिस्टममध्ये सर्वकाही आधीच त्यांच्यावर तयार केले गेले आहे. आणि आणखी काहीतरी होते, परंतु आता मी विसरलो आहे की त्यांनी शेवटी त्याचा वापर का सोडला. विंडोज आवृत्त्यांमधील फरक. आणि दुसरी समस्या मल्टीथ्रेडिंग आहे. आमच्यासाठी “स्वीकारण्यायोग्य” परवान्याअंतर्गत चांगली तृतीय-पक्ष उपयुक्तता न मिळाल्याने, मी पुन्हा Lazarus IDE लाँच केले. आणि मी आवश्यक उपयुक्तता लिहिली. इनपुट ही ऑब्जेक्ट्सची आवश्यक यादी आहे आणि कोणत्या विशिष्ट क्वेरी करणे आवश्यक आहे आणि प्रतिसादात मला डेटा प्राप्त होतो. आणि हे सर्व मल्टी-थ्रेडेड मोडमध्ये. मस्त.

मी PHP Windows साठी pthreads सेट केल्यानंतर, मला वाटले की सर्वकाही लगेच सुरू होईल, परंतु तसे झाले नाही. डीबगिंगच्या काही काळानंतर, मला समजले की pthreads काम करत आहेत, परंतु ते आमच्या सिस्टमवर कार्य करत नाही. हे स्पष्ट झाले की विंडोजवर pthreads सह कार्य करण्यात काही विशिष्टता आहे. आणि तसे होते. मी दस्तऐवज वाचले, आणि तेथे लिहिले होते की विंडोजसाठी थ्रेड्सची संख्या मर्यादित आहे आणि, माझ्या लक्षात येण्यापर्यंत, स्पष्टपणे. ही समस्या बनली. कारण जेव्हा मी ऍप्लिकेशनवर चालणाऱ्या थ्रेड्सची संख्या कमी करायला सुरुवात केली तेव्हा ते काम खूप हळू झाले. मी पुन्हा IDE उघडले आणि ऑब्जेक्ट्सच्या मल्टी-थ्रेडेड पिंगिंगसाठी कार्यक्षमता समान युटिलिटीमध्ये जोडली गेली. बरं, तिथे आधीच खूप पोर्ट स्कॅनिंग आहे. वास्तविक, यानंतर, PHP साठी pthreads ची गरज नाहीशी झाली आणि ती आता वापरली जात नाही. पुढे, या युटिलिटीमध्ये आणखी अनेक कार्ये जोडली गेली आणि ती आजही कार्यरत आहे. यानंतर, विंडोजसाठी एक इंस्टॉलर एकत्र केला गेला, ज्यामध्ये अपाचे, पीएचपी, मारियाडीबी, पीएचपी ऍप्लिकेशन आणि फ्री पास्कलमध्ये लिहिलेल्या सिस्टमशी संवाद साधण्यासाठी उपयुक्ततेचा संच समाविष्ट होता. इंस्टॉलरसाठी, मला वाटले की मी या समस्येचे त्वरीत निराकरण करेन, कारण... ही एक अतिशय सामान्य गोष्ट आहे आणि जवळजवळ प्रत्येक सॉफ्टवेअरसाठी आवश्यक आहे. एकतर मी चुकीच्या ठिकाणी पाहत होतो, किंवा दुसरे काहीतरी. पण मला सतत अशी उत्पादने मिळत गेली जी एकतर पुरेशी लवचिक नव्हती किंवा महाग आणि नम्र देखील होती. आणि तरीही, मला एक विनामूल्य इंस्टॉलर सापडला ज्यामध्ये कोणत्याही शुभेच्छा प्रदान करणे शक्य होईल. हे InnoSetup आहे. मी याबद्दल येथे लिहित आहे कारण मी एखाद्याचा वेळ वाचवल्यास मला ते पहावे लागेल.

आपल्या क्लायंटच्या बाजूने प्लगइन नाकारणे

मी पूर्वी लिहिले आहे की क्लायंट भाग "प्लगइन" सह ब्राउझर होता. त्यामुळे असे काही वेळा होते जेव्हा क्रोम अपडेट केले गेले होते आणि लेआउट थोडा कुटिल होता, नंतर विंडोज अपडेट केले गेले आणि कस्टम उरी स्कीम गायब झाली. मला उत्पादनाच्या सार्वजनिक आवृत्तीमध्ये अशा प्रकारचे आश्चर्य वाटले नाही. शिवाय, प्रत्येक विंडोज अपडेटनंतर सानुकूल uri अदृश्य होऊ लागली. मायक्रोसॉफ्टने आवश्यक विभागातील त्याच्या नसलेल्या सर्व शाखा हटवल्या. तसेच, Google Chrome आता तुम्हाला कस्टम uri मधून ऍप्लिकेशन उघडण्याची किंवा न उघडण्याची निवड लक्षात ठेवण्याची परवानगी देत ​​नाही आणि प्रत्येक वेळी तुम्ही मॉनिटरिंग ऑब्जेक्टवर क्लिक करता तेव्हा हा प्रश्न विचारतो. बरं, सर्वसाधारणपणे, वापरकर्त्याच्या स्थानिक सिस्टमसह सामान्य संवाद आवश्यक होता, जो ब्राउझर प्रदान करत नाही. या योजनेतील सर्वात सोपा पर्याय म्हणजे फक्त तुमचा स्वतःचा ब्राउझर बनवणे हा दिसतो, जसे आता बरेच जण इलेक्ट्रॉनद्वारे करत आहेत. परंतु सर्व्हरच्या भागासह फ्री पास्कलमध्ये बर्‍याच गोष्टी आधीच लिहिल्या गेल्या होत्या, म्हणून आम्ही क्लायंटला त्याच भाषेत बनवण्याचा निर्णय घेतला आणि प्राणीसंग्रहालय तयार न करण्याचा निर्णय घेतला. बोर्डवर क्रोमियम असलेले क्लायंट असे लिहिले होते. त्यानंतर, त्याने विविध पट्ट्या घेण्यास सुरुवात केली.

सोडा

शेवटी आम्ही सिस्टमसाठी एक नाव निवडले. स्थानिक आवृत्तीमधून SaaS मध्ये रूपांतरित करण्याची प्रक्रिया सुरू असताना आम्ही सतत विविध पर्यायांमधून गेलो. आम्ही सुरुवातीला केवळ देशांतर्गत बाजारपेठेत प्रवेश करण्याची योजना आखली नसल्यामुळे, नाव निवडण्याचा मुख्य निकष म्हणजे “.com” झोनमध्ये अव्यवस्थित किंवा फार महाग नसलेले डोमेन असणे. काही फंक्शन्स/मॉड्युल अद्याप स्थानिक आवृत्तीमधून Veliam वर पोर्ट केले गेले नाहीत, परंतु आम्ही ठरवले आहे की आम्ही त्यांना सध्याच्या कार्यक्षमतेसह सोडू आणि उर्वरित अद्यतने म्हणून पूर्ण करू. पहिल्याच आवृत्तीत हेल्पडेस्क, वेलियम कनेक्टर नव्हते, सूचना ट्रिगर्ससाठी थ्रेशोल्ड बदलणे अशक्य होते आणि बरेच काही. आम्ही कोड साइन प्रमाणपत्र विकत घेतले आणि क्लायंट आणि सर्व्हर भागांवर स्वाक्षरी केली. आम्ही उत्पादनासाठी वेबसाइट लिहिली, सॉफ्टवेअर, ट्रेडमार्क इ. नोंदणीसाठी प्रक्रिया सुरू केली. सर्वसाधारणपणे, आम्ही प्रारंभ करण्यास तयार आहोत. केलेल्या कामामुळे आणि कदाचित कोणीतरी आपले उत्पादन वापरेल या वस्तुस्थितीवरून थोडासा उत्साह, जरी आम्हाला याबद्दल कोणतीही शंका नव्हती. आणि मग थांबा. भागीदाराने सांगितले की मेसेंजरद्वारे सूचनांशिवाय बाजारात प्रवेश करणे अशक्य आहे. इतर अनेक गोष्टींशिवाय हे शक्य आहे, परंतु याशिवाय नाही. काही वादविवादानंतर, टेलीग्रामसह एकत्रीकरण जोडले गेले, जे आम्हाला अनुकूल होते. सध्याच्या सर्व इन्स्टंट मेसेंजर्सपैकी, हे एकमेव आहे जे त्याच्या API मध्ये विनामूल्य आणि कोणत्याही जटिल मंजुरी प्रक्रियेशिवाय प्रवेश प्रदान करते. त्याच व्हॉट्सअॅपने त्यांच्या सेवा वापरण्यासाठी चांगले पैसे आकारणार्‍या प्रदात्यांशी संपर्क साधण्याचा सल्ला दिला आहे; गॅस्केटशिवाय प्रवेशासाठी विचारणारी सर्व पत्रे दुर्लक्षित केली गेली. बरं, Viber... आता ते कोण वापरतं हे मला माहीत नाही, कारण... स्पॅम आणि जाहिराती ऑफ चार्ट आहेत. डिसेंबरच्या अखेरीस, मित्रांमधील अंतर्गत चाचण्या आणि चाचण्यांच्या मालिकेनंतर, नोंदणी सर्वांसाठी खुली करण्यात आली आणि सॉफ्टवेअर डाउनलोड करण्यासाठी उपलब्ध करून देण्यात आले.

वितरणाची सुरुवात

अगदी सुरुवातीपासून, आम्हाला समजले की आम्हाला सिस्टम वापरकर्त्यांचा एक छोटासा प्रवाह हवा आहे जेणेकरून ते लढाऊ मोडमध्ये उत्पादनाची चाचणी करू शकतील आणि काही प्रथम अभिप्राय देऊ शकतील. व्हीके बोर फ्रूटवर अनेक खरेदी केलेल्या पोस्ट. पहिल्या नोंदणी आल्या आहेत.

येथे असे म्हटले पाहिजे की आपल्या कंपनीचे प्रसिद्ध नाव नसताना बाजारात प्रवेश करणे आणि त्याच वेळी एजंटलेस मॉनिटरिंग कार्यक्षमता प्रदान करणे ज्यामध्ये आपल्याला आपल्या सर्व्हर आणि वर्कस्टेशन्समधून खाती प्रविष्ट करणे आवश्यक आहे, हे खूप कठीण आहे. हे बर्याच लोकांना घाबरवते. आम्हाला सुरुवातीपासूनच समजले की यात काही समस्या असतील आणि आम्ही यासाठी तांत्रिक आणि नैतिकदृष्ट्या तयार होतो. सर्व रिमोट कनेक्शन्स, आरडीपी आणि एसएसएच आधीच डीफॉल्टनुसार एनक्रिप्ट केलेले असूनही, आमच्या सॉफ्टवेअरद्वारे AES मानक वापरून कूटबद्ध केले जातात. स्थानिक सर्व्हरवरील सर्व डेटा HTTPS द्वारे क्लाउडवर हस्तांतरित केला जातो. खाती एनक्रिप्टेड स्वरूपात संग्रहित केली जातात. सर्व उपप्रणालींसाठी एनक्रिप्शन की सर्व क्लायंटसाठी वैयक्तिक आहेत. रिमोट कनेक्शनसाठी, सत्र एनक्रिप्शन की सामान्यतः वापरल्या जातात.

या परिस्थितीत लोकांना शांत वाटण्यासाठी आपण जे काही करू शकतो ते म्हणजे शक्य तितके मोकळे राहणे, सुरक्षिततेवर काम करणे आणि लोकांच्या प्रश्नांची उत्तरे देताना कधीही कंटाळा न करणे.

बर्‍याच लोकांसाठी, सॉफ्टवेअरची सोय आणि कार्यक्षमता भीतीपेक्षा जास्त आहे आणि ते नोंदणी करतात. काही व्यक्तींनी व्हीकेवरील प्रकाशित पोस्टमध्ये लिहिले की हे सॉफ्टवेअर वापरले जाऊ शकत नाही कारण हा त्यांच्या पासवर्डचा संग्रह आहे आणि साधारणपणे नाव नसलेली कंपनी आहे. असे एकापेक्षा जास्त लोकांचे मत होते असे म्हटले पाहिजे. बर्‍याच लोकांना हे समजत नाही की जेव्हा ते सर्व्हरवर इतर प्रोप्रायटरी सॉफ्टवेअर स्थापित करतात जे सेवा म्हणून चालतात तेव्हा त्याचे सिस्टममध्ये पूर्ण अधिकार देखील असतात आणि त्यांना काहीतरी बेकायदेशीर करण्यासाठी खात्यांची आवश्यकता नसते (हे स्पष्ट आहे की तुम्ही बदलू शकता. ज्या वापरकर्त्याकडून सेवा सुरू केली आहे, परंतु येथे देखील, आपण कोणतेही खाते प्रविष्ट करू शकता). खरं तर, लोकांची भीती समजण्यासारखी आहे. सर्व्हरवर सॉफ्टवेअर स्थापित करणे ही एक सामान्य गोष्ट आहे, परंतु खाते प्रविष्ट करणे थोडे भितीदायक आणि जिव्हाळ्याचे आहे, कारण अर्ध्या लोकांकडे सर्व सेवांसाठी समान पासवर्ड असतो आणि चाचणीसाठी देखील स्वतंत्र खाते तयार करणे आळशी असते. परंतु याक्षणी लोक त्यांच्या क्रेडेन्शियल्ससह विश्वास ठेवतात अशा मोठ्या संख्येने सेवा आहेत. आणि आम्ही त्यापैकी एक बनण्याचा प्रयत्न करतो.

आम्ही ते कुठेतरी चोरले असे अनेक टिप्पण्या होत्या. यामुळे आम्हाला थोडे आश्चर्य वाटले. ठीक आहे, एका व्यक्तीचे मत, परंतु अशा टिप्पण्या वेगवेगळ्या लोकांच्या विविध प्रकाशनांमध्ये आढळल्या. सुरुवातीला त्यांना यावर काय प्रतिक्रिया द्यावी हेच कळत नव्हते. एकतर दुःखी व्हावे की काही लोकांचे असे मत आहे की रशियामध्ये कोणीही स्वतःहून काहीही करू शकत नाही, परंतु केवळ चोरी करू शकतो किंवा त्यांना वाटते की हे फक्त चोरी केले जाऊ शकते असे त्यांना वाटते.

आम्ही आता ईव्ही कोड साइन प्रमाणपत्र मिळविण्याची प्रक्रिया पूर्ण केली आहे. ते प्राप्त करण्यासाठी, तुम्हाला तपासाच्या मालिकेतून जावे लागेल आणि कंपनीबद्दल कागदपत्रांचा एक समूह पाठवावा लागेल, ज्यापैकी काही वकिलाद्वारे प्रमाणित करणे आवश्यक आहे. महामारी दरम्यान EV कोड साइन प्रमाणपत्र मिळवणे हा लेखासाठी वेगळा विषय आहे. प्रक्रियेला एक महिना लागला. आणि तो प्रतीक्षा करण्याचा महिना नव्हता, परंतु अतिरिक्त कागदपत्रांसाठी सतत विनंत्या होता. कदाचित साथीच्या रोगाचा त्याच्याशी काही संबंध नाही आणि प्रक्रियेस प्रत्येकासाठी इतका वेळ लागला? शेअर करा.

काही म्हणतात की आम्ही ते वापरणार नाही कारण FSTEC प्रमाणपत्र नाही. आम्हाला हे स्पष्ट करावे लागेल की आम्ही ते मिळवू शकत नाही आणि करणार नाही कारण हे प्रमाणपत्र मिळविण्यासाठी, कूटबद्धीकरण GOST नुसार असणे आवश्यक आहे आणि आम्ही सॉफ्टवेअरचे वितरण केवळ रशियामध्येच नाही तर AES वापरण्याची योजना आखत आहोत.

या सर्व टिप्पण्यांवरून काही शंका निर्माण होतात की अशा उत्पादनाची जाहिरात करणे शक्य आहे ज्यासाठी तुम्हाला सार्वजनिकरित्या ओळखल्याशिवाय खाते प्रविष्ट करणे आवश्यक आहे. याकडे अत्यंत नकारात्मक वृत्ती असणारे लोक असतील हे माहीत असूनही. नोंदणीची संख्या एक हजाराच्या पुढे गेल्यावर आम्ही त्याबद्दल विचार करणे थांबवले. विशेषतः नंतर, ज्यांनी उत्पादनाचा प्रयत्न देखील केला नाही त्यांच्या नकारात्मकतेव्यतिरिक्त, खूप आनंददायी पुनरावलोकने दिसू लागली. असे म्हटले पाहिजे की ही सकारात्मक पुनरावलोकने उत्पादनाच्या विकासासाठी सर्वात मोठी प्रेरणा आहेत.

कर्मचार्‍यांसाठी रिमोट ऍक्सेस कार्यक्षमता जोडणे

क्लायंटच्या वारंवार कामांपैकी एक म्हणजे "वान्याला त्याच्या संगणकावर घरून प्रवेश देणे." आम्ही Mikrotik वर VPN वाढवले ​​आणि वापरकर्त्यांसाठी खाती तयार केली. पण ही खरी समस्या आहे. वापरकर्ते सूचना पाहू शकत नाहीत आणि VPN द्वारे कनेक्ट करण्यासाठी चरण-दर-चरण त्यांचे अनुसरण करू शकत नाहीत. विंडोजच्या वेगवेगळ्या आवृत्त्या. एका विंडोजमध्ये सर्वकाही चांगले कनेक्ट होते, दुसर्यामध्ये वेगळ्या प्रोटोकॉलची आवश्यकता असते. आणि सर्वसाधारणपणे, हे नेहमी नेटवर्क उपकरणांच्या पुनर्रचनाशी संबंधित होते, जे व्हीपीएन सर्व्हर म्हणून कार्य करते आणि सर्व कर्मचार्यांना त्यात प्रवेश नाही आणि हे गैरसोयीचे होते.

परंतु आमच्याकडे आधीपासूनच सर्व्हर आणि नेटवर्क उपकरणे दूरस्थ कनेक्शन आहेत. तयार वाहतूक का वापरू नये आणि एक वेगळी छोटी उपयुक्तता बनवा जी तुम्ही वापरकर्त्याला जोडण्यासाठी फक्त देऊ शकता. मला फक्त हे सुनिश्चित करायचे आहे की वापरकर्त्याने तेथे काहीही अप्रमाणित प्रविष्ट केले नाही. फक्त एक बटण "कनेक्ट करा". परंतु या युटिलिटीला फक्त एक बटण असल्यास कुठे कनेक्ट करायचे हे कसे समजेल? आमच्या सर्व्हरवर आवश्यक अर्ज ऑनलाइन तयार करण्याची कल्पना होती. सिस्टम अॅडमिनिस्ट्रेटर "डाउनलोड शॉर्टकट" बटणावर क्लिक करतो, आणि RDP द्वारे इच्छित सर्व्हर/कॉम्प्युटरशी कनेक्ट करण्यासाठी हार्डवायर्ड माहितीसह वैयक्तिक बायनरी तयार करण्यासाठी आमच्या क्लाउडवर कमांड पाठवली जाते. सर्वसाधारणपणे, हे केले जाऊ शकते. परंतु यास बराच वेळ लागतो; प्रशासकास प्रथम बायनरी संकलित होईपर्यंत आणि नंतर डाउनलोड होईपर्यंत प्रतीक्षा करावी लागेल. अर्थात, कॉन्फिगरेशनसह दुसरी फाईल जोडणे शक्य होईल, परंतु या आधीपासूनच 2 फायली आहेत आणि साधेपणासाठी वापरकर्त्यास एक आवश्यक आहे. एक फाइल, एक बटण आणि कोणतेही इंस्टॉलर नाहीत. Google वर थोडेसे वाचल्यानंतर, मी निष्कर्षापर्यंत पोहोचलो की जर तुम्ही संकलित “.exe” च्या शेवटी काही माहिती जोडली तर ती खराब होत नाही (चांगले, जवळजवळ). आपण किमान तेथे युद्ध आणि शांतता जोडू शकता आणि ते पूर्वीप्रमाणे कार्य करेल. याचा गैरफायदा न घेणे हे पाप ठरेल. आता तुम्ही जाता जाता, क्लायंटमध्येच अॅप्लिकेशन अनपॅक करू शकता, जसे की त्याला Veliam Connector म्हणतात, आणि शेवटी त्याच्याशी कनेक्ट करण्यासाठी आवश्यक असलेली माहिती जोडू शकता. आणि त्याचे काय करायचे ते अनुप्रयोगालाच माहित आहे. मी थोडे वरच्या कंसात “जवळजवळ चांगले” का लिहिले? कारण तुम्हाला या सुविधेसाठी पैसे द्यावे लागतील की अॅप्लिकेशन त्याची डिजिटल स्वाक्षरी गमावते. परंतु या टप्प्यावर, आमचा विश्वास आहे की अशा सोयीसाठी ही एक छोटी किंमत आहे.

तृतीय पक्ष मॉड्यूल परवाने

मी आधीच वर लिहिले आहे की उत्पादन सार्वजनिकरीत्या उपलब्ध करून देण्याचा निर्णय घेतल्यानंतर, आणि केवळ आमच्या स्वतःच्या वापरासाठी नाही, आम्हाला कठोर परिश्रम करावे लागले आणि काही मॉड्यूल्सच्या बदल्या शोधाव्या लागल्या ज्यांनी स्वतःला आमच्या उत्पादनामध्ये समाविष्ट करू दिले नाही. पण रिलीझ झाल्यानंतर, एक अतिशय अप्रिय गोष्ट चुकून सापडली. वेलिअम सर्व्हर, जो क्लायंटच्या बाजूने होता, त्यात मारियाडीबी डीबीएमएस समाविष्ट होते. आणि तो GPL परवानाकृत आहे. GPL परवाना सूचित करतो की सॉफ्टवेअर मुक्त स्त्रोत असणे आवश्यक आहे आणि जर आमच्या उत्पादनामध्ये MariaDB समाविष्ट असेल, ज्यांच्याकडे हा परवाना आहे, तर आमचे उत्पादन या परवान्याखाली असणे आवश्यक आहे. पण सुदैवाने, या परवान्याचा उद्देश मुक्त स्रोत आहे, चुकून चुकून न्यायालयात चुका करणाऱ्यांना शिक्षा न करणे. कॉपीराइट धारकाचा दावा असल्यास, तो उल्लंघनकर्त्याला लेखी सूचित करतो आणि त्याने 30 दिवसांच्या आत उल्लंघन दूर करणे आवश्यक आहे. आम्ही आमची चूक स्वतः शोधून काढली आणि आम्हाला कोणतेही पत्र मिळाले नाही आणि समस्या कशी सोडवायची यावर लगेचच पर्यायांचा विचार करण्यास सुरुवात केली. समाधान स्पष्ट झाले - SQLite वर स्विच करा. या डेटाबेसमध्ये परवाना निर्बंध नाहीत. बहुतेक आधुनिक ब्राउझर SQLite आणि इतर प्रोग्राम्सचा एक समूह वापरतात. मला इंटरनेटवर माहिती मिळाली की SQLite जगातील सर्वात व्यापक DBMS मानली जाते, तंतोतंत ब्राउझरमुळे, परंतु मी पुरावा शोधला नाही, म्हणून ही चुकीची माहिती आहे. मी SQLite वर स्विच करण्याच्या धोक्यांचा अभ्यास करण्यास सुरुवात केली.

जेव्हा क्लायंटकडे MariaDB आणि डेटासह अनेक शंभर सर्व्हर स्थापित केले जातात तेव्हा हे एक क्षुल्लक कार्य बनते. काही MariaDB वैशिष्ट्ये SQLite मध्ये उपलब्ध नाहीत. बरं, उदाहरणार्थ, कोडमध्ये आम्ही सारख्या क्वेरी वापरल्या

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

हे बांधकाम केवळ टेबलमधून निवड करत नाही तर पंक्तीचा डेटा देखील लॉक करते. आणि आणखी काही डिझाईन्स देखील पुन्हा लिहिल्या गेल्या. परंतु आम्हाला बर्‍याच क्वेरी पुन्हा लिहाव्या लागल्या या वस्तुस्थितीव्यतिरिक्त, आम्हाला अशी यंत्रणा देखील आणावी लागली जी क्लायंटचा वेलीअम सर्व्हर अद्यतनित करताना, सर्व डेटा नवीन DBMS वर पोर्ट करेल आणि जुना हटवेल. तसेच, SQLite मधील व्यवहार कार्य करत नाहीत आणि ही एक वास्तविक समस्या होती. परंतु वर्ल्ड वाइड वेबची विशालता वाचल्यानंतर, मला आढळले की कोणत्याही समस्यांशिवाय SQLite मधील व्यवहार कनेक्ट करताना एक साधी कमांड देऊन सक्षम केले जाऊ शकतात.

PRAGMA journal_mode=WAL;

परिणामी, कार्य पूर्ण झाले आणि आता क्लायंटचा सर्व्हर भाग SQLite वर चालतो. आम्हाला सिस्टमच्या ऑपरेशनमध्ये कोणतेही बदल लक्षात आले नाहीत.

नवीन हेल्पडेस्क

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

हेल्पडेस्क सिस्टीमसाठी आम्ही अत्यंत आवश्यक मानत असलेली दुसरी गोष्ट, किमान स्वतःसाठी, अर्जदाराशी थेट एका क्लिकवर जोडणे. शिवाय, सिस्टम प्रशासक वेगळ्या नेटवर्कवर असल्यास कनेक्शन पास होणे आवश्यक आहे. आउटसोर्सिंगसाठी हे अनिवार्य आहे, पूर्ण-वेळ सिस्टम प्रशासकांसाठी हे देखील खूप आवश्यक आहे. आधीच अनेक उत्पादने आहेत जी दूरस्थ कनेक्शनचे उत्कृष्ट कार्य करतात. आणि आम्ही त्यांच्यासाठी एकत्रीकरण करण्याचा निर्णय घेतला. आम्ही आता VNC साठी एकत्रित केले आहे, आणि भविष्यात आम्ही Radmin आणि TeamViewer जोडण्याची योजना आखत आहोत. रिमोट इन्फ्रास्ट्रक्चर कनेक्शनसाठी आमच्या नेटवर्क ट्रान्सपोर्टचा वापर करून, आम्ही NAT च्या मागे रिमोट वर्कस्टेशन्सशी VNC कनेक्ट केले. रॅडमिनच्या बाबतीतही तेच होईल. आता, वापरकर्त्याशी कनेक्ट होण्यासाठी, तुम्हाला अनुप्रयोगातच "अर्जदाराशी कनेक्ट करा" बटणावर क्लिक करणे आवश्यक आहे. VNC क्लायंट उघडतो आणि अर्जदाराशी जोडतो, तुम्ही एकाच नेटवर्कवर असलात किंवा घरी बसून चप्पल घालत असलात तरीही. प्रथम, सिस्टम प्रशासक, जीपीओ वापरून, प्रत्येकाच्या वर्कस्टेशनवर VNC सर्व्हर स्थापित करणे आवश्यक आहे.

आता आम्ही स्वतः नवीन हेल्पडेस्कवर स्विच करत आहोत आणि डोमेन आणि VNC सह एकत्रीकरण वापरत आहोत. हे आमच्यासाठी खूप सोयीचे आहे. आता आम्ही TeamViewer साठी पैसे देणे टाळू शकतो, जी आम्ही आमची समर्थन सेवा चालवण्यासाठी तीन वर्षांहून अधिक काळ वापरत आहोत.

आम्ही पुढे काय करायचे ठरवत आहोत?

आम्‍ही उत्‍पादन रिलीझ केल्‍यावर, आम्‍ही कोणतेही सशुल्‍क दर आकारले नाहीत, परंतु 50 मॉनिटरिंग ऑब्‍जेक्‍टपर्यंत मोफत दर मर्यादित केले. पाच डझन नेटवर्क डिव्हाइसेस आणि सर्व्हर प्रत्येकासाठी पुरेसे असावेत, आम्ही विचार केला. आणि मग मर्यादा वाढवण्याच्या विनंत्या येऊ लागल्या. आम्हाला थोडासा धक्का बसला असे म्हणणे म्हणजे काहीच नाही. इतके सर्व्हर असलेल्या कंपन्यांना आमच्या सॉफ्टवेअरमध्ये खरोखर रस आहे का? ज्यांनी अशा विनंत्या केल्या आहेत त्यांच्यासाठी आम्ही विनामूल्य मर्यादा वाढवली आहे. त्यांच्या विनंतीला प्रतिसाद म्हणून, आम्ही काहींना विचारले की त्यांना इतकी गरज का आहे, त्यांच्याकडे खरोखरच इतक्या मोठ्या प्रमाणात सर्व्हर आणि नेटवर्क उपकरणे आहेत का. आणि असे दिसून आले की सिस्टम प्रशासकांनी सिस्टीमचा अशा प्रकारे वापर करण्यास सुरुवात केली ज्याची आम्ही योजना केली नव्हती. सर्व काही सोपे झाले - आमच्या सॉफ्टवेअरने केवळ सर्व्हरच नव्हे तर वर्कस्टेशन्सचे देखील निरीक्षण करण्यास सुरवात केली. त्यामुळे मर्यादा वाढवण्याच्या अनेक विनंत्या आहेत. आता आम्ही आधीच सशुल्क दर लागू केले आहेत आणि मर्यादा स्वतंत्रपणे विस्तारित केल्या जाऊ शकतात.

सर्व्हर जवळजवळ नेहमीच स्टोरेज सिस्टम किंवा स्थानिक डिस्कसह RAID अॅरेमध्ये कार्य करतात. आणि आम्ही सुरुवातीला त्यांच्यासाठी उत्पादन केले. आणि या कामासाठी SMART मॉनिटरिंग मनोरंजक नव्हते. परंतु लोकांनी वर्कस्टेशन्सचे निरीक्षण करण्यासाठी सॉफ्टवेअरचे रुपांतर केले आहे हे लक्षात घेऊन, स्मार्ट मॉनिटरिंगच्या अंमलबजावणीसाठी विनंत्या आल्या आहेत. लवकरच त्याची अंमलबजावणी करू.

Veliam Connector च्या आगमनाने, कॉर्पोरेट नेटवर्कमध्ये VPN सर्व्हर तैनात करणे किंवा RDGW करणे किंवा RDP द्वारे कनेक्ट करण्यासाठी आवश्यक मशीन्सवर फक्त पोर्ट्स फॉरवर्ड करणे अनावश्यक झाले. बरेच लोक आमची प्रणाली फक्त या रिमोट कनेक्शनसाठी वापरतात. Veliam Connector फक्त Windows साठी उपलब्ध आहे आणि काही कंपनी वापरकर्ते MacOS चालवणाऱ्या होम लॅपटॉपवरून वर्कस्टेशन्स किंवा कॉर्पोरेट नेटवर्कवरील टर्मिनल्सशी कनेक्ट करतात. आणि असे दिसून आले की सिस्टम प्रशासकाला, अनेक वापरकर्त्यांमुळे, अद्याप फॉरवर्डिंग किंवा व्हीपीएनच्या समस्येकडे परत जाण्यास भाग पाडले जाते. म्हणून, आम्ही आता MacOS साठी Veliam Connector ची आवृत्ती तयार करत आहोत. त्यांच्या आवडत्या ऍपल तंत्रज्ञानाच्या वापरकर्त्यांना एका क्लिकवर कॉर्पोरेट पायाभूत सुविधांशी कनेक्ट होण्याची संधी देखील मिळेल.

मला हे खरंच आवडते की, मोठ्या संख्येने सिस्टीम वापरकर्ते असल्याने, लोकांना कशाची गरज आहे आणि काय अधिक सोयीस्कर असेल याबद्दल तुम्हाला तुमचा मेंदू रॅक करण्याची गरज नाही. ते स्वतः त्यांची इच्छा लिहितात, त्यामुळे नजीकच्या भविष्यासाठी खूप विकास योजना आहेत.

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

स्त्रोत: www.habr.com