SRE故障响应中的AI自动化边界

故障响应中一个反复出现的矛盾是：AI能力越强，团队越容易把“自动化”与“自主决策”混为一谈。缩短平均修复时间的目标本身没有问题，但如果不区分信息处理与最终判断，自动化反而可能成为放大误判的通道。

告警汇总与上下文分析是AI当前最成熟的落地场景。系统可以自动合并时间窗口内的重复告警，提取错误信息、受影响服务与近期变更，再按时间线生成一份故障摘要。这确实能减少值班人员翻看多个来源的重复劳动。但“把告警归为同一事件”不等于“确认了故障原因”。AI可能把相关但独立的异常合并，也可能遗漏没有触发监控的影响，例如数据延迟或后台任务堆积。因此，自动汇总结果至少要保留原始告警、时间范围与数据来源，不能只输出一个没有依据的结论。人工确认的判据应当比较明确：影响范围是否与实际业务表现一致，告警之间是否存在共同时间线，是否有关键数据缺失。只要这些问题无法回答，AI生成的摘要就只能作为调查入口。

代码分析与定位环节的自动化边界，取决于上下文是否完整。如果日志与代码版本能够对应，服务依赖关系清晰，且分析结果可以由测试复现，AI适合自动生成候选定位报告。相反，如果存在多个同时发布的变更、跨服务调用不可见或错误信息不完整，就不应把模型的高置信度当成事实。人工需要重点确认三个问题：疑似代码是否运行在受影响路径上，故障是否能在可控环境中复现，分析结论是否解释了全部关键现象。若只能解释其中一部分，就应保留多个假设，而不是强行选择一个根因。

修复方案的生成阶段，自动化应严格限定在候选补丁的生成、格式检查与已有测试的执行范围内。对于影响范围有限、行为规范清楚、测试覆盖充分的缺陷，AI生成的补丁可以进入隔离分支等待验证。但自动化不应直接覆盖生产分支，尤其不应在缺乏测试、涉及数据迁移、权限控制或公共接口变更时自行执行。人工确认至少需要核实：修复是否针对根因，正常路径与异常路径是否都得到考虑，是否改变了接口契约或数据格式，测试是否覆盖故障场景且能证明问题消失，修复失败时是否有明确的回滚方案。没有可验证的测试时，最稳妥的做法不是让AI补写一套“看起来合理”的测试，而是先由工程师定义预期行为，再让AI协助补充测试样例。

整条链路的核心原则可以概括为：AI自动推进信息处理与候选生成，但每一步的证据完整性、影响可控性、验证可重复性与回滚可执行性，决定了能否进入下一阶段。告警汇总可以自动完成，但要保留证据；代码分析可以自动缩小范围，但要允许人工否定；修复方案可以自动生成，但必须通过测试；合并请求可以自动起草，但合并与发布仍由责任人批准。这样设计，AI带来的不是一条无人监管的自动修复通道，而是一套减少人工检索、保留人工判断的故障响应流程。