三层骨架与 LLM 治理：生产级 AIOps 平台的落地账本与踩坑实录

本文要介绍的，是我们团队自研的一套 AIOps 平台。

先把定位说清楚，这是一套大模型驱动的智能运维平台，做的事可以用一句话概括，就是用 AI 把运维里最容易断掉的三段接起来，让系统既看得见，也动得了。这三段是感知、认知、行动。

其中感知是从海量遥测里认出真正值得关注的信号。认知是把信号组织成可解释、能决策的判断。而行动呢是在受控范围内把事真正做对。三段之外，还横着一层治理，管权限、审计、可观测和成本。这套骨架不是我们发明的，是过去三年在一次次故障里磨出来的。

它也不是一页概念图，不是演示环境里跑通就收工的东西。过去一段时间，它一直在我们的生产环境里跑着，值班的同学每天用它处理真实的故障，它也替我们扛过几次大事故。下面这条事故信息是我们内部复盘表上的一行记录，数字很小，却是我这几年最有成就感的一行:

四分十二秒，人工只点两次。放到之前同类事故从发现到恢复平均要花30多分钟，运气不好碰上周末值班人手不足，能拖到一小时开外。这中间省下的时间到底是怎么来的，这就是我在文章中要讲的事了，可是要把它说清楚，得先看这套平台最核心的几处设计，我挑几处自己认为最值得讲的，先摊开说。

具体到模块，感知层管遥测、拓扑、告警、事件流，而认知层管定级、根因、影响面、编排，行动层管工作流、脚本、工单、自愈。三层之上横切着 AI 治理层。我们给自己定了一条铁律，就是每一层既向上输出结构化结果，又向治理层回写可审计记录。翻译成人话就是，系统里发生的每一次判断和每一个动作，都留得下痕迹。这条铁律看着平淡，后来在安全审计和事故复盘上发挥了不少作用。

再说大模型在里面到底是干什么的。很多人问大模型进运维是不是噱头，我的答案是看它有没有落在具体的位置上，在我们的架构里，它干三件事:

1、语义压缩，把几百 MB 的碎片化指标压成一段人能读的根因叙述

2、知识调用，把 SOP、Runbook、历史工单召回成上下文，让技能不用从零冷启动

3、决策翻译，把判断翻译成可执行的动作。

这三件事，恰好对应我后面要讲的证据链、技能化、闸门三条主线。

还有数据怎么进来，平台接的东西比想象中的要复杂，指标侧是 Prometheus 加 Grafana，日志侧走ELK，链路侧是 SkyWalking、Zabbix 和几个自研探针负责专有监控，再往外，CMDB、发布系统、工单系统也都要接进来，因为根因分析离了变更记录就只能瞎猜。数据进来之后走一条完整的生命周期，统一采集，归一化，热温冷分层存储，最后到看板和告警消费。自研平台最贵的地方从来不是模型，是这一层"接数据"的管道，它占了整个项目一半以上的工程量，却最不容易被看见。

系统功能模块主要有以下这些：

在我看来最容易被低估的是数据治理和报表与分析，一个在最前面干脏活累活，一个在最后面吃力不讨好。这两块在立项的时候都被人质疑过"有必要吗"，因为大家总盯着AI根因分析几个字，没人愿意为把名字对齐买单。这个认知，是我们踩了一堆坑才换来的。

这几年不少朋友问我同一个问题，大模型到底怎么才能真正用到运维里。与其一个个回答，不如写成一篇文章。所以下面的内容，既讲我们做对了什么，也讲我们踩了哪些坑。 47 条告警教会我的事

最早的起点，是一个凌晨。

凌晨一点四十，我的手机、手表、笔记本同时震了起来。订单服务 P99 延迟从 120 毫秒飙到 800 毫秒，五秒之内，47 条推送排着队涌进来。Prometheus 来一条，Zabbix 来一条，SkyWalking 来一条，三个自研探针各来一打。我趴在床上把推送挨个划开，越划越糊涂，每一条单看都"正确"，合在一起就是一场灾难，你根本分不清哪条是根因、哪条是被殃及的池鱼。

后来我复盘那次故障，发现一个更扎心的事实，47 条告警里真正指向根因的只有1条，其余46条全是同一根因在不同监控视角下的"回声"。也就是说，那天夜里真正有价值的信号密度是 1/47，大约 2%。剩下的 98%是噪声，是给值班人添乱的。

