समर्थन के साथ नृत्य: प्रकार और समर्थन के रूप। लड़ाई में काम करने वाले सपोर्ट सिस्टम

सभी को नमस्कार! मेरा नाम अलेक्जेंडर अफेनोव है और मैं लमोडा में ऑर्डर प्रोसेसिंग टीम का टीम लीडर हूं। आज मैं आपको इसके बारे में बताना चाहता हूं कि हम कैसे समर्थन करते हैं।

पहले, आइए इस बारे में बात करें कि यह हमारी प्रक्रियाओं में कैसे अंतर्निहित है और सामान्य तौर पर हम अपने काम, स्प्रिंट और पुनरावृत्तियों की योजना कैसे बनाते हैं।

तब मैं आपको बताता हूं कि समर्थन कहां से आ सकता है और यह किस प्रकार में विभाजित है।
मैं इस बात का अनुभव साझा करूँगा कि हम किस प्रकार टीम के भीतर प्रत्येक प्रकार के समर्थन से निपटते हैं।

अंत में, हम उन प्रथाओं के पेशेवरों और विपक्षों पर विचार करते हैं जो हम उपयोग करते हैं और संक्षेप करते हैं।


मेरी टीम में अब दो सिस्टम हैं। पहली एक बड़ी और डरावनी चीज़ है जिसे ऑर्डर प्रोसेसिंग कहा जाता है। यह एक ऐसी प्रणाली है जो एक प्रक्रिया के जीवन चक्र को निर्माण प्रक्रिया से वितरण (या वापसी) तक स्वचालित करती है।

यह सेवा PHP 7 पर कताई कर रही है, डॉकटर में लिपटे हुए हैं और कुबेरनेट्स द्वारा ऑर्केस्टेड हैं, लेकिन साथ ही इसे Zend1 फ्रेमवर्क और सिम्फनी के टुकड़ों पर लागू किया गया है। जो लोग अब PHP पर प्रोग्राम करते हैं, उन्होंने कंपकंपी की हो सकती है। बाकी के लिए, मैं समझाऊंगा कि Zend1 एक ढाँचा है जिसका जीवन का अंत डेढ़ साल पहले हुआ था। यह अब समर्थित नहीं है और सुरक्षा पैच भी नहीं है।

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

पहली चीज़ जो हम मोनोलिथ से बाहर लाए हैं, वह तथाकथित रिफंड टूल है । वह मेरी टीम द्वारा संचालित दूसरी सेवा है और ग्राहक को पैसे की स्वचालित वापसी (मेरे सहयोगी की रिपोर्ट में अधिक) के लिए जिम्मेदार है।

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

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

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

उपयोग किए गए उपकरणों के बारे में बात करने के लिए संदर्भ की आवश्यकता होगी, इसलिए पहले हम सबसे बुनियादी के बारे में बात करेंगे।

प्रक्रियाएँ और भूमिकाएँ

हम समर्थन के साथ कैसे काम करते हैं और यह हमारे स्प्रिंट में किस स्थान पर है?

आनुपातिक बाल्टियाँ हैं जिन्हें मैं अपनी बाल्टियाँ कहता हूँ ।

हम तकनीकी बैकलॉग से 10% लेते हैं ताकि यह स्थिर न हो और अनिश्चित काल तक जमा न हो।

स्प्रिंट का लगभग 20% कुछ जोखिमों पर बिछाने के लिए लिया जाता है। उदाहरण के लिए, कोई व्यक्ति एक कार्य कर रहा था, लेकिन यह व्यक्ति "बस से टकरा गया था।" अगले एक को फिर से संदर्भ की जांच करनी होगी। नतीजतन, हम मूल्यांकन में नहीं उतरेंगे, और सब कुछ खराब होगा।

अगला, हम नियोजित समर्थन को बिछाते हैं। यही है, हम पहले से ही जानते हैं कि कुछ गलत है। यह एक ऐसी चीज है जो ज्यादा नहीं जलती है, और हम इसकी मरम्मत करेंगे।

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

शेष 30% परियोजनाएं हैं।

आपने शायद देखा कि यह 100% से अधिक निकला। यह इस तथ्य के कारण है कि हम हमेशा जितना हम वास्तव में कर सकते हैं उससे अधिक करने की कोशिश करते हैं। कभी-कभी हम सफल होते हैं, कभी-कभी बहुत नहीं।

मुख्य समर्थन मापदंडों

हम निम्नलिखित मापदंडों के अनुसार प्रत्येक समर्थन टिकट का मूल्यांकन देते हैं:

