诸葛巡检到修复闭环
实践 / 建议诸葛自主巡检到修复：让每一步都有证据
从已记录的值班做法起步
bug-finder 将巡检、RCA、影响评估分为独立入口；跨域 RCA 由 fx-ops 统筹。 collector/interpreter 形成 facts，AI 提出 decision，ledger 和报告保存依据。 诊断要求机制正信号与反证，适合作为“发现后才能修复”的基础。
仓内企信值班案例记录了消息轮询、TODO 工单巡检、值班 Issue 队列三个 Autopilot， 以及消息/工单去重、人工回复检查、连续两次无效反馈转人工和用户确认完成。 这是案例记录，未在本轮复验部署。 企信监听脚本本身只负责读取与原线程回复，不能据此声称已经贯通建单、RCA 和修复。
推荐闭环的四道入口条件
| 入口 | 满足后做什么 | 不满足时怎样结束本阶段 |
|---|---|---|
| 采集可信 | 监控对象、时间窗、覆盖、部署版本和来源错误明确，开始判断异常 | 标 degraded/unknown，补采集或通知责任人 |
| 诊断足够 | 确认事实、假设、反证和影响范围能支持处理类型 | 保留假设，不把猜测写成根因 |
| 可以编码修复 | 对应仓库、允许范围、基线与可跑验收信号明确 | 配置/容量/数据走各自流程；无法验收先补信号或转人工 |
| 可以交付 MR | 固定 SHA 的必需验证与评审通过 | 失败回开发；未验证项明确披露并人工裁决 |
建议修复合同最小包含：异常 ID、原故障单、开发任务、环境/服务、问题指纹、证据窗口、 部署 revision、目标仓库、允许修改范围、验收标准、责任人、规则/能力版本和停止条件。 原始群聊只作来源，跨执行者交接使用这份合同与证据指针。
一次异常的全过程（建议演练）
诸葛发现某服务错误率升高，先核验采集覆盖和流量、近期变更、错误分布及反证。 如果只是数据源不可用，结果是巡检降级；如果是容量或配置问题，路由到相应运维流程。 确认代码缺陷且有可复现路径后，创建或关联开发子任务，交部门小队处理。
开发先构造回归用例，能复现时证明旧版失败、新版通过；难以稳定复现时注明替代证据和残余风险。 独立验证对固定制品部署测试环境，评审核查根因与修改的关联，MR 等待人工合并与生产发布。 诸葛再读取实际上线版本，观察原症状、SLI、有效流量和回归风险，满足恢复政策才关闭故障。 若先由人工回滚止血，故障可以恢复，永久修复任务继续推进。
三个“完成”分别记录
开发任务 done、生产已部署、故障已恢复是不同事实。 FSpec 的产物 done 还可能代表 FAIL 报告已交付；须另读验收 verdict。 MR 的 Closes 只关联开发子任务，故障单通过引用关联，防止合并自动宣告恢复。 Golden Path 允许披露“未验证发布”后继续评审，人工可评估接受，但不能统计为完整自主修复通过。
如何逐项替代人工例行巡检
把人工检查表转换成监控对象、计划周期、覆盖预期、时效、异常判据、查询预算、去重和接管责任。 先影子运行，对照历史故障和人工结果抽样；覆盖/新鲜度/误报漏报达标的检查项退出日常人工重复执行。 正常结果不逐项要求人审批；SRE 保留策略、SLO、重大事故指挥、例外处理与抽样复核。 没有数据、没有流量、权限不足都不能显示为“健康”。
本节依据： bug-finder 诊断架构、企信值班案例、监听边界。