## 引言：出啥事了？

**值班是最费脑子的，一是时间紧张，二是信息量大**。

有时候吧，日子过得好好的，告警信息就来了。

群里几十条消息，哪几条是同一件事；**这条该找谁；以前有没有人处理过，当时是怎么处理的。**

这三个问题有没有答案、有没有文档？
> 很可能没有

还是只是答案存在几个老员工的脑子里，得靠人脑维护？
> 我说：是的

印象最深的那次。

告警群每分钟十几条往上顶：同一个接口超时换着参数刷，三条恢复通知夹在中间，还有几条两周前就出现过的老问题。

值班的同事咔咔地往上翻记录，要搞明白一个问题：这里面到底有几件事、几类告警？

后来我们实在受够了，把这三个问题一个个搬进了系统。

这篇文章写的就是这个过程。
> 放心食用，图是 AI 配的，但是文字不完全是

## 一、那时候的值班：全靠人肉维护

![01-comparison-human-memory.png](https://developer.qcloudimg.com/http-save/yehe-1367556/45cc0edbcabb6a292695a6388963eb30.png)
**收敛靠人眼。** 告警群没有“同一种告警”的概念。同一个空指针换三个请求参数就是三条消息，恢复通知和新增告警长得几乎一模一样。
值班的人先得把同一条告警从几十条消息里挑出来，翻历史记录、比对报错文本、猜哪几条是一回事。
告警风暴一来，时间就非常紧张。

**归因靠记忆。** 一条告警该找谁，取决于谁熟悉那块代码。
这张表沉淀的不及时，新人值班只能靠猜；老人离职，表就缺了一块。
我们甚至维护过一份“邮箱到飞书账号”的口头对照表，因为 git 提交邮箱和 IM 账号对不上。

**沉淀靠自觉。** 处理完一条疑难告警，经验的最大载体是处理人口头说一句“这个啊，是某某配置的老问题”。
**没有记录就没有复用**，下一个人遇到同一条告警，还得从头再查一遍。
复盘会也开过几次，结论只留在会议纪要里，告警群里该刷屏还是刷屏。

还有一件事：没人认领的告警会沉底。会埋没再聊天记录里，直到用户投诉才发现“哦 原来这条一直没处理，漏了”。

## 二、AIOps 接入：四步搭出来的流程
![02-flowchart-four-steps.png](https://developer.qcloudimg.com/http-save/yehe-1367556/5254160b19351942284e66c6443efc69.png)

我没买什么专业的平台，只是从值班动作本身出发，**从痛点触发**，把流程建规范化、自动化。

**第一步：给告警建台账，生成指纹。** 机器人每 5 分钟拉一次告警群消息，解析卡片正文，过滤掉恢复通知和已知噪音，然后给每条告警生成一枚指纹，优先取代码位置，其次接口路径、事件名，最后退到标题。

有了指纹，系统里才有“同一种告警”这个概念。同类告警在第一条没处理完之前自动合并，只累加次数、刷新原卡片，不再重复轰炸。

台账顺便把“以前有人处理过吗”也列出来了，同一个指纹下谁碰过这个告警，直接可以查到，非常直观。
![image.png](https://developer.qcloudimg.com/http-save/yehe-1367556/45d7bf8ecc2ede2a7c307981bd9b16a9.png)
**第二步：归因自动化，把“该找谁”交给 git。** 解析告警里的错误堆栈帧，在业务代码仓库里定位到文件，`git blame` 取出提交人，再经邮箱映射找到飞书账号，私聊通知。

blame 失败还有兜底链：日志文本 grep 代码、历史处理人、当日值班表、兜底处理人。

链条走到底，保证每条告警最终都会落到一个人手上，不遗漏。

**第三步：处理流程搬进飞书，处置变成回一句话。** 负责人收到的是交互卡片：**处理中、已处理（必填原因和措施）、无需处理（必填原因）、转派**，四个按钮覆盖全部处置动作。
> 不强制填不行，只靠自觉去沉淀，有点困难

@ 机器人说“建单”可以给任意话题手动开告警单。没认领的告警会进催办巡检，**通知 3 小时没人认领开始催，最多 3 次，逐级加急（应用内、短信、电话）**，深夜免打扰不催，保留一点人性化。
> 等级高的告警改催还得催

![image.png](https://developer.qcloudimg.com/http-save/yehe-1367556/7b4a780009c936f00551a2fcf3099e94.png)


**第四步：让 AI 接管“为什么”和“下次怎么办”。** 归因之后，Agent 带着告警上下文、脱敏堆栈和链路日志读代码做根因分析，结论直接写回卡片；每次有效处理（原因和措施）自动归纳进处理手册：**现象、常见原因、处理步骤、可无需处理的情形、熟悉的人**，五个小节。
**下一条同类告警到达时，卡片上直接带着“处理经验”区块（图上面有）。**


## 三、五个决定，事后看是对的

![03-framework-five-decisions.png](https://developer.qcloudimg.com/http-save/yehe-1367556/41b74622063073870c3a24592b3ceebb.png)
**1. 负责人归因不用 LLM。** 栈帧解析、文件定位、`git blame` 全是确定性规则，毫秒级，没有幻觉，也不花 token。LLM 留给它擅长的事，也就是**读代码做根因分析**。

**2. 私聊卡片优先，失败退回话题 @。** 告警是打断人的事，应该发给“人”，不该丢进群里等有缘人；但私聊可能失败（账号不在应用可用范围等），失败必须退回话题 @。

**3. 认领只延期，不豁免。** “收到”之后给 2 小时安静期，超时未处理自动恢复催办并 @ 认领人。这一条解决的是“认领即完结”，认领只说明我知道了，不说明我处理完了。

**4. 双通道 AI 分层。** 重分析（读代码、读日志、给证据链）走 Coding Agent；轻任务（自动分类、手册归纳、话术抽取）走轻量模型的结构化输出（目前是 DeepSeek，**便宜不烧心**）。

这样成本和时间都省，轻任务的结果也更稳，不用为了分个类去跑一遍读代码的 Agent，太重了。
![image.png](https://developer.qcloudimg.com/http-save/yehe-1367556/dd0ff715b2fbf189d4fac0bbe9ee3ac4.png)
**5. 经验必须能锁定、能合并。** 处理手册允许人工保存后锁定，AI 新归纳只进“待归纳”，不覆盖人工结论；同类手册支持合并别名。要是不锁，AI 归纳得越多，人工写过的结论越容易被冲掉。

## 四、Skill + MCP：把经验变成 Agent 的动作
![04-framework-skill-mcp-boundary.png](https://developer.qcloudimg.com/http-save/yehe-1367556/b12bdc80378d3f4262d6cf0fc01ab9dd.png)

**手册是给人读的，Skill 是给 Agent 走的。** 处理手册写的是“现象、常见原因、处理步骤、可无需处理的情形、熟悉的人”，人读完知道大概怎么回事。

但是Agent 拿到同一份东西还得自己猜：什么条件下能动手，查到什么程度可以下结论，做到哪一步算结束。

我们把这份供人参考的经验，重写成可遵循的步骤、判断条件和结束标准。

**一份 Skill 就六段。** 以刷奖励告警为例：
- **适用场景**：奖励接口异常、疑似高频领奖（用来路由）。

- **必要信息**：环境、app_id、uid。缺任何一项就分析不准了，容易误判。

- **查询步骤**：调 MCP 查奖励流水，只统计成功发奖，排除重复记录和补发。

- **判断规则**：查询时间范围、两次领奖的最小间隔、连续次数，全部落到具体数值。

- **处置步骤**：命中允许自动处置的规则才拉黑，拉黑后再查一次状态确认结果。

- **完成标准**：记录证据和操作结果，回复原告警话题，关闭对应工单；失败就保持待处理（**允许有自动关闭告警工单的能力，针对一些常见的、确定性非常高的**）。

![image.png](https://developer.qcloudimg.com/http-save/yehe-1367556/d854f14b0f93096e76fa41a74c5b1f49.png)
**“常见”这种词，人看得懂，Agent 不理解。** 手册里原来写“常见非法值”“确认的非法 uid”，回到 Skill 里必须落到具体字段、具体阈值、具体时间窗。
还有一条容易漏：历史上某个人因为参数异常被拉黑，不代表这次报同样错误的用户也该被拉黑。
**经验是线索，不是判决书**。落不到具体证据的，一律转人工。

**Skill 和 MCP 是分工，谁也替不了谁。** Skill 管“该不该做、先做哪步、做到什么程度算完”，MCP 管“怎么查、怎么改”。
Skill 里每一步都要落到具体的工具调用上，Agent 才知道自己手里有什么工具。

只有 Skill 没有 MCP，是一份读起来很顺的操作说明，动不了手；只有 MCP 没有 Skill，工具一堆，但 agent 不知道怎么处理。

**一条告警进来之后，加载顺序是固定的。** 收到告警 → 按接口或告警类型匹配 Skill → 读取当前已发布版本 → 组装本次上下文（通用指引 + Skill 版本 + 本次告警证据 + 该指纹下的历史经验）→ Agent 按流程调 MCP。

第一版没让模型自己选 Skill，而是按接口、告警类型明确绑定。挑错一份 Skill 的代价，比多维护一张映射表大得多。没有匹配项就退回普通告警分析，只出结论，不做处置。

**自动到什么程度，要提前规范好。** 已经被沉淀过的告警类型（手册命中过、证据链固定），Agent 可以自己查证、自己回复话题、自己把工单关掉。关单不改线上状态，这个可以放行。
真正改数据、改配置、影响面说不清的处置，Skill 里固定“到此停”，把证据和结论发给处理人，等人工确认，**对线上数据要有敬畏之心。**

> 多说一句，mcp还是一定开发成本的，所以我们选择了n8n 流程配置平台来降低开发成本，只需拖拽和配置节点就能生成一个针对性非常高的 mcp 服务，你甚至可以在里面内嵌 agent 节点，非常灵活

自动的部分解决的是“不用再翻半小时群聊、翻文档”，不是“人不用做决定”。


## 五、跑出来的数字和口径
![05-infographic-numbers.png](https://developer.qcloudimg.com/http-save/yehe-1367556/f7dbf86bdfa13bcfd2cb20f57f725c58.png)

下面这些指标都来自系统自身的统计（告警台账和认领统计接口），能从这两个接口重算出来。


|指标|口径|接入前|接入后|
|:-:|:-:|:-:|:-:|
|告警收敛率|同类合并条数 / 告警总条数|无收敛能力|100%|
|告警处理率|已处理 / 总告警|60%|100%|
|平均认领耗时（MTTA）|认领时间 − 通知时间 均值|无人统计|12 分钟|
|沉底告警数|超 24h 未处理条数/周|无人统计|0%(**就问谁能逃得过催办**)|
|根因分析覆盖与采纳率|自动分析条数 / 结论被处理人引用条数|无|根因分析 100% 覆盖，采纳率 90%|


## 六、后面正在做的事

![06-framework-next-steps.png](https://developer.qcloudimg.com/http-save/yehe-1367556/ab14253ccdfbd72f9302208997f871dd.png)
- **分类驱动治理**：七类自动分类（代码缺陷、配置、数据、第三方依赖、容量性能、误报、其他）积累到一定量级后，驱动专项治理。配置类进配置评审，第三方依赖类补降级预案，告警数据攒起来，反过来能看出架构该往哪改。

- **故障感知**：之前是停留在单个告警的处理上，没有对整个告警数据的动态感知，例如短短 5 分钟告警数量激增，告警面积非常广，这就不是单个服务的问题，可能是系统全面出问题了，这时候就要启动一级响应，全员待命。

- **证据面扩展**：把指标时序和变更事件也接进根因分析，结论不能只压在一条证据链上。


## 结语

回头看，那三个问题的答案都不用再装在谁的脑子里了：哪几条是一回事，该找谁，以前怎么处理。

原先靠人记，后来靠系统记。指纹、blame、手册，一样一样写下来。手册后来又往前走了一步，不只是给人读，Agent 也能照着做：查证和关单自己走完，人只在要拍板的时候出现。

平台会换代，模型会升级，但是沉淀的知识会一直起作用。


群里几十条消息，哪几条是同一件事；这条该找谁；以前有没有人处理过，当时是怎么处理的。

当值班不再靠人工：一线团队的 AIOps 告警治理实践

十倍工程师

人工智能

告警处理从人工翻聊天记录升级为AI自动化运维：通过指纹合并同类告警，git blame自动定位负责人，处理经验沉淀为手册和Skill，实现告警收敛率100%、根因分析采纳率90%，彻底告别靠人脑维护的告警处理模式。

DeepSeek

短信

路由

AIOps

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

当值班不再靠人工：一线团队的 AIOps 告警治理实践-腾讯云开发者社区-腾讯云

当值班不再靠人工：一线团队的 AIOps 告警治理实践

当值班不再靠人工：一线团队的 AIOps 告警治理实践

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