🥇आउटसोर्सिंग से विकास तक (भाग 1)

सभी को नमस्कार, मेरा नाम सर्गेई एमिलांचिक है। मैं ऑडिट-टेलीकॉम कंपनी का प्रमुख, वेलियम सिस्टम का मुख्य डेवलपर और लेखक हूं। मैंने इस बारे में एक लेख लिखने का फैसला किया कि कैसे मैंने और मेरे दोस्त ने एक आउटसोर्सिंग कंपनी बनाई, अपने लिए सॉफ्टवेयर लिखा और बाद में इसे SaaS सिस्टम के माध्यम से सभी को वितरित करना शुरू किया। इस बारे में कि कैसे मुझे स्पष्ट रूप से विश्वास नहीं हुआ कि यह संभव है। लेख में न केवल एक कहानी होगी, बल्कि वेलियम उत्पाद कैसे बनाया गया, इसका तकनीकी विवरण भी होगा। स्रोत कोड के कुछ टुकड़े भी शामिल हैं। मैं आपको बाद में बताऊंगा कि हमने क्या गलतियाँ कीं और हमने उन्हें कैसे सुधारा। इस बात पर संदेह था कि ऐसा लेख प्रकाशित किया जाए या नहीं। लेकिन मैंने सोचा कि लेख प्रकाशित न करने और यह सोचने से बेहतर है कि ऐसा किया जाए, प्रतिक्रिया प्राप्त की जाए और सुधार किया जाए कि क्या होता अगर...

पृष्ठभूमि

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

हमारे पास निगरानी थी, लेकिन पूरी तरह अकादमिक रुचि से मैं अपना सबसे सरल लिखने का प्रयास करना चाहता था। विचार यह था: मैं चाहता था कि यह वेब पर हो, ताकि मैं बिना किसी क्लाइंट को इंस्टॉल किए आसानी से इसमें जा सकूं और देख सकूं कि वाई-फाई के माध्यम से मोबाइल डिवाइस सहित किसी भी डिवाइस से नेटवर्क के साथ क्या हो रहा है, और मैं वास्तव में भी जल्दी से समझना चाहता था कि कमरे में क्या उपकरण है जो "मोपी" बन गया है क्योंकि... ऐसी समस्याओं पर प्रतिक्रिया समय के लिए बहुत सख्त आवश्यकताएं थीं। परिणामस्वरूप, मेरे दिमाग में एक साधारण वेब पेज लिखने की योजना पैदा हुई, जिस पर नेटवर्क आरेख के साथ एक जेपीईजी पृष्ठभूमि थी, इस चित्र में डिवाइसों को उनके आईपी पते के साथ काट दिया गया, और शीर्ष पर गतिशील सामग्री दिखाई गई हरे या चमकते लाल आईपी पते के रूप में आवश्यक निर्देशांक में चित्र। कार्य निर्धारित हो गया है, आइए शुरू करें।

पहले, मैं डेल्फ़ी, PHP, JS और बहुत सतही रूप से C++ में प्रोग्रामिंग कर रहा था। मैं अच्छी तरह जानता हूं कि नेटवर्क कैसे काम करता है। वीएलएएन, रूटिंग (ओएसपीएफ, ईआईजीआरपी, बीजीपी), एनएटी। यह मेरे लिए स्वयं एक आदिम निगरानी प्रोटोटाइप लिखने के लिए पर्याप्त था।

मैंने PHP में वही लिखा जो मैंने योजना बनाई थी। अपाचे और PHP सर्वर विंडोज़ पर थे क्योंकि... उस समय मेरे लिए लिनक्स कुछ समझ से बाहर और बहुत जटिल था, जैसा कि बाद में पता चला, मैं बहुत गलत था और कई जगहों पर लिनक्स विंडोज की तुलना में बहुत सरल है, लेकिन यह एक अलग विषय है और हम सभी जानते हैं कि कितने होलीवर्स हैं इस विषय। विंडोज टास्क शेड्यूलर ने एक छोटे अंतराल पर (मुझे ठीक से याद नहीं है, लेकिन हर तीन सेकंड में एक बार ऐसा होता है) एक PHP स्क्रिप्ट खींची, जिसने सभी ऑब्जेक्ट्स को सामान्य पिंग के साथ पोल किया और स्थिति को एक फ़ाइल में सहेजा।

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

