用五个事件立起时间线

目标

能够汇总散落在多份日志中的五个时间点，建立时间线，并从用户视角计算影响持续时间。

为什么重要

在事故报告中，客户最先阅读的不是根因分析，而是时间线。因为它同时展示“我们有多久没有察觉”以及“察觉后采取行动有多快”。

五个时间点之间的四个区间各有名称。变更 → 影响是潜伏区间，影响 → 发现是检测延迟，发现 → 措施是响应延迟，措施 → 确认恢复是验证区间。其中，如果检测延迟很长，需要改进的不是系统而是可观测性。缺少验证区间的报告，也只表明“我们认为已经修复”。

影响持续时间从影响开始一直统计到确认恢复。用户不知道部署发生在何时，而且只有在服务真正恢复正常时才脱离影响，而不是在输入回滚命令的瞬间。

三份日志：/opt/data/deploy.log、/opt/data/app.jsonl、/opt/data/alert.log

步骤

1. 创建 /root/timeline 目录。
2. 将 payment 2.7.0 的部署时间以 HH:MM 格式写入 /root/timeline/t_deploy.txt。
3. 将首次发生错误的时间写入 /root/timeline/t_error.txt。
4. 将 critical 告警变为 firing 状态的时间写入 /root/timeline/t_alert.txt。
5. 将执行回滚的时间写入 /root/timeline/t_rollback.txt。
6. 将告警变为 resolved 状态的时间写入 /root/timeline/t_resolved.txt。
7. 编写 /root/timeline/timeline.md。其中必须包含全部五个时间点，并在文件内按时间顺序排列。
8. 将从影响开始到确认恢复之间的分钟数仅以数字形式写入 /root/timeline/mttr.txt。

参考

• cat /opt/data/deploy.log、cat /opt/data/alert.log——两份文件都很短，直接阅读即可。
• 时间格式为 HH:MM。从 2026-08-19T03:19:04Z 中只取 03:19。
• 常见错误 1：第 8 步从部署时间开始计算。用户并不知道部署发生的时间。
• 常见错误 2：在第 7 步中写入人员姓名或账户名。不要把日志中的 actor 值写入时间线。

创建工作目录

创建 /root/timeline 目录。

将结果集中放在 /root/timeline 下。

查找变更时间

将 payment 2.7.0 的部署时间以 HH:MM 格式写入 /root/timeline/t_deploy.txt。

该时间是 deploy.log 中部署 payment 2.7.0 的时刻。只写 HH:MM。

查找影响开始时间

将首次发生错误的时间写入 /root/timeline/t_error.txt。

这是用户实际开始遭遇失败的时刻。请查找 app.jsonl 中首次出现 error 的时间。

查找发现时间

将 critical 告警变为 firing 状态的时间写入 /root/timeline/t_alert.txt。

该时间是 alert.log 中 critical 变为 firing 状态的时刻。

查找采取措施的时间

将执行回滚的时间写入 /root/timeline/t_rollback.txt。

deploy.log 中记录了 rollback。

查找确认恢复时间

将告警变为 resolved 状态的时间写入 /root/timeline/t_resolved.txt。

该时间是 alert.log 中同一规则变为 resolved 状态的时刻。

编写时间线文档

编写 /root/timeline/timeline.md。其中必须包含全部五个时间点，并在文件内按时间顺序排列。

必须包含全部五个时间点，并在文件内按时间顺序排列。

计算影响持续时间

将从影响开始到确认恢复之间的分钟数仅以数字形式写入 /root/timeline/mttr.txt。

从用户视角看，诚实的区间是从影响开始到确认恢复。只写以分钟为单位的数字。