值班这件事干过的人才懂半夜两点被电话吵醒眯着眼睛打开电脑告警群里已经刷了几百条消息——数据库连接数告警、接口P99延迟飙升、订单积压、磁盘空间不足……每一条看起来都像大事但真正要处理的可能只有一个根因。在on-call值班场景里我们缺的不是告警而是对告警的判断力。这篇文章我想聊聊怎么用Claude Tag这套标签化方案来改造on-call值班流程。Claude Tag并不是某个官方产品而是我在实践中总结出来的方法把值班告警交给ClaudeAnthropic推出的大语言模型做语义理解自动给每一条告警打上结构化的标签让值班同学一眼能看懂“这到底是不是我的问题、影响有多大、该叫谁起来处理”。这套方法适合有告警平台但告警质量差、值班人力紧张、新人上手慢的团队也适合一个人要盯多个系统的SRE和运维工程师参考。我把从告警接入、标签体系设计、提示词编写到值班实战、交接班复盘、成本控制的完整链路整理出来每一步都是踩过坑之后才跑通的方案值得动手试试。1. on-call值班真正缺的不是告警而是“看一眼就懂”的判断力1.1 告警泛滥背后的信息熵问题绝大多数团队的监控告警平台本质上就是一个“消息转发器”。它可以很准时地把Prometheus、Zabbix、云监控的告警推送到钉钉、飞书、Slack或者短信网关但推过来的内容往往是一行裸数据[P1] 10.0.3.21 MySQL Threads_connected 从 128 上升到 800超过阈值 300这条信息有温度、有数值但没有上下文。值班同学看到之后脑子里冒出的问题通常是这个IP是哪个集群的核心业务还是边缘业务Threads_connected上升到800是因为慢查询堆积还是连接池没回收还是上游调用方新增了连接影响范围是只有这一个实例还是整个集群都这样现在是凌晨两点该不该把DBA叫起来还是说等十五分钟看它自己恢复这些问题的答案往往分散在监控大盘、变更记录、日志系统、架构文档里。值班同学要手动去查一查就是十分钟起步。遇到复杂故障等搞清楚状况的时候业务已经受影响半小时了。这里其实隐藏着一个信息熵的问题告警平台的输出是低熵的结构化数值但值班人员需要的是高熵的业务语义。从“MySQL连接数上涨”到“用户登录接口变慢疑似连接池耗尽属于核心链路P1故障”中间隔着大量的关联推理。人脑做这个推理费时费力而大语言模型恰好擅长把分散信息汇总成结论。1.2 Claude Tag给告警装上“语义解释器”Claude Tag的核心思路不复杂在告警推送链路中间加一层“语义打标”处理。当监控系统发出告警时先通过webhook把原始告警发送给一个Claude处理服务Claude读取告警文本、结合预设的标签体系和上下文规则输出结构化标签和一句“人类可读的结论”然后带着这些标签把告警转发到值班群。一个原始告警经过Claude Tag处理之后可能变成这样[P1][核心链][数据库][连接池异常] MySQL连接数突增命中连接池回收失败规则 结论10.0.3.21订单库主实例Threads_connected 800疑似连接长期占用未释放 影响订单创建链路建议优先排查长时间运行的事务和连接池 maxLifeTime 配置。同样是给值班同学看一条消息后者的信息密度完全不一样。收到告警的人不再需要靠猜标签直接把“是不是我的问题”和“该往哪个方向查”说清楚了。这个过程中Claude做的其实是三件事理解告警内容解析指标名、实例、阈值、异常形态、匹配标签体系从预设标签集合中挑选最合适的组合、生成辅助结论用自然语言描述可能的根因和影响。前两件事是结构化能力第三件事是生成式能力两者结合恰好补齐了传统告警最缺的“解释层”。1.3 这套方案和传统监控标签有什么区别有运维经验的朋友可能会说Prometheus的Alertmanager本身就支持标签我们也可以给告警加severity、instance等标签何必再引入一层Claude两种标签的出发点是不同的。传统标签是规则预定义的你需要在配置告警规则时手工写好每个告警的标签组合它是静态的也不会根据告警时的实际上下文发生变化。比如你写了一条“MySQL连接数大于300”的告警规则给它打了“database”和“high”的标签那不管实际是慢查询导致的还是连接池配置导致的标签永远是一样的。Claude Tag的核心差异在于动态语义打标Claude每次处理告警时都是结合当前告警的完整文本、近期的系统变更信息、甚至是同时间段其他告警的相关性来生成标签。同样一条MySQL连接数告警白天业务高峰可能标注为“[预期波动][观察]”凌晨突增可能标注为“[核心链][P1][连接池异常]”标签内容是随上下文变化的。换句话说传统标签是告警规则的附属品Claude Tag标签是告警事件的认知结果。前者适合做静态聚类和权限过滤后者适合辅助值班决策。2. 标签体系怎么设计决定这套方案的上限2.1 四类标签来源、类型、影响面、优先级Claude Tag落地之前最关键的步骤是设计好标签体系。如果标签就随便让Claude自由发挥输出的标签五花八门那后面基于标签的聚合、路由、复盘全都没法做。我在实践过程中把标签收敛成四个维度每个维度下限定可选值Claude只能从候选集里选不能凭空造。来源标签source标识告警来自哪个系统或组件。这个通常和监控对象强相关比如来源标签含义database数据库相关MySQL、PostgreSQL、Redismiddleware中间件Kafka、RocketMQ、Elasticsearchgateway网关层Nginx、API Gatewayapplication业务应用服务infrastructure基础设施CPU、内存、磁盘、网络来源标签的价值在于快速路由——前置通知到哪个团队或值班人。类型标签type标识告警对应的故障模式。这是最有技术含量的一层因为故障模式需要结合运维经验归纳。我常用的是类型标签典型场景connection_exhausted连接池耗尽、连接数突增、线程池打满latency_spike延迟上升、P99超标、超时率增加capacity_pressure容量水位高、磁盘/内存/带宽接近上限error_burst错误率突增、异常堆栈密集出现data_inconsistency数据不一致、主从延迟、消息积压config_change疑似配置变更引发的异常dependency_failure外部依赖服务故障导致的连锁反应类型标签是值班同学最关心的信息它在回答“现在到底发生了什么”。Claude之所以能做这件事是因为它具备从告警描述文本中推理故障模式的常识能力——看到“连接数从128涨到800”会联想到连接池耗尽看到“P99从50ms涨到2000ms”会联想到延迟尖峰。影响面标签scope标识告警影响业务的范围和核心程度。core核心链路用户登录、下单、支付等edge边缘功能报表、后台、非核心接口internal内部系统监控自身、离线任务、数据同步unknown无法判断影响面判断对LLM来说相对难一些因为模型不知道你的业务拓扑。所以在实际落地时我会在系统提示词里把服务列表和核心链路描述贴进去让Claude有据可依。后面第三节会详细讲这部分怎么写。优先级标签priority最终值班同学只需要关心的指标。P1紧急影响核心业务需要立即处理P2严重可能扩大影响面尽快确认P3一般可观测无需立即介入P4信息通知不需要处理2.2 标签系统的“防幻觉”设计LLM打标最大的风险是“一本正经地胡说八道”。模型可能把一条凌晨的偶发告警标成P1也可能把真正核心链路的故障当成边缘告警。为了降低这种风险我做了三个约束。第一标签选择改为“候选集打分”。不是让Claude直接输出他认为是类型的字符串而是把候选标签全部列给Claude让他为每一个候选标签打分最终取最高分。比如请为以下告警评估标签候选类型包括 1. connection_exhausted0-100分 2. latency_spike0-100分 3. capacity_pressure0-100分 4. error_burst0-100分 ... 只输出每个标签的分数。这种“选择而不是创造”的约束能把模型的幻觉空间压缩到一个很小的范围内。第二来源标签和类型标签做组合校验。比如来源是database但Claude给出的类型是capacity_pressure这是合理的但如果来源是gateway类型却给connection_exhausted合理度就比较低。我维护了一个来源-类型二元组的合法性清单打标结果不合法时用兜底规则fallback rule替代比如“误报”或者“unknown”。这个校验逻辑大大减少了离谱标签的出现频率。第三事实型字段强制走规则不走模型。告警里本来就带有的字段比如实例IP、告警级别如果有的话、指标名这些直接通过程序解析提取不需要经过LLM。Claude Tag只负责生成推断型的标签类型、影响面、优先级不负责抽取事实字段。这样即使模型判断失误告警的关键事实也不会丢。2.3 标签不是越多越好刚开始做Claude Tag的时候我犯过的错误之一就是把标签设计得很细什么“write-heavy”“cold-call”“runtime_exception_npe”这种具体到让人头皮发麻的标签都往体系里塞。设计时觉得很完美实际跑起来全是问题一方面是Claude很难从告警文本里准确推断这么细的类型另一方面值班同学看到这种标签仍然需要花时间去理解含义并没有起到“秒懂”的效果。后来我把标签收敛到“能帮助值班者做三秒决策”的程度——来源、类型、影响面、优先级这四个维度加起来不到四十个可选值。设计原理很简单标签是要喂给人看的不是喂给机器玩的。人看一个标签如果能在一秒内知道自己接下来该干什么这个标签就合格了如果还要去翻文档确认标签含义那还不如直接看原始告警。3. 从告警触发到标签回写一条完整的接入链路3.1 接入架构需要的三个部分Claude Tag不是独立部署的一套庞大系统它可以很轻地挂在现有监控平台旁边。我的落地架构分为三块告警入口组件接收监控平台Prometheus Alertmanager、Zabbix、云监控等的webhook消息统一结构化为JSON格式。Claude打标服务一个无状态服务接收结构化告警调用Claude API完成打标并把标签和结论附到原告警上。通知路由组件根据标签把告警发送到不同的钉钉/飞书群或者直接回调Alertmanager更新告警标签。三个部分都可以用很轻的语言实现我的参考实现用的是Python FastAPI部署成单机服务就能扛住中小团队每天几百条告警的量。如果觉得自建服务太重也可以在监控平台和群机器人之间加一个云函数/Lambda原理完全一样。3.2 告警结构化喂给Claude之前先整理好Claude能打出什么质量的标签很大程度取决于喂进去的告警文本整不整齐。我自己是拿Prometheus Alertmanager的webhook做接入的原始结构长这样{ status: firing, alerts: [ { labels: { alertname: MySQLThreadsConnectedTooHigh, severity: page, instance: 10.0.3.21:9104, job: mysql-exporter }, annotations: { summary: MySQL 线程连接数过高, description: Instance 10.0.3.21 MySQL Threads_connected 为 800超过阈值 300 }, startsAt: 2024-06-18T02:13:00Z } ] }如果直接把这段JSON丢给Claude它当然也能读但会在不重要的字段上浪费注意力。我在打标之前先做了一步清洗和富化组装成一个更紧凑的prompt输入告警时间2024-06-18 02:13:00 UTC 告警对象10.0.3.21mysql-exporter 告警规则MySQLThreadsConnectedTooHigh 指标信息MySQL Threads_connected 800阈值 300 当前状态firing如果团队有CMDB或者服务拓扑信息还可以在这一步把“10.0.3.21属于订单库主实例绑定订单服务”这个信息附上去Claude对影响面scope的判断就会准确很多。3.3 打标提示词把规则讲清楚而不是让模型自己发挥这是整套方案里最关键、也最需要反复调的一段。我写提示词的原则是“把值班规则手册原封不动搬给Claude”。下面是一版精简后的打标提示词你是一个资深的SRE告警研判助手。收到一条监控告警后你需要做两件事 1. 为这条告警打上标签 2. 用不超过三句话描述告警的可能原因和影响面。 告警信息 {结构化告警内容} 企业服务信息 - 实例 10.0.3.21订单库主实例承载订单创建/查询属于核心链路 - 实例 10.0.3.22订单库从实例负责报表查询属于边缘链路 - 服务 order-service提供订单创建、查询接口 - 服务 payment-service提供支付回调接口依赖 order-service 候选标签如下仅为候选集合不可自行增加新标签 sourcedatabase / middleware / gateway / application / infrastructure typeconnection_exhausted / latency_spike / capacity_pressure / error_burst / data_inconsistency / config_change / dependency_failure scopecore / edge / internal / unknown priorityP1 / P2 / P3 / P4 打分规则 - 请对每个候选值输出0-100的置信分 - 如果告警信息明显不足所有标签置信分都不得超过40并在结论中注明“信息不足” - 如果判断依据存在冲突遵守以下优先级事实型字段如instance 指标形态 你的领域知识 输出格式严格JSON { source: {value: database, score: 95}, type: {value: connection_exhausted, score: 88}, scope: {value: core, score: 90}, priority: {value: P1, score: 92}, conclusion: 一句话根因判断和影响说明 }注意几个细节服务拓扑信息必须写进去候选标签要给全并声明不可新增输出格式要用JSON固化方便下游解析。这套提示词迭代了大概四五版才稳定下来最早那版只让Claude给结果不分值导致很多低置信度的标签没有兜底后来加了打分制才解决。3.4 回写与路由标签只有用起来才有价值打标完成的告警需要让值班的人真正看到。我的做法是双通道回写。第一通道是直接通知。根据priority标签决定通知方式和群组P1电话/短信 核心值班群 自动创建故障群P2核心值班群 值班人P3告警汇总群P4不通知只记录第二通道是监控平台回写。如果有条件把标签回调给Alertmanager那么后续的静默、屏蔽、聚合都可以基于Claude的标签来做。比如让Alertmanager按照“sourcetypescope”做分组聚合就可以天然实现“同一种原因触发的多条告警折叠成一条”。这样告警风暴的问题就能在通知层面得到一定的抑制。优先接P1/P2的告警而不是试图把所有告警都处理掉。Claude Tag落地的第一步不是炫技而是先把通知体验从“让你知道有事”变成“让你知道该怎么办”。4. 值班实战三个场景里Claude Tag带来的改变4.1 场景一告警风暴的自动聚簇有一次周五晚上订单服务的一个实例OOMK8s把Pod反复重启结果一个晚上告警平台刷了两百多条消息容器重启、订单接口5xx、负载均衡健康检查失败、MySQL连接数下降再上升、Redis批量超时……传统on-call在这种场景下值班同学要先手动把所有告警在脑子里串成一条线搞清楚哪个是因、哪个是果才敢确定该怎么处理。用上Claude Tag之后同一个故障时段里Claude处理告警时会参考最近5分钟的处理记录发现这些告警指向同一个根因“order-service实例-OOM重启”于是给全部告警统一打上了sourceapplication、typedependency_failure、scopecore、priorityP1的标签并且在conclusion字段里写“这些告警疑似同源建议按1条P1处理检查order-service内存配置和JVM参数”。值班同学收到达时候不再是一长串刷屏消息而是一条带着聚类结论的P1通知。节省的不仅是看消息的时间更重要的是在慌乱中保持判断力——告警只刷一条“结论”比刷两百条“现象”更能让人冷静下来。这里的实现逻辑不复杂打标服务会维护一个滑动时间窗口把窗口内所有告警先做简单的规则预聚簇比如实例相同、时间段重叠、类型标签相同再让Claude统一生成一段“多告警合并说明”。本质上是用LLM取代了过去SRE靠人工拉群、对时间线、翻日志才能完成的根因串联。4.2 场景二新人第一周就能上手值班on-call值班里最尴尬的时刻不是P1故障处理不了而是新人值班时收到一条告警不知道该不该叫醒别人。叫了可能虚惊一场不叫可能错过黄金处理时间。Claude Tag对新人最友好的地方是直接把“资深SRE的脑内判断”变成了告警消息的一部分。新同学收到的不是冷冰冰的“Threads_connected800”而是“疑似连接池耗尽影响订单创建核心链路建议先查慢查询同时联系DBA确认”。因为Claude的conclusion会说人话新同学哪怕不懂这个组件的原理也能按照结论里的方向去查日志、看大盘、找对应的人。实际上我们团队在接入这套方案之后新同学从入职到独立值班的时间从三周压缩到了一周半——这个数字我没有严格做A/B测试但体感是非常明显的。这里有一个设计细节值得一说conclusion的表述里我会要求Claude尽量带上“建议动作”。比如“建议优先排查”“建议观察5分钟”“建议联系DBA”。值班领域一个准确的建议动作很多情况下比准确的根因描述更有价值。因为在信息不全的时候根因判断可能有误但带着“先查什么”的动作指引不会让人走偏太远。4.3 场景三凌晨值班时先处理哪一个凌晨两点同时来三条告警数据库连接数告警、报表任务失败告警、某个边缘服务的慢查询告警。人脑在困倦状态下很难快速判断优先级尤其是三条告警的原始文本看起来都挺严重。Claude Tag打标之后数据库连接数告警sourcedatabase, typeconnection_exhausted, scopecore, priorityP1报表任务失败告警sourceapplication, typeerror_burst, scopeedge, priorityP3边缘服务慢查询sourceapplication, typelatency_spike, scopeinternal, priorityP3值班同学只要按priority排序去处理即可先响应P1确认数据库连接池是否还有余量、是否需要扩容再抽空扫一眼P3确认是否自动恢复。这个场景里Claude Tag的价值不是替代人的决策而是把决策所需的信息压缩到了几秒可以消费完的程度。人还是做决策的主体——到底是停机扩容还是先观察这需要值班者的经验和判断——但前置信息获取的成本被大幅降低了。5. 交接班与故障复盘打过的标签都能变成资产5.1 交接班简报自动汇总你不在的时间线on-call值班最烦的事之一是交接班。值班人要写清楚昨晚发生了什么、哪些还在处理、哪些需要跟进。没接手过几次交接班的人不知道这份简报写起来又耗时又容易漏——凌晨睡眼惺忪的状态下谁还记得每个时间点发生了什么Claude Tag可以把这个过程也自动化。我的做法是每天早八点让Claude拉取过去24小时所有带标签的告警记录按时间线和优先级自动生成一份交接班简报【on-call交接班简报 2024-06-18】 1. 【P1】订单库连接数告警 - 时间02:13 - 03:40 - 标签database / connection_exhausted / core - 处理DBA介入定位为连接池回收异常调整maxLifeTime后恢复 - 状态已解决建议今天观察高峰期连接池水位 2. 【P3】报表任务失败 - 时间04:20 - 04:50 - 标签application / error_burst / edge - 处理无需处理上游数据延迟导致自动恢复 - 状态待跟进确认数据是否补齐这份简报不需要值班人手写Claude根据告警记录和打标历史生成初稿值班人只需要花两分钟校对补充就行。交接班从“写作文”变成了“改作文”效率提升不是一个量级的。生成简报的提示词也比较简单核心是要求Claude“按时间线分组、只保留事实和动作、状态要用已解决/处理中/待跟进标注”。因为告警上都打了结构化的标签简报的分组和排序不需要模型自己猜直接按标签字段走就行准确率很高。5.2 周维度趋势分析发现“慢性病”告警一次性故障处理完就过去了但on-call团队更需要关注的是“本周哪种类型告警反复出现”。Claude Tag给告警打上类型标签之后周复盘的数据就变得非常好统计。我可以直接按type聚合一周的告警数量得到类似下面的表格type告警次数占比主要来源connection_exhausted1230%订单库、库存库latency_spike1025%商品服务、用户服务capacity_pressure820%消息堆积、磁盘水位error_burst512.5%支付回调config_change37.5%网关配置dependency_failure25%外部API这张表比任何KPI指标都更能说明团队的稳定性状况。connection_exhausted连续两周排在第一位说明连接池配置或者数据库性能存在系统性问题需要做专项优化而不是天天救火。capacity_pressure频繁出现说明容量规划已经滞后需要提前扩容。之前我所在的团队也做周复盘但数据源靠每个人回忆自己值班时处理过的告警要么漏、要么模糊。Claude Tag打标跑通之后复盘会直接从数据说话标签本身就是最原始的记录。5.3 沉淀知识库让Claude的“经验”可以迭代Claude处理告警的判断如果每次用完就丢那这套系统只是帮人省了几秒读告警的时间价值有限。真正让它变成团队资产的办法是把打标结果沉淀成一个“告警处理知识库”。我的做法是每周把已解决告警的标签、conclusion、实际处理过程和结果整理成结构化记录回填到Claude Tag服务的参考知识库里。下次出现类似告警时Claude除了参考服务拓扑信息还会参考这些历史处理记录。比如某个告警第一次出现时Claude可能只能给出“疑似连接池异常”这种泛泛的结论但经过两三次迭代之后知识库里可能已经记录了“该实例连接池异常在过去三次均因maxLifeTime过短触发调整到8小时后恢复”。Claude的conclusion就会从“疑似的方向”变成“可直接执行的命令”这才是真正的经验积累。这一步做起来不难就是一个持续反馈闭环打标结果 → 人工确认/修正 → 回填知识库 → 优化下一次打标质量。需要团队养成修正标签的习惯——值班同学收到告警后如果发现Claude打标明显不准花十秒钟改一下标签这个修正会成为下一次预测的重要依据。6. 落地过程踩过的坑和取舍经验6.1 打标不准的时候别急着调提示词先检查上下文Claude Tag上线第一周我发现它对scope影响面的判断频繁出错经常把核心链路的告警标成edge。一开始我以为提示词写得不够清楚反复加了几轮“订单库是核心”“订单服务是核心”的强调但改善有限。后来排查才发现问题出在服务拓扑信息这一块告警结构化组件里因为CMDB的字段映射写错了instance信息经常丢失Claude拿到手的告警文本里根本没有“10.0.3.21”这个IP自然无法对应到“订单库主实例”是核心链路。把字段映射修好之后scope准确率一下子从七成提升到了九成以上。这个坑给我的教训是LLM应用出的问题一半以上是上游数据质量问题而不是模型能力问题。遇到打标不准不要第一时间怀疑提示词先检查输入数据是否完整、准确、可关联。6.2 控制成本不是每条告警都需要大模型Claude API按token计费如果每条原始告警都丢给Claude处理日均几百上千条告警的成本其实不低尤其是一些高频率重复告警。我在落地时加了两级省钱策略。第一级是规则预过滤。明显无价值的信息类告警比如磁盘使用率超过60%这种有明确阈值且不需要语义推断的直接用规则转发不经过Claude。只有规则无法判断、需要语义理解的告警才走Claude Tag。第二级是上下文缓存复用的精简模式。同一类告警在短时间内反复出现时提示词里的服务拓扑信息、知识库信息可以不重复发送只传增量部分。Claude的prompt caching功能可以降低这部分重复计算的开销实测成本能降低40%左右。算下来中小团队一个月在Claude Tag上的API开销通常就是几十到几百元完全在可接受范围内。用几百块的成本换值班同学每人每天少看半小时告警、少踩几个深夜的坑我觉得性价比极高。6.3 人机协作的闭环标签永远需要人工确认通道最后也是最重要的一个经验Claude Tag可以辅助判断但不能替代人的判断。初期我把部分P1告警设计成“自动创建故障群”的模式后来发现冬天没关、警报蜂鸣的情况还是会发生自动建群全员拉入容易造成疲劳。调整之后我的方案是Claude打出的标签是建议值P1/P2的告警仍然会推送到值班平台由值班同学点击“确认”或“修正”后才正式生效。只有被确认过的P1标签才触发电话和建群动作。这么做不是为了推卸责任而是为了保证“最终判断权在人”。值班同学在工作台上确认标签本质上是在和Claude的结论做一次快速交叉校验。这个校验动作只需要一两秒钟但它能阻止系统性的误判造成更大范围的通知轰炸。修正过的标签也不会被浪费会被记录成反馈数据用来自动评估Claude打标准确率以及定期优化提示词。运行两个月之后我这边Claude Tag对P1告警的判断准确率稳定在了85%左右剩下15%的偏差里有一半是人工可以快速纠正的低危误报另一半是需要新增知识库覆盖的异常类型。说到底Claude Tag不是给on-call值班做“自动驾驶”更像是给每个值班同学配了一个随时在线、读过所有值班手册的副驾。它不能替你打方向盘但能在你困得睁不开眼的时候帮你把路况提前看清楚。 
长河君 · 2026/9/15 1:32:17 · 阅读 1.2k Claude Tag：用大模型语义打标改造on-call值班告警
值班这件事干过的人才懂半夜两点被电话吵醒眯着眼睛打开电脑告警群里已经刷了几百条消息——数据库连接数告警、接口P99延迟飙升、订单积压、磁盘空间不足……每一条看起来都像大事但真正要处理的可能只有一个根因。在on-call值班场景里我们缺的不是告警而是对告警的判断力。这篇文章我想聊聊怎么用Claude Tag这套标签化方案来改造on-call值班流程。Claude Tag并不是某个官方产品而是我在实践中总结出来的方法把值班告警交给ClaudeAnthropic推出的大语言模型做语义理解自动给每一条告警打上结构化的标签让值班同学一眼能看懂“这到底是不是我的问题、影响有多大、该叫谁起来处理”。这套方法适合有告警平台但告警质量差、值班人力紧张、新人上手慢的团队也适合一个人要盯多个系统的SRE和运维工程师参考。我把从告警接入、标签体系设计、提示词编写到值班实战、交接班复盘、成本控制的完整链路整理出来每一步都是踩过坑之后才跑通的方案值得动手试试。1. on-call值班真正缺的不是告警而是“看一眼就懂”的判断力1.1 告警泛滥背后的信息熵问题绝大多数团队的监控告警平台本质上就是一个“消息转发器”。它可以很准时地把Prometheus、Zabbix、云监控的告警推送到钉钉、飞书、Slack或者短信网关但推过来的内容往往是一行裸数据[P1] 10.0.3.21 MySQL Threads_connected 从 128 上升到 800超过阈值 300这条信息有温度、有数值但没有上下文。值班同学看到之后脑子里冒出的问题通常是这个IP是哪个集群的核心业务还是边缘业务Threads_connected上升到800是因为慢查询堆积还是连接池没回收还是上游调用方新增了连接影响范围是只有这一个实例还是整个集群都这样现在是凌晨两点该不该把DBA叫起来还是说等十五分钟看它自己恢复这些问题的答案往往分散在监控大盘、变更记录、日志系统、架构文档里。值班同学要手动去查一查就是十分钟起步。遇到复杂故障等搞清楚状况的时候业务已经受影响半小时了。这里其实隐藏着一个信息熵的问题告警平台的输出是低熵的结构化数值但值班人员需要的是高熵的业务语义。从“MySQL连接数上涨”到“用户登录接口变慢疑似连接池耗尽属于核心链路P1故障”中间隔着大量的关联推理。人脑做这个推理费时费力而大语言模型恰好擅长把分散信息汇总成结论。1.2 Claude Tag给告警装上“语义解释器”Claude Tag的核心思路不复杂在告警推送链路中间加一层“语义打标”处理。当监控系统发出告警时先通过webhook把原始告警发送给一个Claude处理服务Claude读取告警文本、结合预设的标签体系和上下文规则输出结构化标签和一句“人类可读的结论”然后带着这些标签把告警转发到值班群。一个原始告警经过Claude Tag处理之后可能变成这样[P1][核心链][数据库][连接池异常] MySQL连接数突增命中连接池回收失败规则 结论10.0.3.21订单库主实例Threads_connected 800疑似连接长期占用未释放 影响订单创建链路建议优先排查长时间运行的事务和连接池 maxLifeTime 配置。同样是给值班同学看一条消息后者的信息密度完全不一样。收到告警的人不再需要靠猜标签直接把“是不是我的问题”和“该往哪个方向查”说清楚了。这个过程中Claude做的其实是三件事理解告警内容解析指标名、实例、阈值、异常形态、匹配标签体系从预设标签集合中挑选最合适的组合、生成辅助结论用自然语言描述可能的根因和影响。前两件事是结构化能力第三件事是生成式能力两者结合恰好补齐了传统告警最缺的“解释层”。1.3 这套方案和传统监控标签有什么区别有运维经验的朋友可能会说Prometheus的Alertmanager本身就支持标签我们也可以给告警加severity、instance等标签何必再引入一层Claude两种标签的出发点是不同的。传统标签是规则预定义的你需要在配置告警规则时手工写好每个告警的标签组合它是静态的也不会根据告警时的实际上下文发生变化。比如你写了一条“MySQL连接数大于300”的告警规则给它打了“database”和“high”的标签那不管实际是慢查询导致的还是连接池配置导致的标签永远是一样的。Claude Tag的核心差异在于动态语义打标Claude每次处理告警时都是结合当前告警的完整文本、近期的系统变更信息、甚至是同时间段其他告警的相关性来生成标签。同样一条MySQL连接数告警白天业务高峰可能标注为“[预期波动][观察]”凌晨突增可能标注为“[核心链][P1][连接池异常]”标签内容是随上下文变化的。换句话说传统标签是告警规则的附属品Claude Tag标签是告警事件的认知结果。前者适合做静态聚类和权限过滤后者适合辅助值班决策。2. 标签体系怎么设计决定这套方案的上限2.1 四类标签来源、类型、影响面、优先级Claude Tag落地之前最关键的步骤是设计好标签体系。如果标签就随便让Claude自由发挥输出的标签五花八门那后面基于标签的聚合、路由、复盘全都没法做。我在实践过程中把标签收敛成四个维度每个维度下限定可选值Claude只能从候选集里选不能凭空造。来源标签source标识告警来自哪个系统或组件。这个通常和监控对象强相关比如来源标签含义database数据库相关MySQL、PostgreSQL、Redismiddleware中间件Kafka、RocketMQ、Elasticsearchgateway网关层Nginx、API Gatewayapplication业务应用服务infrastructure基础设施CPU、内存、磁盘、网络来源标签的价值在于快速路由——前置通知到哪个团队或值班人。类型标签type标识告警对应的故障模式。这是最有技术含量的一层因为故障模式需要结合运维经验归纳。我常用的是类型标签典型场景connection_exhausted连接池耗尽、连接数突增、线程池打满latency_spike延迟上升、P99超标、超时率增加capacity_pressure容量水位高、磁盘/内存/带宽接近上限error_burst错误率突增、异常堆栈密集出现data_inconsistency数据不一致、主从延迟、消息积压config_change疑似配置变更引发的异常dependency_failure外部依赖服务故障导致的连锁反应类型标签是值班同学最关心的信息它在回答“现在到底发生了什么”。Claude之所以能做这件事是因为它具备从告警描述文本中推理故障模式的常识能力——看到“连接数从128涨到800”会联想到连接池耗尽看到“P99从50ms涨到2000ms”会联想到延迟尖峰。影响面标签scope标识告警影响业务的范围和核心程度。core核心链路用户登录、下单、支付等edge边缘功能报表、后台、非核心接口internal内部系统监控自身、离线任务、数据同步unknown无法判断影响面判断对LLM来说相对难一些因为模型不知道你的业务拓扑。所以在实际落地时我会在系统提示词里把服务列表和核心链路描述贴进去让Claude有据可依。后面第三节会详细讲这部分怎么写。优先级标签priority最终值班同学只需要关心的指标。P1紧急影响核心业务需要立即处理P2严重可能扩大影响面尽快确认P3一般可观测无需立即介入P4信息通知不需要处理2.2 标签系统的“防幻觉”设计LLM打标最大的风险是“一本正经地胡说八道”。模型可能把一条凌晨的偶发告警标成P1也可能把真正核心链路的故障当成边缘告警。为了降低这种风险我做了三个约束。第一标签选择改为“候选集打分”。不是让Claude直接输出他认为是类型的字符串而是把候选标签全部列给Claude让他为每一个候选标签打分最终取最高分。比如请为以下告警评估标签候选类型包括 1. connection_exhausted0-100分 2. latency_spike0-100分 3. capacity_pressure0-100分 4. error_burst0-100分 ... 只输出每个标签的分数。这种“选择而不是创造”的约束能把模型的幻觉空间压缩到一个很小的范围内。第二来源标签和类型标签做组合校验。比如来源是database但Claude给出的类型是capacity_pressure这是合理的但如果来源是gateway类型却给connection_exhausted合理度就比较低。我维护了一个来源-类型二元组的合法性清单打标结果不合法时用兜底规则fallback rule替代比如“误报”或者“unknown”。这个校验逻辑大大减少了离谱标签的出现频率。第三事实型字段强制走规则不走模型。告警里本来就带有的字段比如实例IP、告警级别如果有的话、指标名这些直接通过程序解析提取不需要经过LLM。Claude Tag只负责生成推断型的标签类型、影响面、优先级不负责抽取事实字段。这样即使模型判断失误告警的关键事实也不会丢。2.3 标签不是越多越好刚开始做Claude Tag的时候我犯过的错误之一就是把标签设计得很细什么“write-heavy”“cold-call”“runtime_exception_npe”这种具体到让人头皮发麻的标签都往体系里塞。设计时觉得很完美实际跑起来全是问题一方面是Claude很难从告警文本里准确推断这么细的类型另一方面值班同学看到这种标签仍然需要花时间去理解含义并没有起到“秒懂”的效果。后来我把标签收敛到“能帮助值班者做三秒决策”的程度——来源、类型、影响面、优先级这四个维度加起来不到四十个可选值。设计原理很简单标签是要喂给人看的不是喂给机器玩的。人看一个标签如果能在一秒内知道自己接下来该干什么这个标签就合格了如果还要去翻文档确认标签含义那还不如直接看原始告警。3. 从告警触发到标签回写一条完整的接入链路3.1 接入架构需要的三个部分Claude Tag不是独立部署的一套庞大系统它可以很轻地挂在现有监控平台旁边。我的落地架构分为三块告警入口组件接收监控平台Prometheus Alertmanager、Zabbix、云监控等的webhook消息统一结构化为JSON格式。Claude打标服务一个无状态服务接收结构化告警调用Claude API完成打标并把标签和结论附到原告警上。通知路由组件根据标签把告警发送到不同的钉钉/飞书群或者直接回调Alertmanager更新告警标签。三个部分都可以用很轻的语言实现我的参考实现用的是Python FastAPI部署成单机服务就能扛住中小团队每天几百条告警的量。如果觉得自建服务太重也可以在监控平台和群机器人之间加一个云函数/Lambda原理完全一样。3.2 告警结构化喂给Claude之前先整理好Claude能打出什么质量的标签很大程度取决于喂进去的告警文本整不整齐。我自己是拿Prometheus Alertmanager的webhook做接入的原始结构长这样{ status: firing, alerts: [ { labels: { alertname: MySQLThreadsConnectedTooHigh, severity: page, instance: 10.0.3.21:9104, job: mysql-exporter }, annotations: { summary: MySQL 线程连接数过高, description: Instance 10.0.3.21 MySQL Threads_connected 为 800超过阈值 300 }, startsAt: 2024-06-18T02:13:00Z } ] }如果直接把这段JSON丢给Claude它当然也能读但会在不重要的字段上浪费注意力。我在打标之前先做了一步清洗和富化组装成一个更紧凑的prompt输入告警时间2024-06-18 02:13:00 UTC 告警对象10.0.3.21mysql-exporter 告警规则MySQLThreadsConnectedTooHigh 指标信息MySQL Threads_connected 800阈值 300 当前状态firing如果团队有CMDB或者服务拓扑信息还可以在这一步把“10.0.3.21属于订单库主实例绑定订单服务”这个信息附上去Claude对影响面scope的判断就会准确很多。3.3 打标提示词把规则讲清楚而不是让模型自己发挥这是整套方案里最关键、也最需要反复调的一段。我写提示词的原则是“把值班规则手册原封不动搬给Claude”。下面是一版精简后的打标提示词你是一个资深的SRE告警研判助手。收到一条监控告警后你需要做两件事 1. 为这条告警打上标签 2. 用不超过三句话描述告警的可能原因和影响面。 告警信息 {结构化告警内容} 企业服务信息 - 实例 10.0.3.21订单库主实例承载订单创建/查询属于核心链路 - 实例 10.0.3.22订单库从实例负责报表查询属于边缘链路 - 服务 order-service提供订单创建、查询接口 - 服务 payment-service提供支付回调接口依赖 order-service 候选标签如下仅为候选集合不可自行增加新标签 sourcedatabase / middleware / gateway / application / infrastructure typeconnection_exhausted / latency_spike / capacity_pressure / error_burst / data_inconsistency / config_change / dependency_failure scopecore / edge / internal / unknown priorityP1 / P2 / P3 / P4 打分规则 - 请对每个候选值输出0-100的置信分 - 如果告警信息明显不足所有标签置信分都不得超过40并在结论中注明“信息不足” - 如果判断依据存在冲突遵守以下优先级事实型字段如instance 指标形态 你的领域知识 输出格式严格JSON { source: {value: database, score: 95}, type: {value: connection_exhausted, score: 88}, scope: {value: core, score: 90}, priority: {value: P1, score: 92}, conclusion: 一句话根因判断和影响说明 }注意几个细节服务拓扑信息必须写进去候选标签要给全并声明不可新增输出格式要用JSON固化方便下游解析。这套提示词迭代了大概四五版才稳定下来最早那版只让Claude给结果不分值导致很多低置信度的标签没有兜底后来加了打分制才解决。3.4 回写与路由标签只有用起来才有价值打标完成的告警需要让值班的人真正看到。我的做法是双通道回写。第一通道是直接通知。根据priority标签决定通知方式和群组P1电话/短信 核心值班群 自动创建故障群P2核心值班群 值班人P3告警汇总群P4不通知只记录第二通道是监控平台回写。如果有条件把标签回调给Alertmanager那么后续的静默、屏蔽、聚合都可以基于Claude的标签来做。比如让Alertmanager按照“sourcetypescope”做分组聚合就可以天然实现“同一种原因触发的多条告警折叠成一条”。这样告警风暴的问题就能在通知层面得到一定的抑制。优先接P1/P2的告警而不是试图把所有告警都处理掉。Claude Tag落地的第一步不是炫技而是先把通知体验从“让你知道有事”变成“让你知道该怎么办”。4. 值班实战三个场景里Claude Tag带来的改变4.1 场景一告警风暴的自动聚簇有一次周五晚上订单服务的一个实例OOMK8s把Pod反复重启结果一个晚上告警平台刷了两百多条消息容器重启、订单接口5xx、负载均衡健康检查失败、MySQL连接数下降再上升、Redis批量超时……传统on-call在这种场景下值班同学要先手动把所有告警在脑子里串成一条线搞清楚哪个是因、哪个是果才敢确定该怎么处理。用上Claude Tag之后同一个故障时段里Claude处理告警时会参考最近5分钟的处理记录发现这些告警指向同一个根因“order-service实例-OOM重启”于是给全部告警统一打上了sourceapplication、typedependency_failure、scopecore、priorityP1的标签并且在conclusion字段里写“这些告警疑似同源建议按1条P1处理检查order-service内存配置和JVM参数”。值班同学收到达时候不再是一长串刷屏消息而是一条带着聚类结论的P1通知。节省的不仅是看消息的时间更重要的是在慌乱中保持判断力——告警只刷一条“结论”比刷两百条“现象”更能让人冷静下来。这里的实现逻辑不复杂打标服务会维护一个滑动时间窗口把窗口内所有告警先做简单的规则预聚簇比如实例相同、时间段重叠、类型标签相同再让Claude统一生成一段“多告警合并说明”。本质上是用LLM取代了过去SRE靠人工拉群、对时间线、翻日志才能完成的根因串联。4.2 场景二新人第一周就能上手值班on-call值班里最尴尬的时刻不是P1故障处理不了而是新人值班时收到一条告警不知道该不该叫醒别人。叫了可能虚惊一场不叫可能错过黄金处理时间。Claude Tag对新人最友好的地方是直接把“资深SRE的脑内判断”变成了告警消息的一部分。新同学收到的不是冷冰冰的“Threads_connected800”而是“疑似连接池耗尽影响订单创建核心链路建议先查慢查询同时联系DBA确认”。因为Claude的conclusion会说人话新同学哪怕不懂这个组件的原理也能按照结论里的方向去查日志、看大盘、找对应的人。实际上我们团队在接入这套方案之后新同学从入职到独立值班的时间从三周压缩到了一周半——这个数字我没有严格做A/B测试但体感是非常明显的。这里有一个设计细节值得一说conclusion的表述里我会要求Claude尽量带上“建议动作”。比如“建议优先排查”“建议观察5分钟”“建议联系DBA”。值班领域一个准确的建议动作很多情况下比准确的根因描述更有价值。因为在信息不全的时候根因判断可能有误但带着“先查什么”的动作指引不会让人走偏太远。4.3 场景三凌晨值班时先处理哪一个凌晨两点同时来三条告警数据库连接数告警、报表任务失败告警、某个边缘服务的慢查询告警。人脑在困倦状态下很难快速判断优先级尤其是三条告警的原始文本看起来都挺严重。Claude Tag打标之后数据库连接数告警sourcedatabase, typeconnection_exhausted, scopecore, priorityP1报表任务失败告警sourceapplication, typeerror_burst, scopeedge, priorityP3边缘服务慢查询sourceapplication, typelatency_spike, scopeinternal, priorityP3值班同学只要按priority排序去处理即可先响应P1确认数据库连接池是否还有余量、是否需要扩容再抽空扫一眼P3确认是否自动恢复。这个场景里Claude Tag的价值不是替代人的决策而是把决策所需的信息压缩到了几秒可以消费完的程度。人还是做决策的主体——到底是停机扩容还是先观察这需要值班者的经验和判断——但前置信息获取的成本被大幅降低了。5. 交接班与故障复盘打过的标签都能变成资产5.1 交接班简报自动汇总你不在的时间线on-call值班最烦的事之一是交接班。值班人要写清楚昨晚发生了什么、哪些还在处理、哪些需要跟进。没接手过几次交接班的人不知道这份简报写起来又耗时又容易漏——凌晨睡眼惺忪的状态下谁还记得每个时间点发生了什么Claude Tag可以把这个过程也自动化。我的做法是每天早八点让Claude拉取过去24小时所有带标签的告警记录按时间线和优先级自动生成一份交接班简报【on-call交接班简报 2024-06-18】 1. 【P1】订单库连接数告警 - 时间02:13 - 03:40 - 标签database / connection_exhausted / core - 处理DBA介入定位为连接池回收异常调整maxLifeTime后恢复 - 状态已解决建议今天观察高峰期连接池水位 2. 【P3】报表任务失败 - 时间04:20 - 04:50 - 标签application / error_burst / edge - 处理无需处理上游数据延迟导致自动恢复 - 状态待跟进确认数据是否补齐这份简报不需要值班人手写Claude根据告警记录和打标历史生成初稿值班人只需要花两分钟校对补充就行。交接班从“写作文”变成了“改作文”效率提升不是一个量级的。生成简报的提示词也比较简单核心是要求Claude“按时间线分组、只保留事实和动作、状态要用已解决/处理中/待跟进标注”。因为告警上都打了结构化的标签简报的分组和排序不需要模型自己猜直接按标签字段走就行准确率很高。5.2 周维度趋势分析发现“慢性病”告警一次性故障处理完就过去了但on-call团队更需要关注的是“本周哪种类型告警反复出现”。Claude Tag给告警打上类型标签之后周复盘的数据就变得非常好统计。我可以直接按type聚合一周的告警数量得到类似下面的表格type告警次数占比主要来源connection_exhausted1230%订单库、库存库latency_spike1025%商品服务、用户服务capacity_pressure820%消息堆积、磁盘水位error_burst512.5%支付回调config_change37.5%网关配置dependency_failure25%外部API这张表比任何KPI指标都更能说明团队的稳定性状况。connection_exhausted连续两周排在第一位说明连接池配置或者数据库性能存在系统性问题需要做专项优化而不是天天救火。capacity_pressure频繁出现说明容量规划已经滞后需要提前扩容。之前我所在的团队也做周复盘但数据源靠每个人回忆自己值班时处理过的告警要么漏、要么模糊。Claude Tag打标跑通之后复盘会直接从数据说话标签本身就是最原始的记录。5.3 沉淀知识库让Claude的“经验”可以迭代Claude处理告警的判断如果每次用完就丢那这套系统只是帮人省了几秒读告警的时间价值有限。真正让它变成团队资产的办法是把打标结果沉淀成一个“告警处理知识库”。我的做法是每周把已解决告警的标签、conclusion、实际处理过程和结果整理成结构化记录回填到Claude Tag服务的参考知识库里。下次出现类似告警时Claude除了参考服务拓扑信息还会参考这些历史处理记录。比如某个告警第一次出现时Claude可能只能给出“疑似连接池异常”这种泛泛的结论但经过两三次迭代之后知识库里可能已经记录了“该实例连接池异常在过去三次均因maxLifeTime过短触发调整到8小时后恢复”。Claude的conclusion就会从“疑似的方向”变成“可直接执行的命令”这才是真正的经验积累。这一步做起来不难就是一个持续反馈闭环打标结果 → 人工确认/修正 → 回填知识库 → 优化下一次打标质量。需要团队养成修正标签的习惯——值班同学收到告警后如果发现Claude打标明显不准花十秒钟改一下标签这个修正会成为下一次预测的重要依据。6. 落地过程踩过的坑和取舍经验6.1 打标不准的时候别急着调提示词先检查上下文Claude Tag上线第一周我发现它对scope影响面的判断频繁出错经常把核心链路的告警标成edge。一开始我以为提示词写得不够清楚反复加了几轮“订单库是核心”“订单服务是核心”的强调但改善有限。后来排查才发现问题出在服务拓扑信息这一块告警结构化组件里因为CMDB的字段映射写错了instance信息经常丢失Claude拿到手的告警文本里根本没有“10.0.3.21”这个IP自然无法对应到“订单库主实例”是核心链路。把字段映射修好之后scope准确率一下子从七成提升到了九成以上。这个坑给我的教训是LLM应用出的问题一半以上是上游数据质量问题而不是模型能力问题。遇到打标不准不要第一时间怀疑提示词先检查输入数据是否完整、准确、可关联。6.2 控制成本不是每条告警都需要大模型Claude API按token计费如果每条原始告警都丢给Claude处理日均几百上千条告警的成本其实不低尤其是一些高频率重复告警。我在落地时加了两级省钱策略。第一级是规则预过滤。明显无价值的信息类告警比如磁盘使用率超过60%这种有明确阈值且不需要语义推断的直接用规则转发不经过Claude。只有规则无法判断、需要语义理解的告警才走Claude Tag。第二级是上下文缓存复用的精简模式。同一类告警在短时间内反复出现时提示词里的服务拓扑信息、知识库信息可以不重复发送只传增量部分。Claude的prompt caching功能可以降低这部分重复计算的开销实测成本能降低40%左右。算下来中小团队一个月在Claude Tag上的API开销通常就是几十到几百元完全在可接受范围内。用几百块的成本换值班同学每人每天少看半小时告警、少踩几个深夜的坑我觉得性价比极高。6.3 人机协作的闭环标签永远需要人工确认通道最后也是最重要的一个经验Claude Tag可以辅助判断但不能替代人的判断。初期我把部分P1告警设计成“自动创建故障群”的模式后来发现冬天没关、警报蜂鸣的情况还是会发生自动建群全员拉入容易造成疲劳。调整之后我的方案是Claude打出的标签是建议值P1/P2的告警仍然会推送到值班平台由值班同学点击“确认”或“修正”后才正式生效。只有被确认过的P1标签才触发电话和建群动作。这么做不是为了推卸责任而是为了保证“最终判断权在人”。值班同学在工作台上确认标签本质上是在和Claude的结论做一次快速交叉校验。这个校验动作只需要一两秒钟但它能阻止系统性的误判造成更大范围的通知轰炸。修正过的标签也不会被浪费会被记录成反馈数据用来自动评估Claude打标准确率以及定期优化提示词。运行两个月之后我这边Claude Tag对P1告警的判断准确率稳定在了85%左右剩下15%的偏差里有一半是人工可以快速纠正的低危误报另一半是需要新增知识库覆盖的异常类型。说到底Claude Tag不是给on-call值班做“自动驾驶”更像是给每个值班同学配了一个随时在线、读过所有值班手册的副驾。它不能替你打方向盘但能在你困得睁不开眼的时候帮你把路况提前看清楚。