IT সাপোর্ট সঠিকভাবে করুন: একটি ব্যবহারিক ফিল্ড গাইড

বেশিরভাগ IT সাপোর্ট কাজ গতির ভিত্তিতে বিচার করা হয়, কিন্তু পদ্ধতি ছাড়া গতি শুধু একই সমস্যা অন্যত্র নিয়ে যায়। একটি টিকিট পাঁচ মিনিটে বন্ধ করা যা তিন দিন পর আবার খোলে, তার চেয়ে বেশি খরচ করে একটি যা বিশ মিনিট নেয় এবং আসলে ঠিক হয়ে যায়। এই গাইডটি এমন অভ্যাসগুলি কভার করে যা টিকিট বন্ধকারীকে সমস্যা সমাধানকারী থেকে আলাদা করে।

অনুমানের পরিবর্তে সত্যিকারের ইনটেক দিয়ে শুরু করুন

যন্ত্রে হাত দেওয়ার আগে, ব্যবহারকারীকে তাদের নিজস্ব শব্দে সমস্যার বর্ণনা দিতে বলুন, তারপর তিনটি অনুসরণমূলক প্রশ্ন জিজ্ঞাসা করুন: এটি কখন শুরু হয়েছিল, সম্প্রতি কী পরিবর্তন হয়েছিল এবং এটি প্রতিবার ঘটে নাকি মাঝে মাঝে। "আমার ইন্টারনেট ধীর" মানে DNS resolution, একটি saturated Wi-Fi চ্যানেল, একটি ব্যর্থ NIC, অথবা চল্লিশটি ট্যাব খোলা একটি ব্রাউজার হতে পারে। যদি একটি থাকে তবে সঠিক ত্রুটি পাঠ্য লিখুন। স্ক্রিনশট বর্ণনার চেয়ে সবসময় ভাল — ব্যবহারকারীকে কিছু চেষ্টা করতে বলার আগে একটি চাইতে বলুন।

"আপনি পুনরায় শুরু করার চেষ্টা করেছেন" সরাসরি চলে যাওয়ার প্রলোভন প্রতিরোধ করুন। এটি যথেষ্ট বারবার কাজ করে যে লোকেরা এটিতে ডিফল্ট করে, কিন্তু যদি আপনি ইনটেক এড়িয়ে যান তবে আপনি প্যাটার্ন মিস করবেন। যদি একই সুইচে তিনজন একই ঘন্টায় একই ধীরতার রিপোর্ট করে, তা একটি খারাপ ড্রাইভার সহ একটি ল্যাপটপের চেয়ে আলাদা টিকিট।

ঠিক করার আগে পুনরুৎপাদন করুন

যদি আপনি কোনও সমস্যা পুনরুৎপাদন করতে না পারেন, আপনি এটি ঠিক করেছেন তা নিশ্চিত করতে পারবেন না। ব্যবহারকারীকে একটি স্ক্রিন শেয়ারে সঠিক পদক্ষেপগুলি অনুসরণ করতে বলুন, অথবা দূরবর্তী সরঞ্জাম অনুমতি দিলে তাদের মেশিনে এটি নিজেই করুন। Windows-এ ipconfig /all বা Linux-এ ip a পরীক্ষা করুন মৌলিক নেটওয়ার্ক বিবেক নিশ্চিত করতে, রিপোর্ট করা সময়ের চারপাশে application এবং system ত্রুটির জন্য Event Viewer (eventvwr.msc) দেখুন, এবং Linux বক্সে একই উইন্ডোর জন্য journalctl -xe --since "1 hour ago" পরীক্ষা করুন।

অ্যাপ্লিকেশন ক্র্যাশের জন্য, সঠিক বিল্ড নম্বর এবং OS সংস্করণ পান। "এটি ক্র্যাশ হয়েছে" আপনাকে কিছুই বলে না; "Outlook 16.0.17726 একটি .ics সংযুক্তি সহ ক্যালেন্ডার আমন্ত্রণ খোলার সময় ক্র্যাশ করে" আপনাকে কোথায় দেখতে হবে তা বলে। স্থানীয় হতে অনুমান করার আগে বিক্রেতার রিলিজ নোটে পরিচিত সমস্যাগুলির বিপরীতে ক্রস-রেফারেন্স করুন।

যে জোরে চিৎকার করে তার দ্বারা নয়, প্রভাব দ্বারা ট্রায়েজ করুন

