Ticketing و Documentation به‌عنوان بخشی از کار فنی

Summary کوتاه و دقیق مشکل

Ticket فقط برای شمارش درخواست‌ها نیست؛ تاریخچه فنی Incident است. باید مشخص کند چه مشکلی گزارش شد، چه شواهدی دیدی، چه تغییراتی انجام شد، نتیجه چه بود و اگر Escalate شد نفر بعد چه چیزهایی لازم دارد.

جمله «حل شد» هیچ دانشی برای تیم نمی‌سازد. Ticket خوب اگر مشکل ماه بعد تکرار شود، زمان تشخیص را کوتاه می‌کند و Changeهای انجام‌شده را قابل ردگیری نگه می‌دارد.

Summary کوتاه و دقیق مشکل. Impact/Urgency برای Priority.

Work Notes شامل Test و Result

Work Notes شامل Test و Result. Resolution شامل Root/Immediate Cause تا حد معلوم و Verification.

اطلاعات حساس و Password نباید در Ticket عمومی ذخیره شود. Timestamp و Device ID برای Log Correlation مفید است. Attachment مثل PCAP/Show Output باید نام و توضیح داشته باشد.

Documentation فنی با متن طولانی فرق دارد

Documentation فنی با متن طولانی فرق دارد. اطلاعات باید قابل استفاده باشد: «Gi۱/۰/۲۴ CRC از ۰ به ۱۸۰۰ در ۵ دقیقه رسید» بهتر از «پورت مشکل داشت» است.

Ticket باید برای نفر بعد قابل ادامه باشد. عدد و خروجی دقیق بهتر از صفت مبهم است. Verification و نوع Fix باید ثبت شود.

قبل از Change Note بنویس

از قبل از Change Note بنویس شروع کن. بعد Command/Output کلیدی را ضمیمه کن. اگر تا اینجا چیزی غیرعادی ندیدی، بعد از Fix User Verification یا Test را ثبت کن. در آخر اگر Workaround است صریح بنویس که Permanent Fix نیست.

نتیجه «قبل از Change Note بنویس» و «Command/Output کلیدی را ضمیمه کن» را کنار هم بگذار. اگر هر دو طبیعی بودند، «بعد از Fix User Verification یا Test را ثبت کن» کمک می‌کند محدوده مشکل کوچک‌تر شود. «اگر Workaround است صریح بنویس که Permanent Fix نیست» را زمانی انجام بده که بررسی‌های قبلی جواب روشنی نداده‌اند.

هفته قبل یک Switch Port تعویض شده ولی Ticket فقط «OK شد» دارد

هفته قبل یک Switch Port تعویض شده ولی Ticket فقط «OK شد» دارد. این هفته همان مشکل برگشته و هیچ‌کس نمی‌داند علت قبلی کابل بوده یا VLAN. Documentation ضعیف هزینه تکرار Incident را بالا برده است.

ترتیب منطقی بررسی همین وضعیت می‌تواند این باشد: قبل از Change Note بنویس → Command/Output کلیدی را ضمیمه کن → بعد از Fix User Verification یا Test را ثبت کن → اگر Workaround است صریح بنویس که Permanent Fix نیست. این ترتیب را با نتیجه واقعی هر مرحله جلو ببر؛ اگر یکی از بررسی‌ها علت را روشن کرد، سراغ تغییرهای بی‌ربط نرو.

یک Incident واقعی فرضی را از ابتدا تا بستن Ticket بنویس: Summary

یک Incident واقعی فرضی را از ابتدا تا بستن Ticket بنویس: Summary، Scope، Tests، Change، Verification و Next Action. بعد متن را طوری کوتاه کن که هیچ داده مهمی حذف نشود.

قبل از ایجاد خطا «قبل از Change Note بنویس» را در حالت سالم ثبت کن. بعد از ایجاد یک خطای کنترل‌شده، همان مورد و در پایان «اگر Workaround است صریح بنویس که Permanent Fix نیست» را دوباره بررسی کن. تفاوت قبل و بعد باید در گزارش تمرین مشخص باشد.

ذخیره Password در Ticket

ذخیره Password در Ticket. ثبت نکردن نتیجه Testهای منفی. بستن Ticket با Workaround بدون توضیح.

CCST روی Help Desk Best Practice و Documentation تأکید دارد. ITIL Process Design گسترده‌تر خارج از سطح است.

Ticket باید برای نفر بعد قابل ادامه باشد

Ticket باید برای نفر بعد قابل ادامه باشد. عدد و خروجی دقیق بهتر از صفت مبهم است. Verification و نوع Fix باید ثبت شود.

چرا «مشکل حل شد» Resolution خوبی نیست؟ علت، اقدام، شواهد و Verification را مشخص نمی‌کند. آیا Password باید در Ticket نوشته شود؟ خیر؛ اطلاعات حساس باید طبق Policy جدا و امن مدیریت شود.

Ticket خوب چهار چیز را روشن می‌کند: کاربر چه دید

Ticket خوب چهار چیز را روشن می‌کند: کاربر چه دید، چه کسانی تحت تأثیر بودند، چه شواهدی جمع شد و چه تغییری انجام شد. عبارت «رفع شد» به نفر بعدی چیزی یاد نمی‌دهد. بنویس مثلاً DHCP Scope پر بود، Leaseهای قدیمی آزاد شدند، Scope افزایش یافت و Client جدید دوباره IP گرفت.

Timeline را هم کوتاه ثبت کن؛ زمان شروع، زمان تشخیص، تغییر و تأیید نهایی. در مشکل‌های intermittent همین زمان‌ها برای تطبیق با Syslog و Monitoring ضروری‌اند. Password و اطلاعات محرمانه را داخل Ticket عادی قرار نده مگر سامانه و Policy مشخصی برای آن وجود داشته باشد.

Documentation جدا از کار فنی نیست. اگر Port یک Printer، IP ثابت Server یا Uplink Switch عوض شده، سند مربوط را همان موقع به‌روز کن. چند ماه بعد همین ثبت ساده می‌تواند زمان عیب‌یابی را از یک ساعت به چند دقیقه برساند.