1. व्यापार के लिए आलोचना । यह उनके लिए कितना महत्वपूर्ण है और यह व्यावसायिक प्रक्रिया को कितना तोड़ता है?
2. SLA। हमें समस्या को काम करने और हल करने में कितना समय लेना चाहिए?
3. प्राथमिकता।

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

आलोचना और प्राथमिकता अलग-अलग शब्द हैं।

प्राथमिकता प्रकार

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

मेजर कुछ कम महत्वपूर्ण है और इसे लंबे समय तक दुरुस्त किया जा सकता है, क्योंकि इसमें काम के रास्ते, वैकल्पिक रास्ते हैं।

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

सेवा स्तर के समझौते के रूप में एक ऐसी चीज भी है, जो टीम के साथ समर्थन प्रणाली और सिस्टम के व्यवसाय के मालिक द्वारा स्थापित की जाती है। वे देखते हैं कि एक विशिष्ट शिकायत के हिस्से के रूप में व्यापार की कौन सी रेखा टूट गई है। यदि, उदाहरण के लिए, ऑर्डर बनने बंद हो गए हैं (ऑनलाइन स्टोर की मुख्य रोटी), तो इस समस्या की एक उच्च प्राथमिकता होगी, जिसे हम P1 कहते हैं। P प्राथमिकता है, एकता सबसे महत्वपूर्ण है।

P1 एक प्रकार का SLA है, जिसका अर्थ है कि हमें आधे घंटे के भीतर काम करने के लिए समस्या को उठाना चाहिए और इसे कुछ घंटों में हल करना चाहिए।

P2 कुछ कम महत्वपूर्ण है जो हमें कुछ घंटों में लेना है और दिन के दौरान तय करना है।

पी 3-पी 4 एक ऐसी चीज है जो टूट गई है और तत्काल मरम्मत की आवश्यकता नहीं है। आप किसी दिन ऐसा कर सकते हैं, इसे अगली यात्रा पर ले जा सकते हैं।

और यहां हम टीम द्वारा निर्धारित प्राथमिकता पर आते हैं। यह एक तकनीकी विशेषज्ञ, वरिष्ठ, सहायक अभियंता हो सकता है - जो कोई भी समस्या से निपटता है।

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

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

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

कौन सब कुछ रेक करेगा?

और जब यह सब किया जाता है, तो सवाल उठता है: कौन इस सुंदर छंटे हुए बैकलॉग को रेक करेगा? जवाब है: समर्थन इंजीनियर।

आप अधिक विस्तार से सुन सकते हैं कि समर्थन इंजीनियर कौन है और वह मेरी रिपोर्ट में क्या कहता है "तकनीकी बंधक: टीम लीड के साथ क्या और कौन टीम लीड चाहिए" 2018।

एक समर्थन इंजीनियर एक आदमी है जो एक समर्थन बैकलॉग से सर्वोच्च प्राथमिकता वाले कार्यों को लेता है और ठीक करता है। चूंकि सब कुछ खूबसूरती से सॉर्ट किया गया है, हमारा मानना ​​है कि सबसे ऊपर सबसे महत्वपूर्ण, जरूरी और "बेकिंग" है। यदि कोई कार्य नहीं हैं, तो वह तकनीकी बैकलॉग कर सकता है।

वह और क्या कर रहा है?

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

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

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

3. स्वचालन के कारणों की तलाश ।
उदाहरण : हम अपने सिस्टम में डेटा ट्रांसफर करते हैं, जो डिलीवरी सर्विस के काम को स्वचालित करता है। कभी-कभी यह पता चलता है कि मृत पत्र चैनल के उपयोग और अग्रेषण के साथ भी, हम वहां जानकारी नहीं दे सकते हैं। नतीजतन, ऐसे आदेश कहीं लटक जाते हैं, और उन्हें नाराज होने की आवश्यकता होती है।

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

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

अनुग्रह के स्रोत के रूप में नियमितता

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

बैकलॉग निरीक्षण

अगर कोई नहीं देख रहा है, तो हमें एक सुंदर ढंग से छांटा गया समर्थन बैकलॉग कहां मिलेगा?

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

विस्तृत प्राथमिकता

यह वही प्रक्रिया है जिसमें हम मूल्यांकन करते हैं कि कोई कार्य कितना महत्वपूर्ण है। यह तब सही छंटाई होगी, और समर्थन इंजीनियर ऊपर से सही काम करेगा।

प्राथमिकता के लिए लड़ाई

उदाहरण के लिए, वे आपके लिए एक कार्य निर्धारित करते हैं और कहते हैं: “दोस्तों, मासिक रिपोर्ट अपलोड नहीं की गई है। हमें इसे एक सप्ताह में करने की आवश्यकता है, लेकिन यह काम नहीं करता है। कृपया इसे ठीक करें। प्राथमिकता P1। आपको 2-3 घंटे के भीतर फैसला करना होगा। ”

