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

आज, कम से कम व्यक्तिगत उपयोग के लिए, कम से कम व्यापार के लिए, आप स्टोर पर आते हैं, एक कार खरीदते हैं, "चालू" बटन दबाएं और इसका उपयोग करना शुरू करें।
हां, बारीकियां हैं - सिस्टम पी 5 595 या बेजर 293 के साथ ऐसी चाल काम नहीं करेगी - हमें तकनीकी विशेषज्ञों की आवश्यकता है। हालांकि, आधार में, यहां तक ​​कि कई शाखाओं से एक कंपनी के लिए - आपने एक गज़ेल, कई पीसी खरीदे, उन्हें इंटरनेट एक्सेस के साथ प्रदान किया - और आप काम कर सकते हैं।

कुछ समय पहले, मेरा एक व्यक्ति के साथ दूर के नेटवर्क का विवाद था। उनके पास एक उचित प्रश्न था: छोटे कॉर्पोरेट नेटवर्क के निर्माण और विन्यास को स्वचालित करना असंभव क्यों है। यही कारण है कि वह अपनी प्रत्येक शाखा में लोहे का एक टुकड़ा नहीं खरीद सकता है, प्रत्येक पर 5 बटन दबाएं और एक कार्यशील स्थिर नेटवर्क प्राप्त कर सकता है?
यह सवाल और भी गहरा था और व्यक्तिगत तंत्र को प्रभावित कर रहा था: ऐसा तकनीकी सहायता कर्मचारी (कंपनियों, प्रदाताओं, विक्रेताओं के लिए) क्यों है। क्या वास्तव में उनमें से अधिकांश को स्वचालित रूप से ढूंढना और सही करना असंभव है?

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



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



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

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

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

स्वचालित समस्या निवारण

कई सिस्टम हैं जो नेटवर्क पर समस्या होने पर फॉल्ट टॉलरेंस को बढ़ाते हैं और सेवाओं के नुकसान / डाउनटाइम को कम करते हैं - IGP, VRRP, ग्रेसफुल रिस्टार्ट क्षमता, BFD, MPLS TE FRR और भी बहुत कुछ। लेकिन ये सब बिखरे हुए टुकड़े हैं। वे अलग-अलग सफलता के साथ-साथ उन्हें अंधा करने की कोशिश कर रहे हैं, लेकिन इससे वे विविध अस्तित्व वाले नहीं हैं।
यह विज्ञान में अंतिम सिद्धांत के मुद्दे की याद दिलाता है, जिसके अनुसार उपलब्ध 4 प्रकार की बातचीत एक ही प्रकृति के हैं। यह एक सार्वभौमिक, एकीकृत सिद्धांत है जो सब कुछ स्पष्ट और स्पष्ट रूप से बताता है। लेकिन अभी तक तस्वीर नहीं जुड़ती है।

यहाँ प्रोटोकॉल के बीच कॉन्फ़िगर रिश्ते का एक सुंदर चित्रण है:



एक IS-IS जैसे IGP ऐसे नेटवर्क पर चल रहा है। इसके शीर्ष पर MPLS TE है जिसमें FRR फ़ंक्शन सक्रिय है।
बीएफडी पर आर 1 आर 2 की स्थिति और टीई सुरंग / एलएसपी की स्थिति की निगरानी करता है। जब एक सॉफ्टवेयर त्रुटि के कारण R2 पर एक लाइन कार्ड रिबूट होता है, तो R1 पर बीएफडी तुरंत उन सभी प्रक्रियाओं को रिपोर्ट करता है जो पता होना चाहिए। MPLS TE FRR तक पहुँचता है और ट्रैफ़िक को R3 पर एक अस्थायी पथ पर पुनर्निर्देशित किया जाता है।
इसके अलावा, जीआर कार्यात्मक, सभी मार्गों आर 2, सभी संगत एफआईबी रिकॉर्ड और यहां तक ​​कि पड़ोस संबंध आर 1 पर संग्रहीत हैं। इस समय, आर 2 सामान्य पर लौटता है, बोर्ड लोड, इंटरफेस बढ़ता है। और आर 1 पर सब कुछ तैयार है और कम से कम संभव समय में यह फिर से आर 2 को ट्रैफ़िक स्थानांतरित करने के लिए तैयार है। नतीजतन, सेवाएं अपने पिछले पाठ्यक्रम में लौट रही हैं - हर कोई खुश है, हर कोई खुश है, किसी भी ग्राहक को प्रोग्रामर का घुमावदार हाथ नहीं लगा।

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

