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

सर्वांना नमस्कार, माझे नाव सेर्गेई एमेल्यानचिक आहे. मी ऑडिट-टेलिकॉम कंपनीचा प्रमुख आहे, मुख्य विकसक आणि Veliam प्रणालीचा लेखक आहे. मी आणि माझ्या मित्राने आउटसोर्सिंग कंपनी कशी तयार केली याबद्दल एक लेख लिहिण्याचे ठरवले, स्वतःसाठी सॉफ्टवेअर लिहिले आणि नंतर ते SaaS प्रणालीद्वारे सर्वांना वितरित करण्यास सुरुवात केली. हे शक्य आहे यावर मी स्पष्टपणे विश्वास ठेवला नाही याबद्दल. लेखात केवळ एक कथाच नाही तर Veliam उत्पादन कसे तयार केले गेले याचे तांत्रिक तपशील देखील असतील. स्त्रोत कोडच्या काही तुकड्यांसह. आम्ही तुम्हाला कोणत्या चुका केल्या आणि आम्ही त्या कशा दुरुस्त केल्या ते मी तुम्हाला नंतर सांगेन. असा लेख प्रसिद्ध करायचा की काय अशी शंका होती. पण मला वाटले की लेख प्रकाशित न करण्यापेक्षा ते करणे, अभिप्राय मिळवणे आणि सुधारणा करणे अधिक चांगले आहे तर काय झाले असते याचा विचार करा...

prehistory

मी एका कंपनीत आयटी कर्मचारी म्हणून काम केले. विस्तृत नेटवर्क स्ट्रक्चरसह कंपनी बरीच मोठी होती. मी माझ्या नोकरीच्या जबाबदाऱ्यांवर लक्ष ठेवणार नाही, मी फक्त एवढेच म्हणेन की त्यांनी निश्चितपणे कशाचाही विकास केला नाही.

आमच्याकडे देखरेख होते, परंतु केवळ शैक्षणिक स्वारस्यामुळे मला माझे स्वतःचे सोपे लिहिण्याचा प्रयत्न करायचा होता. कल्पना अशी होती: मला ते वेबवर हवे होते, जेणेकरून मी कोणतेही क्लायंट स्थापित न करता सहजपणे आत जाऊ शकेन आणि वाय-फाय द्वारे मोबाइल डिव्हाइससह कोणत्याही डिव्हाइसवरून नेटवर्कमध्ये काय चालले आहे ते पाहू शकेन आणि मी खरोखर खोलीत कोणती उपकरणे आहेत जी "मोपी" बनली आहेत ते त्वरीत समजून घ्यायचे होते कारण... अशा समस्यांसाठी प्रतिसाद वेळेसाठी अतिशय कठोर आवश्यकता होत्या. परिणामी, माझ्या डोक्यात एक साधे वेब पृष्ठ लिहिण्याची योजना जन्माला आली ज्यावर नेटवर्क आकृतीसह एक jpeg पार्श्वभूमी असेल, या चित्रातील त्यांच्या IP पत्त्यांसह उपकरणे स्वतःच कापून टाका आणि शीर्षस्थानी डायनॅमिक सामग्री दर्शवा. हिरव्या किंवा चमकणाऱ्या लाल IP पत्त्याच्या रूपात आवश्यक निर्देशांकांमध्ये चित्र. कार्य सेट केले आहे, चला प्रारंभ करूया.

पूर्वी, मी डेल्फी, पीएचपी, जेएस आणि अगदी वरवरच्या सी++ मध्ये प्रोग्रामिंग करत होतो. नेटवर्क कसे काम करतात हे मला चांगले माहीत आहे. VLAN, राउटिंग (OSPF, EIGRP, BGP), NAT. मला स्वतः एक आदिम मॉनिटरिंग प्रोटोटाइप लिहिण्यासाठी हे पुरेसे होते.

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

system(“ping -n 3 -w 100 {$ip_address}“); 

होय, होय, त्या क्षणी डेटाबेससह काम करणे देखील माझ्यासाठी मास्टर्ड नव्हते. मला माहित नव्हते की प्रक्रियांना समांतर करणे शक्य आहे आणि सर्व नेटवर्क नोड्समधून जाण्यास बराच वेळ लागला, कारण... हे एका धाग्यात घडले. विशेषत: समस्या उद्भवल्या जेव्हा अनेक नोड्स अनुपलब्ध होते, कारण त्यांच्यापैकी प्रत्येकाने स्क्रिप्टला 300 ms साठी विलंब केला. क्लायंटच्या बाजूला एक साधे लूपिंग फंक्शन होते जे काही सेकंदांच्या अंतराने, Ajax विनंतीसह सर्व्हरवरून अद्यतनित माहिती डाउनलोड करते आणि इंटरफेस अद्यतनित करते. बरं, मग, सलग 3 अयशस्वी पिंग्जनंतर, जर संगणकावर मॉनिटरिंग असलेले वेब पृष्ठ उघडले असेल, तर एक आनंदी रचना वाजली.

