अपने नेटवर्क बुनियादी ढांचे का नियंत्रण कैसे लें। अध्याय प्रथम. पकड़ना

यह लेख "अपने नेटवर्क इन्फ्रास्ट्रक्चर पर नियंत्रण कैसे रखें" लेखों की श्रृंखला में पहला है। श्रृंखला के सभी लेखों की सामग्री और लिंक पाए जा सकते हैं यहां.

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

तो, प्रारंभिक स्थितियाँ।

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

आपका पहला रणनीतिक लक्ष्य एन्ट्रापी का विरोध करना और प्रदान की गई सेवा के स्तर को बनाए रखना सीखना है।

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

Оборудование

सबसे पहले आपको यह समझने की जरूरत है कि सबसे बड़े जोखिम कहां हैं।

फिर, यह अलग हो सकता है. मैं स्वीकार करता हूं कि कहीं, उदाहरण के लिए, ये सुरक्षा मुद्दे होंगे, और कहीं, सेवा की निरंतरता से संबंधित मुद्दे, और कहीं, शायद, कुछ और। क्यों नहीं?

आइए, स्पष्ट होने के लिए, मान लें कि यह अभी भी सेवा की निरंतरता है (यह उन सभी कंपनियों में मामला था जहां मैंने काम किया था)।

फिर आपको उपकरण के साथ शुरुआत करने की आवश्यकता है। यहां ध्यान देने योग्य विषयों की एक सूची दी गई है:

• गंभीरता की डिग्री के आधार पर उपकरणों का वर्गीकरण
• महत्वपूर्ण उपकरणों का बैकअप
• समर्थन, लाइसेंस

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

उदाहरण

मान लीजिए कि हम डेटा सेंटर में रूट स्विच के बारे में बात कर रहे हैं।

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

महत्वपूर्ण! आपको इस मुद्दे पर स्वयं निर्णय लेने की आवश्यकता नहीं है. आपको प्रबंधन या कंपनी प्रबंधन के जोखिमों, संभावित समाधानों और लागतों का वर्णन करना होगा। उन्हें निर्णय लेना ही होगा.

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

लेकिन एक जोखिम है कि वे डिलीवरी नहीं करेंगे। दुर्भाग्य से, हमने एक बार खुद को ऐसी स्थिति में पाया। चार घंटे के बजाय, उपकरण ने एक सप्ताह तक यात्रा की!!!

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

महत्वपूर्ण! आपके पास मौजूद सभी समर्थन की समाप्ति तिथियों के साथ एक स्प्रेडशीट बनाएं और इसे अपने कैलेंडर में जोड़ें ताकि आपको कम से कम एक महीने पहले एक ईमेल मिल जाए कि आपको अपने समर्थन को नवीनीकृत करने के बारे में चिंता करना शुरू कर देना चाहिए।

यदि आप अपना समर्थन नवीनीकृत करना भूल जाते हैं और इसके समाप्त होने के अगले दिन आपका हार्डवेयर टूट जाता है तो आपको माफ नहीं किया जाएगा।

आपातकालीन कार्य

आपके नेटवर्क पर चाहे कुछ भी हो, आदर्श रूप से आपको अपने नेटवर्क उपकरण तक पहुंच बनाए रखनी चाहिए।

महत्वपूर्ण! आपके पास सभी उपकरणों तक कंसोल पहुंच होनी चाहिए और यह पहुंच उपयोगकर्ता डेटा नेटवर्क की कार्यक्षमता पर निर्भर नहीं होनी चाहिए।

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

वहाँ होना चाहिए

• विक्रेता या इंटीग्रेटर समर्थन के साथ टिकट खोलने के लिए आवश्यक जानकारी
• किसी भी उपकरण (कंसोल, प्रबंधन) तक पहुंचने की जानकारी

बेशक, इसमें कोई अन्य उपयोगी जानकारी भी हो सकती है, उदाहरण के लिए, विभिन्न उपकरणों के लिए अपग्रेड प्रक्रिया का विवरण और उपयोगी डायग्नोस्टिक कमांड।

