数据质量告警太多没人看——告警降噪与分级响应实战

-- ❌ 错误：固定阈值
-- 周末DAU天然低，每周末都报警
ALERT IF dau < 100000;
 
-- ✅ 正确：动态基线（PSI/MAD/STL）
WITH baseline AS (
  SELECT day_of_week,
         PERCENTILE_APPROX(dau, 0.05) AS p5,
         PERCENTILE_APPROX(dau, 0.95) AS p95
  FROM dwd_dau
  WHERE dt BETWEEN DATE_SUB('${bizdate}', 90) AND DATE_SUB('${bizdate}', 1)
  GROUP BY day_of_week
)
SELECT today.dau, b.p5, b.p95
FROM (SELECT dau, EXTRACT(DOW FROM dt) AS dow FROM dwd_dau
      WHERE dt = '${bizdate}') today
JOIN baseline b ON today.dow = b.day_of_week
WHERE today.dau NOT BETWEEN b.p5 AND b.p95;
-- 仅当超出该星期几的P5-P95范围才告警

# 抑制规则
def should_suppress(alert):
    # 规则1: 上游已报警 → 下游同因告警抑制
    upstream_alerts = get_active_alerts_in_lineage(alert.table, direction='upstream')
    if any(a.severity in ['P0', 'P1'] for a in upstream_alerts):
        return True, '上游已报警'
    
    # 规则2: 计划内停机时段抑制（升级、回归）
    if in_maintenance_window(alert.table):
        return True, '维护窗口'
    
    # 规则3: 重试中的任务不告警最终失败（除非耗尽）
    if alert.task.retry_count < alert.task.max_retries:
        return True, '重试中'
    
    # 规则4: 同维度组24小时内已告警过同类问题 → 抑制
    if has_similar_alert_recent(alert, hours=24):
        return True, '24小时内已报'
    
    return False, None

抑制规则最考验设计——抑制太严会漏报，抑制太松会刷屏。生产实践里我用「上游优先」原则：上游有故障，下游全部抑制（带链接到上游告警），让值班只关注根因。

降噪手段四：聚合与收敛

同一类告警短时间内多条，应该合并成一条「影响N个对象」而不是N条独立告警。

# 聚合规则示例
# 5分钟内同类型告警合并
 
class AlertAggregator:
    def __init__(self, window=300):
        self.buffer = defaultdict(list)
        self.window = window
    
    def add(self, alert):
        # 按「告警类型+表族（前缀）」分组
        key = (alert.rule_type, alert.table.split('_')[0])
        self.buffer[key].append(alert)
    
    def flush(self):
        for key, alerts in self.buffer.items():
            if len(alerts) == 1:
                send(alerts[0])  # 只有一条，正常发
            else:
                # 多条聚合
                send(Alert(
                    title=f'{key[0]}: {len(alerts)}个表受影响',
                    detail=f'tables: {[a.table for a in alerts]}',
                    level=max(a.level for a in alerts)
                ))

典型场景：上游同步任务挂了，下游50张表全部数据延迟——别发50条「数据延迟」告警，发1条「dwd_*族50张表延迟」。

告警平台的工程架构

[规则引擎] 检测出问题
    ↓
[抑制层] 是否在抑制范围？
    ↓ (no)
[聚合层] 是否要合并已有告警？
    ↓
[降级层] 是否降级到P2？
    ↓
[路由层] 按级别选择通道
    ↓                    
  P0电话/钉钉@all   P1钉钉@值班   P2日报
    ↓
[反馈闭环] 值班标记「真异常/误报」
    ↓
  [自学习] 调整阈值/抑制/分级规则

人工反馈闭环（最关键的长效机制）

再聪明的算法也不如人工反馈。每条告警出去都要让值班快速标记「真异常 / 误报 / 已知问题」。这些标记数据反过来训练系统：

# 反馈数据训练
feedback_data = load_alert_feedback(last_30_days)
 
# 找误报率高的规则 → 提高阈值或加抑制
high_fp_rules = feedback_data.groupby('rule_id').agg(
    fp_rate=('label', lambda x: (x == 'false_positive').mean())
).query('fp_rate > 0.5')  # 误报>50%的规则
 
for rule_id in high_fp_rules.index:
    auto_adjust_threshold(rule_id)
    notify_owner(rule_id, 'High FP rate, threshold adjusted')
 
# 找漏报（事后被业务方发现的故障，但DQC没报） → 补规则
missed_incidents = get_business_incidents() - get_alerted_incidents()
for incident in missed_incidents:
    propose_new_rule_for(incident)

面试高频追问

追问一：告警量从多到少的过程怎么推动？

分阶段：第一阶段「记录」——所有告警先全发，记录30天；第二阶段「分析」——按规则分组算误报率，TOP10误报源头改造；第三阶段「分级」——按业务影响严格分级；第四阶段「抑制+聚合」——加规则；第五阶段「反馈」——值班标记+自学习。我在出海硬件公司用了三个月走完这五阶段，告警量从100条/天降到月均10条。关键是「先充分记录再优化」，凭感觉调阈值容易越调越乱。

追问二：告警太少会不会漏报？怎么防？

防漏报靠「事后审计」——每个真实业务故障复盘时，必查「为什么DQC没报」。如果是规则缺失就补规则；如果是阈值过松就调阈值；如果是抑制错了就改抑制规则。生产实践里我每月做一次告警审计，对比业务故障清单和告警清单，找出「漏报」案例，针对性补充。

追问三：跨团队的告警怎么协同？

两个机制：①告警owner明确——每条告警都有responsible team和ack timeline，不能群里@一下没人管；②升级机制——P0未在SLA内ack自动升级到上级。出海硬件公司告警平台支持「值班轮询」，跨团队主动找人，避免「谁都没看到」。

实战踩坑：告警群被全员屏蔽的故事

我刚到出海硬件公司时，数据质量告警群里日均200+条告警。过了两周我发现一个现象——没有人在群里ack或讨论。问值班同学才知道：整个团队都把这个群设为静默了，因为太吵了，重要消息根本看不见。

当周就发生过一个故障：业务方早上9点说「报表数据明显错了」，查日志发现凌晨3点告警群里其实报过一条P0告警，但被淹没在183条P2告警里。值班同学没看到，业务方先发现。

解决方案：立刻做了三件事：

1）拆群——P0/P1单独群（少而精）、P2进日报群（不打扰）

2）规则审计——TOP20最高频规则全部review，60%关闭或调阈值

3）值班SOP——P0群每条告警必须15分钟内ack，否则自动升级

教训：告警系统的成功标准不是「报得多」，是「真出事时被人看到」。如果告警刷屏到无人看，再智能的系统都失败了。降噪不是技术问题，是产品问题——告警是给人看的，必须考虑人的注意力极限。

总结

告警降噪四手段：分级+动态阈值+抑制+聚合，配合人工反馈闭环。关键指标不是告警量，是「真异常被ack的速度」。面试时按四手段+反馈闭环+群被屏蔽的故事讲，能体现你不只懂技术还懂运营。

下一篇聊一个看起来高大上但有真用的话题：数据质量左移——从被动监控到主动预防的体系建设。

你们告警群是什么状态？日均多少条？评论区聊聊～

关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长