故障排查树：症状、检查与出口

故障类问题的答案不是「怎么做」，而是「怎么确认问题出在哪一层」。

一、「导出一直转圈」的十七张工单

苏禾的数据导出功能上线三个月，故障类工单稳定在每月三十张左右，其中「导出一直转圈」占了十七张。她一开始写了一篇 FAQ，列了六个可能原因：网络、文件太大、浏览器、权限、服务状态、重试。用户读完还是不知道自己是哪一种，于是照样提工单。

她换了个办法：把十七张工单的对话逐条读一遍，看用户在被问到什么时能给出有效信息。结果发现，只要问清三件事——「转圈多久」「文件多大」「换浏览器是否一样」——十七张里有十四张能定位到具体原因。

以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。

于是她把这三次提问画成了一棵树：先问症状，再问两个可观察的检查项，最后分到四条出口。上线后，同类工单降到每月四张，剩下的多数是真正需要看数据的个案。

排查树不是文档，是一次被固定下来的问诊。 它的价值不在于写得多全，而在于每一步都让用户能自己回答。

二、按症状建树，不按功能建树

功能视角的排查是「导出模块 → 检查 A → 检查 B」，用户不知道自己的问题属于哪个模块。症状视角的排查是「你看到什么 → 先确认这个 → 再确认那个」。

先覆盖高频症状，不要追求全覆盖。 本例八个症状覆盖了六个，覆盖率 6 ÷ 8 = 75%，已经能处理绝大多数故障工单。剩下两个低频症状，用一篇通用说明加人工出口更划算。

症状要抄用户的原话。 「性能问题」不是症状，「导出很慢」才是；「鉴权异常」不是症状，「登录后被踢出」才是。

一个症状可以对应多棵树。 「导出失败」在免费套餐和团队套餐里的原因不同，可以在树根先分套餐，再进入各自的检查路径。分支可以共用节点，但入口要分开。

三、三型节点、错误码与日志

一棵树再复杂，也只有三种节点。把节点类型定死，画起来就不会乱。

检查节点必须可观察。 「检查网络是否正常」不可观察；「打开另一个网站，看能否加载」可观察。用户回答不了的问题，不该出现在树里。

分支不要超过三个。 超过三个，用户会随便选一个，数据就废了。确实有四种情况，拆成两层二选一。

每个叶子都必须是出口，不能是空白。 画树时最常见的错误是某个分支走到底没有下一步，用户卡在那里，最后还是提工单。所有叶子都要落到四条出口之一。

树的深度控制在三到五步。 本例平均 3.2 步。超过五步，用户会在中途放弃；低于两步，说明这根本不是树，是一篇 FAQ。

排查树能不能被人接手，取决于用户能不能提供有效信息。错误码和日志位置是两样最值钱的东西。

每个检查节点旁边标注「如果失败，记下什么」。 比如「记下页面右下角的请求 ID」「记下设置 → 关于里的版本号」。用户不需要理解这些信息，只需要复制。

错误码要有一张对照表。 至少覆盖最常见的十个码，每个码写一句人话解释、一个可能原因、一个下一步动作。错误码表可以独立成页，由排查树的检查节点链过去。

日志位置要写路径，不要写「查看日志」。 「设置 → 高级 → 诊断 → 导出诊断包」是可执行的；「查看应用日志」对普通用户没有意义。

不要要求用户自己解读日志。 树的终点是「把诊断包附在工单里」，不是「根据日志判断是数据库问题」。判断是你的工作。

四、四条出口、死路率与建树成本

排查树的每个叶子都必须落到四条出口之一。出口不同，后续动作也不同。

「等待恢复」是最容易被漏掉的出口。 服务真的挂了的时候，让用户反复重试只会增加工单。树里要有一个节点专门判断「是否是已知故障」，是就导向状态页。

退款出口不能做成纯自助。 它只负责把用户送到政策说明与申请入口，是否符合条件由人判断。做成「点这里立即退款」，会带来不可逆的错误。

死路率是排查树最重要的质量指标。 本例每月 80 次树会话，12 次走到底仍无可用出口，死路率 12 ÷ 80 = 15%。这 12 次会回流到人工，属 120 张人工工单的一部分，不是额外新增的工单。

