自动操作回复与自愈闭环

能否让系统自己把 redis 重启了而不是凌晨叫醒人能但前提是「安全边界」先设计好否则自动化会放大故障。监控的价值不止于「发现异常」更在于「安全地自动处置」。但自动化处置的第一原则不是快而是不闯祸——一次错误的自动重启可能比半夜叫醒人代价更高。核心论点本篇讲 monitoring-agent 如何把「detect → 根因(RCA) → decide → act → verify」闭环跑起来且每一步都被安全边界拴住。闭环状态机detect04 巡检的异常信号 ↓ 根因 RCA多源融合详见下节 ↓ decide是否处置、处置哪种动作按 04 告警分级做决策输入 ↓ act执行动作默认只建议不写操作写操作经审批后由授权通道执行 ↓ verify回检指标是否恢复未恢复则升级人工 / 升级 P0verify是闭环的关键处置后必须回检确认恢复未恢复则升级绝不处置完就当没事。RCA 的数据源只吃探活 指标做不出真根因monitoring-agent 必须是多源融合器。按信息密度从低到高应融合 8 类信号#信号类型回答的问题1存活信号探活谁挂了2时序指标Prometheus哪里劣化、速率多快3依赖拓扑04 篇/status矩阵 dependencies依赖边已打通级联归因故障波及范围、根因候选收敛4调用链追踪SkyWalking / Langfuse trace慢请求卡在哪段、跨服务怎么传5结构化日志具体报错堆栈/错误码6LLM 业务信号基础设施问题还是模型/路由层问题7变更事件部署/配置/规则灰度/prompt 版本是否刚改了什么触发8历史模式过往同类告警归因结论是否老毛病复发性价比最高、最该先接的三类接入项价值示例拓扑 × 时序联动依赖边已进 RCA04 方案 C把「谁依赖谁」从展示变级联归因输入redis 死 → 看拓扑知 shop-agent 依赖它 → 对齐 shop-agent 错误率曲线调用链追踪把根因从服务级缩到代码段级知道 P99 飙了不知飙在 gateway 调下游还是 agent 编排——trace 告诉你变更事件现实里大量故障源于此故障前 10 分钟有配置/规则/路由变更 → 根因立刻收敛接入方式事件驱动 零持久化呼应 04 篇设计原则monitoring-agent不轮询、不存储任何监控数据平时只在收到 Alertmanager webhook 时才被激活。激活后临时查询多源做 RCA时序查时序库、trace 查调用链后端、日志查日志系统、变更查规则版本——查完即弃自身不落库。后果agent 是无状态的分析层重启无损、可水平扩展唯一真相源是各专有存储避免平行存储与双源不一致。安全边界核心论点自动化处置能不能上线全看安全边界设计。边界作用幂等同一异常重复触发不产生副作用已重启则不重复重启爆炸半径限制单次处置只动故障组件不动健康组件dry-run危险动作先模拟确认影响面再执行人在回路审批破坏性动作删数据 / 切流量走审批闸门防处置风暴一次网络抖动不触发 50 次重启分布式锁防重入审计轨迹谁、何时、为何处置可追溯含 PII 落点写入前脱敏见 06 跨平面处置总表防 LLM 滥用双层去重冷却自愈闭环的「RCA / 决策」要调大模型比 act 更频繁、更易超量必须节流入手。第一道推送层交给中枢零代码中枢机制作用Prometheus alert rulefor: 2m过滤瞬时抖动Alertmanagergroup_by: [alertname, instance]聚合同组告警Alertmanagergroup_interval: 5m控同组重复推送Alertmanagerrepeat_interval: 4h控再提醒Lokiruler / Grafana 告警汇入 Alertmanager同享去重冷却agent 收到的 webhook已是低频聚合后的告警不是每条原始抖动敲门。第二道LLM 调用层agent 补轻量守卫中枢做不到Alertmanager 只管「推不推」管不了「agent 调不调 LLM」。在/ingest/alert入口加极薄守卫指纹hash(alertname 主组件 根因候选)同根因不同告警名也能合并同指纹LLM_COOLDOWN默认 10m内不重复调 LLM直接复用上次 RCA 结论或标「已知、观察中」act 阶段仍用分布式锁防重入幂等与 LLM 调用层解耦结论90% 去重冷却由 Prometheus/Alertmanager/Loki 承担agent 只补一个指纹 冷却小守卫不过度设计自愈决策因此从每条告警烧一次 token降为同异常 10 分钟内最多一次 LLM 调用。运维 RBAC审批落地人在回路审批一句话不够落地——还得回答谁审、审什么、审多久。运维角色分三级角色权限Viewer只看监控面板与告警不可处置Operator可执行低/中风险处置清缓存、重启高风险需审批Admin可审批高风险处置故障转移、切流量高危动作需双人签收分级审批映射风险等级动作示例审批要求低风险清缓存、触发业务降级自动执行事后通知中风险重启、扩容Operator 可直接执行记录审计轨迹高风险故障转移需 Admin 审批高危删数据、改拓扑需双人签收审批超时策略凌晨无人响应时审批 5 分钟超时自动拒绝降级为告警升级通知 on-call绝不因无人审批而自动放行高风险动作——这是 05 篇核心原则不闯祸的延伸。权限模型通用性角色→权限→审批这套框架不限于运维——同一套「分级授权 审批闸门」思路适用于任何高风险操作面业务侧看资金/数据运维侧看爆炸半径/恢复难度。本篇聚焦运维场景不展开跨域治理。动作目录动作风险走审批清缓存低免审批触发业务降级低免审批按 06 跨平面处置总表重启网关 / monitoring-agent中Operator 可执行扩容副本中Operator 可执行故障转移高需 Admin 审批删数据 / 改拓扑高危双人签收动作分级可逆性是自治执行的前提「只建议不写操作」不是能力限制而是还没到可以安全放开的程度。真要放开自治执行先按可逆性给动作分级与上述风险分级正交前者看爆炸半径、后者看能否反悔类别特征能否自动执行read-only查日志、验状态无副作用随时reversible可逆重启、回滚、扩容可反悔限定条件自动预检 事后 verifyirreversible不可逆删数据、改配置无法反悔强制审批绝不自动外加三条硬约束预检执行前模拟确认影响面、verify执行后回检未恢复升级、熔断同一动作连续失败 N 次 → 停止自治、转人工。错误的自愈比半夜叫醒人更贵——这是「不闯祸」原则在允许自动执行这条线上的守门员。熔断与防处置风暴分工熔断管动作反复失败横向单动作多轮分布式锁管并发重入纵向多实例同一时刻两层叠加才完整。自研边界不变量留给薄壳深度调查交给成熟引擎市面有成熟的 AIOps/RCA 产品Aurora、IncidentFox、ninoxAI 等——服务发现、依赖图谱、告警收敛、LLM 根因分析、Slack 通知它都有甚至自动生成修复 PR。那自愈闭环为什么还自研因为通用产品替代「功能」、替代不了「不变量」不变量通用产品的默认行为冲突点只建议、不写操作Aurora 反而自动生成修复 PR与「RCA 只产建议、自愈由审批放行」直接冲突无旁路 / 唯一计量点不理解「网关是唯一 LLM 计量口」引擎自身调模型也须走网关带monitoringtag审计轨迹写操作留痕但 PII 边界需自配处置动作写入前须脱敏06 跨平面边界划分detect 巡检、级联归因的规则主线、审批闸门、审计轨迹留自研薄壳agentic 深度调查、知识图谱、RAG 复盘交给成熟引擎Aurora / IncidentFox。若外购引擎它的 LLM 调用必须走网关计量、它的自动执行必须挂在同一审批/熔断/审计之下——不变量不随组件外购而外移。与「动作分级」的关系薄壳默认「只建议不写操作」但这不妨碍在满足全部前置可逆性分级 预检 verify 熔断 审批闸门后放开 reversible 类自动执行——「只建议」是默认态不是永久态自治执行不是薄壳的能力升级而是同一套安全边界全部就位后的条件放行。核心要点自动处置的价值不在「快」在「不闯祸」——安全边界幂等 / 爆炸半径 / dry-run / 人在回路 / 防风暴 / 防 LLM 滥用 / 审计设计决定它能否上线。防 LLM 滥用用双层去重冷却推送层交给 Prometheusfor: Alertmanagergroup_by/group_interval/repeat_interval零代码LLM 调用层由 agent 指纹 LLM_COOLDOWN轻量守卫兜底——同异常 10 分钟内最多一次 LLM 调用不过度设计。自愈闭环能跑起来的前提是 RCA 多源融合把检测到异常升级为知道为什么拓扑 × 时序、调用链、变更事件是性价比最高的三类接入。无状态 事件驱动 零持久化monitoring-agent 不存储监控数据只临时查询各专有存储做分析重启无损、可水平扩展。运维 RBAC 用三级角色分级审批兜底高风险动作审批超时绝不自动放行——是不闯祸原则在权限层的延伸。动作分级看可逆性read-only 随时、可逆重启/回滚限定条件自动、不可逆删数据/改配置强制审批外加预检 / verify / 连续失败熔断。自研边界不变量只建议、无旁路、审计脱敏留给薄壳agentic 调查与自治执行可外购成熟引擎Aurora/IncidentFox但其 LLM 调用须走网关计量、执行须挂同一审批/熔断/审计之下。「只建议不写操作」是默认态不是永久态全部安全边界可逆性分级 预检 verify 熔断 审批闸门就位后可条件放行 reversible 类自动执行。