我不推荐任何一款 AIOps 工具(除非你先回答这 7 个问题)

上周有人问我：AIOps 工具到底该选哪家？

我说，这个问题我没法回答，因为它问错了。

过去两年我看过太多选型失败的案例，问题几乎从来不是"工具不行"：

有人花了几十万买了商用平台，结果团队每天只有 30 条告警，降噪功能压根用不上；

有人兴致勃勃部署了开源方案，两个月后因为没人维护，变成了服务器上一堆僵尸容器；

还有人被"AI 根因分析"四个字打动，上线之后才发现，模型给出的建议要人工验证两个小时，比原来还慢。

所以这篇不推荐任何工具。我只给你 7 个问题。

这 7 个问题答完，你自己就知道该买什么、该不该买。如果答不上来，那说明现在还不是买工具的时候。

问题一：你每天收到多少条告警？其中真正需要人处理的，有几条？

注意，我问的是两个数字，不是一个。

这两个数字的比值，直接决定你要不要买降噪工具——而这恰恰是绝大多数团队买错的地方。

判断逻辑：

• 每天不到 50 条，其中真需要处理的超过 5 条 → 你的问题不是噪音，是定位效率。买降噪等于白花钱。
• 每天超过 500 条，其中真需要处理的不超过 10 条 → 降噪是刚需，而且是整个 AIOps 里 ROI 最高的一件事。
• 介于两者之间 → 先别买工具。回去把阈值、抑制规则、分组规则理一遍，你会发现能砍掉一半以上，成本为零。

我见过一个团队，买了某商用平台的告警降噪模块，一年订阅费六位数。上线三个月后做复盘，发现他们每天平均告警 30 条——这个模块一次都没真正发挥过作用。

而他们真正的痛点，是每次故障都要花 40 分钟去翻三个不同的监控系统找关联指标。这个问题，降噪工具解决不了。

先量清楚自己的数据，再谈工具。

问题二：你的监控数据，能出你的内网吗？

这一条直接砍掉一半的候选方案，而且几乎没有折中余地。

判断逻辑：

• 金融、央国企、政务、医疗
   → 基本一刀切，只能私有化部署。海外 SaaS 直接出局，这不是技术问题，是合规问题。
• 互联网、民营 SaaS 企业
   → 数据可出网，商用方案的可选范围大很多。
• 混合云
   → 最麻烦的一种，需要按数据分级分别处理，同一家公司可能两套方案并存。

这里有个提醒：这条要问法务和合规，不要让技术团队自己拍板。

我见过不止一个团队，PoC 都做完了、老板都点头了，最后卡在数据出口审批上，三个月的工作直接归零。这种事一次就够让一个运维负责人在公司里失去信任。

问题三：故障定位的时间，主要花在"找信息"还是"下判断"？

这是全文最核心的一个区分，也是大多数人没想清楚的地方。

把一次故障的处理过程拆开，你会发现时间花在两件完全不同的事上：

找信息——翻日志、查指标、翻历史工单、问同事当时改了什么。

下判断——这个现象说明什么、要不要现在改、改了会不会更糟、要不要拉上业务一起确认。

判断逻辑：

• 如果 70% 的时间花在找信息 → AI 价值极高。它本质是检索和汇总的活，大模型天生擅长。
• 如果 70% 的时间花在下判断 → AI 价值有限。它拿不到你的业务上下文，也给不了政治判断。

结论：如果你的团队整天在翻日志找关联指标，那 AI 富化 + 日志聚类能立刻见效；如果你的团队整天在开会讨论要不要回滚，那你需要的是更完整的可观测性数据，不是 AI。

买工具之前，先花一周时间记录一下：你们上一次故障，时间具体花在哪了。

问题四：谁来做集成？团队里有专职的平台组吗？

这一条决定开源方案对你是资产，还是负债。

判断逻辑：

• 有专职平台/工具组（≥2 人，且不被日常值班占满）
   → 开源可控，长期成本最低。
• 没有专职人力，靠值班的人兼职维护
   → 开源方案大概率烂尾。直接选商用开箱即用，把时间留给业务。
• 有一点点人力但没经验
   → 先买商用跑通流程，把"这件事值不值得做"验证清楚，再考虑替换。

这个判断很残酷，但它决定了你半年后的处境。

部署开源 AIOps 平台的典型剧本是这样的：第一周很热闹，全组一起搭；第二周开始接数据源，发现文档写得含糊；第三周没人管了；一年后那台服务器没人敢动，因为不知道上面跑了什么。