इसलिए, हम यह समझने के लिए कि उन्हें किन तरीकों की आवश्यकता है, कुछ समस्याओं का वर्गीकरण करेंगे।

1. वास्तविक समय महत्वपूर्ण परिस्थितियों
2. वर्तमान में उपलब्ध समस्याएं लेकिन सेवाओं को प्रभावित नहीं करती हैं
3. हार्डवेयर मुद्दे
4. संभावित सॉफ्टवेयर समस्याएँ
5. गलत कॉन्फ़िगरेशन

1. वास्तविक समय महत्वपूर्ण परिस्थितियों

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

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

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

इसके अलावा, प्रत्येक डिवाइस जानता है कि उस पर क्या हुआ। अंतिम उदाहरण पर लौटते हुए, पीई सुरंगों, वीपीएन, आईजीपी के पुनर्निर्माण को देखता है। वह मानव रूप में नियंत्रण प्रणाली को बता सकते हैं, वे कहते हैं, "16:20:12 01/01/2013 सभी सुरंगों और वीपीएन ऐसे और इस तरह के एक इंटरफेस के माध्यम से इस तरह की दिशा में गिर गए। इसके अलावा, रूटिंग स्कीम को फिर से बनाया गया। मुझे यकीन नहीं है कि वहां क्या हुआ था, लेकिन ओएसपीएफ ने मुझे सूचित किया कि डिवाइस ए और बी के बीच लिंक गायब हो गया। आरएसवीपी ने भी एक समस्या की सूचना दी। "
मध्यवर्ती पी, जिस पर SFP मॉड्यूल जल गया, कहते हैं, "16:20:12 01/01/2013 पोर्ट 1/1/1 में मेरा SFP मॉड्यूल क्षतिग्रस्त हो गया था। मैंने सब कुछ चेक किया - एक हार्डवेयर खराबी, एक प्रतिस्थापन की आवश्यकता है। "ओएसपीएफ और आरएसवीपी ने सभी पड़ोसियों को एक अधिसूचना भेजी।"

मजाक के रूप में, निश्चित रूप से, लेकिन एक मानक या कुछ प्रकार के प्रोटोकॉल का विकास क्यों नहीं किया गया है जो आपको डिवाइस पर न्यूनतम विश्लेषण करने और नियंत्रण प्रणाली के लिए अस्पष्ट जानकारी भेजने की अनुमति देगा। सभी उपकरणों से डेटा प्राप्त करने, उन्हें संकलित करने और उनका विश्लेषण करने के बाद, मॉनिटरिंग सिस्टम एक बहुत ही विशिष्ट संदेश दे सकता है:
“डिवाइस बी पर 16:20:12 पर, पोर्ट 1/1/1 में SFP मॉड्यूल विफल रहा (यहां मॉड्यूल के प्रकार, सीरियल नंबर, अपटाइम, औसत सिग्नल स्तर, इंटरफ़ेस पर त्रुटियों की संख्या, विफलता का कारण) का संदर्भ है। इसने निम्नलिखित सुरंगों (सूची, सुरंग मापदंडों के लिंक के साथ), वीपीएन (वीपीएन सेटिंग्स के लिंक के साथ सूची) को गिरा दिया। 16:20:12 पर, ट्रैफ़िक को अस्थायी पथ ए-सी-ई (पथ मापदंडों के लिए लिंक: इंटरफेस, एमपीएलएस लेबल, वीपीएन, आदि) के माध्यम से निर्देशित किया गया था। 16:20:14 पर एक नया एलएसपी एबी बनाया गया था ”

2. वर्तमान में उपलब्ध समस्याएं, लेकिन सेवाओं को प्रभावित नहीं करती हैं

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

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

इस स्थिति पर आपके क्या विचार हैं? बेशक, सबसे पहले, यह लॉग और गैंगवे का मानकीकरण है। मानकीकरण समिति स्तर पर वैश्विक है। सभी निर्माताओं को उनका पालन करना होगा, जैसे कि आईपी मानक।

हां, यह बहुत बड़ी मात्रा में काम है। सभी प्रोटोकॉल के लिए सभी संभव स्थितियों और संदेशों के लिए प्रदान करना आवश्यक है। लेकिन एक तरीका या दूसरा, प्रत्येक विक्रेता व्यक्तिगत रूप से करता है, किसी समस्या की रिपोर्ट करने के अपने तरीके का आविष्कार करता है। तो, शायद एक बार और एक बार और सभी के लिए सहमत होना बेहतर है? आखिरकार, मार्टिनी एल 2 वीपीएन भी एक बार सिस्को का व्यक्तिगत विकास था।
आप इस रूप में नियंत्रण प्रणाली को भेज सकते हैं, उदाहरण के लिए:
«Message_Number.Parent_Message_Number.Device_ID। तिथि। समय / समय सीमा