हाँ, हाँ, उस समय डेटाबेस के साथ काम करना भी मेरे लिए आसान नहीं था। मुझे नहीं पता था कि प्रक्रियाओं को समानांतर करना संभव था, और सभी नेटवर्क नोड्स से गुजरने में काफी समय लगता था, क्योंकि... यह एक सूत्र में घटित हुआ। समस्याएँ विशेष रूप से तब उत्पन्न हुईं जब कई नोड अनुपलब्ध थे, क्योंकि उनमें से प्रत्येक ने स्क्रिप्ट को 300 एमएस तक विलंबित कर दिया। क्लाइंट पक्ष पर एक सरल लूपिंग फ़ंक्शन था, जो कुछ सेकंड के अंतराल पर, अजाक्स अनुरोध के साथ सर्वर से अद्यतन जानकारी डाउनलोड करता था और इंटरफ़ेस को अपडेट करता था। ठीक है, फिर, लगातार 3 असफल पिंग के बाद, यदि मॉनिटरिंग वाला एक वेब पेज कंप्यूटर पर खुला था, तो एक हर्षित रचना बजती थी।

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

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

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

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

इसके अलावा, रोजमर्रा के काम में मुझे क्रॉस-क्रॉसिंग करना पड़ता था। और मैं हर बार सिस्को स्विच पर जाकर यह देखने से थक गया कि किस इंटरफ़ेस का उपयोग करना है। मॉनिटरिंग में किसी ऑब्जेक्ट पर क्लिक करना और विवरण के साथ उसके इंटरफेस की सूची देखना कितना अच्छा होगा। इससे मेरा समय बचेगा. इसके अलावा, इस योजना में खातों और कमांडों को दर्ज करने के लिए पुट्टी या सिक्योरसीआरटी चलाने की आवश्यकता नहीं होगी। मैंने बस मॉनिटरिंग पर क्लिक किया, देखा कि क्या आवश्यक है और अपना काम करने चला गया। मैंने स्विचों के साथ इंटरैक्ट करने के तरीकों की तलाश शुरू कर दी। मुझे तुरंत 2 विकल्प मिले: एसएनएमपी या एसएसएच के माध्यम से स्विच में लॉग इन करना, मेरे लिए आवश्यक कमांड दर्ज करना और परिणाम को पार्स करना। मैंने इसके कार्यान्वयन की जटिलता के कारण एसएनएमपी को खारिज कर दिया; मैं परिणाम प्राप्त करने के लिए अधीर था। एसएनएमपी के साथ, आपको लंबे समय तक एमआईबी में खुदाई करनी होगी और इस डेटा के आधार पर इंटरफेस के बारे में डेटा तैयार करना होगा। सिस्को में एक अद्भुत टीम है

show interface status

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

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

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

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

जैसे-जैसे समय बीतता गया, मैंने अन्य कंपनियों में अंशकालिक काम करना शुरू कर दिया, सौभाग्य से मेरे कार्य शेड्यूल ने मुझे ऐसा करने की अनुमति दी। जब आप अलग-अलग कंपनियों में काम करते हैं, तो विभिन्न क्षेत्रों में आपका कौशल बहुत तेज़ी से बढ़ता है, और आपका क्षितिज भी अच्छी तरह विकसित होता है। ऐसी कंपनियाँ हैं जिनमें, जैसा कि वे कहते हैं, आप एक स्वीडिश, एक रीपर और एक तुरही वादक हैं। एक ओर, यह कठिन है, दूसरी ओर, यदि आप आलसी नहीं हैं, तो आप एक सामान्यवादी बन जाते हैं और यह आपको समस्याओं को तेजी से और अधिक कुशलता से हल करने की अनुमति देता है क्योंकि आप जानते हैं कि संबंधित क्षेत्र कैसे काम करता है।

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