这个数字后来变成了我们团队反复念叨的一个标尺，一个值班同学半夜愿意点开告警的前提，是他相信推送来的东西值得点开。信任一旦被噪声磨没，告警系统就死了，哪怕它的每一条推送在技术上都是对的。

有段时间我们做了很多徒劳的挣扎，调阈值，告警变少但漏报了，加静默期，真正的故障被压住了，上聚合规则，规则越写越多，没人敢删。后来我们自己写的去重规则模块帮我们少走了半步弯路，它把指纹高度相似的重复告警先做了一层收敛，至少让数量先降下来。但也就半步。最后我们认清了一件事，靠人肉维护规则去对抗指数级增长的监控数据，是一场必输的战争。需要换的不是规则，是范式。 把告警翻译成"人话"，数据底座与语义层

换范式的第一步，出乎意料地朴素，把数据搞干净。

很多 AIOps 项目死在起跑线上，不是算法不行，是数据稀烂。Prometheus 里服务叫 aiops-api，日志里叫 aiopsmicroservice，Zabbix 里叫 srv-api-01，CMDB里干脆是另一套资产编号。你让任何算法在三个名字指向同一个服务的数据上做关联分析，它只能输出玄学。

我跟领导申请一个季度做这件事的时候，他第一反应是皱眉："一个季度，就为了把名字对齐？" 我没跟他讲大道理，翻出了上一年所有 P1 故障的复盘记录给他看。里面出现频率最高的一句根因描述，不是缓存击穿，也不是连接打满，而是四个字，信息不对齐。监控说的是 A，值班的人理解成 B，等所有人凑齐把口径对上，黄金处置时间已经没了。领导看完没再说话，批了。

我们花了差不多一个季度，只干一件事，那就是建语义层。

图 1:映射规则引擎。"匹配条件 → 映射目标"的规则列表，按优先级依次生效。

做法上没有黑魔法，就是一套可热更、可版本化、可回滚的映射规则引擎。原始告警里只有 ip=10.0.1.5, cpu=95%，经过规则链翻译，变成运维人能直接行动的信息:

这里有个容易低估的细节，规则必须像代码一样被管理。我们的每条映射规则都有版本号、修改人、生效时间，改错了可以一键回滚到任意历史版本。早期我们曾经有人改错一条正则，导致当晚 300 多条告警归错了团队，半夜全群道歉。从那以后，规则变更走评审、上线走灰度，成了铁律。

灰度怎么做？新规则先只对5%的告警生效，跑满一个班次，机器比对新旧规则的归类差异，差异清单人工过一遍，没问题再放全量。听着笨，但规则引擎这种东西，错的代价是全局性的，笨办法就是最快的办法。这个道理跟发代码一模一样，只是很多团队做数据的时候，忘了数据也需要发布纪律。

顺带插一句，写规则之前还有个数据探查模块，它一开始根本不在我们的功能规划里，是团队里一个同学自己攒的小工具，把原始告警的字段分布、取值样例、异常比例摊开给你看，让你在动笔写规则之前先摸清楚数据长什么样。他当初提这个需求的时候还被我否过一次，理由是锦上添花。后来发现，没有它，写规则基本靠猜字段名。我后来专门找他把这个工具补进来，紧挨着它的还有一块信息提取，负责从大段自由文本的告警描述里抠出结构化字段，比如从"某机房某机架发生链路抖动"这种句子里把机房、机架提出来。这类字段光靠正则很难穷尽，得靠模型兜底。

语义层建好之后，第二步才轮到 AI 登场。我们把告警的名称、描述、来源、级别丢给大模型做语义聚类，再叠加时间窗口的相关性。效果在界面上是一目了然的，同一天的 706 条告警，被聚成 8 个根因簇，每个簇给出置信度和推断依据。

图 2:告警工作台。左侧是多源告警流，上方是"当天告警 AI 根因分析"聚类卡片:706 条告警被归入 8 个根因簇。

回到开头的故障，同样一场数据库连接池事故，现在的画面是，告警事件流把那晚同一根因的告警聚合成 1 个事件，自动定级 P1，自动指派到值班人。值班同学半夜收到的不再是 47 条推送，而是 1 条带着完整上下文的事件通知。

