हमने ग्राहकों को बंदरगाहों से कैसे जोड़ा इसकी कहानी

हाय हमर!

मैं आपको अपनी कहानी बताऊंगा।

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

जैसा कि वे कहते हैं, तब पूरी कहावत थी?

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

पहली बात यह है कि जब दो प्रदाता विलय करते हैं, तो खरीदे गए प्रदाता के ग्राहक आधार का हस्तांतरण होता है (मैं इसे "बी" कहूंगा) खरीदार के आधार पर (इसे "ए" होने दें)। समस्या को जल्दी से हल किया गया है - हम दोनों डेटाबेस का विश्लेषण करते हैं, सही प्रश्न करते हैं, आवश्यक जानकारी को वांछित बिलिंग में खींचते हैं। हम नए कनेक्शन निर्देशों पर मुहर लगाते हैं। मैं कानूनी मुद्दों पर विचार नहीं करता; यह तकनीकी विभाग का काम नहीं है। सब कुछ, इंस्टॉलरों को काम के साथ प्रदान किया जाता है।

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

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

एक निगरानी प्रणाली के रूप में, हम (कंपनी "बी") की पुरानी पुरानी फ्रेंडली पिंजर थी। बेशक, लोहे के 10 टुकड़ों के नेटवर्क में, पिंजर अभी भी काम करेगा, लेकिन सैकड़ों उपकरणों के साथ प्रदाता के नेटवर्क में नहीं। सारा लोहा ज़ाबिक्स की देखरेख में स्थानांतरित किया गया था। लेकिन दृश्य भाग को मानचित्र में स्थानांतरित किया गया था, इसके लिए हमने उपयोग किया:


मानचित्र पर ऐसे उपकरण थे जो ज्ञात थे। इसके अलावा, कनेक्शन तैयार किए गए थे - कौन सा डिवाइस किस से जुड़ा है। इसके समानांतर, कार्ड पर उपकरणों के पते पंजीकृत थे।

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

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

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

इस बीच, हम चले गए। House_id के साथ ग्राहक हैं, house_id वाले उपकरण हैं।

तो:


हो गया। हम जाँचते हैं ... हाँ, और हमारे पास 33_7 लोगों के साथ house_id के ग्राहक हैं, लेकिन ऐसा कोई उपकरण नहीं है ... विकार, इंस्टॉलर के लिए कार्य यह पता लगाना है कि इस घर में क्या स्थापित किया गया है। वास्तव में, वहाँ एक स्विच है, बेकाबू, तांबे द्वारा जुड़ा हुआ है। खींचा, ठीक किया। ऐसे सभी स्थानों की जाँच की, नए उपकरणों को पाया, मानचित्र पर रखा। नाविक के साथ सवारी करें - लापता घर को खत्म करें।

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

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

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

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

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

अपनी कहानी को संक्षेप में बताने के लिए, मैं इस पर टिप्पणी करना चाहता हूं कि मैं हबर में क्यों लिख रहा हूं।

Source: https://habr.com/ru/post/In162561/


All Articles