数据质量出问题业务先发现——指标的监控告警和SLA怎么定？

「这个数怎么是0？」「DAU怎么变成负数？」——业务方在BI上发现问题、然后发邮件骂数据团队，是最丢人的工作模式。这道题考的是主动发现问题的能力——从指标监控、SLA定义、告警分级到值班响应。我在某出海硬件品牌做指标治理时建立了一套完整的监控告警体系，把"业务先发现"事故从月均5起降到0，下面拆给你看。

业务场景：业务先发现的连续3次事故

出海硬件品牌V0时期连续3周发生「业务先发现」事故：

Markdown

## 事故复盘
 
| 周次 | 现象 | 根因 | 业务影响 |
| --- | --- | --- | --- |
| W1 | 印度GMV显示0 | 上游印度库连接断开6小时 | 周报数据缺失 |
| W2 | DAU跳到原来3倍 | 测试账号没过滤上线 | CEO误判 |
| W3 | 客单价为负 | 退款金额没限制取整 | BI报表崩溃 |
 
## 共性：数据团队全部是被业务投诉后才知道

CDO直接拍桌："再有下次，整个团队OKR降级"。从那以后我把监控告警建成了P0项目，3个月把事故清零。

方法一：3层监控架构

数据质量监控分3层，每层都不能少：

方法二：可达性监控（最基础）

数据没到 = 数据是错的。先解决这层。我用Airflow Sensor + 自研Watchdog两套机制：

# 1. 分区到达检查（每张核心表必须有）
@task
def check_partition_arrival(table, dt, expected_time):
    if not partition_exists(table, dt):
        elapsed = now() - expected_time
        if elapsed > timedelta(hours=2):
            send_alert(level='P0', table=table,
                       message=f'{table}/{dt} 已延迟2小时')
        elif elapsed > timedelta(minutes=30):
            send_alert(level='P1', ...)
        return False
    return True
 
# 2. ETL任务状态监控
for task in core_etl_tasks:
    if task.status == 'failed':
        send_alert(level='P0', task=task)
    elif task.duration > task.sla * 1.5:
        send_alert(level='P1', task=task, message='SLA即将违规')

出海硬件品牌每张核心表都接了这套监控，可达性问题从W1事故的6小时盲区，缩短到平均10分钟内告警+值班介入。

方法三：完整性监控（量级异常）

行数突变是最常见的数据问题。基线告警公式：

-- 行数同比/环比双重检查
WITH today AS (
  SELECT COUNT(*) AS cnt FROM dwd_order_pay WHERE dt='${today}'
), yesterday AS (
  SELECT COUNT(*) AS cnt FROM dwd_order_pay WHERE dt=DATE_SUB('${today}',1)
), last_week AS (
  SELECT COUNT(*) AS cnt FROM dwd_order_pay WHERE dt=DATE_SUB('${today}',7)
)
SELECT
  today.cnt AS today_cnt,
  (today.cnt - yesterday.cnt) * 1.0 / yesterday.cnt AS dod_rate,  -- 环比
  (today.cnt - last_week.cnt) * 1.0 / last_week.cnt AS wow_rate   -- 同比
FROM today, yesterday, last_week;
 
-- 告警条件：环比变化>30% 且 同比变化>20% （双确认）
-- 单一维度变化容易误报（比如周末环比一定下降），双确认才靠谱