IT Support सही तरीके से: एक व्यावहारिक फील्ड गाइड

अधिकांश IT support work को स्पीड के आधार पर आंका जाता है, लेकिन बिना विधि के स्पीड सिर्फ समस्या को दूसरे कोने में ले जाती है। पांच मिनट में बंद किया गया एक ticket जो तीन दिन में फिर से खुले, वह उससे ज्यादा खर्चीला होता है जो बीस मिनट लगे और सचमुच ठीक हो जाए। यह गाइड उन आदतों को कवर करता है जो किसी को ticket बंद करने वाले से समस्या हल करने वाले में अलग करती हैं।

एक सही intake से शुरू करें, अनुमान से नहीं

मशीन को छूने से पहले, user को अपने शब्दों में समस्या का वर्णन करवाएं, फिर तीन follow-ups पूछें: यह कब शुरू हुआ, हाल में क्या बदला, और क्या यह हर बार होता है या कभी-कभी। "मेरा इंटरनेट धीमा है" का मतलब DNS resolution, saturated Wi-Fi channel, failing NIC, या चालीस tabs वाले ब्राउज़र में कुछ भी हो सकता है। अगर error text हो तो उसे लिखें। Screenshots विवरण से हमेशा बेहतर होते हैं — user को कुछ भी करने से पहले एक मांगें।

"क्या आपने restart करने की कोशिश की है" पर सीधे जाने की जल्दबाजी से बचें। यह अक्सर काम करता है कि लोग इस पर डिफ़ॉल्ट हो जाते हैं, लेकिन अगर आप intake छोड़ देंगे तो पैटर्न मिस हो जाएंगे। अगर एक ही स्विच पर तीन लोग एक ही घंटे में एक ही धीमापन की रिपोर्ट करें, तो यह एक ही laptop वाले ticket से अलग है जिसमें बुरा driver है।

ठीक करने से पहले reproduce करें

अगर आप एक issue को reproduce नहीं कर सकते, तो आप यह confirm नहीं कर सकते कि आपने इसे ठीक किया। user को screen share पर exact steps बताने के लिए कहें, या अगर remote tools allow करते हैं तो उनकी मशीन पर यह खुद करें। Windows पर ipconfig /all या Linux पर ip a check करें basic network sanity के लिए, reported time के आसपास application और system errors के लिए Event Viewer (eventvwr.msc) देखें, और Linux boxes पर journalctl -xe --since "1 hour ago" check करें same window के लिए।

Application crashes के लिए, exact build number और OS version लें। "यह crashed हो गया" आपको कुछ नहीं बताता; "Outlook 16.0.17726 crashes when opening a calendar invite with an .ics attachment" आपको कहां देखना है यह बताता है। मान लेने से पहले vendor release notes में known issues के खिलाफ cross-reference करें कि यह local है।

Impact से triage करें, जो सबसे जोर से चिल्लाता है उससे नहीं

एक ही user को email से lock out करना असुविधाजनक है। चालीस लोगों के लिए एक shared file server unreachable एक outage है। एक simple severity scale बनाएं — कुछ ऐसा जैसे P1 कई users या critical systems को affect करने वाले outages के लिए, P2 single-user blockers के लिए, P3 degraded-but-working के लिए, P4 cosmetic या convenience requests के लिए — और इसे consistently apply करें, भले ही एक manager के दबाव में हो जो उनकी चीज को पहले चाहता हो।

Severity decision को ticket में खुद document करें। यह आपको बाद में protect करता है जब कोई पूछता है कि उनका P3 दो दिन तक क्यों बैठा रहा जबकि आपने तीन P1s को handle किया।

Root cause ठीक करें, symptom नहीं

एक service को restart करना जो keep crashing करता है समय खरीदता है, solution नहीं। अगर एक print spooler daily dies, तो इसे फिर से restart करने से पहले actual error के लिए Get-WinEvent -LogName Application -MaxEvents 50 check करें। अगर एक user का password unexpectedly expire करता रहता है, तो उसे reset करने और आगे बढ़ने से पहले उनके OU पर apply किए गए group policy को check करें।

Recurring fixes का एक personal log रखें। अगर आप अपने आप को एक ही PowerShell command या same registry fix तीन बार type करते हुए पाते हैं, तो यह एक sign है कि यह एक script या documented runbook में है, आपके head में नहीं।

Document करें जैसे कोई और इसे पढ़ेगा

हर ticket resolution को यह answer देना चाहिए: actual cause क्या था, fix क्या था, और अगर यह फिर से होता है तो आप पहले क्या check करेंगे। एक resolution note के रूप में "Fixed" worthless है next tech के लिए, जिसमें future you भी शामिल है छह महीने बाद जिसको इस ticket का कोई memory नहीं है।

एक अच्छा resolution note ऐसा दिखता है: "Root cause: DHCP scope on VLAN 20 exhausted, new devices को APIPA addresses मिले। Fix: scope को /24 से /23 तक extend किया, printer के लिए reservation add किया। Verify: monthly DHCP lease count check करें, alert threshold को 90% पर set करें।" वह तीसरा sentence वह है जो अधिकांश techs skip करते हैं, और यह है जो repeat ticket को prevent करता है।

Context के साथ escalate करें, सिर्फ एक forward नहीं

जब एक ticket tier 2 या एक vendor को जाता है, तो include करें कि आपने पहले से क्या rule out किया। "Checked cabling, swapped port, confirmed VLAN config, still no link light" next person को आपके पहले बीस मिनट को redo करने से बचाता है। Vague escalations जैसे "user says it's broken, please advise" सिर्फ delay को move करता है, इसे remove नहीं करता।

User के साथ loop बंद करें

User को plain language में बताएं कि क्या गलत था, सिर्फ "fixed" नहीं। लोग support को ज्यादा trust करते हैं जब वे समझते हैं कि क्या हुआ, और यह same person को same ticket फिर से file करने से कम करता है अगले महीने में क्योंकि वे realize नहीं करते कि यह connected है।

अगर आप इसके technical side पर गहरे जाना चाहते हैं — networking fundamentals, Windows event logs, या अपने खुद के diagnostic tools scripting — Korra Studio के पास Networking, Systems, और Scripting पर segments हैं जो अगले काम के लिए worthwhile हैं।