图 3:AI 助手对话式排障。针对 order-svc 延迟突增，助手从三个数据源取了 4.2 万条事件，直接给出根因和置信度。

噪声治理这一项，那晚 47 条告警里的有效信号密度只有 2%;如今同类场景，告警压缩率做到了 94.2%。这不是算法的胜利，是"数据治理 + 语义聚类"组合拳的胜利。 证据链:让 AI 学会讲道理

告警聚合成事件只是及格线，真正让一线同事开始信任平台的，是根因分析，以及它背后的证据链。

这里必须先泼一盆冷水。传统 AIOps 最大的信任障碍，是算法黑盒。模型说根因是数据库主从切换，你问它为什么，它答不上来。一个说不清依据的AI判断，哪怕准确率 95%，一线也不敢用。因为运维决策的容错率是零，回滚错一个版本就是事故。

我们的解法，是把根因分析的输出从一个结论改造成一条可回溯的证据链。

图 4:事件详情页。顶部是 AI 诊断摘要卡，含根因置信度、关联告警数与优先级。

具体讲，根因引擎把四类信号串成一条因果链，变更记录、指标异常、日志报错、拓扑扰动。大模型对这条链做语义压缩，输出候选根因和置信度。关键在于，链上的每一条证据都可以点击回溯到原始数据，点进去就是那条变更工单、那段指标曲线、那行日志。

值班同学看到这条推送，做的不是信任 AI，而是验证 AI。那么点开变更记录，确实有这次发布。点开指标曲线，确实在那个时间点打满。点开日志，确实是连接超时。三秒钟完成三重确认，然后按下回滚键。

这个设计里藏着一个我们踩坑得来的认知，AI 的价值不在于替人做判断，而在于把人做判断的成本从二十分钟压到三秒钟。证据链是给人看的，不是给模型看的。后来我们把这个思路推广到了所有 AI 输出上，包括事件定级(为什么定 P1 不定 P2)、影响面分析(为什么说影响了这八千多个用户)、复盘报告，全部要求给出可点击的依据。

事件定级这件事，后来还多了一个参考维度SLO。我们给每个核心服务定义了可用性和延迟目标，事件定级的时候会把 SLI 的偏差也算进去。所以有时候一条技术指标看着不严重的告警，会因为已经吃掉当天大半的错误预算而被顶成 P1。这个规则一开始有争议，业务方嫌它太敏感，直到有一次它提前拦下了一个会违反月度 SLO 的隐患，争议才平息下去。

当然，证据链也不是一上来就这么靠谱。我们建过一个几百道题的评测集，题目全部来自历史真实事故，人工标注标准根因，根因引擎每次改动都要跑一遍回归。就是靠这个评测集，我们抓到过一次大问题，AI 对"网关超时"类故障的根因判断，连续三周都在往缓存上猜，这一类目的准确率只有四成。排查下来，原因让人哭笑不得，接入的信号源里少了发布系统的变更数据，AI 看不到"三分钟前有人改过网关配置"，只能靠猜。把变更信号接进去之后，这类题目的准确率直接跳到了九成以上。这个案例我们内部讲了很久，AI 猜不准，大多数时候不是模型不行，是它该看的没看到。

顺带说一句，事件和告警的区别，值得每个团队认真想清楚。告警是信号，事件才是可治理的对象。我们把多条相关告警聚合成事件、结合影响面和 SLI 偏差综合定级、绑定完整生命周期(触发、确认、处置、复盘)，最大的收益在复盘环节。事件关闭时，时间线上人、机器人、AI 的所有动作已经自动串好了，导出就是一份复盘报告初稿。以前一份报告写两天，现在是十分钟改稿。

拓扑视图是证据链的可视化形态。开发、运维、业务三方看着同一张图说同一种话，这件事的价值怎么强调都不为过。印象最深的一次，是一个应用慢的工单，业务方咬定是运维的问题，运维咬定应用没问题，来回扯了两天。后来把拓扑图投到会议室大屏上，流量路径清清楚楚高亮在应用自身的一条慢 SQL 上，三十秒，争论结束。可视化有时候不是让事情更好看，是让争论没有地方躲。

感知和认知做得再好，落不到行动，价值就停在看见层。行动层是我们内部争论最激烈、也是最有心得的部分。