Партнеры

अब आपको साझेदारों से जुड़े जोखिमों का आकलन करने की जरूरत है। आमतौर पर यह

• इंटरनेट प्रदाता और ट्रैफ़िक विनिमय बिंदु (IX)
• संचार चैनल प्रदाता

आपको अपने आप से क्या प्रश्न पूछना चाहिए? उपकरणों की तरह, विभिन्न आपातकालीन परिदृश्यों पर भी विचार किया जाना चाहिए। उदाहरण के लिए, इंटरनेट प्रदाताओं के लिए, यह कुछ इस प्रकार हो सकता है:

• यदि इंटरनेट प्रदाता X आपको किसी कारण से सेवा प्रदान करना बंद कर दे तो क्या होगा?
• क्या अन्य प्रदाताओं के पास आपके लिए पर्याप्त बैंडविड्थ है?
• कनेक्टिविटी कितनी अच्छी रहेगी?
• आपके इंटरनेट प्रदाता कितने स्वतंत्र हैं और क्या उनमें से किसी एक के गंभीर रूप से बंद होने से दूसरों को समस्या होगी?
• आपके डेटा सेंटर में कितने ऑप्टिकल इनपुट हैं?
• यदि कोई एक इनपुट पूरी तरह से नष्ट हो जाए तो क्या होगा?

इनपुट के संबंध में, मेरे अभ्यास में दो अलग-अलग कंपनियों में, दो अलग-अलग डेटा केंद्रों में, एक उत्खननकर्ता ने कुओं को नष्ट कर दिया और केवल चमत्कार से हमारे प्रकाशिकी प्रभावित नहीं हुए। ये कोई इतना दुर्लभ मामला नहीं है.

और, निःसंदेह, आपको न केवल ये प्रश्न पूछने की आवश्यकता है, बल्कि, प्रबंधन के सहयोग से, किसी भी स्थिति में स्वीकार्य समाधान प्रदान करने की भी आवश्यकता है।

बैकअप

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

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

सॉफ़्टवेयर संस्करण

उपकरण के सॉफ़्टवेयर को अपग्रेड करना उचित है या नहीं, यह प्रश्न इतना स्पष्ट नहीं है। एक ओर, पुराने संस्करण ज्ञात बग और कमजोरियाँ हैं, लेकिन दूसरी ओर, नया सॉफ़्टवेयर, सबसे पहले, हमेशा एक दर्द रहित अपग्रेड प्रक्रिया नहीं है, और दूसरी ओर, नए बग और कमजोरियाँ हैं।

यहां आपको सबसे अच्छा विकल्प ढूंढने की जरूरत है। कुछ स्पष्ट सिफ़ारिशें

• केवल स्थिर संस्करण स्थापित करें
• फिर भी, आपको सॉफ़्टवेयर के बहुत पुराने संस्करणों पर नहीं रहना चाहिए
• कुछ सॉफ़्टवेयर कहाँ स्थित है, इसके बारे में जानकारी के साथ एक चिह्न बनाएँ
• सॉफ़्टवेयर संस्करणों में कमज़ोरियों और बगों पर समय-समय पर रिपोर्ट पढ़ें, और गंभीर समस्याओं के मामले में, आपको अपग्रेड करने के बारे में सोचना चाहिए

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

महत्वपूर्ण उपकरणों के मामले में, आप अपग्रेड में मदद के अनुरोध के साथ विक्रेता के समर्थन से संपर्क कर सकते हैं।

टिकट प्रणाली

अब आप चारों ओर देख सकते हैं. आपको अन्य विभागों के साथ और विभाग के भीतर बातचीत के लिए प्रक्रियाएं स्थापित करने की आवश्यकता है।

