时间线就是报告的一半

一句话总结

时间线不是事件的列举，而是揭示每个部分意味着什么的工具，这些部分就是下次需要缩短的时间。

为什么需要这个？

在故障报告中，客户首先阅读的不是原因分析，而是时间线。有原因的。因为时间线同时显示了“我们不知道多久了”和“知道后有多快行动了”。

而且这两个数字决定了下个季度改进的课题。

怎么行动

有用的时间线有五个视图。

变更时间—发生变化时。部署、设置变更、流量激增。 影响开始时间——用户实际开始经历失败的时候。 认知视觉——我们知道的时候。闹钟响了或客户报警的时候。 措施时间—实施缓和措施时。 恢复确认时间——按照同样的标准重新检查并确认顶部的时间。

而且这五个之间四个区间各自都有名字。

变化→影响：潜伏阶段。短的话会立即暴露出来，长的话需要积累特定条件才能爆发。后者更可怕。

影响→认知：检测延迟。如果这个值大，问题不是系统，而是观测。如果客户先告知的情况反复发生，无论如何修好原因，信任都无法恢复。

认知→措施：应对延迟。如果有运行手册就简短，没有就长。

措施→恢复确认：验证区间。没有这个区间的报告只能说“我认为已经修复了”。

在现场相遇的样子

这里提一下经常出现的判断。影响持续时间是从哪里到哪里计算。

从变更时间开始，洗脸实际时间会比实际时间长，直到措施时间为止，洗脸实际时间会比实际时间短。从用户的角度来看，诚实计算是从影响开始到恢复确认。用户不知道什么时候部署，不是在执行回滚命令的那一刻，而是在实际恢复正常的那一刻脱离影响。

还有在写时间线时还要遵守一个规则。**不要写人名。**不是“金某人在03:19发布”，而是“03:19 payment 2.7.0发布”。

这不是道德，而是算计。如果客户报告中指定了特定负责人，那么在下一次障碍中，该人会隐藏信息。这样，下一次的检测延迟就会增加。没有指责的报告是购买下一次诊断速度的投资。

配合时间是一半

将多个来源的日志排成一行时，首先遇到的问题是时间和精度。

来源	常见形式	陷阱
应用程序日志	2026-09-06 12:04:31	没有时区——不知道是服务器本地还是UTC
容器管理事件	2026-09-06T12:04:31Z	固定UTC。与应用程序日志相差9小时
云控制台	浏览器本地时间	每个人的看起来都不一样
闹钟	不是发生时间，而是评价时间	比实际晚1~5分钟

**全部都改成UTC写，并说明文档顶部是那样写的。**还有闹钟是 表示“检测时间”不是“发生时间”。如果不区分这两个时间点的话 把“警报晚了”和“障碍晚了开始”混在一起。

精度也正确。将超微秒级日志和毫秒级日志放在同一行时，以秒为单位。 下降。如果像有无精度的样子使用的话，就会把因果关系颠倒过来。

把什么看作是因果关系呢？

按时间顺序排列的话可以看到前后关系，但看不到因果。三个 只有确认才能说是因果关系。

1. 时间一致性——原因是否比结果先发生？即使考虑到传播延迟，顺序是否正确？
2. 范围一致— 原因的影响范围和症状的范围一样吗？只换了一个脚垫 如果整个都死了，那就有其他原因。
3. 反向验证——当逆转原因时，症状是否消失了。这是最强有力的证据。

如果三个中任何一个都不符合，请写上“似乎相关”，但不确定。 在时间线文件中区分并标记****估计和确认，这会建立信任。

| 시각(UTC) | 사건 | 출처 | 확인 |
|---|---|---|---|
| 03:19:02 | payment 2.7.0 배포 시작 | Argo CD | 확인 |
| 03:19:40 | payment 파드 5xx 시작 | 앱 로그 | 확인 |
| 03:23:11 | 결제 실패율 경보 | Alertmanager | 확인(평가 시각) |
| 03:24 경 | 고객 문의 유입 | 지원 티켓 | 추정(티켓 시각은 접수 시각) |
| 03:31:05 | 2.6.4 로 롤백 | Argo CD | 확인 |
| 03:31:52 | 5xx 소멸 | 앱 로그 | 확인 — 되돌림으로 인과 성립 |

下次实习要做的事情

从分发历史、应用程序日志、闹钟历史中分别提取五个视图，制作按时间顺序排列的时间线文档，计算用户视角的影响持续时间。