值班室的屏幕上挂着三十多条告警规则，凌晨两点响过一条，第二天上午才有人点开，发现是某台机器的磁盘用了 81%。用 AI 整理这些规则之前，团队先做了一件事：把通知静音。告警系统从那天起还在运行，但已经没人看它了。
一条告警的唯一标准，是有人要立刻动手
判断某个指标该不该告警，问一句就够：它响的时候，有没有人必须放下手里的事去处理。有，就是告警；没有，就该进看板。这条标准听起来简单，落到具体指标上却常被搞混，因为「重要」和「紧急」经常被当成一回事。
容量趋势、慢查询数量、错误日志条数，这些重要但不紧急，适合放进看板等人定期看。用户可感知的错误率突增、核心链路不可用、关键资源接近耗尽，这些才值得打断人的睡眠。第三类指标从告警里挪出去，噪音会立刻降一大截。
四步，把三十条规则压到八条
| 步骤 | 产出物 | 常见坑 |
|---|---|---|
| 盘存量 | 一张规则清单：指标、阈值、近三个月触发次数、上次有效时间 | 只看名字不看历史，删掉真正救过火的规则 |
| 定动作 | 每条规则后面写一句「响了谁做什么、多久内做完」 | 写不出动作还留着，等于给噪音发通行证 |
| 收敛与延时 | 同一故障合成一条，抖动要求持续若干分钟才触发 | 合并过头，一个故障只剩一句「服务异常」，反而没法定位 |
| 建复盘 | 每月每条规则的触发次数与有效次数对照 | 只统计数量不看有效性，噪音永远删不掉 |
表格里第三步最容易做过头。收敛的目标是让一个故障只叫一次，不是把所有异常糊成一条。合理的做法是保留一个「总入口」告警加若干「细节」看板，人被叫起来之后再去翻细节。
日志字段先定死，再谈分析
一份能用的日志，至少要能回答四个问题：什么时候、哪个服务、哪次请求、结果如何。对应到字段就是时间戳、级别、服务名、请求标识、耗时、状态码，再加上版本号和部署环境。请求标识最容易被省掉，也最不该省——没有它，一次跨五个服务的调用在日志里就是五段互不相识的记录。
另一半是禁止记录的内容：身份证号、手机号、银行卡号、令牌、密码、完整的请求体。这些字段要在写入前处理，不能等查日志时再遮。脱敏做在采集端，日志被导出、被转发、被贴进工单时才不会出事。
分级按响应动作分，不按严重程度分
P0 到 P3 这种分法在很多团队里失效，是因为分级依据是「感觉多严重」。换一个依据会清楚很多：P0 是必须立刻有人上线处理，P1 是当天工作时间内处理，P2 是排进本周，P3 只记录。级别对应动作和时限，规则才有约束力。
分级还要和值班人数匹配。三个人轮值的团队设五级，最后一定退化成「全都当 P0」。级别数量少一点，每级的动作写具体一点，比分级精细更有用。
让模型出结构，判断留在人这边
把系统规模、服务数量、现有规则清单、最近一个月的告警记录交给模型，让它做三件事通常效果不错：找出语义重复的规则、给每条规则补一列「触发后的动作」、按业务链路把指标归组。它擅长把散乱的东西排成表，不擅长判断哪条规则值得留。
提示词里建议明确输出格式，比如要求它输出三列表：指标、建议级别、建议动作，并在动作一栏写不出内容时标为「建议删除」。这个约束会逼它暴露哪些规则本来就空着。写法上的细节可以对照提示词那篇。它也可能编出不存在的指标名或字段名，看着像你们系统里的东西，实际一查没有，这类补全和AI 幻觉是同一套机制。
规则能整理，阈值不能外包
它看不到你们的业务峰值在几点，也不知道一次支付失败对用户意味着什么，更不知道这个季度有几个人值班。所以它给的阈值只能当草稿：先按历史数据的分位数起一个初始值，上线后观察两周，再按误报率调整。直接把它写的数字贴进配置，通常会得到两种结果——要么天天响，要么该响的时候不响。
另外三个环节不在它的管辖范围：告警通道本身挂了，这时任何规则都不会响，需要独立的探活；一个故障引发十条告警，得靠收敛策略而不是靠模型；指标口径改了，历史基线就失效，参考数据漂移里讲的「模型没错、数据变了」。这三件事都要靠工程手段兜住。
规范要少而硬，落到检查项上
写二十条建议没人记得住，把三条做成上线检查项才有用：新增告警必须写明触发后的动作；同一故障的多条告警必须声明收敛关系；连续三个月没有产生有效告警的规则必须复核。检查项挂在发布流程里，规范才会被执行。
剩下的是节奏。每月花半小时看一遍规则清单，按触发次数排序，把前十名逐条问「上次响的时候有人动手吗」。这个动作坚持半年，噪音会自己降下来。
速查：告警与日志规范
- 有人必须立刻动手的才叫告警，其余进看板
- 每条规则后面写清谁、做什么、多久内完成
- 请求标识是串起跨服务日志的唯一线索
- 敏感字段在写入前脱敏，不留到查询时处理
- 每月对照触发次数与有效次数，无效规则复核