अंततः, हम एक ऐसा विकल्प ढूंढने में सफल रहे जो हम दोनों के लिए उपयुक्त हो और हम वही करें जो हम जानते हैं कि कैसे करना है। 2016 में, हमने एक आईटी कंपनी बनाने का फैसला किया जो व्यवसायों को आईटी समस्याओं को हल करने में मदद करेगी। यह आईटी सिस्टम (1सी, टर्मिनल सर्वर, मेल सर्वर इत्यादि) की तैनाती, उनका रखरखाव, उपयोगकर्ताओं और नेटवर्क प्रशासन के लिए क्लासिक हेल्पडेस्क है।

सच कहूँ तो, कंपनी बनाते समय मुझे इस पर लगभग 99,9% विश्वास नहीं था। लेकिन किसी तरह पावेल मुझसे कोशिश करवाने में सफल रहा और आगे देखने पर पता चला कि वह सही था। पावेल और मैंने प्रत्येक को 300 रूबल का भुगतान किया, एक नया एलएलसी "ऑडिट-टेलीकॉम" पंजीकृत किया, एक छोटा सा कार्यालय किराए पर लिया, अच्छे व्यवसाय कार्ड बनाए, ठीक है, सामान्य तौर पर, शायद अधिकांश अनुभवहीन, नौसिखिया व्यवसायियों की तरह, और ग्राहकों की तलाश शुरू कर दी। ग्राहक ढूँढना एक पूरी तरह से अलग कहानी है। यदि किसी की रुचि हो तो शायद हम कॉर्पोरेट ब्लॉग के हिस्से के रूप में एक अलग लेख लिखेंगे। कोल्ड कॉल, फ़्लायर्स इत्यादि। इसका कोई नतीजा नहीं निकला. जैसा कि मैंने अब व्यवसाय के बारे में कई कहानियाँ पढ़ी हैं, किसी न किसी रूप में, बहुत कुछ भाग्य पर निर्भर करता है। हम खुशनसीब हैं। और कंपनी के निर्माण के कुछ हफ़्ते बाद, मेरे भाई व्लादिमीर ने हमसे संपर्क किया, जो हमारे लिए पहला ग्राहक लेकर आया। मैं आपको ग्राहकों के साथ काम करने के विवरण के साथ बोर नहीं करूंगा, लेख इस बारे में नहीं है, मैं सिर्फ इतना कहूंगा कि हम एक ऑडिट के लिए गए थे, महत्वपूर्ण क्षेत्रों की पहचान की और ये क्षेत्र तब टूट गए जब निर्णय लिया गया कि क्या करना है या नहीं आउटसोर्सर के रूप में निरंतर आधार पर हमारे साथ सहयोग करें। इसके बाद तुरंत सकारात्मक निर्णय लिया गया.

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

आपके मॉनिटरिंग सिस्टम पर काम जारी है

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

तो कार्य हैं:

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

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

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

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

परिणाम अक्सर गलत होते थे और स्कैन को पूरा होने में काफी समय लगता था। मैं पिंग के बारे में पूरी तरह से भूल गया, यह एफपिंग के माध्यम से किया गया था:

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

यह भी समानांतर नहीं था और इसलिए यह प्रक्रिया बहुत लंबी थी। बाद में, सत्यापन के लिए आवश्यक आईपी पतों की पूरी सूची एक ही बार में एफपिंग को भेज दी गई, और वापस हमें प्रतिक्रिया देने वालों की एक तैयार सूची प्राप्त हुई। हमारे विपरीत, एफपिंग प्रक्रियाओं को समानांतर करने में सक्षम था।

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

वेलियम में संसाधन लिंक कैसे काम करते हैं

दूरस्थ कनेक्शन

वेलियम के वर्तमान संस्करण में यह वैसा ही दिखता है

