识别并定义问题

识别问题是第一步，也可以说是最重要的一步。如果问题识别错误，后续每一步都会走向错误的方向。这里的目标是形成清晰、具体且经过验证的问题陈述。花时间准确理解问题通常不会浪费，因为这样能让后续所有工作都集中于真正的症状，而不是某个猜测。

先收集事实。与受影响的用户交谈，查看监控面板和日志，并亲自执行快速测试。目标是了解范围（一名用户、一层楼还是整个站点）、时间（何时开始）以及症状（缓慢、间歇性故障还是完全中断）。信息越具体，您的理论就会越准确。

“发生了什么变化？”是一个很有力量的问题。大多数问题都紧接着某项变更出现：新硬件、配置编辑、软件更新或电源事件。询问用户并查看变更日志。如果某项服务昨天还能正常工作，今天却失败了，那么一定有某些情况发生了变化；找出这种差异通常就能直接找到原因。最近的变更应当优先怀疑。

用户会用自己的语言描述症状，因此请耐心且友善地与他们沟通。提出开放式问题：“发生故障时您正在做什么？”以及“还有其他情况发生变化吗？”避免提出带有引导性的问题，以免诱导出错误答案。请注意，用户可能会遗漏细节，或描述结果而不是原因。耐心和恰当的问题可以将含糊的抱怨转化为有用的数据。

确定范围可以大幅缩小排查范围。如果只有一台 PC 受到影响，请检查该设备或其网线。如果整个 VLAN 中断，请怀疑交换机或网关。如果整个站点都无法连接互联网，请重点检查 WAN 链路或 ISP。让问题的规模与可能原因的规模相匹配，可以节省大量时间。

只要条件允许，请亲自复现问题。重现故障可以确认问题确实存在，揭示确切的发生条件，并提供一项修复后可以重复执行的测试。如果用户无法访问某个网站，请在同一网络上用自己的设备尝试访问。间歇性问题更难复现，但复现它对于确认问题是否真正解决非常宝贵。

CompTIA 明确要求质疑显而易见的情况。许多中断都有很普通的原因：网线未插好、设备已关机、密码过期，或登录时启用了大写锁定。先检查这些只需几秒钟，却经常可以解决问题。因为认为“不会是这个”就跳过简单检查，是在一个小故障上浪费数小时的典型做法。

设备经常会自行报告问题。查看日志中的错误消息，观察接口的链路指示灯，并检查监控警报。交换机端口上的红灯、记录中的“接口关闭”事件，或 DHCP 错误消息，都可能直接指向故障所在。让设备告诉您它观察到的情况，可以补充用户提供的信息。

请考虑您面对的是一个问题还是多个问题。有时两个互不相关的故障会同时出现，看起来像一个奇怪的症状。如果线索无法由单一原因解释，请考虑是否有两个问题重叠在一起。将纠缠在一起的问题分开，可以避免强行用一个理论解释所有情况所造成的混乱。

将您的发现整理成准确的问题陈述：谁受到影响、什么功能失败、何时开始，以及是否存在某种规律。“交换机于上午 9 点重启后，VLAN 20 上的所有电话都无法注册”远比“电话坏了”有用。良好的陈述是整个方法其余部分建立的基础。

扎实的问题定义自然会指向可能原因的理论。如果问题在某台交换机发生配置变更后开始，并且只有该交换机所服务的用户受到影响，那么您的第一个理论很容易确定。认真识别问题，能让提出理论、测试和修复都更快、更准确。定义清楚，后续故障排除就会顺畅进行。

测试您对问题识别的理解。

您已经学会了识别和定义问题。要点：

• 从用户、日志和测试中收集范围、时间和症状。
• 始终询问“发生了什么变化？”
• 确定范围，以判断可能原因的规模；条件允许时复现问题。
• 先质疑显而易见的情况。
• 写出准确的问题陈述，为后续每一步提供指导。