जेव्हा सर्व काही कार्यान्वित झाले, तेव्हा मी परिणामाने खूप प्रेरित झालो आणि विचार केला की मी त्यात आणखी भर घालू शकेन (माझ्या ज्ञानामुळे आणि क्षमतेमुळे). परंतु मला नेहमी एक दशलक्ष चार्ट असलेल्या सिस्टम आवडत नव्हत्या, ज्या मला तेव्हा वाटत होत्या आणि आजही वाटतात, बहुतेक प्रकरणांमध्ये अनावश्यक आहेत. मला माझ्या कामात खरोखर मदत होईल तेच तिथे ठेवायचे होते. हे तत्त्व आजही वेलिअमच्या विकासासाठी मूलभूत आहे. पुढे, मला समजले की जर मला मॉनिटरिंग उघडे ठेवायचे नसेल आणि समस्यांबद्दल जाणून घ्यायचे नसेल तर ते खूप छान होईल आणि जेव्हा ते घडले तेव्हा पृष्ठ उघडा आणि हे समस्याप्रधान नेटवर्क नोड कुठे आहे आणि त्याचे पुढे काय करायचे ते पहा. . कसे तरी मी नंतर ईमेल वाचले नाही, मी फक्त ते वापरले नाही. मला इंटरनेटवर आढळले की असे एसएमएस गेटवे आहेत ज्यावर तुम्ही GET किंवा POST विनंती पाठवू शकता आणि ते माझ्या मोबाइल फोनवर मी लिहिलेल्या मजकुरासह एसएमएस पाठवतील. मला लगेच कळले की मला हे खरोखर हवे आहे. आणि मी कागदपत्रांचा अभ्यास सुरू केला. काही काळानंतर मी यशस्वी झालो, आणि आता मला माझ्या मोबाइल फोनवरील नेटवर्कवरील समस्यांबद्दल "पडलेल्या वस्तू" नावाने एसएमएस प्राप्त झाला. प्रणाली जरी आदिम असली तरी ती मी स्वतः लिहिली होती आणि मला ती विकसित करण्यास प्रवृत्त करणारी सर्वात महत्वाची गोष्ट म्हणजे तो एक अनुप्रयोग प्रोग्राम होता ज्याने मला माझ्या कामात खरोखर मदत केली.

आणि मग तो दिवस आला जेव्हा इंटरनेट चॅनेलपैकी एक कामावर गेला आणि माझ्या मॉनिटरिंगने मला त्याबद्दल माहिती दिली नाही. Google DNS अजूनही उत्तम प्रकारे पिंग करत असल्याने. संप्रेषण चॅनेल जिवंत असल्याचे आपण कसे निरीक्षण करू शकता याचा विचार करण्याची वेळ आली आहे. हे कसे करायचे याबद्दल वेगवेगळ्या कल्पना होत्या. माझ्याकडे सर्व उपकरणांमध्ये प्रवेश नव्हता. कोणते चॅनेल लाइव्ह आहे हे कसे समजून घ्यावे हे आम्हाला शोधून काढायचे होते, परंतु ते नेटवर्क उपकरणांवरच पाहण्यास सक्षम न होता. मग एका सहकाऱ्याने कल्पना सुचली की इंटरनेटवर प्रवेश करण्यासाठी सध्या कोणत्या संप्रेषण चॅनेलचा वापर केला जातो त्यानुसार सार्वजनिक सर्व्हरवर जाण्याचा मार्ग भिन्न असू शकतो. मी तपासले आणि ते तसे निघाले. ट्रेसिंग करताना वेगवेगळे मार्ग होते.

system(“tracert -d -w 500 8.8.8.8”);

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

पुढे, रोजच्या कामात मला क्रॉस क्रॉसिंग करावे लागले. आणि प्रत्येक वेळी कोणता इंटरफेस वापरायचा हे पाहण्यासाठी मी सिस्को स्विचेसवर जाऊन थकलो. मॉनिटरिंगमध्ये ऑब्जेक्टवर क्लिक करणे आणि वर्णनांसह त्याच्या इंटरफेसची सूची पाहणे किती छान असेल. त्यामुळे माझा वेळ वाचेल. शिवाय, या योजनेत खाती आणि आदेश प्रविष्ट करण्यासाठी पुट्टी किंवा सिक्योरसीआरटी चालवण्याची आवश्यकता नाही. मी फक्त मॉनिटरिंगवर क्लिक केले, काय आवश्यक आहे ते पाहिले आणि माझे काम करायला गेलो. मी स्विचसह संवाद साधण्याचे मार्ग शोधू लागलो. मला ताबडतोब 2 पर्याय आले: SNMP किंवा SSH द्वारे स्विचमध्ये लॉग इन करणे, मला आवश्यक असलेल्या आज्ञा प्रविष्ट करणे आणि निकालाचे विश्लेषण करणे. मी SNMP च्या अंमलबजावणीच्या जटिलतेमुळे डिसमिस केले; मी परिणाम मिळविण्यासाठी अधीर होतो. SNMP सह, तुम्हाला MIB मध्ये बराच काळ खोदून घ्यावा लागेल आणि या डेटाच्या आधारे, इंटरफेसबद्दल डेटा तयार करावा लागेल. CISCO मध्ये एक अद्भुत संघ आहे

show interface status

क्रॉस-क्रॉसिंगसाठी मला नेमके काय हवे आहे ते ते दर्शवते. जेव्हा मला फक्त या कमांडचे आउटपुट पहायचे असेल तेव्हा SNMP चा त्रास का करावा, मला वाटले. काही काळानंतर ही संधी माझ्या लक्षात आली. वेब पृष्ठावरील ऑब्जेक्टवर क्लिक केले. एक इव्हेंट ट्रिगर झाला ज्याद्वारे AJAX क्लायंटने सर्व्हरशी संपर्क साधला, आणि त्या बदल्यात, मला आवश्यक असलेल्या स्विचशी SSH द्वारे जोडला गेला (क्रेडेन्शियल्स कोडमध्ये हार्डकोड केले गेले होते, ते परिष्कृत करण्याची इच्छा नव्हती, काही वेगळे मेनू बनवण्यासाठी इंटरफेसमधून खाती बदलणे शक्य होईल , मला परिणाम आवश्यक होता आणि त्वरीत) मी तेथे वरील आदेश प्रविष्ट केला आणि तो ब्राउझरवर परत पाठविला. त्यामुळे मी माऊसच्या एका क्लिकवर इंटरफेसची माहिती पाहू लागलो. हे अत्यंत सोयीचे होते, विशेषत: जेव्हा तुम्हाला ही माहिती एकाच वेळी वेगवेगळ्या स्विचवर पहावी लागते.

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

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

ऑडिट-टेलिकॉम कंपनीची निर्मिती

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