ইমেল থেকে একটি ব্যবহারকারী লক করা অসুবিধাজনক। চল্লিশ জনের জন্য একটি shared file server অপ্রাপ্য একটি outage। একটি সহজ severity স্কেল তৈরি করুন — যেমন P1 multiple users বা critical systems-কে প্রভাবিত করে এমন outages-এর জন্য, P2 একক-ব্যবহারকারী blockers-এর জন্য, P3 degraded-but-working-এর জন্য, P4 cosmetic বা convenience requests-এর জন্য — এবং এটি সামঞ্জস্যপূর্ণভাবে প্রয়োগ করুন, এমনকি একজন ম্যানেজারের চাপের অধীনে যিনি তাদের জিনিসকে প্রথম চান।

টিকিটে নিজেই severity সিদ্ধান্ত ডকুমেন্ট করুন। এটি আপনাকে পরে রক্ষা করে যখন কেউ জিজ্ঞাসা করে কেন তাদের P3 দুই দিন ধরে বসেছিল যখন আপনি তিনটি P1 পরিচালনা করেছিলেন।

লক্ষণের পরিবর্তে মূল কারণ ঠিক করুন

যে service ক্র্যাশ করে রাখে তা পুনরায় শুরু করা সময় কেনে, সমাধান নয়। যদি একটি print spooler প্রতিদিন মৃত্যুবরণ করে, আবার পুনরায় শুরু করার আগে আসল ত্রুটির জন্য Get-WinEvent -LogName Application -MaxEvents 50 পরীক্ষা করুন। যদি একজন ব্যবহারকারীর password অপ্রত্যাশিতভাবে expiration রাখে, শুধু এটি রিসেট করার পরিবর্তে তাদের OU প্রয়োগ করা group policy পরীক্ষা করুন এবং এগিয়ে যান।

পুনরাবৃত্ত ফিক্সগুলির একটি ব্যক্তিগত লগ রাখুন। যদি আপনি নিজেকে একই PowerShell কমান্ড বা একই registry fix তিনবার টাইপ করতে খুঁজে পান, এটি একটি সাইন যে এটি একটি স্ক্রিপ্ট বা documented runbook-এ থাকে, আপনার মাথায় নয়।

ডকুমেন্ট করুন যেন অন্য কেউ এটি পড়বে

প্রতিটি টিকিট resolution উত্তর দেওয়া উচিত: আসল কারণ কী ছিল, ফিক্স কী ছিল, এবং যদি এটি আবার ঘটে তবে আপনি প্রথম কী পরীক্ষা করবেন। "Fixed" একটি resolution নোট হিসাবে পরবর্তী tech-এর কাছে অর্থহীন, ছয় মাস পর ভবিষ্যত আপনি সহ এই টিকিটের কোন স্মৃতি ছাড়াই।

একটি ভাল resolution নোট এমন দেখায়: "Root cause: DHCP scope on VLAN 20 exhausted, নতুন devices APIPA addresses পেয়েছে। Fix: scope /24 থেকে /23-তে বর্ধিত করা হয়েছে, printer-এর জন্য reservation যোগ করা হয়েছে। Verify: monthly DHCP lease count পরীক্ষা করুন, 90%-এ alert threshold সেট করুন।" সেই তৃতীয় বাক্যটি হল যে একটি বেশিরভাগ tech এড়িয়ে যায়, এবং এটি যা পুনরাবৃত্ত টিকিট প্রতিরোধ করে।

শুধু একটি forward নয়, context সহ Escalate করুন

যখন একটি টিকিট tier 2 বা vendor-এ যায়, তখন আপনি যা ইতিমধ্যে নিয়ম করেছেন তা অন্তর্ভুক্ত করুন। "Checked cabling, swapped port, confirmed VLAN config, still no link light" পরবর্তী ব্যক্তিকে আপনার প্রথম বিশ মিনিট পুনরায় করা থেকে বাঁচায়। অস্পষ্ট escalations যেমন "user বলে এটি broken, please advise" শুধু delay সরায় বরং এটি অপসারণ করে না।

ব্যবহারকারীর সাথে লুপ বন্ধ করুন

ব্যবহারকারীকে বলুন সাধারণ ভাষায় কী ছিল, শুধু "fixed" নয়। লোকেরা সাপোর্টকে আরও বিশ্বাস করে যখন তারা বোঝে কী ঘটেছে, এবং এটি একই ব্যক্তি একই টিকিট পরের মাসে দাখিল করার ক্ষেত্রে কমিয়ে দেয় কারণ তারা এটি সংযুক্ত তা বুঝতে পারে না।

যদি আপনি এর কোনও technical দিকে গভীরভাবে যেতে চান — networking fundamentals, Windows event logs, বা আপনার নিজের diagnostic tools scripting — Korra Studio-তে Networking, Systems, এবং Scripting-এর segments আছে যা পরবর্তীতে কাজ করার যোগ্য।