कार्यों में से एक सर्वर से जल्दी और आसानी से कनेक्ट करना था, जिनमें से पहले से ही कई (सौ से अधिक) थे और लाखों पूर्व-सहेजे गए आरडीपी शॉर्टकट के माध्यम से सॉर्ट करना बेहद असुविधाजनक था। एक उपकरण की आवश्यकता थी. इंटरनेट पर ऐसे सॉफ़्टवेयर हैं जो ऐसे आरडीपी कनेक्शनों के लिए पता पुस्तिका की तरह कुछ हैं, लेकिन वे निगरानी प्रणाली के साथ एकीकृत नहीं हैं, और खातों को सहेजा नहीं जा सकता है। जब आप दिन में दर्जनों बार अलग-अलग सर्वर से जुड़ते हैं तो हर बार अलग-अलग ग्राहकों के लिए खाते दर्ज करना बिल्कुल नरक है। एसएसएच के साथ चीजें थोड़ी बेहतर हैं; बहुत सारे अच्छे सॉफ्टवेयर हैं जो आपको ऐसे कनेक्शनों को फ़ोल्डरों में व्यवस्थित करने और उनसे खातों को याद रखने की अनुमति देते हैं। लेकिन 2 समस्याएं हैं. पहला यह कि हमें आरडीपी और एसएसएच कनेक्शन के लिए एक भी प्रोग्राम नहीं मिला। दूसरा यह है कि अगर किसी बिंदु पर मैं अपने कंप्यूटर पर नहीं हूं और मुझे जल्दी से कनेक्ट करने की आवश्यकता है, या मैंने सिस्टम को फिर से इंस्टॉल किया है, तो मुझे इस क्लाइंट के खाते को देखने के लिए दस्तावेज़ में जाना होगा। यह असुविधाजनक है और समय की बर्बादी है.

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

इस तथ्य को ध्यान में रखते हुए कि हमारे सिस्टम में क्लाइंट एक ब्राउज़र था जिसकी कंप्यूटर के स्थानीय संसाधनों तक पहुंच नहीं थी, बस कुछ कमांड के साथ हमें आवश्यक एप्लिकेशन लॉन्च करने के लिए, "विंडोज़" के माध्यम से सब कुछ करने के लिए इसका आविष्कार किया गया था। कस्टम यूआरएल योजना” इस प्रकार हमारे सिस्टम के लिए एक निश्चित "प्लगइन" दिखाई दिया, जिसमें केवल पुट्टी और रिमोट डेस्कटॉप प्लस शामिल थे और, इंस्टॉलेशन के दौरान, बस विंडोज़ में यूआरआई योजना पंजीकृत की गई थी। अब, जब हम आरडीपी या एसएसएच के माध्यम से किसी ऑब्जेक्ट से कनेक्ट करना चाहते थे, तो हमने अपने सिस्टम पर इस क्रिया पर क्लिक किया और कस्टम यूआरआई ने काम किया। विंडोज़ या पुट्टी में निर्मित मानक mstsc.exe, जो "प्लगइन" का हिस्सा था, लॉन्च किया गया था। मैंने प्लगइन शब्द को उद्धरण चिह्नों में रखा है क्योंकि यह शास्त्रीय अर्थ में ब्राउज़र प्लगइन नहीं है।

कम से कम वह कुछ तो था. सुविधाजनक पता पुस्तिका. इसके अलावा, पुट्टी के मामले में, सब कुछ आम तौर पर ठीक था; इसे इनपुट पैरामीटर के रूप में आईपी कनेक्शन, लॉगिन और पासवर्ड दिया जा सकता था। वे। हम पहले ही अपने नेटवर्क पर बिना पासवर्ड डाले एक क्लिक से लिनक्स सर्वर से जुड़ चुके हैं। लेकिन आरडीपी के साथ यह इतना आसान नहीं है। मानक एमएसटीएससी पैरामीटर के रूप में क्रेडेंशियल्स की आपूर्ति नहीं कर सकता है। रिमोट डेस्कटॉप प्लस बचाव के लिए आया। उन्होंने ऐसा होने दिया. अब हम इसके बिना काम चला सकते हैं, लेकिन लंबे समय तक यह हमारे सिस्टम में एक वफादार सहायक था। HTTP(S) साइटों के साथ सब कुछ सरल है, ऐसी वस्तुएं बस ब्राउज़र में खुलती हैं और बस इतना ही। सुविधाजनक और व्यावहारिक. लेकिन यह ख़ुशी केवल आंतरिक नेटवर्क पर थी।

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

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

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