माझा मित्र पावेल (एक IT विशेषज्ञ) याने मला स्वतःचा व्यवसाय सुरू करण्यासाठी सतत प्रोत्साहन देण्याचा प्रयत्न केला. ते काय करत होते याच्या विविध भिन्नता असलेल्या असंख्य कल्पना होत्या. यावर वर्षानुवर्षे चर्चा होत आहे. आणि सरतेशेवटी, हे काहीही घडले नसावे कारण मी एक संशयवादी आहे आणि पावेल एक स्वप्न पाहणारा आहे. प्रत्येक वेळी त्याने एखादी कल्पना मांडली, मी नेहमी त्यावर विश्वास ठेवला नाही आणि भाग घेण्यास नकार दिला. पण आम्हाला आमचा स्वतःचा व्यवसाय उघडायचा होता.

शेवटी, आम्हा दोघांना अनुकूल असा पर्याय शोधण्यात आम्हाला यश आले आणि आम्हाला जे करायचे ते आम्ही करू शकलो. 2016 मध्ये, आम्ही एक IT कंपनी तयार करण्याचा निर्णय घेतला जी व्यवसायांना IT समस्या सोडवण्यास मदत करेल. ही आयटी प्रणाली (1C, टर्मिनल सर्व्हर, मेल सर्व्हर इ.), त्यांची देखभाल, वापरकर्त्यांसाठी क्लासिक हेल्पडेस्क आणि नेटवर्क प्रशासनाची तैनाती आहे.

खरे सांगायचे तर, कंपनी तयार करताना, मी त्यावर सुमारे 99,9% विश्वास ठेवला नाही. पण कसा तरी पावेल मला प्रयत्न करायला लावू शकला आणि पुढे पाहताना तो बरोबर निघाला. पावेल आणि मी प्रत्येकी 300 rubles मध्ये चीप केले, एक नवीन LLC “Audit-Telecom” ची नोंदणी केली, एक छोटेसे कार्यालय भाड्याने घेतले, मस्त बिझनेस कार्ड बनवले, तसेच, सर्वसाधारणपणे, बहुधा अननुभवी, नवशिक्या व्यावसायिकांप्रमाणे, आणि क्लायंट शोधू लागलो. ग्राहक शोधणे ही पूर्णपणे वेगळी गोष्ट आहे. जर कोणाला स्वारस्य असेल तर कदाचित आम्ही कॉर्पोरेट ब्लॉगचा भाग म्हणून एक स्वतंत्र लेख लिहू. कोल्ड कॉल्स, फ्लायर्स इ. यामुळे कोणताही निकाल लागला नाही. व्यवसायाविषयीच्या अनेक कथा मी आता वाचल्याप्रमाणे, एक ना एक मार्ग, बरेच काही नशिबावर अवलंबून आहे. आम्ही भाग्यवान होतो. आणि कंपनीच्या निर्मितीच्या काही आठवड्यांनंतर, माझा भाऊ व्लादिमीर आमच्याकडे आला, ज्याने आम्हाला आमचा पहिला क्लायंट आणला. क्लायंटसोबत काम करण्याच्या तपशिलांचा मी तुम्हाला कंटाळा आणणार नाही, हा लेख त्याबद्दल नाही, मी फक्त एवढेच सांगेन की आम्ही ऑडिटसाठी गेलो होतो, गंभीर क्षेत्रे ओळखली होती आणि या क्षेत्रांचा निर्णय घेतला जात असताना ही क्षेत्रे तुटली. आउटसोर्सर म्हणून आम्हाला सतत सहकार्य करा. यानंतर तातडीने सकारात्मक निर्णय घेण्यात आला.

मग मुख्यत: मित्रांद्वारे तोंडी शब्द, इतर सेवा कंपन्या दिसू लागल्या. हेल्पडेस्क एकाच यंत्रणेत होता. नेटवर्क उपकरणे आणि सर्व्हरची जोडणी भिन्न आहेत, किंवा त्याऐवजी भिन्न आहेत. काही लोकांनी शॉर्टकट सेव्ह केले, तर काहींनी RDP अॅड्रेस बुक वापरले. मॉनिटरिंग ही दुसरी वेगळी यंत्रणा आहे. एका संघासाठी भिन्न प्रणालींमध्ये काम करणे खूप गैरसोयीचे आहे. महत्त्वाची माहिती दृष्टीआड झाली आहे. बरं, उदाहरणार्थ, क्लायंटचा टर्मिनल सर्व्हर अनुपलब्ध झाला. या क्लायंटच्या वापरकर्त्यांकडून अर्ज त्वरित प्राप्त होतात. समर्थन विशेषज्ञ एक विनंती उघडतो (ती फोनद्वारे प्राप्त झाली होती). जर घटना आणि विनंत्या एका सिस्टीममध्ये नोंदवल्या गेल्या असतील, तर सहाय्यक तज्ञ ताबडतोब वापरकर्त्याची समस्या काय आहे हे पाहतील आणि त्याला त्याबद्दल सांगतील, त्याच वेळी परिस्थिती कार्य करण्यासाठी आवश्यक ऑब्जेक्टशी कनेक्ट करताना. प्रत्येकाला सामरिक परिस्थितीची जाणीव आहे आणि ते सामंजस्याने कार्य करतात. आम्हाला अशी प्रणाली सापडली नाही जिथे हे सर्व एकत्र केले जाईल. हे स्पष्ट झाले की आमचे स्वतःचे उत्पादन बनवण्याची वेळ आली आहे.

तुमच्या मॉनिटरिंग सिस्टमवर काम सुरू ठेवा

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

तर, कार्ये:

