پشتیبانی IT به درستی: راهنمای عملی میدانی

اکثر کارهای پشتیبانی IT بر اساس سرعت ارزیابی می‌شوند، اما سرعت بدون روش فقط مشکل را به جای دیگری منتقل می‌کند. تیکتی که در پنج دقیقه بسته می‌شود و سه روز بعد دوباره باز می‌شود، هزینه‌ای بیشتری دارد از تیکتی که بیست دقیقه طول می‌کشد و واقعاً حل می‌شود. این راهنما عادات‌هایی را پوشش می‌دهد که کسی را که تیکت‌ها را می‌بندد از کسی که مشکلات را حل می‌کند جدا می‌کند.

با دریافت واقعی شروع کنید، نه حدس

پیش از اینکه ماشینی را لمس کنید، از کاربر بخواهید مشکل را به کلمات خود توضیح دهد، سپس سه پرسش پیگیری کنید: کی شروع شد، چه چیزی اخیراً تغییر کرد، و آیا هر بار رخ می‌دهد یا گاهی اوقات. "اینترنت من کند است" می‌تواند به معنای مسئله تحلیل DNS، کانال Wi-Fi اشباع شده، NIC ناقص یا مرورگری با چهل تب باز باشد. متن خطای دقیق را یادداشت کنید اگر یکی وجود دارد. تصاویر هر وقت بهتر از توضیحات هستند — قبل از اینکه از کاربر بخواهید چیزی را امتحان کند، یکی درخواست کنید.

از تمایل برای پریدن مستقیم به «آیا restart را امتحان کردی» خودداری کنید. بسیار اوقات کار می‌کند که مردم به آن پناه می‌برند، اما اگر دریافت را نادیده بگیرید الگوها را از دست می‌دهید. اگر سه نفر در سوئیچ یکسان در ساعت یکسان کندی یکسان گزارش کنند، این تیکت متفاوتی نسبت به یک لپ تاپ با درایور بد است.

پیش از اصلاح، باز تولید کنید

اگر نمی‌توانید مسئله‌ای را باز تولید کنید، نمی‌توانید تایید کنید که آن را اصلاح کردید. از کاربر بخواهید مراحل دقیق را روی اشتراک صفحه‌نمایش انجام دهد، یا خود آن را روی ماشین آن‌ها انجام دهید اگر ابزارهای راه‌دور اجازه دهند. ipconfig /all را در Windows یا ip a را در Linux برای بررسی سلامت شبکه پایه چک کنید، Event Viewer (eventvwr.msc) را برای خطاهای برنامه و سیستم حول زمان گزارش‌شده مشاهده کنید، و journalctl -xe --since "1 hour ago" را بر روی جعبه‌های Linux برای همان پنجره چک کنید.

برای خرابی‌های برنامه، شماره build دقیق و نسخه سیستم‌عامل را دریافت کنید. «خراب شد» به شما هیچ چیز نمی‌گوید؛ «Outlook 16.0.17726 هنگام باز کردن دعوتنامه تقویم با پیوست .ics خراب می‌شود» به شما می‌گوید کجا نگاه کنید. قبل از فرض کردن اینکه محلی است، با مسائل شناخته شده در یادداشت‌های انتشار فروشنده مقابل‌قرار دهید.

طبقه‌بندی بر اساس تأثیر، نه بر اساس کسی که بیشتر فریاد می‌زند

یک کاربر قفل شده از ایمیل ناخوشایند است. یک سرور فایل اشتراکی غیرقابل دسترس برای چهل نفر یک قطع‌خدمات است. یک مقیاس جدیت ساده بسازید — چیزی مثل P1 برای قطع‌خدمات‌هایی که بر روی چندین کاربر یا سیستم‌های انتقادی تأثیر می‌گذارند، P2 برای مسدودکننده‌های کاربر واحد، P3 برای کاهش عملکرد اما کار کردن، P4 برای درخواست‌های آرایشی یا راحتی — و به طور مداوم آن را اعمال کنید، حتی تحت فشار از مدیری که می‌خواهد چیزی آن‌ها اول باشد.