有人说回滚点个按钮的事让 AI 干了呗。也有人说生产操作必须人审，回滚错一次谁来负责。两派在会议室争论很久，白板上写满了自主，可控，责任的排列组合，谁也说服不了谁。我们组里有个年轻人，是"全自主派"最坚定的一个，原话是"你们这是给自动驾驶配了个副驾，还要求副驾全程脚踩刹车"。三个月后，恰恰是他自己提出来要给某类操作加一道强制人审，原因是他复盘了一个外部事故案例，发现有些操作的不可逆程度超出他原本的估计。这大概是我们内部最有说服力的一次转向，不是被谁说服的，是自己撞明白的。

最后打破僵局的也不是道理，是一道算术题，我们把过去一年的运维操作拉出来分了个类，发现 80% 的操作是低风险且高度重复的，真正高风险的不到 5%，而且几乎每一次高风险操作前都有充分的上下文可供判断。既然风险分布这么不均匀，凭什么执行策略要一刀切？最后找到的平衡点，是分级执行:

| 风险等级 | 典型操作 | 执行方式 | |---------|---------|---------| | 低风险 | 清理日志、重启挂掉的 sidecar、磁盘扩容(有上限) | AI 自主执行，事后通知 | | 中风险 | 扩缩容、限流、切换只读副本 | AI 生成方案，人工一键确认 | | 高风险 | 回滚版本、切核心流量、删数据 | AI 只给建议，人工全程操作 |

分级上线之后的数据很有意思，八成低风险操作被 AI 接管，oncall 负担肉眼可见地下降，而高风险操作的AI误操作事故，至今为零。这个平衡点不是拍脑袋，是拿事故可能性算出来的账。

还有一个意外收获值得一提。分级机制上线三个月后，一位入职刚满三周的值班同学，独立处置了一次 P1，AI 聚合出事件、给出证据链和建议方案，他逐条核对证据，在中风险闸门上点了确认，全程 9 分钟，处置动作和五年经验的老手如出一辙。放在以前，新人前三个月值班的正确姿势是多看少动，闸门真正的价值，是让新人敢动手，而且动手就不会出大事。

工作流的落地形态，是把 SOP 变成可执行的编排。举一个我们真实的自动排障工作流片段:

图 6:工作流编排画布。定时触发、查询日志、AI 根因分析、条件判断拖拽连线，SOP 就变成了能跑的流程。

注意 hostbash 这个节点上的 guard: requireapproval。这就是闸门，AI 可以调用任何技能，但高危技能的每一次调用都要过人审，并且全链路留痕。能力开放和风险管控必须长在一起，不能先是野路子跑通了再补安全，那样补不上。

图 7:技能管理页。按"云/设备"分组，标注运行环境与"安全/需确认"分级。

顺带一提，每次执行都留审计痕迹(输入、输出、耗时、操作人)，对异常频次和越权操作主动告警。这不是合规要求逼的，是出过事之后长出来的肌肉记忆。今年公司安全审计，我们把全年 AI 执行记录导出去，一万多次调用，每一次都能回答"谁、在什么时候、对什么对象、执行了什么、结果如何"。 当 AI 自己也需要被运维，LLMOps 的觉醒时刻

我们的觉醒时刻很具体。某天我们自研的 AI 助手在根因分析上突然变得离谱，同一类故障给出的根因五花八门，今天说是数据库，明天说是网络，后天开始建议你重启交换机。排查发现是上游模型供应商静默升级了版本，行为漂移了。传统监控对此完全无感，CPU、内存、QPS 一切正常，系统"健康"得很。那一刻我们意识到，概率性的输出没法用确定性的指标去守护，大模型是一个会自己悄悄变坏的系统。

于是我们把 LLM 当成一个生产系统来对待，建了四件套。

第一件，LLM 可观测性。调用量层面看 QPS、Token、耗时、错误率，质量层面看幻觉率、拒答率、人工接管率，这些是传统监控里根本没有的维度，成本层面按技能、按租户拆 Token;风险层面识别越权调用和敏感数据外发。

图 8:LLM 可观测性。错误率、幻觉、Token 用量、费用、错误类型分布，一屏看全。

图 9:LLM 调用追踪。左侧是错误 Trace 列表，右侧是单次调用的输入输出与错误堆栈。