1. श्रेणीबद्ध रचना;
2. काही प्रकारचे सर्व्हर भाग जे क्लायंटच्या आवारात व्हर्च्युअल मशीनच्या रूपात ठेवता येतात आणि आम्हाला आवश्यक असलेले मेट्रिक्स गोळा करून ते सेंट्रल सर्व्हरला पाठवले जातात, जे या सर्व गोष्टींचा सारांश देईल आणि आम्हाला दाखवेल;
3. इशारे. ज्यांना चुकवता येत नाही, कारण... त्यावेळी एखाद्याला बसून मॉनिटरकडे पाहणे शक्य नव्हते;
4. अर्ज प्रणाली. क्लायंट दिसू लागले ज्यांच्यासाठी आम्ही केवळ सर्व्हर आणि नेटवर्क उपकरणेच नव्हे तर वर्कस्टेशन्स देखील सेवा दिली;
5. सिस्टममधून सर्व्हर आणि उपकरणे द्रुतपणे कनेक्ट करण्याची क्षमता;

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

आम्ही पहिला प्रोटोटाइप बनवला. तो आम्हाला आवश्यक असलेली क्लायंट नेटवर्क उपकरणे आणि सर्व्हरला पिंग करू शकला आणि हा डेटा आमच्या मध्यवर्ती सर्व्हरवर पाठवू शकला. आणि त्याने या बदल्यात हा डेटा मोठ्या प्रमाणात सेंट्रल सर्व्हरवर अपडेट केला. येथे मी केवळ कसे आणि काय यशस्वी झाले याबद्दल एक कथा लिहिणार नाही, तर कोणत्या हौशी चुका झाल्या आणि नंतर मला वेळोवेळी त्याची किंमत कशी चुकवावी लागली. तर, ऑब्जेक्ट्सचे संपूर्ण झाड एकाच फाईलमध्ये अनुक्रमित ऑब्जेक्टच्या स्वरूपात संग्रहित केले गेले. आम्ही अनेक क्लायंटला सिस्टमशी कनेक्ट करत असताना, सर्व काही कमी-अधिक प्रमाणात सामान्य होते, जरी काहीवेळा काही कलाकृती होत्या ज्या पूर्णपणे समजण्यायोग्य नसतात. परंतु जेव्हा आम्ही डझनभर सर्व्हर सिस्टमशी कनेक्ट केले तेव्हा चमत्कार घडू लागले. काहीवेळा, काही अज्ञात कारणास्तव, सिस्टममधील सर्व वस्तू फक्त अदृश्य होतात. येथे हे लक्षात घेणे महत्त्वाचे आहे की क्लायंट ज्या सर्व्हरने सेंट्रल सर्व्हरला दर काही सेकंदांनी POST विनंतीद्वारे डेटा पाठविला होता. एका सजग वाचक आणि अनुभवी प्रोग्रामरने आधीच अंदाज लावला आहे की ज्या फाईलमध्ये अनुक्रमित ऑब्जेक्ट एकाच वेळी वेगवेगळ्या थ्रेड्समधून संग्रहित केला गेला होता त्या फाइलमध्ये एकाधिक प्रवेशाची समस्या होती. आणि जेव्हा हे घडत होते, तेव्हा वस्तू गायब झाल्यामुळे चमत्कार घडले. फाईल फक्त रिकामी झाली. परंतु हे सर्व त्वरित सापडले नाही, परंतु केवळ अनेक सर्व्हरसह ऑपरेशन दरम्यान. या वेळी, पोर्ट स्कॅनिंग कार्यक्षमता जोडली गेली (सव्‍हरने केंद्राकडे केवळ डिव्‍हाइसेसच्‍या उपलब्‍धतेबद्दलच माहिती नाही, तर त्‍यांच्‍यावर उघडल्‍या पोर्टबद्दल देखील माहिती पाठवली). हे आदेश कॉल करून केले गेले:

$connection = @fsockopen($ip, $port, $errno, $errstr, 0.5);

परिणाम अनेकदा चुकीचे होते आणि स्कॅन पूर्ण होण्यासाठी बराच वेळ लागला. मी पिंग बद्दल पूर्णपणे विसरलो, ते fping द्वारे केले गेले:

system("fping -r 3 -t 100 {$this->ip}");

हे देखील समांतर नव्हते आणि म्हणून ही प्रक्रिया खूप लांब होती. नंतर, सत्यापनासाठी आवश्यक असलेल्या IP पत्त्यांची संपूर्ण यादी एकाच वेळी fping वर पाठवली गेली आणि परत आम्हाला प्रतिसाद देणाऱ्यांची एक तयार यादी प्राप्त झाली. आमच्या विपरीत, fping प्रक्रियांना समांतर करण्यात सक्षम होते.

WEB द्वारे काही सेवा सेट करणे हे दुसरे सामान्य नित्य कार्य होते. बरं, उदाहरणार्थ, एमएस एक्सचेंजकडून ईसीपी. मुळात तो फक्त एक दुवा आहे. आणि आम्ही ठरवले की आम्हाला अशा लिंक्स थेट सिस्टममध्ये जोडण्यास सक्षम असणे आवश्यक आहे, जेणेकरून विशिष्ट क्लायंटच्या ईसीपीमध्ये प्रवेश कसा करायचा यासाठी दस्तऐवजात किंवा कुठेतरी बुकमार्कमध्ये पहावे लागणार नाही. अशा प्रकारे सिस्टमसाठी संसाधन लिंक्सची संकल्पना प्रकट झाली, त्यांची कार्यक्षमता आजपर्यंत उपलब्ध आहे आणि जवळजवळ बदललेली नाही.

Veliam मध्ये संसाधन लिंक कसे कार्य करतात

रिमोट कनेक्शन

Veliam च्या सध्याच्या आवृत्तीत कृतीत असे दिसते

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

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

