Mend 自动修复

要解决什么问题

线上事件里，大量重复性恢复动作——重启 Pod、回滚配置、拉断路器、暂停金丝雀晋升——往往已经写在 runbook 里，但仍依赖值班同学按步骤手工点。手工执行慢、易跳步，失败重试还可能留下重复资源或孤立规则。Mend 面向已诊断或已告警的场景：在 Triage 给出手册、或 Beacon 触发 SLO/错误预算告警时，把「已知模式」的修复做成幂等、可审计、可回滚的自动化执行，而不是再做根因分析或改业务代码。

如何工作

整体流程是 分类 → 匹配 → 执行 → 验证 → 报告：

• 安全等级（T1–T4）：任何操作前必须先分级；T4 禁止自动执行，T3 需批准，高置信度下 T1/T2 才按门禁放行。
• 模式匹配：交接需模式置信度 ≥ 50% 才行动；≥ 90% 才进入自动修复路径，并受等级门禁约束。
• 配方（子命令）：默认 runbook 按手册逐步执行；另有 diagnose、rollback、verify，以及 scale、circuit、canary 等运行时场景。
• 护栏：同一模式同一事件最多 3 次修复尝试（指数退避）；执行前校验 runbook 新鲜度（如超 90 天未审查需警告）；修复后做分阶段验证（健康 → 冒烟 → SLO → 恢复确认），指标恶化可触发自动回滚。
• 协作：消费 Triage / Beacon / Nexus 的上下文，可向 Radar 要验证、向 Gear 要基础设施回滚、向 Builder 升级未知或需改代码的问题。

适用边界

• 交给 Triage：根因分析、未知故障、模式未匹配。
• 交给 Builder：应用逻辑与代码修复；Mend 只改运行时与操作状态。
• 交给 Gear / Beacon / Siege：基础设施配置与扩缩容规划、监控与 SLO 定义、混沌与弹性测试 respectively。
• 低流量服务上，多窗口错误预算燃烧率告警可能不可靠，需回退到计数或事件型告警；模式编录仍建议人工审核，避免 LLM 在专有系统上的误判。