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

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


सामग्री

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

अध्याय 5: समस्याओं को समाधान में बदलना

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

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

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

हम चक्र को बंद करते हैं: हम सेवा डेस्क को निगरानी से जोड़ते हैं

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


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

हमारे अलर्ट के बारे में क्या है - एक अलार्म संदेश?

बेशक, निगरानी प्रणाली का वह हिस्सा जो वास्तविक समय की ट्रैकिंग में लगा हुआ है, यह समझ जाएगा कि समस्या अब मौजूद नहीं है, लेकिन इसका मतलब यह बिल्कुल नहीं है कि अलार्म संदेश गायब हो जाएगा।

आमतौर पर, आपको समस्या को हल करने तक अलर्ट रखने की आवश्यकता होती है, जब तक कि यह पूरी तरह से तय नहीं हो जाता है, जिसका मतलब है कि जब आप टिकट बंद करते हैं, तो आपको किसी तरह अलार्म संदेश को साफ करने की आवश्यकता होती है।

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


चित्र 5.2: टिकट बंद करना मूल अलर्ट को रीसेट करता है।

अलर्ट और टिकट को अलग करने का एक अच्छा कारण है।

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

ज्ञान के संरक्षण का मतलब है भविष्य में समस्याओं का तेजी से समाधान

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

ज्ञान का आधार

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

सबसे पहले ज्ञान के आधारों में से एक, जो व्यापक हो गया था, वह था माइक्रोसॉफ्ट केबी, जिसे 1990 के दशक की शुरुआत में सीडी पर भेज दिया गया था। आज, यह ऑनलाइन लेखों का एक बड़ा संग्रह है - इतना बड़ा कि ज्ञान आधार में एक अलग लेख है कि इसे सही तरीके से कैसे क्वेरी करें (चित्र 5 में दिखाया गया है। यदि आप मुझ पर विश्वास नहीं करते हैं)।


चित्र 5.3: Microsoft ज्ञानकोष से लेख।

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

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

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

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

ज्ञानकोष लेख के रूप में टिकट

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

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

ज्ञान का आधार एकीकरण

दो चीजें हैं जिनके साथ आप मदद डेस्क से टिकटों को उपयोगी बीज़ेड लेखों में बदलने की कोशिश कर सकते हैं। सबसे पहले, कुछ स्वचालन की आवश्यकता है। जब एक नया टिकट बनाया जाता है, तो जिस सिस्टम में यह किया जाता है उसे स्वचालित रूप से नवीनतम टिकटों की समीक्षा करनी चाहिए और उन्हें एक तकनीकी विशेषज्ञ के समाधान के लिए उम्मीदवार के रूप में प्रस्तुत करना चाहिए जो किसी समस्या पर काम करने जा रहा है।
यदि आप कुछ प्रश्न पूछते हैं तो इसका एक बड़ा उदाहरण कैसे हो सकता है - StackOverflow.com; अपने आप में, यह पहले से ही टिकट / ज्ञान के आधारों के संयोजन का प्रतिनिधित्व करता है। यह स्वचालित रूप से नवीनतम प्रश्नों की खोज करता है और उन्हें एक अलग तरीके से नेत्रहीन रूप से प्रस्तुत करता है: उन्हें आपके प्रश्न के नीचे डाला जाता है, लेकिन उस फ़ील्ड के ऊपर जहां आप अपने अनुरोध का विवरण दर्ज करते हैं, जैसा कि चित्र 5.4 में दिखाया गया है। यह आपको ज्ञान के आधार से मान्यताओं की समीक्षा करने के लिए मजबूर करता है, ताकि आप जल्दी से देख सकें कि शायद आपके प्रश्न का उत्तर पहले से ही है।


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


चित्र 5.5: नई समस्याओं को हल करने के लिए पुराने टिकटों का उपयोग करना।

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

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

चित्र 5.6। दिखाता है कि सिस्टम इसे कैसे लागू कर सकता है - इस मामले में, यह चेक बॉक्स नहीं है; सिस्टम "होल्ड पर" से "प्रकाशित" करने के लिए टिकट की स्थिति बदलने के लिए "दृश्यता" आइटम ड्रॉप-डाउन मेनू का उपयोग करता है


चित्र 5.6: टिकट दृश्यता का प्रबंधन

इन चेकमार्क (या अन्य संकेतक) की मात्र उपस्थिति तकनीशियनों के लिए एक अनुस्मारक के रूप में काम कर सकती है जो दस्तावेज़ों के समाधान आवश्यक हैं। प्रबंधन के दृष्टिकोण से, संगठन कुछ कोटा निर्धारित कर सकते हैं: कम से कम 75% टिकटों को बंद करना एक विस्तृत समाधान होना चाहिए, या एक टिकट का संदर्भ देना चाहिए जो समस्या को हल करने के लिए विस्तृत प्रक्रिया का वर्णन करता है। , , .

, , , . , -- , :

• , , .
• – , , , , .
• , , , , . , , , «» « », .

– , , – .

– . « », SLA , . , – , , . , SLA , , .

, SLA – . - « », 99.999% , « », - , , .

– . , «», , , . . - , « » , . , , .

: . , . , , . , , , , . , , SaaS , , , . : ?

. , – ? 5.7 , , , .


5.7: .

, : . , , - , , — , , . , , , . , . , - , - . , SLA – , , . , , SLA.

, – . , , , ( ) . , .

, , , . : , , .

, , . , (, ). , , , , .

, , . , , , . , , , .
, : . , SLA, . « 100 »,- , ? , , , , , , . , , , , , , , , , . , प्रदर्शन की उम्मीदों में कार्यभार की अवधारणा भी शामिल थी - भविष्य में सेवा स्तर के समझौतों को तैयार करने के लिए यह आवश्यक है ।

इस डेटाबेस प्रदर्शन

- , - . , : , . (.5.8)


5.8: .

, – , , . क्यों? :

• , , . , , SLA.
• , . , – . , : «, , 1%, 0,75%? , SLA 6 .»

, , « » . : « SLA, , ». , « SLA, , , , SLA ».

, , , , , , , , SLA.

परिणाम

, — . , , : — , .

अगले अध्याय में ...

, , . , , , , . .