आमच्या सिस्टममधील क्लायंट हा एक ब्राउझर होता ज्याला संगणकाच्या स्थानिक स्त्रोतांमध्ये प्रवेश नाही हे लक्षात घेऊन, आम्हाला आवश्यक असलेले अनुप्रयोग फक्त काही कमांडसह लॉन्च करण्यासाठी, "विंडोज" द्वारे सर्वकाही करण्याचा शोध लावला गेला. कस्टम url योजना". अशा प्रकारे आमच्या सिस्टमसाठी एक विशिष्ट "प्लगइन" दिसू लागले, ज्यामध्ये फक्त पुट्टी आणि रिमोट डेस्कटॉप प्लस समाविष्ट होते आणि इंस्टॉलेशन दरम्यान, फक्त विंडोजमध्ये यूआरआय योजना नोंदणीकृत होते. आता, जेव्हा आम्हाला आरडीपी किंवा एसएसएच द्वारे ऑब्जेक्टशी कनेक्ट करायचे होते, तेव्हा आम्ही आमच्या सिस्टमवर ही क्रिया क्लिक केली आणि कस्टम यूआरआय कार्य केले. Windows किंवा putty मध्ये तयार केलेले मानक mstsc.exe, जो “प्लगइन” चा भाग होता, लाँच केला गेला. मी प्लगइन हा शब्द कोट्समध्ये ठेवला आहे कारण हे शास्त्रीय अर्थाने ब्राउझर प्लगइन नाही.

किमान ते काहीतरी होते. सोयीस्कर अॅड्रेस बुक. शिवाय, पुट्टीच्या बाबतीत, सर्व काही सामान्यतः ठीक होते; त्यास इनपुट पॅरामीटर्स म्हणून आयपी कनेक्शन, लॉगिन आणि पासवर्ड दिले जाऊ शकतात. त्या. आम्ही आमच्या नेटवर्कवरील लिनक्स सर्व्हरशी आधीच पासवर्ड न टाकता एका क्लिकवर कनेक्ट केले आहे. पण RDP सह हे इतके सोपे नाही. मानक mstsc मापदंड म्हणून क्रेडेन्शियल देऊ शकत नाही. रिमोट डेस्कटॉप प्लस बचावासाठी आला. त्याने हे होऊ दिले. आता आम्ही त्याशिवाय करू शकतो, परंतु बर्याच काळापासून ते आमच्या सिस्टममध्ये विश्वासू सहाय्यक होते. HTTP(S) साइट्ससह सर्वकाही सोपे आहे, अशा वस्तू ब्राउझरमध्ये उघडल्या जातात आणि तेच. सोयीस्कर आणि व्यावहारिक. पण हा आनंद फक्त अंतर्गत नेटवर्कवर होता.

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

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

जेव्हा मी सिस्टममध्ये मला आवश्यक असलेल्या ऑब्जेक्टवर क्लिक करतो तेव्हा केंद्रीय मॉनिटरिंग सर्व्हर, सर्व क्लायंट Mikrotik चे SSH खाती जाणून घेऊन, इच्छित एकाशी जोडतो, इच्छित होस्टला फॉरवर्डिंग नियम तयार करतो याची खात्री करण्यासाठी या कल्पनेचा जन्म झाला. आवश्यक पोर्ट. येथे अनेक मुद्दे आहेत. उपाय सार्वत्रिक नाही - ते फक्त Mikrotik साठी कार्य करेल, कारण कमांड सिंटॅक्स सर्व राउटरसाठी भिन्न आहे. तसेच, अशा फॉरवर्डिंगला नंतर कसे तरी हटवावे लागले आणि आमच्या सिस्टमचा सर्व्हर भाग मूलत: मी माझे RDP सत्र पूर्ण केले की नाही याचा मागोवा घेऊ शकत नाही. बरं, अशा फॉरवर्डिंग क्लायंटसाठी एक छिद्र आहे. पण आम्ही सार्वत्रिकतेचा पाठपुरावा केला नाही, कारण... उत्पादन फक्त आमच्या कंपनीमध्ये वापरले गेले होते आणि ते लोकांसाठी सोडण्याचा कोणताही विचार नव्हता.

प्रत्येक समस्या आपापल्या पद्धतीने सोडवली गेली. नियम तयार केल्यावर, हे फॉरवर्डिंग फक्त एका विशिष्ट बाह्य IP पत्त्यासाठी उपलब्ध होते (ज्यावरून कनेक्शन सुरू केले होते). त्यामुळे सुरक्षेची कोंडी टळली. परंतु अशा प्रत्येक कनेक्शनसह, NAT पृष्ठावर एक Mikrotik नियम जोडला गेला आणि तो साफ केला गेला नाही. आणि प्रत्येकाला माहित आहे की जितके अधिक नियम आहेत तितके राउटरचे प्रोसेसर लोड केले जाईल. आणि सर्वसाधारणपणे, मी हे स्वीकारू शकत नाही की एक दिवस मी काही मिक्रोटिककडे जाईन, आणि तेथे शेकडो मृत, निरुपयोगी नियम असतील.

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

तसे, ते येथे आहे:

global atmonrulecounter {"dontDelete"="dontDelete"}
:foreach i in=[/ip firewall nat find comment~"atmon_script_main"] do={ 
	local dstport [/ip firewall nat get value-name="dst-port" $i]
	local dstaddress [/ip firewall nat get value-name="dst-address" $i]
	local dstaddrport "$dstaddress:$dstport"
	#log warning message=$dstaddrport
	local thereIsCon [/ip firewall connection find dst-address~"$dstaddrport"]
	if ($thereIsCon = "") do={
		set ($atmonrulecounter->$dstport) ($atmonrulecounter->$dstport + 1)
		#:log warning message=($atmonrulecounter->$dstport)
		if (($atmonrulecounter->$dstport) > 5) do={
			#log warning message="Removing nat rules added automaticaly by atmon_script"
			/ip firewall nat remove [/ip firewall nat find comment~"atmon_script_main_$dstport"]
			/ip firewall nat remove [/ip firewall nat find comment~"atmon_script_sub_$dstport"]
			set ($atmonrulecounter->$dstport) 0
		}
	} else {
		set ($atmonrulecounter->$dstport) 0
	}
}

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

Mikrotik बॅकअप