यह आवश्यक नहीं हो सकता है (उदाहरण के लिए, यदि आपकी कंपनी छोटी है), लेकिन मैं काम को इस तरह व्यवस्थित करने की अत्यधिक अनुशंसा करूंगा कि सभी बाहरी और आंतरिक कार्य टिकट प्रणाली के माध्यम से हों।

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

आइए पहुंच खोलने के एक महत्वपूर्ण और सामान्य कार्य का एक उदाहरण लें। मैं एक एल्गोरिदम का वर्णन करूंगा जिसने एक कंपनी में पूरी तरह से काम किया।

उदाहरण

आइए इस तथ्य से शुरू करें कि अक्सर एक्सेस ग्राहक अपनी इच्छाओं को एक नेटवर्क इंजीनियर के लिए समझ से बाहर की भाषा में तैयार करते हैं, अर्थात्, एप्लिकेशन की भाषा में, उदाहरण के लिए, "मुझे 1C तक पहुंच प्रदान करें।"

इसलिए, हमने कभी भी ऐसे उपयोगकर्ताओं से सीधे अनुरोध स्वीकार नहीं किए हैं।
और वह पहली आवश्यकता थी

• पहुंच के लिए अनुरोध तकनीकी विभागों से आना चाहिए (हमारे मामले में ये यूनिक्स, विंडोज़, हेल्पडेस्क इंजीनियर थे)

दूसरी आवश्यकता यह है

• इस एक्सेस को लॉग किया जाना चाहिए (तकनीकी विभाग द्वारा जहां से हमें यह अनुरोध प्राप्त हुआ है) और अनुरोध के रूप में हमें इस लॉग एक्सेस के लिए एक लिंक प्राप्त होता है

इस अनुरोध का स्वरूप हमें समझ में आना चाहिए, अर्थात्।

• अनुरोध में यह जानकारी होनी चाहिए कि किस सबनेट और किस सबनेट तक पहुंच खुली होनी चाहिए, साथ ही प्रोटोकॉल और (टीसीपी/यूडीपी के मामले में) पोर्ट के बारे में भी जानकारी होनी चाहिए।

इसे वहां भी दर्शाया जाना चाहिए

• यह एक्सेस क्यों खोला गया है इसका विवरण
• अस्थायी या स्थायी (यदि अस्थायी है, तो किस तिथि तक)

और एक बहुत ही महत्वपूर्ण बिंदु अनुमोदन है

• उस विभाग के प्रमुख से जिसने पहुंच शुरू की (उदाहरण के लिए, लेखांकन)
• तकनीकी विभाग के प्रमुख से, जहाँ से यह अनुरोध नेटवर्क विभाग को आया (उदाहरण के लिए, हेल्पडेस्क)

इस मामले में, इस पहुंच का "मालिक" उस विभाग का प्रमुख माना जाता है जिसने पहुंच शुरू की (हमारे उदाहरण में लेखांकन), और वह यह सुनिश्चित करने के लिए जिम्मेदार है कि इस विभाग के लिए लॉग एक्सेस वाला पृष्ठ अद्यतित रहे। .

लॉगिंग

यह ऐसी चीज़ है जिसमें आप डूब सकते हैं। लेकिन यदि आप एक सक्रिय दृष्टिकोण लागू करना चाहते हैं, तो आपको यह सीखना होगा कि इस डेटा बाढ़ से कैसे निपटें।

यहां कुछ व्यावहारिक अनुशंसाएं दी गई हैं:

• आपको प्रतिदिन लॉग की समीक्षा करने की आवश्यकता है
• नियोजित समीक्षा (और आपातकालीन स्थिति नहीं) के मामले में, आप स्वयं को गंभीरता स्तर 0, 1, 2 तक सीमित कर सकते हैं और यदि आप आवश्यक समझें तो अन्य स्तरों से चयनित पैटर्न जोड़ सकते हैं
• एक स्क्रिप्ट लिखें जो लॉग को पार्स करती है और उन लॉग को अनदेखा करती है जिनके पैटर्न आपने अनदेखा सूची में जोड़े हैं

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