Message_Number नेटवर्क विफलता की अनुक्रम संख्या है।
पेरेंट_मेसेज_नंबर- इसकी वजह से होने वाले पैरेंट एक्सीडेंट की संख्या।
Device_ID नेटवर्क पर डिवाइस का विशिष्ट पहचानकर्ता है।
दिनांक - दुर्घटना की तिथि।
समय / समय सीमा - दुर्घटना की घटना का समय या उसकी अवधि का समय।
अलार्म_आईडी - मानक में अलार्म के लिए एक विशिष्ट पहचानकर्ता।
वैकल्पिक पैरामीटर - इस दुर्घटना के लिए विशिष्ट अतिरिक्त पैरामीटर।

दूसरे, उपकरण को स्थिति और लॉग का न्यूनतम विश्लेषण करने में सक्षम होना चाहिए। यह पता होना चाहिए कि कारण कहां है, जहां जांच, और विस्तृत लॉग के अलावा, विश्लेषण के परिणाम भी भेजें।

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

तीसरा, नेटवर्क इंटेलिजेंट मॉनिटरिंग सिस्टम को मानव दुर्घटनाओं को प्रतिबिंबित करना चाहिए।

विश्लेषण के बाद, एक मानकीकृत संदेश को मॉनिटरिंग सर्वर को भेजा जाए, उदाहरण के लिए:

"2374698214.0.8422। 10/29/2013 09: 00: 00-10: 00: 01.65843927456.GE0 / 0/0 "
"2374698219.2374698214.8422। 10/29/2013 10: 00: 00-10: 00: 05। 50. 90. R2D2। 70 "
"2374698220.2374698214.8422। 10/29/2013 10:00:01। 182. GE0 / 0/0। असामान्य विद्युत प्रवाह। बिजली की त्रिशूल पहुंच गई है। असामान्य पावर टाइमर की समय सीमा समाप्त हो गई है »

निगरानी प्रणाली संदेश डेटा को घटकों में पार्स करती है:
दुर्घटना संख्या 2374698214। किसी चीज का परिणाम नहीं। यह आईडी 8422 10/29/2013 के साथ डिवाइस पर हुआ। 09:00:00 से 10:00:05 तक चली। दुर्घटना के लिए सार्वभौमिक पहचानकर्ता 65843927456 है। अतिरिक्त पैरामीटर: GE0 / 0/0।

दुर्घटना संख्या 2374698219। दुर्घटना के कारण "2374698214। यह आईडी 8422 10/29/2013 के साथ डिवाइस पर हुआ। 10:00:00 से 10:00:05 तक चली। दुर्घटना के लिए सार्वभौमिक पहचानकर्ता 50 है। अतिरिक्त पैरामीटर: 90. 70. R2D2।

दुर्घटना संख्या 2374698220। दुर्घटना संख्या 2374698214 के कारण। यह डिवाइस पर आईडी 8422 10/29/2013 के साथ 10:00:05 बजे हुआ। दुर्घटना के लिए सार्वभौमिक पहचानकर्ता 182 है। अतिरिक्त पैरामीटर: GE0 / 0/0। असामान्य विद्युत प्रवाह। बिजली की त्रिशूल पहुंच गई है। असामान्य पावर टाइमर की समय सीमा समाप्त हो गई है।

वह तब नेटवर्क उपकरणों के डेटाबेस से संपर्क करता है और 8422 नंबर के साथ डिवाइस के विवरण को पुनर्प्राप्त करता है।
वैश्विक दुर्घटना डेटाबेस की ऑनलाइन या स्थानीय प्रतिलिपि में, यह दुर्घटना का वर्णन और अर्थ 65843927456 - एक असामान्य रूप से उच्च शक्ति प्रवाह को पाता है। एक पैरामीटर के रूप में - स्रोत इंटरफ़ेस GE0 / 0/0।
50 - उच्च CPU उपयोग। पैरामीटर: सामान्य लोड (90), इस प्रक्रिया द्वारा सबसे भरी हुई प्रक्रिया (आर 2 डी 2) और सीपीयू उपयोग (70)।
182 - इंटरफ़ेस बंद करें। मापदंडों में, इंटरफ़ेस नंबर और कारण इंटरफ़ेस बंद हो जाएगा।