आम्ही सर्व Mikrotik चा बॅकअप FTP वर कॉन्फिगर केला आहे. आणि एकूणच सर्व काही ठीक होते. पण जेव्हा तुम्हाला बॅकअप घ्यायचा असेल तेव्हा तुम्हाला हा FTP उघडावा लागेल आणि तो तिथे शोधावा लागेल. आमच्याकडे एक प्रणाली आहे जिथे सर्व राउटर कनेक्ट केलेले आहेत; आम्ही SSH द्वारे उपकरणांशी संवाद साधू शकतो. आम्ही ते का बनवत नाही जेणेकरून सिस्टम स्वतःच दररोज सर्व Mikrotik कडून बॅकअप घेते, मला वाटले. आणि तो अंमलात आणू लागला. आम्ही कनेक्ट केले, बॅकअप घेतला आणि ते स्टोरेजमध्ये नेले.

Mikrotik कडून बॅकअप घेण्यासाठी PHP मध्ये स्क्रिप्ट कोड:

<?php

	$IP = '0.0.0.0';
	$LOGIN = 'admin';
	$PASSWORD = '';
	$BACKUP_NAME = 'test';

    $connection = ssh2_connect($IP, 22);

    if (!ssh2_auth_password($connection, $LOGIN, $PASSWORD)) exit;

    ssh2_exec($connection, '/system backup save name="atmon" password="atmon"');
    stream_get_contents($connection);
    ssh2_exec($connection, '/export file="atmon.rsc"');
    stream_get_contents($connection);
    sleep(40); // Waiting bakup makes

    $sftp = ssh2_sftp($connection);

    // Download backup file
    $size = filesize("ssh2.sftp://$sftp/atmon.backup");
    $stream = fopen("ssh2.sftp://$sftp/atmon.backup", 'r');
    $contents = '';
    $read = 0;
    $len = $size;
    while ($read < $len && ($buf = fread($stream, $len - $read))) {
        $read += strlen($buf);
        $contents .= $buf;
    }
    file_put_contents ($BACKUP_NAME . ‘.backup’,$contents);
    @fclose($stream);

    sleep(3);
    // Download RSC file
    $size = filesize("ssh2.sftp://$sftp/atmon.rsc");
    $stream = fopen("ssh2.sftp://$sftp/atmon.rsc", 'r');
    $contents = '';
    $read = 0;
    $len = $size;
    while ($read < $len && ($buf = fread($stream, $len - $read))) {
        $read += strlen($buf);
        $contents .= $buf;
    }
    file_put_contents ($BACKUP_NAME . ‘.rsc’,$contents);
    @fclose($stream);

    ssh2_exec($connection, '/file remove atmon.backup');
    ssh2_exec($connection, '/file remove atmon.rsc');

?>

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

अंतर्गत प्रणालीमध्ये ते कसे दिसते याचे स्क्रीनशॉट

सामान्य डेटाबेस स्टोरेजमध्ये संक्रमण

मी आधीच वर लिहिले आहे की कलाकृती दिसल्या. कधीकधी सिस्टममधील ऑब्जेक्ट्सची संपूर्ण यादी अदृश्य होते, कधीकधी ऑब्जेक्ट संपादित करताना, माहिती जतन केली जात नाही आणि ऑब्जेक्टचे तीन वेळा नामकरण करावे लागते. यामुळे सर्वांची प्रचंड चिडचिड झाली. ऑब्जेक्ट्स गायब होणे क्वचितच घडले आणि ही फाईल पुनर्संचयित करून सहजपणे पुनर्संचयित केली गेली, परंतु ऑब्जेक्ट्स संपादित करताना अपयश बर्‍याचदा घडले. बहुधा, मी सुरुवातीला डेटाबेसद्वारे हे केले नाही कारण सपाट टेबलमध्ये सर्व कनेक्शन असलेले झाड ठेवणे कसे शक्य आहे हे माझ्या मनात बसत नव्हते. ते सपाट आहे, परंतु झाड श्रेणीबद्ध आहे. परंतु एकाधिक प्रवेशासाठी एक चांगला उपाय, आणि त्यानंतर (जशी प्रणाली अधिक जटिल होते) व्यवहार, एक DBMS आहे. या समस्येचा सामना करणारा मी कदाचित पहिला नाही. मी गुगल करू लागलो. असे दिसून आले की माझ्या आधी सर्व गोष्टींचा शोध लावला गेला आहे आणि असे बरेच अल्गोरिदम आहेत जे सपाट टेबलवरून झाड तयार करतात. प्रत्येकाकडे पाहिल्यानंतर, मी त्यापैकी एक अंमलात आणला. पण ही आधीच प्रणालीची नवीन आवृत्ती होती, कारण... खरं तर, यामुळे, मला बरेच काही पुन्हा लिहावे लागले. परिणाम नैसर्गिक होता, प्रणालीच्या यादृच्छिक वर्तनाच्या समस्या दूर झाल्या. काहीजण म्हणू शकतात की सॉफ्टवेअर डेव्हलपमेंटच्या क्षेत्रात त्रुटी खूप हौशी आहेत (सिंगल-थ्रेडेड स्क्रिप्ट, फाइलमधील वेगवेगळ्या थ्रेड्समधून एकाच वेळी अनेक वेळा ऍक्सेस केलेली माहिती संग्रहित करणे इ.). कदाचित हे खरे असेल, परंतु माझे मुख्य काम प्रशासन होते, आणि प्रोग्रामिंग ही माझ्या आत्म्यासाठी एक बाजू होती, आणि मला प्रोग्रामरच्या संघात काम करण्याचा अनुभव नव्हता, जिथे अशा मूलभूत गोष्टी माझ्या वरिष्ठांनी मला लगेच सुचवल्या असत्या. कॉम्रेड म्हणून, मी हे सर्व अडथळे स्वतः भरले, परंतु मी साहित्य खूप चांगले शिकले. आणि तसेच, माझ्या कामात क्लायंटसोबतच्या बैठका, कंपनीचा प्रचार करण्याच्या उद्देशाने केलेल्या कृती, कंपनीमधील प्रशासकीय समस्या आणि बरेच काही यांचा समावेश होतो. पण एक ना एक मार्ग, ज्याला आधीच मागणी होती. मुलांनी आणि मी स्वतः आमच्या दैनंदिन कामात उत्पादन वापरले. स्पष्टपणे अयशस्वी कल्पना आणि उपाय होते ज्यावर वेळ वाया गेला होता, परंतु शेवटी हे स्पष्ट झाले की हे एक कार्यरत साधन नाही आणि कोणीही ते वापरले नाही आणि ते वेलीअममध्ये संपले नाही.

