आपके समस्या निवारण नियम, समस्या निवारण के लिए दृष्टिकोण? [बन्द है]


22

क्या आपके पास कोई सामान्य नियम हैं जो किसी कठिन नेटवर्क / हार्डवेयर / सॉफ़्टवेयर समस्या का निवारण करते समय आप वापस गिर जाते हैं?

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


शायद मुझे शीर्षक संपादित करना चाहिए। मुझे पता है कि कोई व्यक्ति "धन्यवाद" का जवाब देने वाला है; मुझे इस पर गर्व है; ;-)
उपयोगकर्ता नाम

जवाबों:


16

कुछ समय के लिए किसी समस्या से लड़ने के बाद मैंने अपने लिए लिखी बातों की एक सूची दी:

  1. आपका प्राथमिक लक्ष्य क्या है ? स्पष्ट रूप से और संक्षिप्त रूप में कहा जाना चाहिए। लक्ष्य बहुत खास होना चाहिए। यह सामान्य नहीं होना चाहिए। अधिमानतः एक वाक्य
  2. आपकी समस्या क्या है ?
  3. वहाँ सिर्फ एक समस्या या कई है ? यदि कई हैं, तो उन्हें एक बार में हल करें।
  4. विभिन्न स्थितियों के साथ समस्या को पुन: उत्पन्न करने का प्रयास करें । क्या यह सभी संभावित परिस्थितियों में पुन: पेश किया जा सकता है या नहीं? क्या यह समस्या की प्रकृति के बारे में कुछ कहता है?
  5. यदि यह एक जरूरी समस्या है तो क्या कोई समाधान है ? संभव के रूप में कई workarounds खोजने की कोशिश करें।
  6. के रूप में बनाने की कोशिश करें कई अनुमान है कि आपके समस्या का कारण है पर संभव के रूप में।
  7. अपने अनुमानों को साबित करने की कोशिश करें, सिस्टम के साथ प्रयोग करें।
  8. आप जो करने की कोशिश कर रहे हैं, उसके अनुरूप हो । एक समय में एक काम करो।
  9. आप जो कर रहे हैं, उस पर नज़र रखें कि आपने पहले से क्या प्रयास किया है।
  10. करो विचलित नहीं अपने प्राथमिक लक्ष्य से। लगातार जांच करें कि क्या आप अभी भी अपनी मुख्य समस्या को हल कर रहे हैं, एक अलग नहीं।
  11. दोनों को ठीक करें ।

डिबगिंग नियमों की एक बड़ी सूची भी थी, यह एक पीडीएफ फॉर्म में था जिसमें प्रत्येक नियम के लिए एक्सैपल्स और स्पष्टीकरण थे। मैं जल्दी से पीडीएफ नहीं ढूँढ सका, लेकिन मुझे लगता है कि यह सूची का एक पोस्टर है:

यहां छवि विवरण दर्ज करें


15
  • यदि समस्या इंटरनेट से संबंधित है, तो यह संभवतः DNS है।

  • यदि समस्या का निदान करना कठिन है, तो शायद यह रैम है।

  • यदि समस्या विंडोज वर्कस्टेशन के साथ है, तो संभवतः इसे फिर से तैयार करना सबसे तेज़ है।

  • यदि समस्या शुक्रवार को है, तो यह संभवतः कुछ गंभीर है।


मैं एक मजाक पोस्ट को कम करना चाहता था, लेकिन यह आश्चर्यजनक रूप से सटीक है!
TessellatingHeckler

मुझे # 3 पसंद आया; अधिक सच नहीं हो सकता है।
फेडरर

10

मुझे वैज्ञानिक पद्धति पर वापस आना पसंद है ।

