कैसे एक सेवा प्रदाता ने अपनी सेवा डेस्क की

सभी को नमस्कार! मेरा नाम एलेक्सी वोल्कोव है। मेरे सहयोगी, डेवलपर अलेक्जेंडर सोलोविओव ( भीव ) के साथ, हम डेटालाइन में आंतरिक वेब सेवाएं करते हैं। यह गिरावट, हमने BMC रेमेडी को बदलने के लिए अपना सर्विस डेस्क लॉन्च किया। एक पोस्ट में मैं आपको बताऊंगा कि क्यों हमने एक तैयार समाधान से इनकार कर दिया और सब कुछ खुद किया।


प्रति दिन औसतन 450 एप्लिकेशन सर्विस डेस्क से गुजरते हैं।

रेमेडी ने हमें खुश नहीं किया क्या?

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

असुविधाजनक इंटरफ़ेस। एक आवेदन को पंजीकृत करने के लिए, इसे काम पर ले जाएं और इसकी अनुमति को नोट करें, हमें 100500 क्लिक करना होगा।


घटना के साथ पेज। संदेश की सामग्री के लिए कम से कम फ़ील्ड लें, जिन्हें एक विशेष विंडो में खोला जाना चाहिए।


समाधान लिखने के लिए या किसी अन्य निष्पादक को घटना को पुनर्निर्देशित करने के लिए टैब की एक पूरी झरना खोलने की आवश्यकता है।

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

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

पर्याप्त लाइसेंस नहीं। डाटालाइन के भोर में एक बार, हमने 100 लाइसेंस खरीदे। तब से, कंपनी तेजी से बढ़ी है। लाइसेंस प्रतिस्पर्धा कर रहे थे। तेजी से, ऐसे हालात पैदा हुए जब एक इंजीनियर को अपना काम करने के लिए लाइसेंस जारी होने का इंतजार करना पड़ा। दरअसल, यह आखिरी तिनका था।

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

सर्विस डेस्क 2.0

हटाने के लिए आसान काम थे। नई सेवा डेस्क का मुख्य कार्य सभी तकनीकी सहायता गतिविधि को "एक खिड़की" में खींचना है: संपर्क, कार्य पत्राचार, दस्तावेज। हम एक ग्राहक के समर्थन के लिए एक आवेदन भेजने के बाद होने वाली हर चीज की एक तरह की लॉगिंग प्राप्त करना चाहते थे। रास्ते के साथ, हम समर्थन की पहली पंक्ति पर लोड को कम करने और मानव कारक को अधिकतम करने के लिए कई चीजों को स्वचालित करना चाहते थे।

यहां उन कार्यों का सबसे महत्वपूर्ण है जो हमने नई सेवा डेस्क में लागू किए हैं:

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



एक ग्राहक और सहयोगियों के साथ पत्राचार। यह फ़ंक्शन केवल यह सुनिश्चित करने के लिए है कि घटना पर पत्राचार मेल में "लीक" नहीं करता है और संचार का पूरा इतिहास हमारे साथ रखा गया था।

अब तक, सब कुछ बहुत न्यूनतर है। फाइलें, टेबल आदि डाउनलोड करने की क्षमता के साथ एक पूर्ण-पाठ संपादक बनाने की योजना है।



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



यह आंतरिक घटना के लिए नियुक्तियों की कहानी है "एक कर्मचारी का बर्खास्तगी।"


हादसा इतिहास। यहां हम अभी भी सुंदरता लाएंगे, लेकिन मुख्य कार्य पहले ही हल हो चुका है - सब कुछ लॉग इन है।

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



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

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



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

• प्रति दिन अनुरोधों की संख्या;
  
• प्रतिक्रिया की गति;
  
• अनुरोधों में देरी;
  
• अनुरोधों के प्रकार;
  
• विभागों द्वारा लोडिंग;
  
• प्रेषणकर्ता काम करते हैं;
  
• ग्राहकों के संदर्भ में उभरती समस्याओं की आवृत्ति और गुणवत्ता;
  
• विभिन्न निर्भरताएं, उदाहरण के लिए, अनुरोध के प्रकार पर निष्पादन की गति।
  

थोड़ी देर बाद हम चार्ट और ग्राफ़ के साथ डैशबोर्ड बनाना चाहते हैं, ताकि एक्सेल में किसी भी उतराई और जादू टोना के बिना हमें एक तस्वीर मिल जाए जो तकनीकी समर्थन में हो रही है।


फ़िल्टर का उपयोग करके रिपोर्ट सीधे सेवा डेस्क में उत्पन्न की जा सकती है।


विभिन्न प्रारूपों में डेटा लोड करना।


आप उन फ़ील्ड्स का चयन कर सकते हैं जो अपलोड में प्रदर्शित होंगे।

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

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


किसी भी चेकलिस्ट आइटम के लिए एक घटना बनाई जा सकती है।


बाईपास सॉफ्टवेयर के अंदर एक घटना के लिए एक फार्म। एक ही वस्तु पर काम में ऊपर लटकने वाली घटनाएं।

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

की शुरूआत

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

तब हम बाहरी अनुप्रयोगों के प्रसंस्करण को चलाने के लिए तीन ग्राहकों के साथ सहमत हुए। यहीं से पहली समस्याएं हुईं।

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

मुझे मैनुअल लेबर जोड़ना था - एक कंट्रोल रूम दिखाई दिया। यह सभी अनुप्रयोगों के लिए एक purgatory है जो support@dtln.ru पर आया है। वहां से, प्रेषणकर्ता विभाग द्वारा मैन्युअल रूप से आवेदन पत्र वितरित करते हैं।



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

आगे क्या है?

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

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


यह वही है जो एक पैरामीटर क्रम में दिखता है।

तकनीकी सहायता का मूल्यांकन। कुख्यात "पांच-पैमाने पर हमारी सेवा को रेट करते हैं" मुक्त रूप में लिखने की क्षमता के साथ, वह सब कुछ जो क्लाइंट हमारी सेवा के बारे में सोचता है।

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

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

***
सेवा डेस्क नवंबर से युद्ध मोड में काम कर रहा है, और इस बार मैं मुख्य रूप से आंतरिक अनुरोधों के कारण घटनाओं (+ 40%) की संख्या में लगातार वृद्धि देख रहा हूं। मैं आशा करता हूं कि यह इस तथ्य के कारण है कि नई सेवा डेस्क सभी मामलों में अधिक अनुकूल है और अनुरोध किया गया है कि वह उसके अतीत को समाप्त कर दें।

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