हेल्पडेस्क - हेल्पडेस्क

हेल्पडेस्कची स्थापना कशी झाली हे सांगणे वावगे ठरणार नाही. ही एक पूर्णपणे वेगळी कथा आहे, कारण... Veliam मध्ये ही आधीच 3री पूर्णपणे नवीन आवृत्ती आहे, जी मागील सर्व आवृत्तींपेक्षा वेगळी आहे. आता ही एक साधी प्रणाली आहे, अनावश्यक घंटा आणि शिट्ट्यांशिवाय अंतर्ज्ञानी, डोमेनशी समाकलित करण्याची क्षमता, तसेच ईमेलवरील लिंक वापरून कोठूनही समान वापरकर्ता प्रोफाइलमध्ये प्रवेश करण्याची क्षमता आहे. आणि सर्वात महत्त्वाचे म्हणजे, अर्जदाराशी थेट VPN किंवा पोर्ट फॉरवर्डिंगशिवाय कुठूनही (घरी किंवा कार्यालयात) VNC द्वारे कनेक्ट करणे शक्य आहे. मी तुम्हाला सांगेन की आम्ही येथे कसे आलो, आधी काय घडले आणि कोणते भयानक निर्णय घेतले गेले.

आम्ही सुप्रसिद्ध TeamViewer द्वारे वापरकर्त्यांशी कनेक्ट झालो. आम्ही ज्या वापरकर्त्यांना सेवा देतो त्या सर्व संगणकांनी टीव्ही स्थापित केला आहे. पहिली गोष्ट जी आम्ही चूक केली आणि नंतर ती काढून टाकली, ती म्हणजे प्रत्येक HD क्लायंटला हार्डवेअरशी जोडणे. विनंती सोडण्यासाठी वापरकर्त्याने एचडी सिस्टममध्ये कसे लॉग इन केले? टीव्ही व्यतिरिक्त, प्रत्येकाच्या संगणकावर लाजरमध्ये लिहिलेली एक विशेष उपयुक्तता स्थापित केली होती (येथे बरेच लोक डोळे फिरवतील आणि कदाचित ते काय आहे ते Google वर जातील, परंतु मला माहित असलेली सर्वोत्तम संकलित भाषा डेल्फी होती आणि लाजर जवळजवळ समान गोष्ट, फक्त विनामूल्य). सर्वसाधारणपणे, वापरकर्त्याने एक विशेष बॅच फाइल लाँच केली ज्याने ही उपयुक्तता लॉन्च केली, ज्यामुळे सिस्टमचा HWID वाचला आणि त्यानंतर ब्राउझर लॉन्च झाला आणि अधिकृतता आली. हे का केले गेले? काही कंपन्यांमध्ये, सेवा दिलेल्या वापरकर्त्यांची संख्या वैयक्तिकरित्या मोजली जाते आणि प्रत्येक महिन्याची सेवा किंमत लोकांच्या संख्येवर आधारित असते. हे समजण्यासारखे आहे, तुम्ही म्हणाल, पण ते हार्डवेअरशी का बांधले आहे? हे अगदी सोपे आहे, काही व्यक्ती घरी आल्या आणि त्यांनी त्यांच्या घरच्या लॅपटॉपवरून "येथे माझ्यासाठी सर्वकाही सुंदर बनवा" या शैलीत विनंती केली. सिस्टम HWID वाचण्याव्यतिरिक्त, युटिलिटीने रेजिस्ट्रीमधून वर्तमान टीम व्ह्यूअर आयडी काढला आणि तो आमच्याकडे प्रसारित केला. टीम व्ह्यूअरमध्ये एकीकरणासाठी API आहे. आणि आम्ही हे एकत्रीकरण केले. पण एक झेल होता. या API द्वारे, वापरकर्त्याच्या संगणकाशी कनेक्ट करणे अशक्य आहे जेव्हा त्याने हे सत्र स्पष्टपणे सुरू केले नाही आणि त्यास कनेक्ट करण्याचा प्रयत्न केल्यानंतर, त्याने "पुष्टी करा" क्लिक करणे देखील आवश्यक आहे. त्या वेळी, वापरकर्त्याच्या विनंतीशिवाय कोणीही कनेक्ट करू नये हे आम्हाला तर्कसंगत वाटले आणि ती व्यक्ती संगणकावर असल्याने, तो सत्र सुरू करेल आणि रिमोट कनेक्शन विनंतीला होकारार्थी प्रतिसाद देईल. सर्व काही चुकीचे निघाले. अर्जदार सत्र सुरू करण्यासाठी दाबण्यास विसरले, आणि त्यांना टेलिफोन संभाषणात हे सांगावे लागले. यामुळे वेळ वाया गेला आणि प्रक्रियेच्या दोन्ही बाजूंनी निराशा झाली. शिवाय, जेव्हा एखादी व्यक्ती विनंती सोडते तेव्हा अशा क्षणांसाठी हे अजिबात असामान्य नाही, परंतु जेव्हा तो दुपारच्या जेवणासाठी निघतो तेव्हाच कनेक्ट करण्याची परवानगी असते. कारण समस्या गंभीर नाही आणि त्याच्या कामाच्या प्रक्रियेत व्यत्यय येऊ नये असे त्याला वाटत नाही. त्यानुसार, तो कनेक्शनला परवानगी देण्यासाठी कोणतेही बटण दाबणार नाही. हेल्पडेस्कमध्ये लॉग इन करताना अतिरिक्त कार्यक्षमता दिसली - Teamviwer's ID वाचताना. Teamviwer स्थापित करताना वापरला जाणारा कायमस्वरूपी पासवर्ड आम्हाला माहीत होता. अधिक तंतोतंत, केवळ सिस्टमला हे माहित होते, कारण ते इंस्टॉलरमध्ये आणि आमच्या सिस्टममध्ये तयार केले गेले होते. त्यानुसार, ऍप्लिकेशनमधून एक कनेक्शन बटण होते ज्यावर क्लिक करून काहीही प्रतीक्षा करण्याची आवश्यकता नाही, परंतु टीम व्ह्यूअर लगेच उघडले आणि कनेक्शन झाले. परिणामी, दोन प्रकारचे संभाव्य कनेक्शन होते. अधिकृत Teamviewer API द्वारे आणि आमच्या स्व-निर्मित एक. माझ्या आश्चर्याची गोष्ट म्हणजे, त्यांनी प्रथम वापरणे जवळजवळ ताबडतोब बंद केले, जरी ते फक्त विशेष प्रकरणांमध्ये वापरण्याची सूचना होती आणि जेव्हा वापरकर्ता स्वतः पुढे जातो तेव्हा. तरीही, आता मला सुरक्षा द्या. परंतु अर्जदारांना याची गरज नसल्याचे निष्पन्न झाले. पुष्टीकरण बटणाशिवाय त्यांच्याशी कनेक्ट केल्यामुळे ते सर्व पूर्णपणे ठीक आहेत.

