IT Support Done Right: A Practical Field Guide

วิธีจัดการตั๋วสนับสนุน IT อย่างมืออาชีพ: การคัดแยก การวินิจฉัย การบันทึก และการเพิ่มเติมที่ทำอย่างถูกต้อง ไม่ใช่แค่ปิดอย่างรวดเร็ว

งานสนับสนุน IT ส่วนใหญ่ได้รับการตัดสินโดยพิจารณาจากความเร็ว แต่ความเร็วโดยไม่มีวิธีการก็แค่ย้ายปัญหาเดิมไปยังอีกที่หนึ่ง ตั๋วที่ปิดในห้านาทีแต่เปิดขึ้นมาอีกครั้งในสามวันจะมีต้นทุนมากกว่าตั๋วที่ใช้เวลายี่สิบนาทีและแก้ไขได้จริง คำแนะนำนี้ครอบคลุมนิสัยที่แยกความแตกต่างระหว่างคนที่ปิดตั๋วและคนที่แก้ปัญหา

เริ่มด้วยการรับสมัครที่แท้จริง ไม่ใช่การเดา

ก่อนสัมผัสเครื่องใดๆ ให้ผู้ใช้อธิบายปัญหาด้วยคำพูดของตนเอง จากนั้นถามคำถามติดตามสามข้อ: เมื่อใดที่เริ่มต้น มีการเปลี่ยนแปลงอะไรเมื่อเร็ว ๆ นี้ และจะเกิดขึ้นทุกครั้งหรือบ่อยครั้ง "อินเทอร์เน็ตของฉันช้า" อาจหมายถึง DNS resolution ช่อง Wi-Fi ที่เต็ม NIC ที่มีปัญหา หรือเบราว์เซอร์ที่เปิดแท็บสี่สิบแท็บ เขียนข้อความแสดงข้อผิดพลาดที่แน่นอนหากมี ภาพหน้าจอดีกว่าคำอธิบายเสมอ — ขอภาพหนึ่งก่อนขอให้ผู้ใช้ลองทำสิ่งใด ๆ

ต้านทานความพยายามที่จะกระโดดตรงไปที่ "คุณพยายามรีสตาร์ทแล้วหรือ" มันได้ผลบ่อยพอที่ผู้คนใช้เป็นค่าเริ่มต้น แต่ถ้าคุณข้ามการรับสมัครคุณจะพลาดรูปแบบ ถ้าสามคนในสวิตช์เดียวกันรายงานความช้าเดียวกันในชั่วโมงเดียวกัน นั่นคือตั๋วที่แตกต่างจากแล็ปท็อปเล่มเดียวที่มีไดรเวอร์ที่ไม่ดี

ทำซ้ำก่อนแก้ไข

ถ้าคุณไม่สามารถทำซ้ำปัญหาได้ คุณไม่สามารถยืนยันว่าคุณแก้ไขมันได้ ขอให้ผู้ใช้ไปผ่านขั้นตอนที่แน่นอนบนหน้าจอแบ่งปัน หรือทำด้วยตนเองบนเครื่องของพวกเขาหากเครื่องมือระยะไกลอนุญาต ตรวจสอบ ipconfig /all บน Windows หรือ ip a บน Linux เพื่อเก็บสติเครือข่ายพื้นฐาน ดูที่ Event Viewer (eventvwr.msc) เพื่อดูข้อผิดพลาดของแอปพลิเคชันและระบบรอบเวลาที่รายงาน และตรวจสอบ journalctl -xe --since "1 hour ago" บนกล่อง Linux สำหรับหน้าต่างเดียวกัน

สำหรับการขัดข้องของแอปพลิเคชัน ให้รับหมายเลขบิลด์ที่แน่นอนและเวอร์ชัน OS "ขัดข้อง" ไม่บอกคุณอะไร; "Outlook 16.0.17726 ขัดข้องเมื่อเปิดคำเชิญปฏิทินที่มี .ics attachment" บอกคุณว่าต้องดูที่ไหน ตรวจสอบข้ามกับปัญหาที่ทราบในหมายเหตุประจำรุ่นของผู้จัดจำหน่ายก่อนสมมติว่าเป็นเรื่องเฉพาะที่

จัดประเภทตามผลกระทบ ไม่ใช่โดยคนที่ร้องเพื่อให้ดังที่สุด

ผู้ใช้รายเดียวที่ถูกล็อกออกจากอีเมลนั้นไม่สะดวก เซิร์ฟเวอร์ไฟล์ที่ใช้ร่วมกันไม่สามารถเข้าถึงได้สำหรับสี่สิบคนเป็นเหตุการณ์ที่หยุดชะงัก สร้างมาตราส่วนความรุนแรงที่เรียบง่าย — บางอย่างเช่น P1 สำหรับเหตุการณ์ที่หยุดชะงักที่ส่งผลกระทบต่อผู้ใช้หลายคนหรือระบบที่สำคัญ P2 สำหรับตัวปิดกั้นผู้ใช้รายเดียว P3 สำหรับลดลงแต่ทำงาน P4 สำหรับสุนทรพจน์หรือคำขอความสะดวก — และนำไปใช้อย่างสม่ำเสมอ แม้ภายใต้ความกดดันจากผู้จัดการที่ต้องการสิ่งของตนก่อน

