别让 AIOps 变成“闭眼修系统”——说说可解释 AIOps 如何防止二次事故

最近我听到一个很典型的吐槽：

“我们上了 AIOps 之后，系统是能自动修，但修完一次，炸两次。”

说实话，这事一点都不意外。现在不少企业玩 AIOps 都喜欢讲自动闭环：

• 自动发现问题
• 自动定位
• 自动修复
• 自动回归

听着爽得很，但缺了一个最核心的东西：可解释性。

说白了，AIOps 要做的不是“黑盒拍板”，而是“让机器告诉你为啥这么搞”。
否则一次修复，一套系统跑偏，你就是把运维从人肉地狱里拽出来又踹回去。

今天这篇，我就想接地气地聊聊：为什么 AIOps 必须可解释，怎么做到可解释，以及怎么避免黑盒修复带来的二次事故。

不学术，不装腔，都是运维圈天天爆的坑。

🥇“黑盒修复”为啥危险？

一句话总结：

没有解释的 AIOps 修复，就是“经验算法 + 误杀风险”。

举几个我在行业里见到的真实案例：

❌ Redis QPS 高 → 程序自动重启

结果重启的是缓存集群的核心节点，业务雪崩。

❌ CPU 90% → 自动 Kill Top 进程

结果干掉的是流控线程，濒死业务更撑不住了。

❌ 预测磁盘要满 → 自动扩容

结果扩容错卷组，全站 IO 抖动、写入异常。

这些事故的神逻辑就是：

“模型说它有问题，我干它。”

这太危险了，因为根本没有向工程师说明：

• 你判断问题的指标是什么？
• 你为什么认为风险高？
• 你确定问题在这里？你风险评估了吗？

AI 不是神，不解释的自动化就是“带电作业”。

🥈真实世界的 AIOps 是不确定的

我们要承认一个前提：

运维问题不是“分类问题”，而是“多变量叠加”。

同一个 CPU 90%，

• 有时说明业务忙
• 有时说明死循环
• 有时说明 GC 在打分代
• 有时说明 I/O 阻塞假忙

你让黑盒做闭环，不就是把复杂问题“数字化拍脑袋”吗？

🥉“可解释 AIOps”是什么？

一句话——AI 不是替你决策，而是给你透明证据、可追溯逻辑、风险说明。

可解释能力至少包括 4 个模块：

✔ 1. 特征溯源：我为什么这么判？

比如诊断慢 SQL，不是说“SQL 慢了”，而是列出证据链：

• 扫描行数
• 计划执行
• 慢字段
• IO 等待
• 索引调用情况

✔ 2. 风险说明：不修多糟、修了多险？

“修复风险评分：0.85，可能影响 3 个依赖业务”

✔ 3. 决策备选方案

不是一句：“I’ll fix it for you”
而是：

• Option A：重启服务（风险 65%）
• Option B：刷新配置（风险 15%）
• Option C：限流观察（风险 3%）

✔ 4. 行为回放与审计

不支持回放的 AIOps 修复都是耍流氓。

你必须看见：

• 修完前是什么参数
• 修完后是什么参数
• 误判概率多少
• 历史类似 case 如何

🛠 AIOps 怎么做“可解释诊断”？

举个简单代码例子，用 Python 模拟一个可解释修复建议系统：

def diagnose(cpu, gc_time, thread_block, risk_model):
    reasons = []
    if cpu > 85:
        reasons.append("CPU 使用率超过 85%")
    if gc_time > 30:
        reasons.append("GC 时间占比超过 30%")
    if thread_block > 100:
        reasons.append("阻塞线程数超过 100")

    risk = risk_model.predict([[cpu, gc_time, thread_block]])[0]

    actions = [
        ("重启服务", 0.7),
        ("触发 GC 优化", 0.4),
        ("限流观察", 0.15)
    ]

    return {
        "reason": reasons,
        "risk": risk,
        "actions": sorted(actions, key=lambda x: x[1])
    }


print(diagnose(90, 40, 120, risk_model))

这个代码展示的不是“最牛算法”，而是一种思想：

• 模型告诉你凭啥判断
• 明确风险值
• 提供多个修复策略排序

这就是“可解释”。

🧨怎么避免黑盒造成二次事故？

我要总结三个“硬规矩”：

🚫 规则 1：不能直接修

自动修复 = 先模拟。

模拟成功才允许执行。

比如你的限流策略：

if simulate_effect(action) > threshold:
    apply(action)

模拟机制，能救命。

🚫 规则 2：不能跨层操作

AI 不准越权：

• POD 自己弄自己
• 节点不要乱删
• 集群配置必须走审批

否则你就是让一个拿菜刀的人操控核弹。

🚫 规则 3：每次自动化必须留审计

像下面这样记录：

{
  "original": "replica=3",
  "changed": "replica=5",
  "reason": "I/O queued",
  "risk": 0.42
}

没审计的自动化就是乱拳打人。

🧩再高冷的算法，都要“人类语言”

我们必须把模型输出变成人的话：

• “我认为服务有内存泄露”
• “风险高，因为过去 5 次类似 case 都导致重启”
• “修复建议风险系数 80%”
• “依赖 3 个下游服务可能受影响”

运维不是数学考试，而是工程沟通。

🔥一个反思：AIOps 的价值不是省人，是省命

有的人把 AIOps 视为“裁掉运维人力的武器”。
我说句不好听的——这种企业最后都会反噬。

AIOps 应该做的是：

• 帮助定位
• 帮助解释
• 帮助决策
• 帮助执行

而不是“替人拍脑袋”。

🏁结语：AIOps 不是上帝，它需要透明化

我希望未来的 AIOps 长成这样：

像老司机一样解释风险，而不是像赌徒一样压注命运。