事故进行中时，最糟糕的时机就是在生产宕机时才去想该检查什么。故障排查流程图把这种思考前移到事故之前——它把决策路径捕捉一次，让任何值班的人在高压下照着走，而不是凭记忆临场发挥。
本文梳理一个真实的事故响应流程。因为几乎每个节点都是分支问题，故障排查流程图本质上就是一棵决策树——更通用的模式见那篇。
为什么事故需要流程图
两个工程师处理同一次宕机，会按不同顺序检查不同的东西。这种不一致既耗时又导致漏步。故障排查流程图把路径标准化：先查这个，根据答案再做那个。它还兼作培训——新的值班工程师可以照着图走，而不必呼叫资深的。
分步讲解
下面是我们故障排查流程图模板所画的流程：
1. 收到告警。 入口——一条告警、一次呼叫、一份「出问题了」的报告。
2. 检查服务状态。 第一个诊断：服务到底还可达吗？
3. 服务可达？（判断） 如果否，去重启或故障转移——在深入调试前先把服务拉回来。如果是，进入排查。
4. 查看日志和指标。 收集证据：错误日志、延迟、近期发布。
5. 找到根因？（判断） 如果否，转到收集更多上下文，扩大范围回退到日志排查。如果是，继续。这条环符合现实——你很少第一遍就找到原因。
6. 应用修复。 做出应该能解决问题的改动。
7. 恢复已验证？（判断） 关键关卡。如果否，转到回滚并继续——撤销改动继续排查，而不是把一个没修好的修复留在那。如果是，继续。
8. 观察 30 分钟 → 已解决。 别急着宣布胜利。一段观察窗口确认修复稳住了，再到达已解决终点。
三个判断点（可达、根因、恢复验证）连同它们的回退环，正是让这成为可用事故手册而非线性清单的关键。用这个模板打开流程图工具，就能看到回滚和重新排查的路径。
常见错误
没有回滚路径。 如果「应用修复」直接通到「已解决」、中间没有验证关卡，那这张图就假设了每个修复都有效。「恢复已验证？→ 否 → 回滚」这条分支是事故流程里最重要的部分。
过早宣布解决。 没有观察窗口，一个只是看起来有效的修复就会被标为已解决——然后事故重开。把等待内建进流程。
跳过可达性检查。 对一个干脆已经宕掉的服务深入调试，浪费了最关键的头几分钟。先查可达性、先恢复、再排查。
常见问题
什么是故障排查流程图？
故障排查流程图是一棵决策树，把事故响应或调试变成可复用的路径——状态检查、日志排查、回滚、恢复验证。
为什么事故响应要用流程图？
高压之下人会跳步骤、靠记忆办事。流程图把决策路径写明确，让任何值班的人都能一致地照着走。
想搭建自己的事故手册？从故障排查流程图模板开始——它已经预置了状态检查、回滚和验证关卡，无需注册。