प्रत्येक समस्या का समाधान अपने तरीके से किया गया। जब नियम बनाया गया था, तो यह अग्रेषण केवल एक विशिष्ट बाहरी आईपी पते (जिससे कनेक्शन प्रारंभ किया गया था) के लिए उपलब्ध था। इसलिए सुरक्षा छेद होने से बच गया। लेकिन ऐसे प्रत्येक कनेक्शन के साथ, NAT पृष्ठ पर एक मिक्रोटिक नियम जोड़ा गया और उसे साफ़ नहीं किया गया। और हर कोई जानता है कि जितने अधिक नियम होंगे, राउटर का प्रोसेसर उतना ही अधिक लोड होगा। और सामान्य तौर पर, मैं यह स्वीकार नहीं कर सका कि एक दिन मैं किसी मिक्रोटिक में जाऊंगा, और वहां सैकड़ों मृत, बेकार नियम होंगे।

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

वैसे, यहाँ यह है:

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
	}
}

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

मिकरोटिक बैकअप

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

मिकरोटिक से बैकअप लेने के लिए 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');

?>

बैकअप दो रूपों में लिया जाता है - बाइनरी और टेक्स्ट कॉन्फिग। बाइनरी आवश्यक कॉन्फ़िगरेशन को तुरंत पुनर्स्थापित करने में मदद करता है, और टेक्स्ट आपको यह समझने की अनुमति देता है कि यदि उपकरण का जबरन प्रतिस्थापन होता है और बाइनरी को उस पर अपलोड नहीं किया जा सकता है तो क्या करने की आवश्यकता है। परिणामस्वरूप, हमें सिस्टम में एक और सुविधाजनक कार्यक्षमता मिली। इसके अलावा, नया मिक्रोटिक जोड़ते समय, कुछ भी कॉन्फ़िगर करने की आवश्यकता नहीं थी; मैंने बस सिस्टम में ऑब्जेक्ट जोड़ा और एसएसएच के माध्यम से इसके लिए एक खाता सेट किया। फिर सिस्टम ने ही बैकअप लेने का काम संभाल लिया. SaaS Veliam के वर्तमान संस्करण में अभी तक यह कार्यक्षमता नहीं है, लेकिन हम इसे जल्द ही पोर्ट कर देंगे।

आंतरिक सिस्टम में यह कैसा दिखता था इसके स्क्रीनशॉट

सामान्य डेटाबेस भंडारण में संक्रमण

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

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

यह बताना अतिश्योक्ति नहीं होगी कि हेल्पडेस्क का गठन कैसे हुआ। यह बिल्कुल अलग कहानी है, क्योंकि... वेलियाम में यह पहले से ही तीसरा पूरी तरह से नया संस्करण है, जो पिछले सभी से अलग है। अब यह एक सरल प्रणाली है, जो अनावश्यक घंटियों और सीटियों के बिना सहज है, एक डोमेन के साथ एकीकृत करने की क्षमता के साथ-साथ एक ईमेल से लिंक का उपयोग करके कहीं से भी एक ही उपयोगकर्ता प्रोफ़ाइल तक पहुंचने की क्षमता है। और सबसे महत्वपूर्ण बात यह है कि वीपीएन या पोर्ट फ़ॉरवर्डिंग के बिना कहीं से भी (घर पर या कार्यालय में) सीधे आवेदन से वीएनसी के माध्यम से आवेदक से जुड़ना संभव है। मैं आपको बताऊंगा कि हम यहां तक कैसे पहुंचे, पहले क्या हुआ और क्या भयानक निर्णय लिए गए।

