接口响应时间突然上升，最近刚好有一次发布。把两件事放在一起，很容易得出“新版本导致故障”的结论。但也可能是数据库连接耗尽、下游服务变慢，或流量组成发生变化。值班工程师需要的是能缩小范围的证据，而不是一句听起来合理的根因。
OpenSRE 提供连接观测与基础设施工具的 Agent 框架，用来调查生产问题。按 2026 年 9 月 23 日官方仓库，它仍标注 public alpha，接口与集成处于演进中。本文用一个假设事故讨论评估方法，没有连接生产观测系统，也没有执行修复。项目仓库
先固定服务、时间和影响范围
“网站很慢”不足以开始有效调查。可以先记录受影响服务、开始时间、时区、请求路径和用户症状，再说明最近有哪些已知变化。
假设结算接口从北京时间十点开始变慢，健康检查仍正常。先比较相同路径在故障前后的延迟、错误率和请求量，不要拿全站平均值替代这个接口的情况。
还要区分指标时间与事件时间。有些日志延迟写入，告警也可能在持续异常一段时间后触发。时间线里应保留这些差异，避免把告警发送时刻误认为故障开始时刻。
给 Agent 的第一轮任务可以限定为只读调查：确认变化、收集证据、列出竞争解释和下一步检查。暂时不需要让它重启服务或调整数据库。
接一个真正需要的观测源
OpenSRE 的集成目录覆盖多类系统，但数量不能说明你自己的连接已经可用。先接指标或日志中最熟悉的一项，验证能否查到指定服务与时间段。集成说明
连接检查通过以后，再比较一次人工查询与工具返回：标签是否一致，时区是否一致，是否只返回了部分结果，查询权限是否漏掉某些实例。
如果日志工具返回空列表，应区分没有匹配记录、权限不足、查询条件错误和服务不可用。Agent 不能把所有空结果都解释成“没有异常”。
数据库、云资源和集群最好使用适合调查的账号。读取状态所需权限与修改资源所需权限分别配置，让第一轮评估的结果只影响调查报告。
先排除几个不同方向的解释
对接口变慢，可以先比较应用处理时间与下游耗时。如果数据库调用占比增加，再查连接数、等待与慢查询；如果外部支付服务耗时增加，则转向那条依赖。
发布记录是重要线索，但不能因为时间接近就认定因果。还要看新旧实例是否都有异常、受影响路径是否与本次修改相关，以及没有更新的服务是否也出现相同变化。
假设新版本和旧版本都变慢，而共同下游同时出现等待，这会削弱“只由新代码引起”的解释。报告应保留这样的反证，不要只收集支持最初猜测的截图。
每次追加工具查询前，说明它想区分哪两个可能原因。连续重复相同查询却没有新信息时，应调整方向或报告缺口，而不是不断增加日志数量。
让报告中的判断能回到查询结果
一份调查报告可以先写已经观察到的现象，再写当前假设与置信限制。每条重要判断附上对应时间范围、指标或日志位置，以及查询返回的必要摘要。
例如“数据库等待增加”需要说明观察对象和时间，不能只贴一段含有 timeout 的日志。日志可能来自某个重试请求，未必代表整个服务。
对于根因尚未确认的情况，给出下一项能区分解释的检查。比如需要查看连接池配置变化，或需要由负责人确认下游限流策略。这样的报告仍然有用，不必为了交付完整而把假设改成确定结论。
来源也要能复现。保存查询条件、环境与必要标识，避免几小时以后链接打开的是当前指标，已经看不到事故窗口。
当前启动方式与“本地运行”要分开理解
本次查看的默认分支 README 描述了首次启动登录与账户验证，并说明交互入口会启用托管模型。不能把安装在自己机器上理解为整个流程自动离线或完全不需要账号。
实际采用时固定一个发布版本，阅读对应启动说明，再检查模型、凭据和数据流向。默认分支与已安装版本可能不同，旧教程里的命令也未必仍是推荐入口。发布记录
若使用外部模型，提交给模型的告警和工具结果可能离开本机。先确定哪些字段需要遮蔽、哪些日志不应发送，以及调查记录如何保存。关闭遥测与阻止模型请求外发，是两件不同的事。
当前集成说明还把组织级托管连接器标为 coming soon。评估本地 CLI 时，不要把尚未确认可用的团队托管能力算进采购或上线计划。
用隔离环境回放一次已知故障
试点可以从已经复盘过的事故或合成场景开始。准备告警、指标、部署记录和一两个干扰项，先写下人工确认的事实，再让 Agent 调查。
如果需要真实服务来产生测试信号，使用隔离环境，避免拿线上用户流量制造故障。环境里可以部署一个小服务和它的依赖，明确哪些操作会增加延迟，哪些只是无关日志。
测试主机与生产资源使用不同账号和数据。试验结束后检查创建的资源和费用，保留复现说明，下一次升级时才能用相同条件比较。
评分不要只看最终根因短语是否命中。还要检查是否查错环境、是否忽略反证、是否把失败工具调用当作成功，以及报告是否包含了足够的定位线索。
把诊断建议与执行变更分开验收
Agent 建议重启进程，可能是因为它猜测资源泄漏，也可能只是常见回答。执行前应说明预期作用、影响范围与验证方式。
如果决定回滚发布，先确认回滚对象、数据兼容和当前流量状态。代码能够退回旧版本，不代表数据库结构或已经产生的数据也能直接恢复。
变更完成后检查原来受影响的指标和用户路径。看到命令退出成功，只说明命令执行结果，不能说明事故已经解决。恢复观察也需要持续一段合适窗口，避免把短暂下降当作稳定恢复。
在试点阶段，可以让 Agent 只生成待执行步骤，由值班人员判断。等报告质量和错误处理经过多次回放，再考虑为有限动作增加自动执行能力。
记录调查成本与失败方式
每次调查保存开始与结束时间、工具调用次数、模型用量和人工补查内容。重复调用占比高时，先看是否缺少明确计划或查询结果太宽，不必马上更换更大的模型。
对报告中的误判单独分类。服务映射错误、时间窗口错位、数据缺失与推理错误，对应的修复不同。只有看到具体样本，才能决定是改集成、补运行手册，还是调整任务说明。
还要评估值班人员阅读报告所需时间。十几页没有重点的日志摘录，可能比几条带证据的判断更难使用。保留完整调查记录的同时，给交接者一份简短、可追查的结论。
事故结束后还可以把当时可见的证据与事后补充的证据分开。回放评估若提前提供了事后才知道的根因，会让结果显得过于容易。保留时间顺序，让工具在相同信息条件下调查，才能判断它当时是否真的有机会找到问题。
什么时候值得扩大使用范围
若它能在熟悉的事故样本中找到相关证据，明确未知，并减少重复查询工作，可以选择一个服务进行只读影子运行。比较它与人工调查的差异，而不是直接替代值班责任。
如果团队连服务标签、部署记录和日志时间都无法对应，先改善这些基础信息。Agent 能查询更多系统，也无法凭空补出不存在的证据。
扩大到第二个服务前，保留上一阶段的错误样本与配置版本。每次升级重新回放，确认原来能处理的问题没有退步。OpenSRE 是否适合你的团队，最终体现在它能否让故障调查更容易复核和交接。