से ( http://en.wikipedia.org/wiki/Scientific_method )

  1. प्रश्न को परिभाषित करें
  2. जानकारी और संसाधन इकट्ठा करें (निरीक्षण करें)
  3. रूप परिकल्पना
  4. प्रयोग करें और डेटा एकत्र करें
  5. डेटा का विश्लेषण
  6. डेटा की व्याख्या करें और निष्कर्ष निकालें जो नई परिकल्पना के लिए शुरुआती बिंदु के रूप में काम करते हैं
  7. दस्तावेज़ परिणाम

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

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

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

O'Reilly के पास एक अच्छी पुस्तक नेटवर्क समस्या निवारण उपकरण है जिसका अनुसरण करने के लिए चरणों का एक अच्छा सेट है जो वैज्ञानिक विधि के समान है। मैंने पुस्तक को बहुत उपयोगी पाया और इसकी दृढ़ता से अनुशंसा की। पुस्तक बहुत अधिक विस्तार में जाती है और कई उपयोगी उपकरण सुझाती है।

से नेटवर्क समस्या निवारण टूल

  1. अपना लक्ष्य बताएं
  2. सिस्टम को परिभाषित करें
  3. संभावित परिणामों की पहचान करें
  4. पहचानें और चुनें कि आप क्या मापेंगे
  5. यदि उपयुक्त परीक्षण पैरामीटर्स और कारकों की पहचान करें
  6. उपकरण का चयन करें
  7. माप की बाधाओं को स्थापित करें
  8. प्रयोगात्मक डिजाइन की समीक्षा करें
  9. डेटा इकट्ठा करना
  10. डेटा का विश्लेषण

यह भी देखें:


निश्चित रूप से। यद्यपि, चरण 7 कुछ हद तक विनम्र है। मेरा डॉक्टर आमतौर पर "हां, यह तय हो गया है। अब यह काम करता है।"
स्क्विलमैन

मैं वैज्ञानिक पद्धति का सम्मान करता हूं, मुझे लगता है कि इससे पहले कि मैं मानता हूं कि एक मानवीय कारक होना चाहिए, जिसके माध्यम से चलने की आवश्यकता है। उदाहरण के लिए, मुझे रिपोर्टिंग के स्रोत (समस्या की रिपोर्ट करने वाले व्यक्ति) पर विचार करना होगा ... और यह मानने से सावधान रहना चाहिए कि वह एक 'विश्वसनीय' स्रोत है (विश्वसनीय द्वारा, मेरा मतलब है कि वह / वह एक अच्छा होगा प्रश्न को परिभाषित करने, जानकारी इकट्ठा करने और मेरी पहली परिकल्पना बनाने में मेरी सहायता करने के लिए संसाधन)।
l0c0b0x

10

(ये हाइलाइट्स "द प्रेक्टिस ऑफ सिस्टम एंड नेटवर्क एडमिनिस्ट्रेशन" के "डिबगिंग" अध्याय से समाहित हैं )

जानने के लिए दो बातें:

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

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

दो रणनीतियाँ:

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

  2. घटाव: समस्या दूर होने तक घटकों को हटाते रहें। आपने जो अंतिम चीज़ निकाली वह समस्या थी: उदाहरण: दर्जनों कार्ड वाली मशीन बूट नहीं होगी। मशीन के बूट होने तक कार्ड निकालते रहें।

गूंगे भाग्य के दो टुकड़े:

  1. मेरी कही हर बात को भूल जाओ। यह समस्या सिस्टम में किए गए अंतिम बदलाव के कारण हो रही है। (यह समय के ९९% काम करता है ... समस्या यह है कि ९९% समय आपको नहीं पता है कि वास्तव में अंतिम परिवर्तन क्या था)

  2. जब बाकी सब विफल हो जाता है, तो बेवकूफ चीजों की जांच करें। http://whatexit.org/tal/mywritings/dumb-things-to-check.html उदाहरण: एक पागल समस्या को सिर्फ समझाया नहीं जा सकता। फिर हमने कॉन्फ़िगरेशन फ़ाइल की जांच की: एक उपयोगकर्ता ने इसे एक विंडोज बॉक्स में कॉपी करके संपादित किया था, इसे संपादित किया, फिर इसे वापस कॉपी किया। अब हर पंक्ति के अंत में एक ^ M था। हमने कभी गौर नहीं किया क्योंकि हमारे पाठ संपादक ने चुपचाप इस तथ्य को छिपा दिया था। अफसोस की बात है कि कॉन्फ़िगरेशन फ़ाइल को पढ़ने वाले सॉफ़्टवेयर ने ^ ^ को एक गैर-ब्रेक स्थान में बदल दिया, जिसने अन्य प्रक्रियाओं के टन को खराब कर दिया।


6

पूरी प्रक्रिया के दौरान मुझे जो सामान्य अभ्यास याद हैं:

  1. मैं जो कुछ करता हूं उसे लिखो।
  2. एक समय में केवल एक बदलाव करें।
  3. यदि संभव हो, तो एक और प्रयास करने से पहले परिवर्तन को उलट दें जब तक कि निश्चित प्रगति नहीं हो रही है।

समस्या निवारण के दौरान यहाँ मेरी मूल कार्यप्रणाली को परिभाषित किया गया है:

  • जब सिस्टम उठ रहा है और अच्छी तरह से चल रहा है, इससे पहले कि कोई समस्या हो, मैं यह देखने के लिए सीखने की कोशिश करता हूं कि यह क्या कर रहा है। जो रिचर्ड्स बताते हैं कि इस छोटी सी जगह में मैं इससे बेहतर क्यों हो सकता हूं
  • मैं सबसे सरल समाधान के साथ शुरू करता हूं। उदाहरण के लिए, नेटवर्क कनेक्टिविटी नहीं? भौतिक परत की जाँच करें। मैं आपको यह नहीं बता सकता कि कितनी बार रुक-रुक कर कनेक्शन की समस्याएं एक सर्वर समस्या नहीं थीं, लेकिन एक नेटवर्क केबल जो आधा या एक था जो खराब हो गया था।
  • मैं उन सभी लक्षणों को पकड़ने की कोशिश करता हूं जिन्हें मैं बदलाव करने से पहले सभी संभावित स्रोतों से देख सकता हूं।
  • मैं प्रारंभिक नैदानिक ​​परीक्षण चलाता हूं। उदाहरण के लिए, जब मुझे बताया जाता है कि सर्वर डाउन हो गया है, तो पहली बात यह है कि पिंग और nbtstat (Windows) का उपयोग करें ताकि इसे सत्यापित किया जा सके। समस्या दूर के अंत में हो सकती है (एक पुरानी वायु सेना तकनीक नियंत्रण कह उधार लेने के लिए)।
  • मैं शोध करने से नहीं डरता। Google, support.microsoft.com, eventid.net और जैसी साइटें आपकी मित्र हैं।
  • मैं समुदाय से मदद मांगने से नहीं डरता। सिर्फ सर्वरफॉल्ट.कॉम जैसी साइटें ही नहीं हैं, बल्कि मेरे पास उन लोगों का एक अच्छा वर्गीकरण है, जिन पर मैं भरोसा करता हूं और ट्विटर पर सम्मान करता हूं।
  • मैं उन उत्तरों का मूल्यांकन करता हूं जो मैं देख रहा हूं जो मैं देख रहा हूं। मुझे लगता है कि कोई भी एक समाधान सही नहीं है जब तक कि मैं उन सबूतों के पर्याप्त विचार नहीं कर सकता जो मैं समाधान में बताए गए हैं।

6

मेरे द्वारा किया गया प्रयास

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

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

मैं समस्या निवारण के बारे में सोचता हूं:

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

समस्या निवारण की प्रक्रिया:

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

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

तो साइट लोड नहीं है, अब क्या? यह अभी तक ठीक करने योग्य नहीं है, इसलिए समस्या को एक छोटे से करने के लिए स्थानों की तलाश करें। सर्वर पर है? क्या यह पिंग करता है? DNS काम करता है? हाँ। पोर्ट 80 पर सेवा का जवाब है? क्या सेवा चल रही है? क्या यह शुरू होता है? क्या यह ईवेंट लॉग / लॉगफाइल्स में त्रुटियां देता है? हाँ! वे क्या कहते हैं?

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

जितना संभव हो उतने बड़े "चींटियों को बाहर निकालो"।

सिस्टम को समझें। मेरे पास सिस्टम के बारे में जितना अधिक सामान्य ज्ञान है, यह उतना ही आसान हो जाता है। जहाँ मेरी समझ कमज़ोर है, समस्याएँ अधिक भयभीत करने वाली, अधिक कठिन, धीमी गति से चलने वाली, और एक फिक्स की तुलना में एक वर्कअराउंड के साथ समाप्त होने की अधिक संभावना है, या एक छोटे, सटीक सर्जिकल फिक्स की तुलना में एक बड़े गूंगे धीमे फिक्स (पुनर्स्थापना) के साथ।


4

आम तौर पर मैं पूछता हूं "क्या बदल गया है जो इस समस्या का कारण हो सकता है"? अधिकांश मुद्दे ज्ञात अच्छे कॉन्फ़िगरेशन में परिवर्तन के कारण होते हैं। यदि आप अलग कर सकते हैं कि किसने परिवर्तन किया है तो आप आमतौर पर अपना उत्तर प्राप्त करते हैं।


2

मुझे लगता है कि यह एक कौशल है, विज्ञान नहीं। ऐसे समय होते हैं जब आप गलत रास्ते पर जाते हैं लेकिन अधिकांश भाग के लिए:

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

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


1

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

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


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

स्पष्ट करने का आपका तरीका अवैज्ञानिक नहीं है। आप बस परिकल्पना और परीक्षण चरणों के कई पुनरावृत्तियों के माध्यम से जल्दी से चल रहे हैं। मैं दृढ़ता से सहमत हूं कि आपको उन विचारों को प्राथमिकता देनी चाहिए जिन्हें आप जल्दी से परख सकते हैं।
ज़ॉडेचे
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.