हम प्रसिद्ध टीमव्यूअर के माध्यम से उपयोगकर्ताओं से जुड़े। जिन कंप्यूटरों के उपयोगकर्ताओं को हम सेवा प्रदान करते हैं उनमें टीवी स्थापित है। पहली चीज़ जो हमने गलत की, और बाद में उसे हटा दिया, वह थी प्रत्येक एचडी क्लाइंट को हार्डवेयर से जोड़ना। अनुरोध छोड़ने के लिए उपयोगकर्ता ने एचडी सिस्टम में कैसे लॉग इन किया? टीवी के अलावा, हर किसी के कंप्यूटर पर एक विशेष उपयोगिता स्थापित थी, जो लाजर में लिखी गई थी (यहां कई लोग अपनी आंखें घुमाएंगे, और शायद Google पर भी जाएं कि यह क्या है, लेकिन सबसे अच्छी संकलित भाषा जो मैं जानता था वह डेल्फी थी, और लाजर लगभग है) वही चीज़, केवल मुफ़्त)। सामान्य तौर पर, उपयोगकर्ता ने एक विशेष बैच फ़ाइल लॉन्च की जिसने इस उपयोगिता को लॉन्च किया, जो बदले में सिस्टम के HWID को पढ़ता है और उसके बाद ब्राउज़र लॉन्च होता है और प्राधिकरण होता है। ऐसा क्यों किया गया? कुछ कंपनियों में, सेवा प्राप्त उपयोगकर्ताओं की संख्या को व्यक्तिगत रूप से गिना जाता है, और प्रत्येक माह के लिए सेवा की कीमत लोगों की संख्या पर आधारित होती है। आप कहते हैं, यह समझ में आता है, लेकिन यह हार्डवेयर से क्यों जुड़ा है? यह बहुत सरल है, कुछ लोग घर आए और अपने घर के लैपटॉप से "यहाँ मेरे लिए सब कुछ सुंदर बनाओ" की शैली में अनुरोध किया। सिस्टम HWID को पढ़ने के अलावा, उपयोगिता ने वर्तमान टीमव्यूअर आईडी को रजिस्ट्री से खींच लिया और इसे हमें भी भेज दिया। टीमव्यूअर के पास एकीकरण के लिए एक एपीआई है। और हमने यह एकीकरण किया. लेकिन एक कैच था. इन एपीआई के माध्यम से, उपयोगकर्ता के कंप्यूटर से कनेक्ट करना असंभव है जब वह स्पष्ट रूप से इस सत्र को शुरू नहीं करता है और इससे कनेक्ट करने का प्रयास करने के बाद, उसे "पुष्टि करें" पर भी क्लिक करना होगा। उस समय, यह हमें तर्कसंगत लगा कि किसी को भी उपयोगकर्ता के अनुरोध के बिना कनेक्ट नहीं करना चाहिए, और चूंकि व्यक्ति कंप्यूटर पर है, वह सत्र शुरू करेगा और दूरस्थ कनेक्शन अनुरोध पर सकारात्मक प्रतिक्रिया देगा। सबकुछ ग़लत निकला. आवेदक सत्र आरंभ करने के लिए प्रेस करना भूल गए, और उन्हें टेलीफोन पर बातचीत में यह बताना पड़ा। इससे समय बर्बाद हुआ और प्रक्रिया के दोनों तरफ निराशा हुई। इसके अलावा, ऐसे क्षणों के लिए यह बिल्कुल भी असामान्य नहीं है जब कोई व्यक्ति अनुरोध छोड़ता है, लेकिन उसे तभी जुड़ने की अनुमति दी जाती है जब वह दोपहर के भोजन के लिए निकलता है। क्योंकि समस्या गंभीर नहीं है और वह नहीं चाहते कि उनकी कार्य प्रक्रिया बाधित हो. तदनुसार, वह कनेक्शन की अनुमति देने के लिए कोई बटन नहीं दबाएगा। हेल्पडेस्क में लॉग इन करते समय टीमविवर की आईडी पढ़ते समय अतिरिक्त कार्यक्षमता इस प्रकार दिखाई दी। हम उस स्थायी पासवर्ड को जानते थे जिसका उपयोग टीमविवर को स्थापित करते समय किया गया था। अधिक सटीक रूप से, केवल सिस्टम ही इसे जानता था, क्योंकि यह इंस्टॉलर और हमारे सिस्टम में बनाया गया था। तदनुसार, एप्लिकेशन से एक कनेक्शन बटन था जिस पर क्लिक करने पर कुछ भी इंतजार करने की आवश्यकता नहीं थी, लेकिन टीमव्यूअर तुरंत खुल गया और एक कनेक्शन हो गया। परिणामस्वरूप, दो प्रकार के संभावित कनेक्शन थे। आधिकारिक टीमव्यूअर एपीआई और हमारे स्व-निर्मित एपीआई के माध्यम से। मेरे आश्चर्य के लिए, उन्होंने पहले वाले का उपयोग लगभग तुरंत बंद कर दिया, हालांकि इसे केवल विशेष मामलों में उपयोग करने का निर्देश था और जब उपयोगकर्ता स्वयं इसे आगे बढ़ाता है। फिर भी अब मुझे सुरक्षा दीजिए. लेकिन पता चला कि आवेदकों को इसकी जरूरत नहीं थी. पुष्टिकरण बटन के बिना उनसे जुड़े रहने से वे बिल्कुल ठीक हैं।