单次调用的追踪要能做到一键回放，从用户输入、Prompt 组装、工具调用、到模型输出，每一步可展开。我们排查过一起401认证错误，90次Trace全部失败，回放定位到是某个服务的API Key过期，从发现到修复15分钟。没有调用追踪，这种问题排查要靠加日志重新发版。

这条 Trace 排查还给我们留了一条纪律，Prompt 也是代码。早期我们的 Prompt 散落在各个服务里，有人手一抖改了半行措辞，幻觉率直接翻倍，我们查了两天才定位到原因。从那以后，所有 Prompt 进 Git 仓库，版本化，变更走评审，享受和映射规则完全相同的发布待遇。大模型时代的变更管理，第一条原则就是别把提示词当文本，要把它当代码。

第二件，质量评估，也就是给 LLM 建一套量化体检。我们用 7 个维度打分，安全、相关性、准确性、幻觉、满意度、上下文完整性、注入防护。重点说几个维度。

幻觉维度，用证据回溯法检测。AI 给出的每条结论，去原始数据里找对应证据，找不到的就是幻觉，目标控制在 3% 以下。上线这套检测后我们发现，知识库问答的幻觉率一度接近一成，根因是检索召回的 chunk 质量差。修了一个月检索，幻觉率降到 2% 出头。

第三件，Token 经济性。大模型不便宜，不控成本的平台撑不过两个季度。我们按周追踪总成本、按模型拆占比、按应用做预算，并让 AI 自己出降本建议。这一层在平台里对应的是成本智能 FinOps，它把 Token 花费和业务价值放在一起看，顺带也能看云资源的账单。一个实际生效的建议:

这条建议我们犹豫了一个礼拜才敢上线，毕竟省的是真金白银，赌的是质量。上线后抽样评分稳住了，语义缓存命中率稳定在三成五上下，该省的钱一分没少省。降本这件事最大的心理障碍不是技术，是省了钱出了错谁背锅，所以我们的做法是灰度切流、双轨跑两周、数据说话，让每个降本决策都有退路。

第四件，技能治理。把脚本、API、知识统一抽象成技能，按风险分级设执行权限。这一层是上一节闸门的治理底座。

这套 LLMOps 体系最大的价值，是让我们第一次能用数字回答我的 LLM 到底靠不靠谱，而不是靠感觉决定它能不能上生产。 把经验沉淀成 Skill，从个人直觉到团队资产

讲到这儿，该回应这次共创计划最打动我的一个命题了，怎么把运维方法从"一个人的直觉"，变成"一份可对标、可复制、可演进的能力资产"。

我们的答案是Skill化。任何一个排查套路，只要被验证过两次以上，就应该被沉淀成一个技能，输入什么、调用什么、判断标准是什么、产出什么。

举个最小可用的例子，把"Redis 连接拒绝的标准排查"沉淀成一个 Skill:

这个 Skill 上线后，Redis 连接拒绝类告警的平均处置时间从 18 分钟降到 5 分钟，而且任何一个新入职的值班同学，借助 AI 调用这个技能，排查动作和一个五年经验的老手完全一致。经验不再依附于某个人在不在值班表上。

按这个节奏，一段时间下来我们一共沉淀了几十个个技能。回头看，这几十个技能就是我们团队运维知识库的可执行形态，比 wiki 上的文档活着。 值班表的化学反应

方法讲完了，说点软性的，因为有些变化，数字量不出来。

以前培养一个能独立值班的运维，我们的经验值是六个月，前三个月熟悉系统，后三个月跟着老师傅攒手感。现在这个周期被压到了三个月以内，靠的不是新人变聪明了，是几十个技能把老师傅的手感装进了系统。新人遇到没见过的问题，调用技能，排查路径就是标准路径。同时能力资产化的另一面，是必须防止新人只知其然。所以我们后来加了一条要求，凡是 AI 辅助处置的事件，复盘时必须回答一个问题，如果今天没有AI，你会怎么查？这个问题留住了思考，也留住了成长。

顺便说个跟"省心"有关的模块。平台里的容量规划我原来一直觉得是锦上添花，直到有一次大促前，它按历史流量曲线预测出订单服务的连接数会在峰值时段顶到上限，提前两周给了扩容建议。那次扩容拦下来的隐患，正好就是前面那类连接池事故。所以有时候事故不是被更聪明的 AI 拦下的，是被一张提前画出来的容量曲线拦下的。一点都不性感，但真的管用。

