生产事故响应
使用场景: 值班工程或 SRE 团队
告警触发
→ 服务可访问？
否 → 重启 / 切换实例
是 → 查看日志与监控
→ 已定位原因？
否 → 补充证据
是 → 应用修复 → 验证 → 观察 → 结束
这样组织的原因: 这个结构把“先恢复”与“深挖根因”分开了，能同时兼顾恢复速度和排查质量。
真实案例
客服问题分流
使用场景: 支持团队，处理重复出现的产品问题
收到工单
→ 客服能复现吗？
否 → 索要更多信息
是 → 是否已知问题？
是 → 提供临时方案
否 → 带日志升级
这样组织的原因: 最大的价值是统一前置信息收集方式，让升级前不再遗漏关键上下文。
内部应用调试
使用场景: 产品或平台团队，排查回归问题
收到 bug 报告
→ 在 staging 能复现吗？
否 → 对比环境差异
是 → 检查最近变更
→ 修复验证通过？
否 → 回滚
是 → 观察并关闭
这样组织的原因: 把环境对比和回滚留在图里，能避免团队只盯着代码本身，忽略环境和发布因素。
使用技巧
- 第一个判断尽量快，一个基础健康检查经常能在深入排查前省掉很多时间。
- 至少给“信息不足”预留一条路径，因为很多事故一开始的上下文本来就不完整。
- 终点要放在验证和短时间观察之后，而不是改完东西的那一刻。
相关资源
在线开始编辑
回到模板页，直接替换成你的课程主题、章节和复习重点，就可以继续使用这套结构。
使用这个模板： /editor/new?template=troubleshooting-flowchart
使用这个排障模板