इसके अलावा, नियंत्रण प्रणाली एक स्पष्ट और व्यापक संदेश उत्पन्न करती है:

“एक बाहरी उपकरण 093:00 और 10:00:05 के बीच असामान्य रूप से उच्च शक्ति का प्रवाह पैदा करते हुए, 10GE 0/0 इंटरफ़ेस के लिए C3PO स्विच से जुड़ा था।
इस कारण से, R2D2 प्रक्रिया ने 10:00 से 10:00:05 तक की समय अवधि के दौरान सीपीयू के 70% का उपयोग किया। बंदरगाह 10:00:05 पर बंद कर दिया गया था।
असामान्य विद्युत प्रवाह। बिजली की त्रिशूल पहुंच गई है। असामान्य पावर टाइमर की समय सीमा समाप्त हो गई है । "

3. हार्डवेयर की समस्या

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

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

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

फिर, नियंत्रण प्रणाली को इस बारे में एक संदेश प्राप्त करना चाहिए:

“स्लॉट 4 में लाइन कार्ड L43F नेटवर्क चिप को नुकसान के कारण स्विचिंग कपड़े के साथ सिंक्रनाइज़ेशन खो गया। बोर्ड को बदलने की जरूरत है। ” और लिंक पर सही उपकरण की जगह के लिए उत्पन्न टेम्पलेट।

4. संभावित सॉफ्टवेयर मुद्दे

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

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

5. गलत कॉन्फ़िगरेशन

शायद यह सबसे कठिन पहलू है। विविधताओं की एक विशाल विविधता है। यहां तक ​​कि एक नियमित आईपी अपने स्वचालित डिबगिंग को लागू करने की कोशिश करते समय भावनाओं का तूफान पैदा करेगा।

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

यही है, कम से कम कॉन्फ़िगरेशन भंडारण को मानकीकृत करना और इसे नियंत्रण प्रणाली में स्थानांतरित करना आवश्यक होगा।

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

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

लेकिन, ईमानदारी से, ये पहले से ही गैर-तुच्छ चीजें हैं और केवल टोपोलॉजी या औपचारिक एलएलडी (लो लेवल डिज़ाइन) के उचित मानकीकरण द्वारा महसूस किया जा सकता है।

ऊपर वर्णित सब कुछ के लिए वास्तविक जीवन के उदाहरण मैंने पहले ही इस लेख में उद्धृत किए हैं।

टेक का समर्थन

मेरी राय में, इस क्षेत्र में (कई अन्य लोगों के रूप में), अब मानव संसाधन के अनावश्यक काम और अति प्रयोग की एक बड़ी मात्रा है।

हम वाहक स्तर के नेटवर्क के बारे में बात करेंगे, SOHO और SMB के साथ पूरी तरह से अलग-अलग सूक्ष्मताएं।

एक असफल बोर्ड को एक उदाहरण के रूप में बदलने के लिए प्रक्रिया लें।
अब यह निम्नानुसार है (विभिन्न विक्रेताओं के लिए कुछ बदलावों के साथ):
1) बोर्ड आदेश से बाहर है, अजीब संदेश भेजने के लिए रिबूट या शुरू किया गया है। ग्राहक लॉग में त्रुटियों और दुर्घटनाओं को देखता है, लेकिन समस्या को स्पष्ट रूप से पहचान नहीं सकता है।
2) ग्राहक विक्रेता समर्थन हॉटलाइन को कॉल करता है, शब्दों में समस्या का वर्णन करता है, या मानक फॉर्म भरता है। दास श्रम या पूरी तरह से स्वतंत्र रूप से एकत्र किए गए डेटा, लॉग, फाइलें प्रदान करता है।
3) हॉटलाइन ऑपरेटर एक अनुरोध खोलता है और उसे तकनीकी विशेषज्ञों के समूह में नियुक्त करता है।
4) टीम लीडर इंजीनियर को एक अनुरोध सौंपता है।
5) इंजीनियर डेटा का विश्लेषण करता है और अंततः उसी दुर्घटना को देखता है। यह उपकरणों से जुड़ता है, परीक्षणों की एक श्रृंखला आयोजित करता है, जानकारी एकत्र करता है।
6) अक्सर इंजीनियर के पास सही कारण स्थापित करने का अवसर नहीं होता है, और वह स्वेच्छा से एक प्रतिस्थापन की सिफारिश नहीं कर सकता है - अगले स्तर पर अनुरोध की वृद्धि।
7) उच्च स्तर के इंजीनियरों की क्षमता के आधार पर, अनुरोध कुछ समय के लिए वहां यात्रा कर सकता है। तब तक, एक निश्चित एल्गोरिथ्म के अनुसार कुछ कमांड दर्ज करने या लॉग और नैदानिक ​​जानकारी का विश्लेषण करने से, एक हार्डवेयर खराबी स्थापित नहीं की जाएगी।
8) श्रृंखला के माध्यम से, सिफारिश जिम्मेदार इंजीनियर और ग्राहक को आगे तक पहुंचती है।
9) फिर अनुरोध और विभिन्न नौकरशाही को बंद करने की पुष्टि प्रक्रिया का अनुसरण करता है।
10) ग्राहक प्रतिस्थापन के लिए एक नया अनुरोध खोलता है - फॉर्म को फिर से भरता है, फिर से समस्या का संकेत देता है। कॉल सेंटर एप्लिकेशन को उपयुक्त विभाग में स्थानांतरित करता है, जिम्मेदार व्यक्तियों को नियुक्त किया जाता है और उसके बाद ही प्रतिस्थापन प्रक्रिया वास्तव में शुरू होती है।