लिनक्स में मल्टीथ्रेडिंग पर स्विच करना

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

PHP स्वयं बॉक्स से बाहर मल्टीथ्रेडिंग का समर्थन नहीं करता है। मल्टीप्रोसेसिंग में सक्षम, आप फोर्क कर सकते हैं। लेकिन, वास्तव में, मेरे पास पहले से ही एक मतदान तंत्र लिखा हुआ था और मैं इसे बनाना चाहता था ताकि मैं एक बार डेटाबेस से सभी आवश्यक नोड्स की गिनती कर सकूं, एक ही बार में सब कुछ पिंग कर सकूं, प्रत्येक से प्रतिक्रिया की प्रतीक्षा कर सकूं और उसके बाद ही तुरंत लिख सकूं आंकड़ा। इससे पढ़ने के अनुरोधों की संख्या में बचत होती है। मल्टीथ्रेडिंग इस विचार में बिल्कुल फिट बैठता है। PHP के लिए एक PThreads मॉड्यूल है जो आपको वास्तविक मल्टीथ्रेडिंग करने की अनुमति देता है, हालाँकि इसे PHP 7.2 पर सेट करने के लिए काफी मेहनत करनी पड़ी, लेकिन यह किया गया। पोर्ट स्कैनिंग और पिंग अब तेज़ हैं। और, उदाहरण के लिए, पहले प्रति लैप 15 सेकंड के बजाय, इस प्रक्रिया में 2 सेकंड लगने लगे। यह एक अच्छा परिणाम था.

नई कंपनियों का त्वरित ऑडिट

विभिन्न मेट्रिक्स और हार्डवेयर विशेषताओं को एकत्रित करने की कार्यक्षमता कैसे आई? यह आसान है। कभी-कभी हमें केवल मौजूदा आईटी बुनियादी ढांचे का ऑडिट करने का आदेश दिया जाता है। खैर, नए ग्राहक के ऑडिट में तेजी लाने के लिए भी यही बात जरूरी है। हमें कुछ ऐसी चीज़ की ज़रूरत थी जो हमें एक मध्यम या बड़ी कंपनी में आने और तुरंत पता लगाने की अनुमति दे कि उनके पास क्या है। मेरी राय में, आंतरिक नेटवर्क पर पिंग केवल उन लोगों द्वारा अवरुद्ध किया जाता है जो अपने जीवन को जटिल बनाना चाहते हैं, और हमारे अनुभव में उनमें से कुछ ही हैं। लेकिन ऐसे लोग भी हैं. तदनुसार, आप एक साधारण पिंग के साथ उपकरणों की उपस्थिति के लिए नेटवर्क को तुरंत स्कैन कर सकते हैं। फिर हम उन्हें जोड़ सकते हैं और उन खुले पोर्ट को स्कैन कर सकते हैं जिनमें हमारी रुचि है। वास्तव में, यह कार्यक्षमता पहले से ही मौजूद थी; केवल केंद्रीय सर्वर से स्लेव सर्वर में एक कमांड जोड़ना आवश्यक था ताकि यह निर्दिष्ट नेटवर्क को स्कैन कर सके और जो कुछ भी मिला उसे सूची में जोड़ सके। मैं बताना भूल गया, यह माना गया था कि हमारे पास पहले से ही एक कॉन्फ़िगर सिस्टम (स्लेव मॉनिटरिंग सर्वर) के साथ एक तैयार छवि थी जिसे हम ऑडिट के दौरान क्लाइंट से आसानी से रोल आउट कर सकते थे और इसे अपने क्लाउड से कनेक्ट कर सकते थे।