और आप पूछते हैं: “गंभीरता से? आप लोग किस बारे में बात कर रहे हैं? आखिरकार, इसे ठीक करने के लिए एक सप्ताह है। चलो पी 2 को अपग्रेड करते हैं, और हमारे पास कुछ दिन होंगे। ”

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

नए कार्यों की स्थापना

इससे पहले, मैंने संतरी प्रणाली का उल्लेख किया है, जिसमें ऐसे कार्य शामिल हैं जो पहले से ही ग्राहकों द्वारा उड़ाए जा रहे हैं। हालाँकि, हम स्वयं उन समस्याओं की आशंका करते हैं जो इस बैकलॉग में कार्यों को उत्पन्न करती हैं और फेंकती हैं।

एसएलए प्रदर्शन की निगरानी

ऐसा करने के लिए, हमारे पास कार्यक्रम हैं जो बताते हैं कि हमारे पास कार्य हैं, जिसके लिए समय जल्द ही समाप्त हो जाएगा। ऐसा लगता है कि ये पहेली पहली बार में समझ में आती हैं।

सपोर्ट इंजीनियर सपोर्ट

एक सहायक अभियंता होने के नाते एक निराशाजनक प्रक्रिया है, इसलिए एक व्यक्ति को मदद करनी चाहिए। हम उसकी ज़िंदगी कैसे आसान बना सकते हैं?

टीम की अगली भूमिका को स्थानांतरित करना

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

समस्या के स्रोत को खोजने में मदद करें

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

"नए रूप" की आवश्यकता

यदि एक निश्चित अवधि के लिए कोई व्यक्ति दृश्यमान परिणाम प्राप्त नहीं कर सका, तो इस कार्य को दूसरे में स्थानांतरित किया जाना चाहिए। कोई अन्य व्यक्ति दूसरी तरफ से समस्या को देख सकेगा, जिससे समस्या का समाधान अलग तरीके से हो सकता है।

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

स्वचालन के लिए उपकरणों का विकास

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

सूत्रों का समर्थन करें

इतने समर्थन हैं कि हम कभी-कभी यह नहीं सोचते हैं कि यह इतनी बार कहां से आता है?

नई प्रणालियों और प्रक्रियाओं का स्थिरीकरण

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

पुराने सिस्टम के लिए समर्थन

उदाहरण के लिए, हमारे मोनोलिथ। वह स्थिर नहीं रह सकता, जैसा कि हम हमेशा जोड़ते हैं, उसे फिर से लिखते हैं। बेशक, यह एक नए समर्थन के निर्माण की ओर जाता है।

तकनीकी खराबी

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

मानव कारक

हमारे पास एक मामला था जब कोई व्यक्ति RabbitMQ में एक संदेश देने में सक्षम था कि हमारे उपभोक्ता ने लटका दिया, और सब कुछ काम करना बंद कर दिया। यह पिछले 7 वर्षों में कभी नहीं हुआ है, लेकिन यहाँ यह किसी भी तरह से प्रबंधित है :)

मानवीय कारक जिसके कारण विफलता हुई

किसी ने "मैं इसे अब ठीक कर दूंगा" शब्दों के साथ सर्वर से हार्ड ड्राइव निकाला, जिस पर बिलिंग कताई थी। नतीजतन, हमें वही मिला जो हमें मिला था। यह लमोड़ा अनुभव नहीं है, लेकिन मेरे अभ्यास से एक वास्तविक मामला है।

समर्थन प्रकार

विश्लेषिकी अनुरोध

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

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


डेटा परिवर्तन अनुरोध

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

ऐसा करने के लिए, हम नए एपीआई हैंडल बनाने की कोशिश करते हैं, इंटरफेस बनाते हैं, और इन कार्यों को विकास और हमारे ऑपरेशन टीम से अधिकतम ड्रॉप करने के लिए। यह एक खतरनाक अभ्यास है, और हम इंटरफ़ेस और एपीआई सुधार के माध्यम से इससे छुटकारा पाते हैं।

व्यापार प्रक्रियाओं की मरम्मत

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


फीचर एक्स ने काम करना बंद कर दिया

यह मेरा पसंदीदा प्रकार का समर्थन है, क्योंकि यह सबसे अधिक समझने योग्य है। यही है, हम ठेस में किसी तरह का था, लेकिन यह टूट गया और इसे ठीक करने की जरूरत है। पता करें कि किस रिलीज़ में मृत्यु हुई और किस कारण से हुई। टिकट की मरम्मत और बंद करें। सब कुछ सरल है।

