SRE团队把发布后的延迟告警交给Agent，它查到了指标、异常日志和变更记录，给出的根因也逐条附了出处，值班工程师却无法复现这个判断。问题往往藏在引用之间：这些记录各自是真的，是否真的在描述同一次故障？
比如，订单API在10:00开始发布v42，10:03的五分钟窗口P95从120毫秒升到900毫秒，P95指95分位请求耗时。以下用一个假设案例拆开这次判断：Agent找到10:02收集到的连接池超时日志，于是认定“新版本导致连接池耗尽”。
这条解释看起来完整：发布在前，告警在后，还有机制相关的异常。可那条日志实际发生在09:57，来自仍运行v41的旧实例。它证明旧实例曾经超时，却没有证明v42让当前请求排队。
先要修的不是答案措辞，而是允许哪些证据被连在一起。
三条真记录，拼出了一个错结论
把Agent的引用展开，会看到它使用了三个不同口径的“时间”。下表均为同一天、同一时区。
原始时间含义
实体或范围
能证明什么
E1 连接池超时
09:57发生，10:02被采集观察到
old-7，v41
旧实例在发布前曾超时
E2 延迟告警
10:03求值，向前统计五分钟
订单API聚合流量
这个窗口的延迟统计异常
E3 发布记录
10:00开始接流量
新批次v42
新版本开始参与服务
如果查询工具只返回“10:02，连接池超时”，日志摘要已经丢掉事件时间。如果指标查询只给一个P95，聚合后的结果又遮住了实例和版本。到了根因候选这一步，模型接收到的就是“发布后出现连接池超时且延迟升高”。
错误在形成根因以前就发生了。引用校验即使确认E1、E2、E3都存在，也只能证明没有伪造出处，无法补出“慢请求运行在v42上，并且慢在获取连接”这段缺失的联系。
▲ 证据时间与版本核对：旧日志不能证明新版本根因
把证据放回它发生的位置
OpenTelemetry的日志数据模型区分了两类时间：Timestamp是源端记录的事件发生时间，ObservedTimestamp是采集系统观察到事件的时间。后者也不是后台完成索引的时间。工具若把它们压成一个timestamp，Agent就失去了识别迟到日志的依据。
E1不必删除，应当放回09:57的旧实例时间线上。若源端时间缺失，就明确记录“事件时间未知”；若两台机器的时钟偏差大到无法判定先后，也应保留顺序不确定，不能用采集时间把空白填成确定因果。
然后核对实体。OpenTelemetry中的service.name、service.version和service.instance.id分别表达逻辑服务、组件版本和实例。只按订单服务名合并，会把滚动发布中的新旧实例揉在一起。
在诊断侧，我会把实例映射到故障当时的镜像摘要、配置修订和发布批次，并保留映射的有效时间。这里的重点是“故障当时”：拿当前库存给历史日志补上v42，会把版本错误写进证据。代码版本没变、配置却变了，也要能分开比较。
指标还有另一层时间。Prometheus范围选择器是向求值时刻之前取样；本例10:03的五分钟窗口覆盖09:58之后到10:03，横跨10:00发布。这个点变高，不能直接读成“10:03才开始变慢”。瞬时选择器返回的也可能是回看范围内最近样本，不一定恰好在求值时刻采集。
因此，查询记录要固定表达式、求值时间或起止时间、步长和聚合口径。Prometheus的query_range接口把start、end、step分别作为参数；复盘时应保留这些实际入参，而不是只存“最近五分钟”。版本维度若已在聚合中丢失，就回到仍保留维度的数据源，或承认当前无法比较。
一条能用于判断的引用，可以写成下面这样。它是诊断侧的记录示意，不是产品接口：
source=logs；evidence_id=E1
event_time=2026-10-10T09:57:00+08:00
observed_time=2026-10-10T10:02:00+08:00
scope=prod-a/order-api/old-7；version=v41
query_basis=事件时间；result_ref=已保存的原始结果E1
usable_for=发布前旧实例异常；not_for=v42故障期连接等待
工具适配层还要保留是否截断、采样、查询超时，以及结果覆盖哪些实例。否则“没查到连接等待”既可能是真没有，也可能只是那类记录没有采到。空结果只有连同覆盖范围才有判别意义。
让候选解释接受一次反证
对齐时间与实体，只解决了证据能否比较，还没有证明原因。下一步不是继续搜“v42连接池问题”，而是把当前解释写成能被推翻的预测。
在本例里，至少要让下面几种解释竞争，而不是把“数据库慢”和“连接池满”写成同义候选。
候选解释
应看到的现象
优先反证查询
结果如何解释
v42自身连接管理退化
同类请求在v42上等待连接更多
同窗比较v41/v42的连接等待与请求耗时
两版都慢且等待未升，削弱这一特定解释
共同依赖变慢
两版请求在同一依赖调用段耗时升高
查同窗调用追踪及依赖端处理耗时
只有客户端变慢，仍需查网络或排队
请求构成改变
总体P95上升，某些慢路由占比增大
按路由与请求类别重算延迟及流量构成
分组稳定而整体变差，优先查流量变化
新旧版本的对照还要限制在可比流量上。同集群、同路由之外，请求大小和负载也会影响结果；新版本只接大请求，就不能拿两条总量曲线判代码退化。若发布确实影响共享资源，旧版本同时变慢也不能排除发布影响。
比如，补查得到E4：prod-a中同一路由、同一请求类别，请求大小与负载可比。比较发布前(09:55,10:00]与发布后(10:00,10:03]，连接获取等待P95：v41为4→4毫秒，v42上线后为4毫秒；请求P95：v41为120→880毫秒，v42上线后为900毫秒。v42没有发布前基线；这里是按版本分组的窗口统计，不是开头那条五分钟聚合告警。
将“仅v42自身连接管理退化”记为候选H1：E4显示旧版也变慢，两版连接等待却未增加，H1由待证转为被削弱，引用E4，下一步查共同调用路径；P95仍可能遮住少量请求的严重等待，因此这里没有排除连接问题。即使随后看到依赖调用段耗时增加，也还要分辨网络、队列与重试，不能直接认定依赖服务故障。
如果反证查询未拿到完整结果，有用的返回可以是：“现有E1属于发布前v41实例，不支持v42连接池根因。故障窗口内两版连接等待数据不完整；保留该候选为待证。下一步补查同路由连接等待与调用追踪；若仍缺失，交由值班SRE继续调查。”
模型只提候选，诊断侧运行确定性规则。比如为E4登记示例规则：SRE核对请求大小、负载后置comparable=true；适配层给出coverage=complete及两版等待P95。程序见v41前后均4ms、v42为4ms，输出H1=weakened、引用E4；任一字段缺失则待证。这里用相等值演示，实际容差由团队预先定标，不能由模型临时改写。
“支持”也不等于根因已确认：本例只有定位到故障请求确实耗时于连接获取、找到对应的连接占用原因，并检查共同依赖等竞争解释后，才交SRE确认根因。
建议由调度器保存响应与步骤记录，并决定预算内补查；按查询ID记账，候选状态与完成标记一起提交。比如E4已保存而H1未更新，就重跑该步核对，不重查、不再扣查询预算；已完成则跳过。响应未保存记结果未知，补查另计预算；权限不足、预算耗尽或关键观测缺失时交值班SRE。
诊断工具保持只读；需要回滚或修改生产配置时，由事故负责人按现有授权和预案另行处置。根因还没确定时的止损，与根因已经证实，是两种不同决定。
▲ 归因路径对照：真实引用仍须对齐与反证，缺证据保留待证
用离线回放验收，而不是再看一次演示
团队接入真实告警前，可以先按症状定位改造位置。补工具不是唯一答案。
症状
优先检查的原因
判别方法与下一步
引用都真实，先后却不成立
事件时间与观测时间混用
展开两种时间，重建时间线、重做关联
同一查询复盘时变了结果
相对窗口漂移、数据后补或查询配置变化
对照实际参数与原始结果快照
新旧版本比较互相矛盾
聚合丢维度或流量不等价
补查分组数据；无法补齐就保留未知
一直支持最初猜测
查询只找支持证据
加入竞争假设及明确的反证查询
查询空结果就宣布排除
覆盖不足或工具失败被吞掉
检查采样、截断、错误状态，再决定补采或转人工
回放包要保存告警、当时的实体映射、查询入参、工具返回、证据引用及候选状态变化，并记录模型、提示与工具版本。平台团队承担这份证据契约的维护；只存最后一段回答，复现不了它用过的材料。
固定响应的回放，由SRE先给案例标注允许的证据关系、禁止的结论和停止条件，平台测试程序核对结构化输出，不让模型给自己判分。比如E4允许削弱H1，却不允许据此确认依赖故障；换一个待查候选可以接受，把E1当成v42故障期证据则失败。语义争议交SRE复核，再决定是否更新用例。重新查询后端是另一项检查，要另查迟到数据、保留期和配置变化。
回放截止点应跟着每次查询走。比如，告警10:03触发，查询10:04执行；10:03:30已可查询的记录可以进入该次响应，10:05才可查询的记录不能倒灌。采集到不等于后端已可查询，固定回放优先使用当次保存的工具响应。
比如，测试R1单独移除故障窗版本映射，补查仍失败且预算耗尽。预期：H1保持待证，返回缺失字段和失败查询，交值班SRE；若输出“v42连接池耗尽”或“已排除v42”，均判失败。验收对象是证据选择、支持关系和停止条件，不要求生成文字逐字一致；涉及模型波动时，要做多轮回放并记录差异，不能用一次正确回答代替验证。
这套做法会增加结果快照、历史映射和覆盖标记的维护成本。架构师要把可用证据、反证结果和停止理由一并交付，值班人员才能接着查。对可追踪时间和实体的系统，把这些约束前移到工具返回与诊断控制中；对观测缺口大、多个原因互相影响的故障，让它交出可复查的调查材料，把最终归因留给人。
IT架构师联盟
面向架构师与工程同行，解析AI Agent、系统架构与可靠性，讲清技术机制、工程边界和实践方法。
热门跟贴