लेकिन ऑडिट के परिणाम में आमतौर पर विभिन्न सूचनाओं का एक समूह शामिल होता है, और उनमें से एक यह है कि नेटवर्क पर किस प्रकार के उपकरण हैं। सबसे पहले, हम एक डोमेन के हिस्से के रूप में विंडोज सर्वर और विंडोज वर्कस्टेशन में रुचि रखते थे। चूँकि मध्यम और बड़ी कंपनियों में डोमेन की कमी संभवतः नियम का अपवाद है। एक भाषा बोलने के लिए, मेरी राय में, औसत 100+ लोग हैं। सभी विंडोज़ मशीनों और सर्वरों से डेटा एकत्र करने का एक तरीका खोजना आवश्यक था, उनके आईपी और डोमेन व्यवस्थापक खाते को जानना, लेकिन उनमें से प्रत्येक पर कोई सॉफ़्टवेयर इंस्टॉल किए बिना। WMI इंटरफ़ेस बचाव के लिए आता है। विंडोज़ मैनेजमेंट इंस्ट्रुमेंटेशन (WMI) का शाब्दिक अर्थ विंडोज़ प्रबंधन उपकरण है। WMI विंडोज़ प्लेटफ़ॉर्म पर चलने वाले कंप्यूटर बुनियादी ढांचे के विभिन्न हिस्सों के संचालन के केंद्रीकृत प्रबंधन और निगरानी के लिए बुनियादी तकनीकों में से एक है। विकी से लिया गया. इसके बाद, मुझे डेबियन के लिए wmic (यह एक WMI क्लाइंट है) संकलित करने के लिए फिर से छेड़छाड़ करनी पड़ी। सब कुछ तैयार होने के बाद, जो कुछ बचा था वह केवल आवश्यक जानकारी के लिए wmic के माध्यम से आवश्यक नोड्स का सर्वेक्षण करना था। WMI के माध्यम से आप विंडोज़ कंप्यूटर से लगभग कोई भी जानकारी प्राप्त कर सकते हैं, और इसके अलावा, आप इसके माध्यम से कंप्यूटर को नियंत्रित भी कर सकते हैं, उदाहरण के लिए, इसे रीबूट करने के लिए भेज सकते हैं। इस प्रकार हमारे सिस्टम में विंडोज़ स्टेशनों और सर्वरों के बारे में जानकारी का संग्रह सामने आया। इसके अतिरिक्त, वर्तमान सिस्टम लोड संकेतकों के बारे में नवीनतम जानकारी थी। हम उनसे अधिक बार अनुरोध करते हैं, और हार्डवेयर पर जानकारी कम बार। इसके बाद ऑडिटिंग थोड़ा और आनंददायक हो गई.

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

हम स्वयं हर दिन इस प्रणाली का उपयोग करते हैं, और यह प्रत्येक तकनीकी कर्मचारी के लिए हमेशा खुला रहता है। और हमने सोचा कि जो हमारे पास पहले से है उसे हम दूसरों के साथ साझा कर सकते हैं। सिस्टम अभी तक वितरण के लिए तैयार नहीं था। स्थानीय संस्करण को SaaS में बदलने के लिए बहुत कुछ फिर से करना पड़ा। इनमें सिस्टम के विभिन्न तकनीकी पहलुओं में बदलाव (दूरस्थ कनेक्शन, समर्थन सेवा), लाइसेंसिंग के लिए मॉड्यूल का विश्लेषण, ग्राहक डेटाबेस को साझा करना, प्रत्येक सेवा की स्केलिंग और सभी भागों के लिए ऑटो-अपडेट सिस्टम का विकास शामिल है। लेकिन यह लेख का दूसरा भाग होगा.

अपडेट

दूसरा भाग

स्रोत: www.habr.com

आउटसोर्सिंग से विकास तक (भाग 1)