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

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

प्रागितिहास

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

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

पहिले, म डेल्फी, PHP, JS र धेरै सतही रूपमा C++ मा प्रोग्रामिङ गरिरहेको थिएँ। मलाई नेटवर्कहरू कसरी काम गर्ने राम्ररी थाहा छ। VLAN, रूटिङ (OSPF, EIGRP, BGP), NAT। यो मेरो लागि एक आदिम निगरानी प्रोटोटाइप लेख्न पर्याप्त थियो।

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

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

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

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

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

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

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

यसबाहेक, दैनिक काममा मैले क्रस क्रसिङ गर्नुपर्थ्यो। र कुन इन्टरफेस प्रयोग गर्ने भनेर हेर्नको लागि हरेक पटक सिस्को स्विचहरूमा जाँदा म थकित भएँ। अनुगमनमा कुनै वस्तुमा क्लिक गर्नु र विवरणहरूको साथ यसको इन्टरफेसहरूको सूची हेर्नु कत्ति राम्रो हुन्छ। यसले मेरो समय बचाउने थियो। यसबाहेक, यस योजनामा खाताहरू र आदेशहरू प्रविष्ट गर्न पुट्टी वा SecureCRT चलाउन आवश्यक पर्दैन। मैले भर्खरै अनुगमनमा क्लिक गरें, के आवश्यक थियो देखे र मेरो काम गर्न गएँ। मैले स्विचहरूसँग अन्तरक्रिया गर्ने तरिकाहरू खोज्न थालें। मैले तुरुन्तै २ विकल्पहरू भेट्टाएँ: SNMP वा SSH मार्फत स्विचमा लग इन गर्नुहोस्, मलाई आवश्यक आदेशहरू प्रविष्ट गर्नुहोस् र परिणाम पार्स गर्नुहोस्। मैले SNMP लाई यसको कार्यान्वयनको जटिलताको कारण खारेज गरें; म नतिजा प्राप्त गर्न अधीर थिएँ। SNMP को साथ, तपाईंले लामो समयको लागि MIB मा खन्नुपर्नेछ र, यो डाटाको आधारमा, इन्टरफेसहरूको बारेमा डाटा उत्पन्न गर्नुहोस्। CISCO मा एक अद्भुत टोली छ

show interface status

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

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

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

अडिट-टेलिकम कम्पनीको निर्माण

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

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

अन्तमा, हामीले एक विकल्प फेला पार्न सक्षम भयौं जुन हामी दुवैलाई उपयुक्त छ र हामीलाई के गर्ने भनेर थाहा छ। 2016 मा, हामीले एउटा IT कम्पनी सिर्जना गर्ने निर्णय गर्यौं जसले व्यवसायहरूलाई IT समस्याहरू समाधान गर्न मद्दत गर्नेछ। यो IT प्रणाली (1C, टर्मिनल सर्भर, मेल सर्भर, आदि), तिनीहरूको मर्मत, प्रयोगकर्ताहरू र नेटवर्क प्रशासनको लागि क्लासिक हेल्पडेस्कको तैनाती हो।

स्पष्ट रूपमा भन्नुपर्दा, कम्पनी सिर्जना गर्दा, मैले यसलाई 99,9% को बारेमा विश्वास गरेन। तर कुनै न कुनै तरिकाले पावेलले मलाई प्रयास गर्न सक्यो, र अगाडि हेर्दै, ऊ सही भयो। पावेल र मैले प्रत्येकमा 300 rubles मा चिप गर्नुभयो, एउटा नयाँ LLC "Audit-Telecom" दर्ता गर्नुभयो, एउटा सानो कार्यालय भाडामा लिनुभयो, राम्रो व्यापार कार्डहरू बनाउनुभयो, सामान्य रूपमा, सम्भवतः अनुभवहीन, नौसिखिया व्यापारीहरू जस्तै, र ग्राहकहरू खोज्न थाले। ग्राहकहरू खोज्नु पूर्ण रूपमा फरक कथा हो। सायद हामी कर्पोरेट ब्लग को भाग को रूप मा एक अलग लेख लेख्नेछौं यदि कसैलाई रुचि छ। चिसो कलहरू, फ्लायरहरू, आदि। यसले कुनै परिणाम दिएको छैन। मैले अहिले व्यापारको बारेमा धेरै कथाहरू पढेको रूपमा, एक वा अर्को तरिका, धेरै भाग्यमा निर्भर गर्दछ। हामी भाग्यमानी थियौं। र शाब्दिक रूपमा कम्पनीको निर्माणको केही हप्ता पछि, मेरो भाइ भ्लादिमीरले हामीलाई सम्पर्क गर्नुभयो, जसले हामीलाई हाम्रो पहिलो ग्राहक ल्यायो। म तपाईंलाई क्लाइन्टहरूसँग काम गर्ने विवरणहरू बोर गर्नेछैन, यो लेखको बारेमा होइन, म केवल भन्छु कि हामी लेखा परीक्षणको लागि गयौं, महत्वपूर्ण क्षेत्रहरू पहिचान गरियो र यी क्षेत्रहरू टुट्यो जब कि निर्णय लिइयो। आउटसोर्सरको रूपमा निरन्तर आधारमा हामीलाई सहयोग गर्नुहोस्। यस पछि, एक सकारात्मक निर्णय तुरुन्तै भयो।

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

