排查总原则

本章你将学到：排查问题时必须遵守的八条原则。它们是整本手册的地基，后面所有排查方案都建立在这八条之上。

什么时候用得上：每一次接到用户问题的时候。尤其是当你觉得"这个问题我好像见过，直接让他 XX 就行"的时候——那正是最容易违反原则的时刻。

为什么需要"原则"而不是"步骤"

新客服最常见的工作方式是：听到用户说"打不开"，就从脑子里搜"打不开怎么办"，然后把记住的步骤一条条丢给用户：重启、重装、关杀软、换网络……用户照做，可能好了，可能没好。好了不知道为什么好，没好也不知道下一步做什么。

这种方式有三个致命问题：

1. 效率低。用户可能花一小时试了七八个方法，其中六个和他的问题完全无关。
2. 不可靠。就算好了，很可能是碰巧；问题过两天再来。
3. 无法成长。做一年还是只会那几招，遇到新问题就只能升级。

运维工程师处理故障不是这样的。他们靠的是一套原则：先搞清楚现象，再收集证据，再形成假设，再验证假设。步骤是原则推导出来的，而不是背出来的。掌握了原则，面对从没见过的问题也知道从哪下手。

大白话

医生看病不是"咳嗽就开止咳药"。他会问咳多久了、有没有痰、有没有发烧，听诊、必要时拍片，然后判断是感冒、支气管炎还是肺炎，最后才开药。"咳嗽就开止咳药"的是江湖郎中。我们要做医生，不做郎中。

原则一：先问清，再动手

在你完全理解用户遇到了什么之前，不要给任何操作建议。

"打不开"至少有五种完全不同的含义：

• 双击图标没有任何反应；
• 双击后弹出一个报错框；
• 出现了窗口，但一直转圈；
• 出现了窗口，但界面一片空白；
• 打开了，但几秒钟后自己消失。

这五种情况的原因、排查方向几乎完全不同。你如果听到"打不开"就让用户"重装一下"，有四种情况下是在浪费他的时间。

怎么做：把用户的描述复述成一句具体的话，让他确认。"您的意思是：双击图标之后，屏幕上什么都没出现，鼠标也没有转圈，等了一分钟还是这样，对吗？"

注意

用户不是故意说不清楚。对他来说"打不开"就是全部的信息。把模糊描述变成精确描述，是你的工作，不是他的。

原则二：先收集证据，再做判断

每一个判断都要有证据支撑。没有证据的判断叫猜。

用户说"游戏启动很慢"。你可以猜：电脑差、硬盘慢、后台程序多、杀软扫描……每一个都可能。但你不需要猜——让用户打开任务管理器截一张图，你立刻就能看到：是 CPU 满了、内存满了、还是哪个磁盘 100%。

证据的来源通常是：

证据类型	例子	怎么拿
截图	报错框、任务管理器、设置页面	让用户截图发过来
命令输出	ping、tracert、ipconfig	让用户运行命令后截图
日志	客户端日志、Windows 事件查看器	让用户找到文件发过来
用户观察	"复制文件显示 33 MB/s"	让用户看某个具体数字并告诉你
环境信息	系统版本、配置、网络类型、是否网吧	直接问，或从截图里读

大白话

证据就是"能截图的东西"。感受不能截图（"很卡"），观察可以（"ping 显示 230ms"）。排查靠观察，不靠感受。

怎么做：形成任何判断之前，问自己"我看到了什么证据支持这个判断？"如果答案是"没有，但我觉得应该是"，那就先去拿证据。

原则三：一次只改一个变量

每次只让用户改一个东西，然后看问题有没有变化。

这是所有排查方法里最重要、也最容易被违反的一条。

反面例子：让用户"先关掉杀软、再重启路由器、再换个下载目录，然后再试"。用户试了，好了。请问是哪个起了作用？不知道。下次别的用户来了，你还得让他三个都做。更糟糕的是，如果没好，你也不知道是三个都没用，还是其中一个起了作用但被另一个抵消了。

正面做法：让用户先关杀软试一次。没变化，把杀软开回来（恢复原状），再重启路由器试一次。有变化，那么原因就锁定在路由器这一层，可以继续往下细查。

注意

"一次只改一个变量"还有一个隐含要求：改了没用要改回去。否则用户电脑上的改动越积越多，最后成了一个谁也说不清状态的烂摊子。

原则四：由近到远、由简到繁

先查离问题最近、最容易验证的东西，再查远的、复杂的。

"由近到远"的意思是：从用户的电脑本身开始，再到他家里的网络，再到运营商，再到我们的服务器。因为越近的东西用户越能直接观察和控制，越远的东西越难验证。

"由简到繁"的意思是：先做那些一分钟就能确认的事（看一眼任务管理器、看一眼报错内容、问一句是不是网吧），再做那些要花二十分钟的事（重装、换硬盘、重置网络）。

一个具体的顺序参考：