यह एक बल्कि निराशावादी परिदृश्य है, लेकिन किसी भी तरह इस पूरी प्रक्रिया में लंबा समय लगता है और इसमें कम से कम 4-5 लोगों के प्रयास होते हैं - एक ग्राहक इंजीनियर, कॉल सेंटर ऑपरेटर, टीम लीडर, सपोर्ट इंजीनियर, उच्च स्तर के इंजीनियर, स्पेयर पार्ट्स विभाग के कर्मचारी ।

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

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

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

सामाजिक-मनोवैज्ञानिक पहलू

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

वास्तव में, यह एक शाश्वत प्रश्न है और परेशानियों का कारण है। कोचों ने कारों के आगमन के साथ कहां जाना है, कॉम्पैक्ट पीसी के आगमन के साथ पहले कंप्यूटरों की सेवा करने वाले विशाल कर्मचारी कहां गए?
आधुनिक दुनिया हमें अधिक से अधिक विविध रोजगार प्रदान करती है। अंत में, आप मैट्रिक्स के लिए एक ईंधन सेल प्राप्त कर सकते हैं।

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

नेटवर्क तैयार किए जाने चाहिए, केबल बिछाई जानी चाहिए, निगरानी प्रणाली की निगरानी, ​​समस्याओं का समाधान होना चाहिए।

बस हमारे जीवन को कुछ हद तक उचित बनाने की जरूरत है।

एक अधिक महत्वपूर्ण मुद्दा विक्रेता समर्थन है।
मैं पूरी तरह से मानकों और सुपर-प्रोटोकॉल के बजाय, इस तरह के एक सिस्टम नागविना पर लेख की टिप्पणियों से पूरी तरह सहमत हूं ।

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

बड़े ऑपरेटरों (और बहुत बड़े वाले नहीं) में अक्सर स्व-लिखित प्रणाली होती है। ये कॉन्फ़िगरेशन सत्यापनकर्ता, ऑटो-ट्यूनिंग स्क्रिप्ट और सतह समस्या विश्लेषक हैं।

इंजीनियर अक्सर निष्क्रिय और आलसी होते हैं, या इसके विपरीत अति सक्रिय होते हैं और मैन्युअल रूप से हजारों लाइनें बनाते हैं जो अगली पीढ़ी के प्रवेश के साथ हार्ड ड्राइव को स्वरूपित करते समय गायब हो जाएंगे।

हो सकता है कि जैसा भी हो, यह सब ऐसा नहीं है। बिलकुल नहीं।

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

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

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

इस लेख को लिखने के दौरान, जिसे मूल रूप से एक नोट के रूप में योजनाबद्ध किया गया था, मैं इस नतीजे पर पहुंचा कि विषय मेरे लिए बहुत दिलचस्प है और इस समस्या के लिए समर्पित लेखों की एक श्रृंखला होगी:

• नियंत्रण प्रणाली। अवसर, काम के सिद्धांत।
• उपकरणों और सेवा नियंत्रण के इंटेलिजेंट सिस्टम के बीच संपर्क जानकारी के आदान-प्रदान और आदान-प्रदान के प्रोटोकॉल।
• कॉन्फ़िगरेशन में त्रुटियों का पता लगाने और उन्मूलन।
• उपकरण सेटिंग्स का स्वचालन।