IT 支持做对：实战指南

大多数 IT 支持工作按速度评判，但没有方法的速度只会把同样的问题推给下一个人。一个五分钟内关闭但三天后重新出现的工单，成本高于花费二十分钟并真正解决问题的工单。本指南涵盖了那些将关闭工单的人和真正解决问题的人区分开来的做法。

从真实的信息采集开始，不要猜测

在接触任何机器之前，让用户用自己的话描述问题，然后问三个后续问题：何时开始的、最近改变了什么、每次都发生还是间歇性的。"我的网络很慢"可能意味着 DNS 解析、Wi-Fi 频道饱和、NIC 故障或浏览器中打开了四十个标签页。如果有确切的错误文本，就把它写下来。截图总是比描述更好——在让用户尝试任何东西之前先要求一个。

抵制立即跳到"你试过重启吗"的冲动。它经常有效，所以人们默认使用它，但如果你跳过信息采集，你会错过模式。如果同一个交换机上的三个人在同一个小时内报告相同的缓慢，那是一张不同的工单，不同于一台笔记本电脑驱动程序损坏的情况。

修复前先复现

如果你不能复现一个问题，你就不能确认你解决了它。让用户在屏幕共享上走过确切的步骤，或者如果远程工具允许的话，在他们的机器上自己做。在 Windows 上检查 ipconfig /all 或在 Linux 上检查 ip a 以获得基本的网络合理性检查，查看事件查看器（eventvwr.msc）中报告时间周围的应用程序和系统错误，以及在 Linux 机器上检查 journalctl -xe --since "1 hour ago" 以查看相同的时间窗口。

对于应用程序崩溃，获取确切的内部版本号和操作系统版本。"它崩溃了"什么都没告诉你；"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 在网络、系统和脚本方面有值得接下来学习的内容。