डॉन जोन्स। "अपने वातावरण में एकीकृत आईटी निगरानी प्रणाली बनाना।" अध्याय 2. आईटी प्रबंधन में व्यक्तिगत साइटों के लिए प्रबंधन प्रथाओं का उन्मूलन

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

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

अतः, अध्याय 2। ऐसा करने के बारे में ताकि जानकारी खंडित न हो। उन लोगों के लिए जो पहले से ही निगरानी प्रणालियों का उपयोग करते हैं, कई चीजें परिचित लगेंगी।

सामग्री

अध्याय 1. अपने आईटी वातावरण का प्रबंधन: चार चीजें जो आप गलत करते हैं
अध्याय 2. आईटी प्रबंधन में व्यक्तिगत साइटों के लिए प्रबंधन प्रथाओं का उन्मूलन
अध्याय 3. एक आईटी प्रबंधन चक्र में सब कुछ जोड़ना
अध्याय 4. निगरानी: डेटा केंद्र से परे एक नज़र
अध्याय 5: समस्याओं को समाधान में बदलना
अध्याय 6: उदाहरणों के साथ एकीकृत प्रबंधन

अध्याय 2. आईटी प्रबंधन में व्यक्तिगत साइटों के लिए प्रबंधन प्रथाओं का उन्मूलन

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

बहुत अधिक साधनों का अर्थ बहुत कम निर्णय होता है

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


चित्र 2.1: मॉनिटरिंग एक्सचेंज सर्वर।

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


चित्र 2.2: सक्रिय निर्देशिका स्थिति की निगरानी।

यदि निर्देशिका सेवा ठीक है, तो समस्या को नेटवर्क अवसंरचना विशेषज्ञ को भेजा जाना चाहिए। उसे एक और टूल मिलेगा जो प्रदर्शन मूल्यांकन स्क्रीन के साथ एंटरप्राइज राउटर मैनेजमेंट सॉफ्टवेयर की तरह लग सकता है। चित्र 2.3 देखें।


चित्र 2.3: सिस्को राउटर स्वास्थ्य निगरानी।

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

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

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

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

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

विशिष्ट उपकरण सहयोग की सुविधा नहीं देता है

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

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

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

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

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

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

विशेष सॉफ्टवेयर की उपस्थिति, जो एक और तकनीकी विशेषज्ञता को संदर्भित करती है, इसके परिणामस्वरूप इन दो कठिनाइयों का परिणाम है जो मैंने पहले के बारे में बात की थी।

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

बादल का मुद्दा। स्थानीय और दूरस्थ निगरानी का एकीकरण

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

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

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

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


चित्र 2.4: एकीकृत निगरानी के लिए संकेतकों का एक समूह।

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

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

लापता साइटें

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


चित्र 2.5: अनुप्रयोग संरचना।

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


चित्र 2.6: विस्तृत अनुप्रयोग आरेख।

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

और फिर से, एकीकृत निगरानी एक फायदा हो सकता है। केवल एक तकनीकी हिस्से पर ध्यान केंद्रित करने के बजाय - उदाहरण के लिए, सर्वर; वह तकनीकी रूप से स्वतंत्र हो सकता है और हर जगह से जानकारी एकत्र कर सकता है ।

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

, -. – , , , , SaaS . , , . , .
, . ''. , , . , , , , . .
-, : . , , , - . «»- , , .

, , « ». , , , .

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

आईटी में सब कुछ एक समस्या नहीं है: सेवाओं के आदेश, मार्ग और प्रावधान।

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

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

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

कुछ विस्तृत कार्यक्षमता पर विचार करें जो एकीकृत प्रबंधन (सिर्फ "मॉनिटरिंग" के विपरीत) समस्याओं को सुलझाने और आईटीआई प्रदर्शन करने से संबंधित काम के लिए पेशकश कर सकते हैं:

• वर्कफ़्लो - जब समस्याएं उत्पन्न होती हैं, तो उन्हें एक संरचित प्रक्रिया या वर्कफ़्लो के लिए निर्देशित किया जाना चाहिए। यह अनिवार्य चरणों की श्रृंखला के माध्यम से अनिवार्य पारित होने के साथ समस्याओं को हल करने में मदद करेगा। समस्याओं और विभिन्न नियमित सेवाओं को हल करने के लिए वर्कफ़्लो अलग-अलग होंगे, लेकिन वर्कफ़्लो को प्रबंधित करने और ट्रैक करने की क्षमता होने से वास्तविक लाभ हो सकता है।
• . . , , , , . ; , , , .
• . , , , . , – - , , «». , . : , . .
• . -. , . , , . , -.
• . « » , .

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

अगले एपिसोड में ...

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

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

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

अध्याय 1 पर

जाएँ अध्याय 3 पर जाएँ