IT 支援做對的方式：實務場地指南

大多數 IT 支援工作以速度來評判，但沒有方法的速度只是把同樣的問題轉移到別處。五分鐘內結案但三天後再次開啟的工單，成本比花費二十分鐘實際解決問題的工單高。本指南涵蓋了區分有人結案工單和有人解決問題的習慣。

從真正的初步評估開始，不是猜測

在接觸機器之前，讓使用者用自己的話描述問題，然後提出三個後續問題：何時開始、最近改變了什麼，以及每次都發生還是間歇性發生。「我的網路很慢」可能意味著 DNS 解析、Wi-Fi 頻道飽和、NIC 故障或開啟四十個分頁的瀏覽器。記下確切的錯誤文字（如果有的話）。螢幕截圖永遠勝過描述——在要求使用者嘗試任何操作之前先要求提供一張。

抵擋直接跳到「你試過重新啟動嗎」的衝動。它足夠經常有效，讓人預設採用它，但如果你跳過初步評估，就會錯過模式。如果同一交換器上的三個人在同一小時內報告相同的緩慢，這是不同於單一筆電驅動程式故障的工單。

修復前先重現

如果你無法重現問題，就無法確認你已修復它。要求使用者在螢幕共享上逐步執行確切步驟，或在遠端工具允許的情況下在他們的機器上自己做。在 Windows 上檢查 ipconfig /all 或在 Linux 上檢查 ip a 以確保基本網路正常運作，查看事件檢視器（eventvwr.msc）以找出報告時間附近的應用程式和系統錯誤，並在 Linux 機器上檢查 journalctl -xe --since "1 hour ago" 以查看相同的時間窗口。

對於應用程式當機，取得確切的組建編號和 OS 版本。「它當機了」什麼都告訴不了你；「Outlook 16.0.17726 在開啟帶有 .ics 附件的日曆邀請時當機」告訴你要在哪裡查詢。在假設是本地問題之前與廠商發行說明中的已知問題進行交叉參考。

按影響分類，而不是按誰喊得最大聲分類

單一使用者被鎖定在電子郵件之外很不方便。四十個人無法訪問共享檔案伺服器是中斷。建立簡單的嚴重性等級——例如 P1 用於影響多個使用者或關鍵系統的中斷、P2 用於單一使用者阻礙、P3 用於效能降低但可運作、P4 用於美觀或便利要求——並一致地應用它，即使來自主管的壓力說他們的事務優先。

在工單本身中記錄嚴重性決定。當有人問起為什麼他們的 P3 擱置了兩天而你處理了三個 P1 時，這會保護你。

修復根本原因，而不是症狀

重新啟動不斷當機的服務爭取時間，不是解決方案。如果列印脫離管理器每天都會當機，在重新啟動它之前先檢查 Get-WinEvent -LogName Application -MaxEvents 50 以找出實際的錯誤。如果使用者的密碼持續意外過期，檢查套用到他們 OU 的群組原則，而不只是重設密碼並繼續。

保持重複修復的個人日誌。如果你發現自己輸入相同的 PowerShell 命令或相同的登錄機碼修復三次，這是它屬於指令碼或記錄的執行手冊而不是在你的記憶裡的信號。

記錄時假設別人會讀

每個工單解決方案應該回答：實際原因是什麼、修復是什麼，以及如果再次發生，你會首先檢查什麼。「已修復」作為解決方案備註對下一位技術人員沒有用，包括六個月後沒有此工單記憶的未來你。

良好的解決方案備註看起來像：「根本原因：VLAN 20 上的 DHCP 範圍已耗盡，新裝置取得 APIPA 位址。修復：將範圍從 /24 延伸到 /23，為印表機新增保留。驗證：每月檢查 DHCP 租用計數，在 90% 設定警示閾值。」第三個句子是大多數技術人員跳過的，也是防止重複工單的句子。

以內容升級，而不只是轉發

當工單轉到第二層或廠商時，包含你已經排除的內容。「檢查纜線、交換連接埠、確認 VLAN 配置，仍然沒有連結指示」讓下一個人免於重新做你最初的二十分鐘。模糊的升級如「使用者說它故障了，請建議」只會移動延遲而不是移除它。

與使用者閉合迴路

用清晰的語言告訴使用者什麼是錯的，而不只是「已修復」。當人們理解發生了什麼時，他們會更信任支援，它會減少同一個人下個月提交相同工單的情況，因為他們沒有意識到它是相關的。

如果你想深入了解其中任何一個的技術方面——網路基礎、Windows 事件日誌或編寫自己的診斷工具指令碼——Korra Studio 在網路、系統和指令碼上有值得接下來完成的章節。