Agent 自愈系统实战：从崩溃恢复到无人值守

很多团队把"高可用"理解为多机部署和负载均衡，但真正的无人值守系统还需要最后一块拼图：自愈（self-healing）。它不是玄学，而是一套工程化的闭环：检测、诊断、修复、验证、留痕。

为什么传统监控不够

Prometheus + 告警群是大多数团队的标配，但它解决的是"让人知道"，而不是"让系统恢复"。凌晨三点的告警意味着：人是系统可靠性的瓶颈。自愈系统的目标是把已知故障的处理从人身上移走，只把未知故障升级给人。

自愈闭环的五个阶段

1. 检测（Detect）：除了指标阈值，还要有心跳与"金丝雀请求"。一个服务进程活着但线程池耗尽，CPU 曲线完全正常，只有端到端探测能发现。检测的关键是缩短"故障发生→被感知"的窗口，从分钟级压到秒级。

2. 诊断（Diagnose）：自动收集上下文——最近一次部署、错误日志尾部、依赖服务状态、系统资源水位。没有诊断的自愈是瞎猜，会把偶发问题放大成雪崩。诊断输出应该是一个结构化的"嫌疑列表"，按置信度排序。

3. 修复（Repair）：从低风险到高风险分级操作：重启单个实例 → 摘除流量 → 回滚最近部署 → 扩容。每一级都要有熔断条件，比如同一节点 10 分钟内自愈超过 3 次就停止并升级人工。

4. 验证（Verify）：修复动作完成不等于故障恢复。必须有与检测阶段相同的探针重新通过，才算自愈成功。很多"重启大法"失败的根源是修复后没有验证，坏节点被重新放回流量池。

5. 留痕（Record）：每次自愈都要写结构化日志：时间、故障签名、采取的动作、结果、耗时。这是后续改进的唯一原料。没有留痕的自愈系统是黑箱，你甚至不知道它今天救了你几次。

落地时的三个务实建议

先窄后宽。 不要一上来就做通用自愈框架。选一个最高频、模式最固定的故障（比如磁盘写满、连接池耗尽），写死它的诊断和修复路径，跑通闭环后再泛化。

幂等是底线。 自愈动作可能被重复触发——网络抖动导致检测误判、上一轮修复还在进行。每个修复动作必须幂等，并且有分布式锁或租约机制防止并发操作。

给自愈系统本身做监控。 谁来监控监控者？自愈循环卡死、锁泄漏、诊断逻辑 bug，都可能让系统表面平静实则腐烂。一个最简单的办法：每天定时汇总自愈次数，突然归零和突然飙升同样可疑。

小结

自愈不是取代 SRE，而是把 SRE 从重复劳动中解放出来，去做真正需要判断力的架构工作。衡量标准很朴素：凌晨被叫醒的次数。如果你的告警群里 80% 的消息其实只需要"重启并观察"，那这正是自愈系统该吃掉的负载。从一个小闭环开始，让它慢慢学会更多故障的处理套路——无人值守的未来，是这样一步步练出来的。