تصمیم جدیت را در خود تیکت مستند کنید. این شما را بعداً محافظت می‌کند زمانی که کسی پرسد چرا P3 آن‌ها دو روز بیکار نشسته است در حالی که شما سه P1 را مدیریت کردید.

علت اصلی را اصلاح کنید، نه علامت

راه‌اندازی مجدد سرویسی که مدام خراب می‌شود وقت می‌خرد، نه راه‌حل. اگر اسپولر چاپ روزانه بمیرد، Get-WinEvent -LogName Application -MaxEvents 50 را برای خطای واقعی چک کنید پیش از اینکه آن را دوباره راه‌اندازی کنید. اگر رمزعبور کاربر بطور غیرمنتظره‌ای مدام منقضی شود، گیاهی گروه‌ها را در جای OU آن‌ها چک کنید بجای اینکه فقط آن را تنظیم مجدد کنید و رفتار کنید.

یک گزارش شخصی از اصلاحات مکرر نگه دارید. اگر خود را متوجه کنید که PowerShell فرمان یکسان یا registry fix یکسان را سه بار تایپ می‌کنید، این علامت است که متعلق به اسکریپت یا runbook مستند‌سازی شده است، نه در ذهن شما.

مستندسازی کنید مثل اینکه کسی دیگری آن را بخواند

هر حل تیکت باید پاسخ دهد: علت واقعی چه بود، راه‌حل چه بود، و اگر این دوباره اتفاق بیفتد، اولین چه چیزی را چک می‌کنید. «Fixed» به عنوان یادداشت تحلیل‌ها بی‌ارزش است برای تکنسین بعدی، شامل خود شما شش ماه از الآن بدون خاطر این تیکت.

یک یادداشت حل خوب به نظر می‌رسد: «علت اصلی: محدوده DHCP در VLAN 20 تمام شد، دستگاه‌های جدید آدرس‌های APIPA گرفتند. راه‌حل: محدوده از /24 به /23 گسترش داده شد، رزرویشن برای چاپگر اضافه شد. تأیید: تعداد اجاره DHCP را ماهانه چک کنید، آستانه هشدار در 90% تنظیم شده است.» آن جملهٔ سوم جملهٔ است که اکثر تکنسین‌ها بخش‌های آن را می‌پرند، و این جملهٔ است که تکرار تیکت را جلوگیری می‌کند.

با زمینه escalate کنید، نه فقط یک forward

زمانی که تیکت به tier 2 یا فروشنده می‌رود، آنچه را شامل کنید که قبلاً حذف کردید. «کابل را چک کردم، port را swap کردم، پیکربندی VLAN را تایید کردم، هنوز light link نیست» بیست دقیقه اول شما را برای فرد بعدی از تکرار صرفه‌جویی می‌کند. Escalation‌های مبهم مثل «کاربر می‌گوید خراب است، لطفاً توصیه کنید» فقط تأخیر را به جای حذف کردن منتقل می‌کند.

حلقه را با کاربر بسته کنید

به کاربر بگویید چه چیزی اشتباه بود به زبان ساده، نه فقط «fixed.» مردم زمانی بیشتر به پشتیبانی اعتماد می‌کنند که چه اتفاقی افتاد را درک کنند، و این درخواست‌های تیکت تکراری را از همان فرد ماه بعد کاهش می‌دهد زیرا نمی‌دانند مرتبط است.

اگر می‌خواهید عمیق‌تر روی جنبهٔ فنی هرکدام از اینها بروید — مبانی شبکه، Windows event logs، یا scripting ابزارهای تشخیصی خود — Korra Studio دارای بخش‌هایی در Networking، Systems، و Scripting است که ارزش کار کردن از طریق بعدی را دارد.