बार-बार होने वाले इंसिडेंट से सुधार बैकलॉग तक
उपयोग का उदाहरण, ग्राहक केस स्टडी नहीं।
दोहराए जाने वाले इंसिडेंट को संभावित कारण के अनुसार समूहित किया जाता है और उनकी टिकट लागत के मुकाबले आँका जाता है, ताकि स्वामी सुधार बैकलॉग में समाधानों को प्राथमिकता दे सके।
समस्या
वही इंसिडेंट हर महीने लौट आते हैं: एक विफल होता इंटरफ़ेस, एक रिपोर्ट जो क्लोज़ के समय टाइम-आउट हो जाती है, एक कॉन्फ़िगरेशन जो हर रिलीज़ के बाद भटक जाता है। हर एक को अलग-अलग हल किया जाता है, पैटर्न का कोई स्वामी नहीं है, और सपोर्ट बजट एक ही समस्या के लिए बार-बार भुगतान करता है।
आज यह कैसे काम करता है
लक्षण हटते ही इंसिडेंट अलग-अलग बंद कर दिए जाते हैं। मासिक रिपोर्ट श्रेणी के अनुसार टिकट गिनती है। मूल कारण विश्लेषण केवल बड़े इंसिडेंट के लिए होता है। सुधार अनुरोध नई परियोजना माँगों से प्रतिस्पर्धा करते हैं और शायद ही कभी शेड्यूल होते हैं, इसलिए दोहराया जाने वाला काम सपोर्ट कतार में बना रहता है।
परिदृश्य देखें
त्वरित अवलोकन
उदाहरणात्मक कार्यप्रवाह। उपशीर्षक सहित।
प्रतिलेख
- वही इंसिडेंट हर महीने लौट आते हैं। हर एक अलग से हल होता है, पैटर्न का कोई स्वामी नहीं है, और सपोर्ट बजट उसी समस्या के लिए फिर भुगतान करता है।
- हल हो चुके इंसिडेंट संभावित कारण से समूहित होते हैं। हर समूह में सुधार के लिए आवश्यक प्रयास का अनुमान लगाया जाता है और उसकी तुलना दोहराव से लगने वाले टिकटों और काम के घंटों से की जाती है।
- स्वामी सुधार बैकलॉग के लिए सुधारों को अनुमोदित करता है। बदलाव रिलीज़ जाँच से गुज़रते हैं, और इंसिडेंट डेटा दिखाता है कि समस्या लौटती है या नहीं।
- पुनरावृत्ति दर और बार-बार होने वाले इंसिडेंट पर सपोर्ट घंटों से मापा जाता है। उपयोग का एक उदाहरण। आइए आपके मामले पर चर्चा करें।
विस्तृत परिदृश्य
उदाहरणात्मक परिदृश्य। एक काल्पनिक सपोर्ट इंजीनियर हर महीने लौट आने वाले इंसिडेंट को एक ऐसे सुधार में बदलता है जिसकी प्राथमिकता स्वामी तय करता है और जो रिलीज़ जाँच से गुज़रता है। 1:13
प्रतिलेख
- Sam टिकट खोलने से पहले ही उसे पहचान लेती है। वही लक्षण लौट आया है, और उसके साथ वही जाँच भी।
- अलग-अलग, हर इंसिडेंट हल हो गया था। साथ रखने पर वे संकेत देते हैं कि एक बार-बार होने वाली समस्या है जिसका एक स्वामी होना चाहिए।
- इंसिडेंट को संभावित कारण के अनुसार समूहित करें, पैटर्न का सत्यापन करें, और समाधान के प्रयास की तुलना पुनरावृत्ति से पैदा होने वाले सपोर्ट काम से करें।
- स्वामी तय करता है कि समाधान सुधार बैकलॉग में जाएगा या नहीं, और अन्य प्राथमिकताओं के मुकाबले उसका स्थान कहाँ होगा।
- अनुमोदित बदलाव रिलीज़ और रिग्रेशन जाँच से गुज़रते हैं। प्रस्तावित सुधार प्रोडक्शन बदलने की अनुमति नहीं है।
- रिलीज़ के बाद ट्रैक करें कि समस्या लौटती है या नहीं, और उस पर कितना सपोर्ट प्रयास लगता है। आपकी टीम को आगे किस बार-बार होने वाली समस्या की जाँच करनी चाहिए?
- [अंतिम स्क्रीन] आपकी टीम को आगे किस बार-बार होने वाली समस्या की जाँच करनी चाहिए? अपने बार-बार होने वाले इंसिडेंट पर चर्चा करें. qxorbit.ai/hi/contact
- उपयोग का उदाहरण, ग्राहक केस स्टडी नहीं।
प्रस्तावित कार्यप्रवाह
- इंसिडेंट वर्गीकरण, समाधान नोट और प्रभावित घटकों का उपयोग करके हल किए गए इंसिडेंट को संभावित मूल कारण से समूहित करें
- हर दोहराए जाने वाले समूह के लिए सुधार का आकार आँकें: आवश्यक बदलाव, प्रभावित परिवेश, रिलीज़ और रिग्रेशन प्रयास
- सुधार की तुलना बार-बार होने वाली लागत से करें: प्रति माह टिकट, इंजीनियर घंटे, स्वामियों द्वारा बताया गया व्यावसायिक प्रभाव
- क्रमबद्ध उम्मीदवारों को एप्लिकेशन स्वामी के सामने रखें, जो तय करता है कि सुधार बैकलॉग में क्या जाएगा
- अनुमोदित सुधारों को रिग्रेशन जाँच के साथ रिलीज़ प्रक्रिया से डिलीवर करें, और रिलीज़ के बाद पुनरावृत्ति की निगरानी करें
जहाँ नियंत्रण व्यक्ति के पास रहता है
- समूहन और आकलन प्रस्ताव हैं; स्वामी तय करता है कि क्या और किस क्रम में ठीक किया जाए
- नियोजित सुधार तय रिलीज़ और रिग्रेशन प्रक्रिया का पालन करते हैं; तत्काल बदलावों के लिए तय आपातकालीन प्राधिकरण आवश्यक है
- सुधार मद बंद करने का निर्णय लेने से पहले तय अवलोकन अवधि के सापेक्ष पुनरावृत्ति डेटा की समीक्षा करें
प्लेटफ़ॉर्म मैपिंग उन परिवेशों को दर्शाती है जिनमें इस विचार का मूल्यांकन किया जा सकता है। वास्तविक कार्यान्वयन कॉन्फ़िगरेशन, लाइसेंस, API, डेटा और अनुमतियों पर निर्भर करता है। लाभ गुणात्मक रूप से बताए गए हैं; संख्यात्मक दावों के लिए प्रलेखित आधार-रेखा आवश्यक है।