บันทึกการตัดสินใจความรุนแรงในตั๋วเอง สิ่งนี้ป้องกันคุณในภายหลังเมื่อมีคนถามว่าทำไม P3 ของตน นั่งอยู่สองวันในขณะที่คุณจัดการ P1 สามตัว

แก้ไขสาเหตุหลัก ไม่ใช่อาการ

การรีสตาร์ทบริการที่ขัดข้องอยู่เนื่องจากเวลา ไม่ใช่โซลูชัน ถ้า print spooler ตายทุกวัน ให้ตรวจสอบ Get-WinEvent -LogName Application -MaxEvents 50 เพื่อหาข้อผิดพลาดที่แท้จริงก่อนรีสตาร์ทอีกครั้ง ถ้ารหัสผ่านของผู้ใช้หมดอายุโดยไม่คาดคิดเสมอ ให้ตรวจสอบนโยบายกลุ่มที่ใช้กับ OU ของพวกเขาแทนที่จะรีเซ็ตและไปต่อ

เก็บบันทึกส่วนตัวของการแก้ไขที่เกิดซ้ำ ถ้าคุณพบว่าตนเองพิมพ์คำสั่ง PowerShell เดียวกันหรือการแก้ไขรีจิสตรี่เดียวกันสามครั้ง นั่นคือสัญญาณที่ว่ามันควรจะอยู่ในสคริปต์หรือ runbook ที่บันทึก ไม่ใช่ในหัวของคุณ

บันทึกราวกับว่าคนอื่นจะอ่านมัน

การแก้ไขตั๋วแต่ละใบควรตอบ: สาเหตุที่แท้จริงคืออะไร การแก้ไขคืออะไร และคุณจะตรวจสอบอะไรก่อนหากสิ่งนี้เกิดขึ้นอีก "Fixed" เป็นหมายเหตุการแก้ปัญหาไร้ค่าสำหรับเทคโนโลยีถัดไป รวมถึงคุณในอนาคตหกเดือนต่อมาโดยไม่มีความทรงจำของตั๋วนี้

หมายเหตุการแก้ปัญหาที่ดีมีลักษณะเช่น: "สาเหตุหลัก: ขอบเขต DHCP บน VLAN 20 หมด อุปกรณ์ใหม่มี APIPA addresses แก้ไข: ขยายขอบเขตจาก /24 ถึง /23 การจองสำหรับเครื่องพิมพ์เพิ่มเติม ยืนยัน: ตรวจสอบจำนวนลีส DHCP รายเดือน เกณฑ์การแจ้งเตือนตั้งไว้ที่ 90%." ประโยคที่สามคือประโยคที่เทคโนโลยีส่วนใหญ่ข้าม และมันคือประโยคที่ป้องกันตั๋วซ้ำ

เพิ่มเติมด้วยบริบท ไม่ใช่แค่ส่งต่อ

เมื่อตั๋วไปที่ tier 2 หรือผู้จัดจำหน่าย ให้รวมสิ่งที่คุณได้ยกเว้นไปแล้ว "ตรวจสอบสายเคเบิล สวิตช์พอร์ต ยืนยันการตั้งค่า VLAN ยังไม่มีแสงลิงค์" ช่วยคนต่อไปจากการทำให้เสร็จย้อนหลังสองสิบนาทีแรกของคุณ การเพิ่มเติมที่คลุมเครือเช่น "ผู้ใช้บอกว่ามันหัก โปรดแนะนำ" เพียงแต่ย้ายความล่าช้าแทนที่จะลบออก

ปิดลูปกับผู้ใช้

บอกผู้ใช้ว่าอะไรผิดในภาษาธรรมชาติ ไม่ใช่แค่ "fixed" ผู้คนเชื่อใจการสนับสนุนมากขึ้นเมื่อพวกเขาเข้าใจว่าเกิดอะไรขึ้น และมันลดจำนวนคนเดิมที่ยื่นตั๋วเดียวกันเดือนหน้าเพราะพวกเขาไม่ตระหนักว่าเกี่ยวข้อง

ถ้าคุณต้องการเจาะลึกด้านเทคนิคของสิ่งนี้ — บริหารเครือข่าย บันทึกเหตุการณ์ Windows หรือการสคริปต์เครื่องมือวินิจฉัยของคุณเอง — Korra Studio มีส่วนในเครือข่าย ระบบ และ Scripting ที่น่าจะทำต่อไป

เขียนด้วยความช่วยเหลือของ AI ตรวจสอบและเผยแพร่โดย Michal Pilch (CISSP), Korra Studio