Linux मध्ये मल्टीथ्रेडिंगवर स्विच करत आहे

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

PHP स्वतः मल्टीथ्रेडिंगला बॉक्सच्या बाहेर समर्थन देत नाही. बहुप्रक्रिया करण्यास सक्षम, आपण काटा करू शकता. पण, खरं तर, माझ्याकडे आधीच एक मतदान यंत्रणा लिहून ठेवली होती आणि मला ते बनवायचे होते जेणेकरून मी एकदा डेटाबेसमधून मला आवश्यक असलेल्या सर्व नोड्सची गणना करू, सर्वकाही एकाच वेळी पिंग करू, प्रत्येकाच्या प्रतिसादाची प्रतीक्षा करा आणि त्यानंतरच लगेच लिहा. माहिती. हे वाचलेल्या विनंत्यांच्या संख्येवर बचत करते. मल्टीथ्रेडिंग या कल्पनेत पूर्णपणे फिट आहे. PHP साठी एक PThreads मॉड्यूल आहे जे तुम्हाला वास्तविक मल्टीथ्रेडिंग करण्यास अनुमती देते, जरी हे PHP 7.2 वर सेट करण्यासाठी योग्य प्रमाणात टिंकरिंग करावे लागले, परंतु ते पूर्ण झाले. पोर्ट स्कॅनिंग आणि पिंग आता जलद आहेत. आणि त्याऐवजी, उदाहरणार्थ, प्रति लॅप 15 सेकंद पूर्वी, ही प्रक्रिया 2 सेकंद घेऊ लागली. त्याचा चांगला परिणाम झाला.

नवीन कंपन्यांचे त्वरित ऑडिट

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

परंतु ऑडिटच्या परिणामामध्ये सामान्यत: विविध माहितीचा समूह समाविष्ट असतो आणि त्यापैकी एक म्हणजे नेटवर्कवर कोणत्या प्रकारची उपकरणे आहेत. सर्व प्रथम, आम्हाला डोमेनचा भाग म्हणून विंडोज सर्व्हर आणि विंडोज वर्कस्टेशन्समध्ये रस होता. मध्यम आणि मोठ्या कंपन्यांमध्ये डोमेनचा अभाव हा नियमाला अपवाद आहे. एक भाषा बोलण्यासाठी, माझ्या मते, सरासरी 100+ लोक आहेत. सर्व विंडोज मशीन्स आणि सर्व्हरवरून डेटा संकलित करण्याचा मार्ग शोधणे आवश्यक होते, त्यांचे IP आणि डोमेन प्रशासक खाते जाणून, परंतु त्या प्रत्येकावर कोणतेही सॉफ्टवेअर स्थापित न करता. WMI इंटरफेस बचावासाठी येतो. विंडोज मॅनेजमेंट इंस्ट्रुमेंटेशन (WMI) चा अर्थ विंडोज मॅनेजमेंट टूल्स असा होतो. Windows प्लॅटफॉर्मवर चालणार्‍या कॉम्प्युटर इन्फ्रास्ट्रक्चरच्या विविध भागांच्या ऑपरेशनचे केंद्रीकृत व्यवस्थापन आणि देखरेख करण्यासाठी WMI हे एक मूलभूत तंत्रज्ञान आहे. विकीवर घेतलेले. पुढे, डेबियनसाठी wmic (हा WMI क्लायंट आहे) संकलित करण्यासाठी मला पुन्हा टिंकर करावे लागले. सर्वकाही तयार झाल्यानंतर, फक्त आवश्यक माहितीसाठी wmic द्वारे आवश्यक नोड्सचे मतदान करणे बाकी होते. WMI द्वारे आपण Windows संगणकावरून जवळजवळ कोणतीही माहिती मिळवू शकता आणि त्याशिवाय, आपण त्याद्वारे संगणक नियंत्रित देखील करू शकता, उदाहरणार्थ, रीबूट करण्यासाठी पाठवा. आमच्या सिस्टममधील विंडोज स्टेशन आणि सर्व्हरबद्दल माहितीचे संकलन अशा प्रकारे दिसून आले. या व्यतिरिक्त, वर्तमान प्रणाली लोड निर्देशकांबद्दल वर्तमान माहिती होती. आम्ही त्यांना अधिक वेळा विनंती करतो आणि हार्डवेअरवरील माहिती कमी वेळा. यानंतर ऑडिटिंग थोडे अधिक आनंददायक झाले.

सॉफ्टवेअर वितरण निर्णय

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

सुधारणा

दुसरा भाग

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