死路要分类，不能只计数。 常见三类：树里没有这个分支、分支存在但检查项用户答不了、出口链接失效。第一类补分支，第二类改检查项，第三类修链接。

排查树是第二阶段的工作，不要和第一阶段的 FAQ 混在一起算账。

建树范围：6 个高频症状
单棵 3 小时（含工单复盘、节点设计、走查）
6 × 3 = 18 小时 × 60 美元/时 = 1080 美元（一次性）

预期拦截：每月减少 30 张故障工单
30 × 12 分钟 = 360 分钟 = 6 小时 = 360 美元/月
回本 = 1080 ÷ 360 = 3 个月

若实际只减少 15 张：180 美元/月，回本 6 个月

先做一棵树验证，再批量建。 六棵一起画，很容易在第三棵发现节点类型设计错了，前两棵要返工。先用最高频的症状做一棵，跑两周，再决定其余五棵怎么改。

回本周期对拦截量很敏感。 拦截 30 张是 3 个月，拦截 15 张就是 6 个月。建树前先用工单量估一个保守值，按保守值算；达不到就说明这类问题不该用树解决。

树要跟着产品改。 界面改版、错误码调整、套餐上限变化，都会让某个节点失效。每次发版后抽一棵树走一遍，比季度大修便宜。

五、行动清单与复算验收

先读工单，再画树。跳过读工单直接画，画出来的是你以为的排查路径。

• 导出最近一个月故障类工单，按用户原话归成症状类别。
• 统计每个症状的工单数，选出前六个作为首批。
• 逐张读对话，记录「问到哪一句时用户能给出有效信息」。
• 把有效提问改写成检查节点，确保每个都可观察。
• 为每个分支设计二选一或三选一，不超过三个选项。
• 补齐四条出口，确认每个叶子都有下一步。
• 把错误码对照表与日志路径链进对应节点。
• 上线两周后统计死路率，按三类原因分别修补。

验收标准：任意一条故障工单，用户能在一棵树里走完并落到四条出口之一，且每个检查节点都是他能自己回答的问题。

使用边界与实操验收

本文只处理「症状 → 检查 → 出口」的排查树，不涉及帮助中心的整体导航、FAQ 的写法与搜索排序。

排查树不承诺修复。 它的目标是让用户知道问题在哪一层、下一步该做什么，而不是保证每个问题都能自助解决。把「树走完仍未解决」当成失败，会逼你把树写得越来越长。

涉及数据损坏、账号安全与服务中断的问题，树只做分流。 这类问题必须尽快到人，不能让用户在树里反复尝试。树的第一层就应该有一个「影响多人 / 数据异常 / 安全相关」的快速通道。

12 ÷ 80 的分母是树会话数，不是总工单数。 这个口径要和团队说清楚，否则会有人把它当成「15% 的工单没解决」，得出错误结论。

关键参考与核验范围

核验日期：2026-10-25。以下链接仅作为公开文档入口，用于核对系统化故障排查的通用方法，本文未逐条引用其内容。

• Google SRE 手册：Effective Troubleshooting ：用于核对「先稳定、再定位、分层假设」的排查顺序。
• Google 技术写作课程 ：用于核对面向任务的步骤与检查项写法。

引用口径。 本文只借用两份材料的方法：排查要先缩小范围、每一步都基于可观察的证据。文中的 17 张工单、6 棵树、3.2 步与 15% 死路率全部来自教学假设，与上述材料无关。

核验范围。 核验的是「症状优先 + 三型节点 + 四出口」这套结构是否仍然可操作，不是比对某个错误追踪工具。工具会变，节点类型不变。

如何自行复核。 挑一张最近的故障工单，按本文三型节点口头走一遍：能不能在三步内落到一个出口？如果不能，缺的是检查节点还是出口，一眼就能看出来。

系列导航

• 上一篇：FAQ 的写法：从工单原话到可执行答案
• 下一篇：教程与截图：让用户在 60 秒内完成一件事
• 回到目录：一个人的自助支持：帮助中心、排查树与工单减少
• 相关阅读：文档站：五分钟跑通第一个请求与错误自查