तपाइँको निगरानी प्रणाली मा जारी काम

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

त्यसैले, कार्यहरू:

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

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

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

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

नतिजाहरू प्रायः गलत थिए र स्क्यान पूरा हुन लामो समय लाग्यो। मैले पिंगको बारेमा पूर्ण रूपमा बिर्सें, यो fping मार्फत गरिएको थियो:

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

यो पनि समानान्तर थिएन र त्यसैले प्रक्रिया धेरै लामो थियो। पछि, प्रमाणिकरणको लागि आवश्यक आईपी ठेगानाहरूको सम्पूर्ण सूची एकैचोटि fping मा पठाइयो, र फिर्ता हामीले प्रतिक्रिया दिनेहरूको तयार-निर्मित सूची प्राप्त गर्यौं। हाम्रो विपरीत, fping प्रक्रियाहरू समानान्तर गर्न सक्षम थियो।

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

कसरी संसाधन लिङ्कहरू Veliam मा काम गर्दछ

रिमोट जडानहरू

यो Veliam को हालको संस्करणमा कार्यमा जस्तो देखिन्छ

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

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

हाम्रो प्रणालीमा क्लाइन्ट एक ब्राउजर थियो जुन कम्प्यूटरको स्थानीय स्रोतहरूमा पहुँच छैन भन्ने तथ्यलाई ध्यानमा राख्दै, हामीलाई केहि आदेशको साथ आवश्यक अनुप्रयोग सुरू गर्नको लागि, यो "विन्डोज" मार्फत सबै काम गर्न आविष्कार गरिएको थियो। अनुकूलन url योजना"। यसरी हाम्रो प्रणालीको लागि एक निश्चित "प्लगइन" देखा पर्‍यो, जसमा केवल पुट्टी र रिमोट डेस्कटप प्लस समावेश थियो र स्थापनाको क्रममा, केवल विन्डोजमा URI योजना दर्ता गरियो। अब, जब हामी RDP वा SSH मार्फत वस्तुमा जडान गर्न चाहन्थ्यौं, हामीले हाम्रो प्रणालीमा यो कार्य क्लिक गर्यौं र अनुकूलन URI ले काम गर्‍यो। Windows वा putty मा निर्मित मानक mstsc.exe, जुन "प्लगइन" को भाग थियो, सुरु गरिएको थियो। मैले शब्द प्लगइनलाई उद्धरणहरूमा राखेको छु किनभने यो शास्त्रीय अर्थमा ब्राउजर प्लगइन होइन।

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

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

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

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

हरेक समस्याको समाधान आ-आफ्नै तरिकाले भयो। जब नियम सिर्जना गरिएको थियो, यो फर्वार्डिङ केवल एक विशिष्ट बाह्य आईपी ठेगानाको लागि उपलब्ध थियो (जसबाट जडान प्रारम्भ गरिएको थियो)। त्यसैले सुरक्षा प्वालबाट जोगियो। तर त्यस्ता प्रत्येक जडानको साथ, NAT पृष्ठमा Mikrotik नियम थपिएको थियो र खाली गरिएको थिएन। र सबैलाई थाहा छ कि त्यहाँ धेरै नियमहरू छन्, राउटरको प्रोसेसर अधिक लोड हुन्छ। र सामान्यतया, म स्वीकार गर्न सक्दिन कि एक दिन म केहि 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
	}
}

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

Mikrotik ब्याकअप

हामीले FTP मा सबै Mikrotik को ब्याकअप कन्फिगर गर्यौं। र समग्रमा सबै ठीक थियो। तर जब तपाईलाई ब्याकअप चाहिन्छ, तपाईले यो 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 मा समाप्त भएन।

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

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

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

Linux मा multithreading मा स्विच गर्दै

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

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

नयाँ कम्पनीहरूको द्रुत अडिट

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

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

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

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

अपडेट

को दोस्रो भाग

स्रोत: www.habr.com

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