लेकिन एक और समर्थन है - फीचर एक्स काम नहीं करता है । यह एक ही चीज़ की तरह लग सकता है, लेकिन दूसरे शब्दों में कहा गया है। हालाँकि, ऐसा नहीं है।

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

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

बड़ी घटना

यह सिर्फ ताबूत और पीट की आग की कहानी है, जब आईटी सिस्टम में कुछ इतनी बुरी तरह से टूट गया कि एक विशिष्ट व्यवसाय प्रक्रिया उत्पन्न हुई।

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

यह एक विशेष तरीके से ऐसी चीजों के साथ काम करने के लायक है, और मैं आपको बताऊंगा कि हम इसे कैसे करते हैं।

कैसे पता करें कि कुछ हो रहा है?

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

शायद आपको समर्थन सेवा से पता चल जाएगा , जो निगरानी की निगरानी करता है और सिस्टम पर ड्यूटी पर मौजूद व्यक्ति को सूचित करता है।

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

यह शांत है, लेकिन ऐसा लगता है कि यह पर्याप्त नहीं है। कई समस्याओं को रास्ते में भी पकड़ा जा सकता है, यदि आप कुछ रुझानों की निगरानी करते हैं।। हमारे पास ऐसा मामला था जब हमने मॉनिटर पर देखा कि सुबह में खरगोश एमक्यू क्लस्टर पर मेमोरी की खपत बढ़ने लगी थी। हमने समझा कि हमारे पास केवल 16 गीगाबाइट हैं, और कुछ घंटों में इस तरह की गतिशीलता के साथ स्मृति समाप्त हो जाएगी और सब कुछ गिर जाएगा।



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

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

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

और वे सब कुछ बाहर करने में कामयाब होने के बाद, पूर्वव्यापी चरण शुरू करते हैं।

पूर्वप्रभावी

लामोदा में, इस बैठक में, हमारे पास घटना में शामिल हर प्रणाली का एक व्यक्ति है। यदि आवश्यक हो, तो व्यवसाय का कोई व्यक्ति मौजूद है, कभी-कभी सीटीओ भी आता है। और इस बैठक में, हम यह वर्णन करते हैं कि वास्तव में क्या हुआ और किस प्रणाली में विस्फोट हुआ।

फिर सबसे मजेदार क्षण आता है - क्रियाओं के अनुक्रम का विश्लेषण। यही है, यदि संभव हो तो हमने निकटतम मिनट का पता लगाने और बुझाने के बीच क्या किया।



हम देखते हैं कि 13.05 पर कॉल सेंटर में एक शिकायत प्राप्त हुई थी। लगभग 13.13 तक यह स्पष्ट हो गया कि यह बड़े पैमाने पर है। और केवल 14.50 पर टीम ने काम करने के लिए काम लिया। इससे पहले, किसी कारण से, 1.5 घंटे सरल थे, हालांकि कार्य निर्धारित किया गया था, और टीम को सूचित किया गया था। ऐसा लगता है कि 1.5 घंटे में यह अंतर कम हो सकता है और इस तरह इस घटना पर लाखों रूबल बच सकते हैं।

यह समस्या क्यों उत्पन्न हुई?

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

आप यह भी देख सकते हैं कि फिक्स 16.55 पर उत्पादन में था, जो भी अजीब है, इससे पहले कि 40 से अधिक मिनट बीत चुके हैं। जब सब कुछ जाँचने लगता है, तो आप रोल कर सकते हैं, लेकिन हमने नहीं किया।

ऐसा क्यों हो रहा है?

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

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

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

डालना भी आवश्यक है । और फिर

निष्पादन को नियंत्रित करें। योजनाएं अच्छी हैं, लेकिन समस्या से बचना ज्यादा महत्वपूर्ण है।

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

पानी के नीचे पेशेवरों और विपक्ष

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

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

इसे हर समय कहाँ से लाएँ?

प्रारंभिक उत्तर है - यह स्पष्ट नहीं है कि कहां है। और यह सच है, क्योंकि यह बहुत कुछ प्रत्येक विशिष्ट व्यवसाय पर निर्भर करता है।

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

हालांकि, मैं समझता हूं कि हर किसी के पास ऐसा नहीं है। इसीलिए मेरा मानना ​​है कि यदि हम गंभीर समर्थन के लिए पूर्वव्यापी दृष्टिकोण लागू करते हैं, तो व्यवसाय को यह दिखाना संभव होगा कि पाइप में कितना पैसा जाता है, क्योंकि आईटी के पास आंतरिक समस्या और उग्र समर्थन को हल करने के लिए पर्याप्त संसाधन और समय नहीं है।

मीठा स्थान

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