समस्या की पहचान और परिभाषा

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

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

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

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

दायरा निर्धारित करने से खोज काफी सीमित हो जाती है। यदि केवल एक PC प्रभावित है, तो उस उपकरण या उसकी केबल की जाँच करें। यदि पूरा VLAN बंद है, तो स्विच या गेटवे पर संदेह करें। यदि पूरी साइट में इंटरनेट नहीं है, तो WAN लिंक या ISP पर ध्यान दें। समस्या के आकार को संभावित कारण के आकार से मिलाने पर बहुत समय बचता है।

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

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

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

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

अपने निष्कर्षों को एक सटीक समस्या-विवरण में मिलाएँ: कौन प्रभावित है, क्या विफल है, यह कब शुरू हुआ और कोई पैटर्न क्या है। "सुबह 9 बजे स्विच के पुनःचालू होने के बाद से VLAN 20 के सभी फ़ोन पंजीकृत नहीं हो पा रहे हैं"—यह "फ़ोन खराब हैं" से कहीं अधिक उपयोगी है। अच्छा विवरण उस आधार की तरह है जिस पर शेष पद्धति निर्मित होती है।

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

आपने समस्याओं की पहचान करना और उन्हें परिभाषित करना सीखा। मुख्य बिंदु:

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