निगरानी

किसी कंपनी के लिए निगरानी प्रणाली का अभाव होना असामान्य बात नहीं है। उदाहरण के लिए, आप लॉग पर भरोसा कर सकते हैं, लेकिन उपकरण कुछ भी "कहने" के लिए समय दिए बिना ही "मर" सकता है, या यूडीपी सिसलॉग प्रोटोकॉल पैकेट खो सकता है और नहीं आ सकता है। सामान्य तौर पर, निस्संदेह, सक्रिय निगरानी महत्वपूर्ण और आवश्यक है।

मेरे अभ्यास में दो सबसे लोकप्रिय उदाहरण:

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

महत्वपूर्ण! सबसे महत्वपूर्ण घटनाओं के लिए एसएमएस सूचनाएं सेट करें। यह निगरानी और लॉगिंग दोनों पर लागू होता है। यदि आपकी ऑन-ड्यूटी शिफ्ट नहीं है, तो काम के घंटों के बाहर भी एसएमएस आना चाहिए।

प्रक्रिया के बारे में इस तरह सोचें कि सभी इंजीनियर जाग न जाएं। इसके लिए हमारे पास एक इंजीनियर ड्यूटी पर था।

परिवर्तन नियंत्रण

मेरी राय में, सभी परिवर्तनों को नियंत्रित करना आवश्यक नहीं है। लेकिन, किसी भी मामले में, यदि आवश्यक हो, तो आपको आसानी से यह पता लगाने में सक्षम होना चाहिए कि नेटवर्क पर कुछ बदलाव किसने और क्यों किए हैं।

कुछ सुझाव:

• उस टिकट पर क्या किया गया, इसका विवरण देने के लिए टिकट प्रणाली का उपयोग करें, उदाहरण के लिए टिकट में लागू कॉन्फ़िगरेशन की प्रतिलिपि बनाकर
• नेटवर्क उपकरण पर टिप्पणी क्षमताओं का उपयोग करें (उदाहरण के लिए, जुनिपर पर टिप्पणी करें)। आप टिकट नंबर लिख सकते हैं
• अपने कॉन्फ़िगरेशन बैकअप के अंतर का उपयोग करें

आप इसे एक प्रक्रिया के रूप में कार्यान्वित कर सकते हैं, परिवर्तनों के लिए सभी टिकटों की प्रतिदिन समीक्षा कर सकते हैं।

Процессы

आपको अपनी टीम में प्रक्रियाओं को औपचारिक बनाना और उनका वर्णन करना होगा। यदि आप इस बिंदु पर पहुंच गए हैं, तो आपकी टीम के पास पहले से ही कम से कम निम्नलिखित प्रक्रियाएं चलनी चाहिए:

दैनिक प्रक्रियाएं:

• टिकटों के साथ काम करना
• लॉग के साथ काम करना
• परिवर्तन नियंत्रण
• दैनिक जांच पत्रक

वार्षिक प्रक्रियाएँ:

• गारंटी, लाइसेंस का विस्तार

अतुल्यकालिक प्रक्रियाएँ:

• विभिन्न आपातकालीन स्थितियों पर प्रतिक्रिया

प्रथम भाग का निष्कर्ष

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

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

निम्नलिखित भाग आपको बताएंगे कि त्रुटियों को कैसे ढूंढें और कैसे समाप्त करें, और फिर अपने बुनियादी ढांचे में सुधार करें।

बेशक, आपको सब कुछ क्रमिक रूप से करने की ज़रूरत नहीं है। समय नाजुक हो सकता है. यदि संसाधन अनुमति दें तो इसे समानांतर में करें।

और एक महत्वपूर्ण अतिरिक्त. अपनी टीम से संवाद करें, पूछें, परामर्श लें। अंततः, वे ही हैं जो इस सब का समर्थन करते हैं और करते हैं।

स्रोत: www.habr.com