故障排查流程图把可观察的问题转为一连串有依据的判断。在事件响应中，下一步取决于检查结果，提前画清路径可以减少临场猜测。
目标是帮助响应者选择安全的下一步、识别权限边界并及时升级。不能统一要求所有人重启服务、等待固定分钟数，再宣布恢复。
从具体症状和范围开始
选择一个明确入口，例如影响客户的结账错误率告警。“系统有问题”太宽泛，难以分支。写清服务、环境、用户操作，以及权威运行手册的位置。
区分告警和客户影响。监测本身异常也会触发告警，真实客户故障也可能没有对应告警。第一轮检查应利用服务现有信号确认影响与范围。
说明预期读者。客服、值班工程师和事件指挥者的权限不同。遇到需要额外权限的步骤，应画出交接，流程图本身不会授予操作权限。
把判断写成能回答的问题
有效的判断应能通过证据回答。“多个位置的模拟结账都失败了吗？”比“系统健康吗？”更具体，并应关联提供答案的看板、查询或获准检查。
可能缺少数据时保留“不确定”分支。指标平台不可用不代表答案是否，应转向其他获准数据源或升级负责人，不能逼响应者猜一个出口。
把检查和变更分开。查看看板属于检查；改路由、回滚、重启属于变更。低风险排查不应在图中悄然变成未经授权的干预。
绘制核心排查路径
1. 记录症状与上下文。 保存事件编号、首次观察时间、受影响操作和初步证据。多人使用统一事件记录，避免出现互相冲突的版本。
2. 确认影响和负责人。 检查用户侧信号与已有事件。超出服务负责人权限时启用对应事件机制。重复报告加入现有响应，避免独立修改系统。
3. 执行获准诊断。 查看服务、依赖、近期变更和有代表性的失败请求。无法访问可能源于 DNS、网络、认证、依赖或应用本身，并不自动意味着应重启。
4. 是否有获准的缓解措施？ 将证据与运行手册条件对照。可以先缓解再找根因；没有适用操作时，应收集有针对性的证据并在检查点升级，不临时尝试破坏性修复。
5. 执行一个受控动作。 记录批准人、变更内容与时间。并发变更通过事件负责人协调，避免多人各自改动导致无法判断效果。
6. 验证客户侧恢复。 复查受影响的用户操作及系统信号。部署命令成功或健康检查变绿，不足以证明结账已经恢复。
7. 观察或升级。 按实际流量、任务周期和运行手册选择验收条件。验证失败后重新评估并升级；只有当前状态适用且获得授权时才回滚。
8. 交接后续工作。 记录剩余风险、临时措施、证据与负责人。服务稳定后，根因分析、长期修复与手册改进仍可继续。
完整示例：部署后出现结账错误
假设客户在应用部署后报告结账失败。值班工程师确认结账链路错误升高，创建事件记录。首页能打开不能结束调查，因为故障发生在特定操作上。
工程师比较版本、错误特征与依赖信号。时间接近只提供假设，并不能证明部署就是根因。运行手册要求先确认兼容条件，并由事件负责人批准回滚。
若数据库变更让旧应用版本不再兼容，回滚就可能失败。因此动作前必须判断“回滚前提满足了吗”。不确定时交给服务负责人，不能把回滚当成永远安全的撤销。
假设前提通过且已获批，由一人执行并记录版本和时间，其他人继续收集证据，不独立修改生产环境，便于判断此次操作的效果。
随后检查有代表性的结账请求、相关错误和延迟。如果客户影响仍存在，带着新增证据回到调查检查点，而不是反复回滚同一版本或重启无关组件。
如果结账恢复，负责人按服务手册安排观察与通知。低流量时段的确认方法可能与高峰不同。记录应明确“缓解有效，根因仍在调查”，避免过早下结论。
给循环和变更增加边界
| 判断 | 所需证据 | 缺少证据时的出口 |
|---|---|---|
| 客户影响已确认吗？ | 用户链路检查和服务信号 | 使用其他获准来源或升级 |
| 符合已知故障模式吗？ | 症状与手册条件一致 | 继续针对性诊断 |
| 允许执行缓解吗？ | 范围、前提和授权 | 请求有权限的负责人 |
| 恢复条件通过了吗？ | 用户结果与相关系统指标 | 重估、控制影响或升级 |
| 可以关闭事件吗？ | 观察、沟通及后续负责人 | 保持开放或明确交接 |
每个调查循环都要有检查点。可以按团队规定的调查间隔或一组检查完成后重新评估，具体值来自实际运行规则，不套用教程中任意分钟数。
重复收集相同日志不算取得进展。到检查点时总结测试了什么、什么发生变化、哪些假设仍未排除，下一分支应要求新增证据、其他专家或控制影响的决定。
不可逆操作应单独处理。删除数据、修改数据库结构或切换流量的后果，不是一个通用回滚箭头能表达的。应连接获准操作规程和负责角色。
让图在压力下仍然可读
动作框和判断框使用简短具体的标签。命令、前提与看板保留在运行手册中，在图上引用。这样既能看清路径，也不丢失操作所需细节。
多人参与时按职责分组。调查人不一定有权批准变更或通知客户。交接应包含事件编号、当前影响、证据和需要对方作出的决定。
不同结束状态用不同名称：“误报已确认”“服务稳定但仍需后续处理”“已升级事件指挥”不是同一结果，不能都压成一个“已解决”。
用桌面演练检验流程
走查已知故障、未知故障、监测缺失、缓解失败和权限不足。请不熟悉草稿的响应者解释下一步及所用证据。
加入“无法回滚”和“健康检查正常但客户操作失败”两类场景。只检查正常路径，很容易漏掉这些危险假设。
把歧义当作文档缺陷。负责人、阈值或权限需要猜测时，应修改流程图或手册。系统有实质变化后重新演练，比只改修订日期更有价值。
创建可编辑的排查图
打开故障排查流程图模板，替换为真实症状、获准检查、缓解前提和升级负责人。图形含义可参考流程图符号。
CodePic 用于编辑图、导出 PNG、保留可编辑 JSON 和只读分享，不会监测服务或执行图中的操作。不要把生产凭据或敏感事件证据放进公开图。
常见问题
故障排查流程图就是决策树吗？
它经常包含决策树分支，也可能包含动作、循环、交接和恢复阶段，应根据真实排查过程选择结构。
可以先缓解再分析根因吗？
可以，前提是操作已获准、符合证据且满足实施条件。要明确区分“服务恢复”和“根因得到证实”。
每次修复无效都应回滚吗？
应先评估当前状态和手册。有些操作不可安全逆转；验证失败意味着重新评估和升级，回滚只在适用且获准时执行。