图 10:容量规划。90 天容量预测曲线:当前利用率 78%，预测 30 天后到 92% 触顶，右下角是扩容建议。 账本，敢不敢用数字说话

聊了这么多方法论，最后得对得起可量化三个字。我们的价值衡量体系围绕六个指标，这里交几个实底:

这些数字在平台里都有固定的视图，"运维报表"和"MTTR 分析"两块就是干这个的，不用我们自己在 Excel 里手搓。尤其 MTTR 分析，它能按故障类型、按团队、按时间段切开看，我们不少改进决策都是盯着这张图定的。

不过账本里也得写诚实的那一页。你看MTTR从38分钟降到32分18秒，只降了15%，远不如MTTD那样亮眼。为什么？我们把MTTR拆开看，发现发现、定位、决策这三段都被 AI 大幅压缩了，唯独"执行恢复"这一段纹丝不动，回滚要走变更审批，审批链是人类的，该两个签字还是一个签字都省不掉。AI 再快，也快不过人类的流程。这个发现反而让我们高兴，因为它直接指出了下一个战场，把高风险操作的审批流程本身也纳入治理，该合并的合并，该预授权的预授权，前提是证据链足够可信，让签字的人三秒钟就能看明白自己在为什么签字。

还有一句我常跟团队讲的话，算法准确率从90% 提到95%，如果业务指标没有任何变化，那 5% 的提升可能毫无意义。 写给同路人，几条带血的教训

最后，把我劝你别踩的几个坑，原样搬出来。

别跳过数据底座直接上算法。这是最常见的死法。统一采集口径、建好 CMDB 和拓扑、把告警治理干净，这事一点都不酷，但它是所有智能化的前提。我们见过太多团队，80% 的项目时间在补数据的坑，最后 POC 做完就归档了。

别把告警当终点。告警只是信号，事件才是可治理的对象。只做告警不做事件聚合和复盘沉淀，同一个故障半年后会原样再来一次，因为教训根本没留下来。

别让AI在没有闸门的情况下碰生产。我见过一个真实案例，某团队的黑盒扩容系统在大促时把实例数扩到平时的 8 倍，成本直接爆表，事后没人能解释为什么是8倍。几十万的直接损失是小头，信任损失才是不可逆的，那套系统从此再没被打开过。

别用PPT驱动AIOps。正确顺序是先找一个高频、够痛、数据相对齐的场景，把价值跑出来，再谈平台化。反过来做，先搭一个"什么都能干"的大平台再找场景，你会发现每个场景都差点意思，最后平台变成仪表盘展览馆。

别等数据完美才动手。这条听起来和第一条矛盾，其实不是。数据治理不是一次性工程，是陪跑式的，先圈定一个场景，把它的数据从 60 分治到 80 分就够起步了，边用边治，用出来的问题比规划出来的问题真实得多。等"数据全部治理好再上 AI"的团队，一般等不到那一天，因为预算和耐心都是有限的。

别追求"无人值守"的幻象。现阶段纯自主的运维 Agent 在大多数企业还不成熟，因为运维操作的可逆性太差。演进路径一定是，先辅助决策，再建议操作，然后低风险自主执行，最后高风险人工确认。谁能在自主性和安全性之间找到平衡点，谁就赢。

别想着替代人。AIOps 的目标是把人从重复劳动里解放出来，去做架构优化、容量规划这些更有价值的事。AI 替代的是任务，不是岗位。平台是运维参与设计的，规则是运维可以调的，建议是运维可以反馈的，这样的系统才有生命力。 最后

前面讲过那个被 47 条告警吵醒的凌晨，现在不会重演了。不是因为我们消灭了故障，故障永远都在，上个月还来过一次磁盘写满。不一样的是，故障来的那一刻，系统已经把证据链摆好、把建议备好、把闸门位置留好，值班同学需要做的只是最后那两次点击。

这大概就是我做 AIOps 这么多年真正想要的东西不是更酷的架构，是一线同事不用再半夜拼图，是经验不再随人员流动而流失，是系统复杂到一个大脑装不下的时候，还有一个数字大脑在帮我们扛着。

从看见，到理解，到行动，再到让行动本身可治理、可沉淀、可复制。