DIAGNOSE METHOD
根因分析（RCA）
ROOT CAUSE ANALYSIS用时间线、证据和因果验证解释事故为何发生且为何未被拦住。
什么时候该用，什么时候别用？
- 高影响事故、质量缺陷或反复故障
- 需要跨系统重建事件链
- 修复症状后仍需防复发
- 影响很小且原因显而易见，完整 RCA 成本过高
- 组织只想找责任人而非改系统
根因分析（RCA）的具体操作步骤
按顺序完成；每一步都要留下可以复查的文字或证据。
- 01
控制影响并保存证据
先止损、恢复服务，同时保留日志、版本、配置和沟通记录。
怎样避免证据在恢复过程中消失？
- 02
建立无评价时间线
按时间记录动作、系统状态和决策，只写事实。
异常前后每个关键节点发生了什么？
- 03
分析因果与防线
识别触发器、促成条件，以及监控、评审、测试为何没有拦截。
哪些条件同时存在才造成影响？
- 04
制定分层措施
覆盖立即修复、检测改善、预防机制，并为每项指定负责人和验证日期。
如何证明复发概率真的下降？
跟着一个例子完整走一遍
原始问题
一次配置发布导致全站登录失败 24 分钟。
- 1
时间线显示配置格式正确，但旧版服务不认识新字段。
- 2
灰度只覆盖新版实例，未包含版本混跑场景。
- 3
告警监控请求成功率，却未监控登录成功率。
- 4
措施覆盖兼容测试、混版本灰度和业务结果告警。
得到的结论
结论解释“为什么发布会失败、为什么灰度未发现、为什么告警太晚”，而非只回滚配置。
复制后直接填写
第一次不用追求完美，先把空白处填出来，再根据证据修改。
影响：【用户/时长/损失】
时间线：【】
触发因素：【】
促成条件：【】
失效防线：【】
立即修复：【】
预防措施：【负责人/日期/验证方式】看似在用，其实容易用错
- 复盘充满“本应该”却没有当时上下文
- 行动项只有“加强意识、完善流程”
- 没有验证措施是否按期生效