告警风暴里 先救值班员的注意力
凌晨两点，手机震了。不是一个告警，是一屏幕。支付超时、接口 5xx、数据库连接池满、容器重启、磁盘 IO 飙高。值班的人先干嘛？先看哪个红得最厉害。这很荒诞，但这是现场。
很多团队买了一大堆可观测性工具，指标、日志、链路都有。告警数量也跟着涨。原来一个应用一个告警，现在一个 Pod 一次重启能带出十几条。人不是被故障打败的，是被噪音拖垮的。
所以 AIOps告警降噪与根因定位的目标，不是把 AI 吹成神。是让值班员在三十秒内判断：这事大不大，要不要叫人，先看哪条。做不到这个，后面全是白搭。
降噪也不是删告警。删错了，比不删更贵。漏掉一条核心链路超时，可能比看一百条无用告警更疼。
降噪的坑 多半不在阈值
不少团队一上来就调阈值。CPU 超过 90% 才报，内存超过 95% 才报。世界安静了两天。第三天，交易慢查询把连接池打满，CPU 没炸，告警也没响。麻烦在于，静态阈值只懂线，不懂业务的形状。
更靠谱的做法通常有几步。先去重。同一台机器同一故障反复报，合并成一条。再抑制。父依赖挂了，子节点告警没必要全弹出来。然后聚类。把同一时间窗、同一拓扑邻域、同一错误码的告警归堆。最后关联。把指标、日志、链路、变更拉到同一张时间轴上。
去重解决重复，抑制解决依赖，聚类解决相似，关联解决因果候选。四件事听着简单，做起来全是脏活。因为拓扑不一定准，标签不一定齐，服务名在 K8s 里还可能变来变去。
动态基线也有用。比如按小时、按天、按大促周期做分位数，别拿凌晨三点的流量去卡中午的峰值。但动态基线不是万能药。业务突变、版本发布、缓存雪崩，都会让基线暂时失效。这时候需要变更事件来兜底。
说个短的。见过一个团队，把告警按服务分组后，值班群从每天上千条降到几十条。结果有次数据库主从切换，抑制规则把从库告警全压了，主库又没配复制延迟告警。安静了四十分钟。后来他们加了一条：抑制规则必须带过期时间，关键依赖禁止永久静默。
根因定位 别把相关当因果
根因定位最容易犯的错，是看到 A 和 B 一起波动，就说 A 导致 B。相关性很便宜，因果很贵。尤其在微服务里，一个下游超时能引发上游重试，上游重试又能压垮另一个下游。看起来到处都是因，其实源头只有一个。
怎么找源头？先看拓扑。调用关系、主机依赖、数据库主从、消息队列、缓存集群。再看时间。谁先异常，谁后异常。时间差不一定准，但能排除一批。然后看变更。发布、配置、扩缩容、网络策略、证书过期。很多故障不是系统自己坏的，是有人动了东西。
根因定位的候选集，通常来自三条线：拓扑上游、时间先行、变更邻近。三条线交叉的地方，嫌疑最大。别急着全自动。先做排序，给人一个可解释的列表。
可解释很重要。如果你告诉值班员“AI 认为是网关”，他没法信。你得告诉他：网关的 5xx 在 02:13 先起，下游订单服务在 02:15 超时，02:10 有一次网关配置变更，且变更前后错误码分布变了。这才叫证据链。
自动化的边界 人能兜底什么
告警降噪与根因定位，做到最后都是边界问题。哪些能自动关，哪些只能建议，哪些必须叫人。一刀切全自动，迟早出事。全手动，值班员又会被淹死。
我的偏见是：低风险、重复性高、可验证的告警，可以自动抑制或合并。涉及资金、登录、核心写入链路的，宁可多弹一条，也别悄悄吞掉。根因定位可以自动给出几个怀疑对象，但不要自动执行回滚。回滚这种动作，代价太大，得有人签字。
还有一点，别忽略反馈。值班员点“忽略”或者“确认根因”，这些动作要回流到模型。不然规则会越来越老，最后变成没人敢改的祖传配置。工具是活的，拓扑是活的，业务也是活的。
这事没那么玄。AIOps告警降噪与根因定位，本质是把运维经验变成可计算、可验证、可回滚的规则和模型。算法重要，数据质量更重要。数据质量里，最贵的不是存储，是标签和拓扑的准确性。
凌晨两点的手机，最好只响一次。响的那次，得值得。