1. 看报错内容 / 现象细节（30 秒）
2. 看任务管理器（1 分钟）
3. 确认环境：系统版本、是不是网吧、有没有杀软和加速器（1 分钟）
4. 看游戏 / 客户端装在哪个盘、什么盘（2 分钟）
5. 简单网络测试：ping（2 分钟）
6. 查日志、事件查看器（5–10 分钟）
7. 干净重装、驱动重装（20 分钟以上）

禁止

不要一上来就让用户重装。重装是"大招"，它会抹掉大量线索，让你失去搞清楚原因的机会。重装之后问题没好的，你就彻底没方向了。

原则五：能复现，才算定位

在你说"问题在 X"之前，最好能让问题按你的预期出现和消失。

比如你判断"启动慢是因为游戏装在 USB 2.0 接口的 U 盘上"。怎么验证？把游戏挪到 SSD 上，启动变快了——验证成功。如果挪过去还是一样慢，说明你的判断错了，U 盘不是（唯一的）原因。

复现的价值在于：它把"我觉得"变成"我确认"。没有复现的判断只是一个概率较高的猜测。

当然，不是所有问题都能方便地复现（比如偶发的闪退）。这种情况下，至少要做到"证据链完整"：每一步推理都有对应的证据。

原则六：症状不等于原因，原因不等于根因

"磁盘 100%"是症状，"装在 U 盘上"是原因，"U 盘插在 USB 2.0 接口上"才是根因。

把这三层分开是排查的核心能力：

• 症状：用户看到的、你观察到的现象。它告诉你"哪里不对"。
• 原因：直接导致症状的那件事。它告诉你"为什么不对"。
• 根因：导致原因的那件事。它告诉你"怎样才能彻底解决"。

只处理症状（"重启一下"），问题会回来。只处理原因（"把 U 盘换到别的口"），如果用户没有 USB 3.0 接口，问题依然存在。处理根因（"游戏不能装在慢速存储上，挪到 SSD"），问题才算真正解决。

大白话

症状是发烧，原因是感染，根因是伤口没处理。退烧药能压住症状，抗生素能解决感染，但伤口不处理还会再感染。

原则七：不让用户做不可逆的操作

在没有把握之前，不要让用户做任何"做了就回不去"的事。

不可逆操作包括但不限于：

• 删除文件、格式化磁盘、清空分区；
• 修改注册表；
• 卸载驱动（尤其是网卡驱动——卸了之后可能连网都没了）；
• 重置网络、重置系统；
• 修改 BIOS 设置；
• 关闭安全启动、关闭内核隔离等系统安全设置。

这不是说永远不做这些事，而是说：做之前要有充分证据表明确实需要这么做，并且用户理解风险，并且尽可能先备份。

禁止

永远不要让用户"把 X 盘格式化了重新装"或者"删掉 XX 文件夹"，除非你百分之百确定那个位置只有我们的东西、并且用户确认过。删错了没法恢复，责任非常大。

原则八：解决之后要确认，确认之后要记录

用户说"好像好了"不算好了。要让他真的再试一次，确认问题不再出现。

然后记录：问题现象、排查过程、最终原因、解决方法。记录有两个用途：

1. 沉淀到知识库，下一个客服遇到类似问题可以直接用。
2. 如果问题过几天又来，可以接着上次的线索查，不用重头开始。

记录不需要长篇大论，一个模板就够，见 模板。

把八条原则串起来

接到问题
  │
  ├─ 原则一：先问清 ──→ 把"打不开"变成精确描述
  │
  ├─ 原则二：先收集 ──→ 截图 / 命令 / 日志 / 环境信息
  │
  ├─ 原则四：由近到远、由简到繁 ──→ 决定先看哪个证据
  │
  ├─ 原则六：分清症状 / 原因 / 根因 ──→ 形成假设
  │
  ├─ 原则三：一次只改一个变量 ──→ 验证假设
  │     └─ 原则七：不做不可逆操作
  │
  ├─ 原则五：能复现才算定位 ──→ 确认原因
  │
  └─ 原则八：确认 + 记录 ──→ 沉淀

常见误区

• "这个问题我见过，肯定是 X。" 见过一次不代表这次也是。用证据确认，不用经验替代证据。
• "用户着急，先让他重装快一点。" 重装二十分钟，还不一定有用；问清楚花两分钟。
• "多给几个方法让他都试试，总有一个管用。" 违反原则三。而且给用户一堆方法，会让他觉得你也不知道问题在哪。
• "用户说好了就结束。" 要让他再复现一次操作确认。很多"好了"是碰巧，或者是用户不好意思继续问。
• "这个太复杂了，直接升级。" 升级之前至少要完成信息收集，否则技术同事还得回来重新问一遍用户。

自检问题

1. 用户说"游戏打不开"，你的第一句话应该是什么？为什么不是"您重装一下试试"？
2. 什么叫"一次只改一个变量"？如果改了没用，接下来要做什么？
3. 用"游戏装在 U 盘上启动慢"这个例子，说出症状、原因、根因分别是什么。
4. 列出至少五种"不可逆操作"。
5. 为什么不建议一上来就让用户重装？
6. 用户说"好像好了"，你应该怎么做？