用AI整理故障时间线：把发生、发现和未知分开
复盘材料放在一起，最容易得到一条看似顺滑的故事：先发布，随后报错，最后恢复。问题是，日志生成时间、告警送达时间和事后回忆里的时间，可能在描述三个不同节点。我的建议是让AI先整理这些节点的身份，再尝试排序；资料中的空白也应当成为结果的一部分。
AI生成概念配图
先给每个时间贴上含义
Google SRE的复盘示例把时间线统一标为UTC，分别记录故障开始、告警、事件宣告、缓解与结束，并保留支持材料。这说明同一场故障有多个值得区分的节点。下面的双时间字段和未知区间写法是本文的整理建议，并非Google规定的统一格式。
我会要求每条记录同时保留事件时间与发现时间。前者回答事情何时发生，后者回答某个人或系统何时知道。另存原始时间字符串、时区、记录来源和时间精度。只有分钟就保留到分钟；“十点左右”不能被AI改成精确到秒的数字。
虚构案例：同一条错误，两个时间
以下资料完全虚构：某服务在九月十二日的日志中出现02:04Z错误，工程师到10:09才读到它；当日团队使用UTC+8。告警平台另记10:07通知送达。正确整理应写：错误事件为10:04，人工发现为10:09，告警送达为10:07。三条记录可以关联，但不能用人工读取时刻替换错误发生时刻。
聊天中又有人在10:12说“五分钟前应该恢复了”，而监控在10:14仍有错误。AI应保留这个冲突，标注恢复时刻待查，并列出两条材料。它不能为了让结尾完整，选择一个顺眼的时间。若监控只覆盖部分请求，还要写明观察范围，避免把局部恢复当成全站恢复。
排序之前，先处理不能排序的部分
保留原始时区，再换算展示时区；缺少日期或时区的记录进入待澄清组，不默认套用其他记录的设置。
将“约十分钟后”记成相对时间，并保留它依赖的起点；起点不确定，推算结果也不能确定。
明确未知区间，例如10:02至10:04之间缺少请求记录；缺日志不等于当时没有异常。
相同分钟内无法确定顺序的动作并列展示，不按材料出现顺序补出先后。
可以直接复用的任务模板
“请只依据以下材料整理故障时间线。每条输出事件描述、事件时间、发现时间、原始时间及其时区、来源编号、确定程度。统一展示为【时区】，但保留原值。时间缺失、互相冲突或依赖推算时单列说明。输出已能排序的节点、暂不能排序的节点、未知区间。不要补写日志之外的动作，也不要把先后关系改写成原因。”
拿到初稿后，我会再要求AI找出所有“导致、因此、恢复于”字样，逐项说明它依赖什么材料。这一步专门寻找越过资料的叙述。例如发布发生在报错之前，只支持时间相邻；要讨论发布是否触发故障，还需要机制、影响范围或进一步调查。
哪些情况下应该停在草稿
机器时钟漂移、跨日记录缺日期、日志延迟写入，都可能让整齐的排序失真。AI无法凭几段文字校准这些条件。遇到这种情况，我宁愿交付带空白的时间线和待查清单，也不把估计拼成完整故事。时间线的价值，在于让团队知道下一步该查哪一段，以及哪些结论现在还不能下。
