故障复盘时间线怎么整理？对齐时间、证据与恢复节点

故障复盘时间线先回答“什么时候发生了什么、依据在哪里”，再讨论为什么发生。把故障出现、告警发现、人工处置和业务恢复混成一列，容易把“有人点击了回滚”写成“服务已经恢复”，也容易把最早收到的告警误当作故障起点。

整理时保留原始时间和时区，换算到同一时间轴，再按影响、发现、处置和恢复分层。使用Boardmix时间轴可以把多源记录并排放置，让每个节点连回日志、监控或沟通记录；图中暂时无法确定的时刻，应保留区间或未知状态。

四种时间，分别代表四件事

• 事件发生时间：某次配置变更、请求失败或连接断开发生的时刻。
• 被观察时间：监控首次检测、用户首次报告，或值班人员实际看到信号的时刻。
• 处置时间：决定回滚、发起操作、操作结束是不同节点，必要时分别记录。
• 恢复时间：具体业务指标回到约定状态，并完成相应确认的时刻。

同一条日志还可能有事件时间与入库时间。若日志延迟两分钟到达，不能按入库先后重排真实事件。采集规则、监控窗口和时钟误差不清楚时，先写限制，不要把分钟级记录扩写成精确到秒的结论。

GitHub的2018年10月21日故障分析很好地体现了这些区别：10月21日22:52 UTC发生网络连接问题，22:54开始产生监控告警，23:07团队决定锁定部署工具；到10月22日23:03，积压任务处理完成且系统运行得到确认，状态才恢复为绿色。几个节点各有含义，不能只挑两个时间相减就称为“修复耗时”。

读公开复盘时，也要区分报告明确记录的事实与自己的解释。上面的节点可用于学习记录方式，不足以单独还原该事故的完整因果链。

从原始记录到时间线：保留两列时间

假设团队正在复盘一次预约接口异常，拿到如下演练材料。展示时间统一为北京时间（UTC+8），原始时间仍保留，便于别人回查。

预约接口事件记录的对时与归类

编号	原始时间	统一时间	记录内容	类别与来源
E1	02:00:10 UTC	10:00:10 UTC+8	配置版本V8生效	变更；发布日志
E2	10:01—10:02 UTC+8	同左区间	该分钟窗口内预约失败增加	影响；监控聚合记录
E3	02:03:05 UTC	10:03:05 UTC+8	告警发送	发现；告警记录
E4	10:04 UTC+8	10:04 UTC+8，精度到分钟	值班人员在群里确认已接手	响应；沟通记录
E5	02:07:20 UTC	10:07:20 UTC+8	发起恢复V7操作	处置；操作日志
E6	02:08:40 UTC	10:08:40 UTC+8	V7重新生效	处置完成；发布日志
E7	10:10 UTC+8	10:10 UTC+8	约定观察窗口内错误指标恢复，人工预约验证通过	恢复确认；指标与验证记录

E2只能放在10:01—10:02区间，不能画成10:01:00的精确故障起点。E5表示发起操作，E6表示版本生效，E7才是本例采用的业务恢复确认。这样画出来的时间线，即使不附任何复杂图形，也比“10点故障、10点07修好”更有解释力。

材料还应保留日期、环境、服务名称和记录链接。跨午夜的事故尤其不能只写时分；测试环境的成功记录也不能用来证明生产环境恢复。

两份记录对不上，不要悄悄选一个

如果群消息说“10:06已经恢复”，而业务指标直到10:10才满足恢复条件，把两者都留下。前者可能表示某人观察到一个页面恢复，后者覆盖的是预约接口及约定观察窗口。先写清观察对象，冲突可能就转化成“局部恢复”和“整体恢复”的区别。

仍然矛盾时，增加一张问题卡：冲突记录编号、可能解释、需要补的材料、核对人。例如应用日志时钟比网关慢了一段时间，在没有校时依据前，不能通过拖动节点让它看起来符合预想顺序。确需校正时，保留偏移量、依据和转换后的时间。

没有记录不是事件没有发生。用“尚未找到10:00—10:01的应用日志”描述缺口，比画一条平稳曲线暗示该段正常更准确。时间线可以不完整，但不应把缺口填成猜测。

动作和结果相邻，不等于已经证明因果

本例中V8生效后错误增加，恢复V7后指标改善，值得进一步检查配置影响；但时间上的相邻尚未排除流量变化、依赖恢复或同时发生的其他操作。将“V8导致故障”先列为待验证解释，并注明支持它的E1、E2、E6、E7与缺少的材料。

时间线中可分别使用“事实”和“解释”两类卡片，但不要让解释卡与日志节点采用完全相同的样式。事实卡写发生了什么，解释卡写哪种机制可能把节点连接起来，以及怎样证实或反驳。

Google SRE的复盘方法将事故记录、贡献因素和后续行动结合起来，并强调无责复盘。时间线据此帮助团队理解当时可见的信息和选择，而不是从结果倒推某个人“本来就该知道”。需要继续追问原因时，可用5Why分析的证据与边界方法，但不要用连续追问替代日志与机制核查。

把时间线做成可继续追查的工作画布

在Boardmix中创建一条带日期与时区的横轴，纵向分为“业务影响、发现与沟通、处置动作、恢复确认”四轨。先放E1—E7，再把时间不精确的E2画成区间；每张卡写编号和来源位置，原始材料放在相邻资料区。

按三个视角走查：业务人员确认用户受影响的范围，值班人员确认当时收到的信息，执行者确认动作起止与实际结果。遇到争议直接标在对应节点旁，不把所有问题移到一个失去上下文的文末清单。

交付时留下一条可以回查的链：时间节点—来源—解释—补证动作。故障持续时长、发现延迟和响应耗时可以随后按明确口径计算；当起点只有区间时，结果也应保留范围。先把记录讲清楚，才有条件讨论哪些环节值得改善。