排查问题
从发现异常到解决或移交。
The case
有什么不对劲。不知道具体是什么，不知道有多严重，接下来的每一步，要么解决问题，要么白白耗掉一个小时。排查问题失败，往往不是因为缺乏解决问题的能力，而是因为没有在一开始花时间把问题描述清楚。
本能反应是立刻开始尝试。重启。重装。在还没说清楚症状之前就去搜索。有时候靠运气能成。但不成的时候，已经在一个本就不清晰的局面里又引入了新的变量。
排查问题的日程，本质上就是一棵有固定入口的决策树。把问题描述清楚，尝试复现，确认有什么变更，有针对性地搜索，按顺序试最可信的方案。每个分支，要么继续往下走，要么跳过某些步骤。如果走到最后还没解决，就移交出去——但要带着有用的信息，而不是一个无奈的耸肩。
日程还提供了一个停止条件。没有它，排查问题往往会无限蔓延，填满所有可用的时间。步骤 #12 的判断节点迫使一个问题浮出水面：继续下去还值得吗，还是说这已经是别人的问题了？
排查问题
- 写下操作步骤、预期结果和实际发生的情况。
- 按照列表逐步操作，尝试复现问题。 如果无法复现，返回 @1 ——列表还不够完整。
- 确认最近有哪些变更。 软件更新、新的输入、配置调整，任何变动都算。如果什么都没变，跳至 @7。
- 撤销变更。 恢复到之前的状态或版本。如果撤销成功，返回 @2，确认问题是否仍然存在。
- 隔离变更。 仅禁用、断开或移除发生变更的部分，然后再次测试。目标是在采取其他措施之前，确认该变更是否是问题根源。 如果问题解决，跳至 @13。
- 重新应用变更。 已确认它是问题根源。记录下来。跳至 @13。
- 搜索准确的报错信息或症状描述。 如有报错，原文复制。模糊的搜索只会带来模糊的结果。
- 记录搜索结果中出现频率最高的解决方案。 频率只是起点，不是证明。
- 确认参考资料的发布日期。 五年前的解决方案可能已不再适用。
- 尝试最可信的解决方案。 如果问题解决，跳至 @13。
- 尝试下一个可信的解决方案。 如果问题解决，跳至 @13。
- 决定：继续尝试还是上报移交。 已经花了多长时间？问题有多紧急？如果选择移交，跳至 @14。如果继续，返回 @10。
- 记录解决问题的方法。 一句话。你会忘记的，而且还会再遇到同样的问题。
- 为接手的人整理问题说明。 尝试过什么、排除了什么、怀疑是什么原因。交接要清晰。
按需调整
最重要的步骤是 #13，也是大多数人会跳过的那一步。解决问题和记录解决方法是两件不同的事——后者能让你六个月后不必再为同一个问题浪费四十分钟。一句话就够了。
步骤 #10 和 #11 是可以延伸的循环占位符。有些问题需要尝试十次才能找到有效的方法。根据需要添加步骤，并在 #12 决定是继续还是移交。
#14 的上报移交值得认真对待。清晰的交接——尝试过什么、排除了什么——对接手的人真的很有帮助。只说"坏了"是没有用的。
如果是针对特定领域使用这个日程——软件、硬件或某种设备——可以根据日常诊断流程调整中间步骤。结构保持不变，细节由自己填充。