开源省的是许可证费，花的是人力。如果人力本来就不够，开源就是负债。

问题五：出了故障，AI 给的建议错了一次，谁负责？

这一条决定你能把自动化做到哪一层。

判断逻辑：

• 没有"可逆"机制
  （一键回滚、操作审计、灰度执行）→ AI 只能停在"给建议"这一层，不能自动执行。这不是保守，这是底线。
• 有可逆机制 + 有值班人确认
   → 可以做到"AI 执行、人确认"，效率提升明显。
• 完全无人值守的自动修复
   → 只有极少数场景能接受，比如扩容、重启无状态实例。有状态的东西不要碰。

这也是为什么我一直建议：如果要让 AI 动手，先给它套一层带审计和 Undo 的安全护栏。

比如把 Prometheus、Grafana、Loki 这些传统监控组件封装成带权限校验和操作记录的接口，让 Agent 只能"读"、写操作必须留痕且可回滚。这类工具解决的不是能力问题，是敢不敢用的问题。

一个不能回滚的自动化，不是自动化，是定时炸弹。

问题六：你的预算是买断还是订阅？三年后这笔钱还在吗？

这一条决定 TCO 结构，也是选型时最容易算错的一笔账。

判断逻辑：

• 订阅制看起来便宜，但三年总价常常超过买断。
   很多团队是在第二年续费时才发现这件事的——那时候已经迁不动了。
• 开源不是免费，隐性成本在人力
  ：部署、调优、版本升级、故障处理，全都要折算成钱。
• 按告警量计费的模式要特别小心。
   降噪做得越好可能越省钱，但也可能因为接入的监控源变多，费用在某个季度突然暴涨。

算 TCO 的时候，把人力成本按市场价折进去，不要按"反正人闲着也是闲着"算——这个算法骗的是自己，最后账单出来的时候还是得认。

一个参考的算法：三年 TCO = 许可证费 + 集成人力 + 运维人力 + 迁移成本 + 机会成本。最后两项几乎所有人都会漏掉。

问题七：三个月后，你要拿什么向老板汇报？

这一条决定你的 PoC 要采集什么指标。这是最多人栽跟头的一问。

判断逻辑：

• 如果一开始没想清楚验收指标，PoC 做完了也证明不了价值，最后只能尴尬续费，或者被砍掉。
• 可用的指标其实只有几类：MTTR 变化、告警量变化、值班被叫次数、单次故障处理人时。
• 建议在 PoC 开始前就把基线数据测出来，否则事后没有对比基准，说什么都是"我感觉挺好用"。

我见过一个团队，PoC 做了三个月，全组反馈都不错，但拿不出一个数字。评审会上老板问了一句"所以到底省了多少"，项目当场被砍。

"挺好用"不是指标，"MTTR 从 47 分钟降到 22 分钟"才是。

7 个问题的答案，指向什么

把这 7 个问题的答案连起来，技术路线基本就定了：

• Q1 告警量高 + Q3 时间主要花在"找信息"
   → 优先做告警降噪 + AI 富化，这是投入产出比最高的一步
• Q2 数据不能出网 + Q4 有平台组
   → 开源底座 + 自研 Agent，长期成本最低，但要接受前期投入
• Q2 数据不能出网 + Q4 没有专职人力
   → 国产一体化平台，别碰自建
• Q2 数据能出网 + 预算充足
   → 商用 SaaS 直接上，把时间花在业务上
• Q7 答不上来
   → 先别买。花两周做 PoC，把基线数据测出来再说

注意，我给的是映射关系，不是厂商名单。

因为同一套答案，在不同的团队规模和预算下，最优解可能完全不同。一个 5 人团队和一个 200 人的运维中心，即使 7 个问题答案一模一样，选出来的东西也应该是两回事。

这也正是我不做工具盘点的原因：盘点给出的是结论，而选型需要的是框架。结论会过期，框架不会。

下一篇

下一篇我写一个最便宜的起点：30 行 Python + DeepSeek，把告警变成一份诊断报告。

不用买任何东西，一个下午能跑通。这是目前投入产出比最高的技术方案——先用起来，再决定要不要花钱。

相关阅读

• 03 · 30 行 Python + DeepSeek，把告警变成一份诊断报告
• 10 · AIOps 选型的 7 个问题：一份可以直接发给同事填的评估框架

*公众号回复「7问」，拿这份可以直接发给同事填的选型评估表。*