数据指标 SLA报表准时不代表指标可信一、SLA 不能只看任务成功很多数据团队把 SLA 理解成调度任务准时完成。确实任务失败会影响报表使用但指标可信度不只取决于任务状态。数据是否完整、口径是否变更、上游是否延迟、质量规则是否通过同样决定看板能不能被使用。指标 SLA 应该描述这个指标在什么时间、什么质量条件下可以被信任而不是只描述任务有没有跑完。为什么任务成功 ≠ 指标可信这件事容易被忽视因为大多数调度系统Airflow、DolphinScheduler的 DAG 状态只有三种成功、失败、运行中。任务标记为成功只说明 SQL 跑完了没报错不代表数据是对的。上游 ODS 表延迟了 30 分钟你的 DWD 任务仍然能成功——它只是扫了一个还没更新完的表。业务方看到报表准时出了拿去给老板汇报回头发现数据差了一大截。SLA 的任务是防止这种事发生——在报表被人使用之前先自检一遍数据是否真的可用。二、指标 SLA 要覆盖链路flowchart TD A[上游数据到达] -- B[清洗任务完成] B -- C[质量校验通过] C -- D[指标产出] D -- E[BI 刷新] E -- F[可用状态]任何一环异常都可能让指标不可用。上游日志延迟、维表未更新、质量规则失败、BI 缓存没刷新都应该进入 SLA 视野。metric_sla: metric: daily_gmv ready_before: 09:30 max_delay_minutes: 20 require_quality_pass: true notify_on_partial_data: truerequire_quality_pass很关键。任务跑完但质量没过指标不应该显示成正常。为什么require_quality_pass是 SLA 里最重要的字段因为质量校验是在任务成功之后但数据可用之前的最后一道关卡。如果昨天 GMV 的日环比波动在 ±5% 以内今天突然涨了 200%质量规则应该捕获并暂停 SLA。没有这个字段SLA 只会告诉业务方数据在 09:30 之前出了不会告诉业务方这个数据可能是错的。三、状态要面向使用者type MetricStatus { metric: string status: ready | delayed | partial | failed updatedAt: string reason?: string }BI 看板可以把指标状态展示出来。比如数据已更新至 08:50上游支付流水延迟今日 GMV 暂不可用于最终判断。这比静默展示一个不完整数字更负责。指标状态还要区分 partial 和 failed。部分数据可用时运营可能可以观察趋势但不能做最终结论完全失败时则需要隐藏或标红。四、SLA 要和通知闭环绑定指标延迟时通知对象要明确。数据工程师需要知道任务和日志分析师需要知道哪些看板受影响业务方需要知道数据能不能用。一个告警打给所有人只会让每个人都觉得和自己无关。sla_notification: data_engineer: message: task_and_table analyst: message: metric_and_dashboard business_user: message: availability_and_eta还要记录 SLA 违约原因。长期因为同一个上游延迟说明应该改采集或调整指标发布时间长期因为质量规则误报说明规则需要重新校准。SLA 不是用来贴罚单的而是发现系统性问题。指标口径变更也要进入 SLA。如果今天任务准时完成但 GMV 口径刚改过且没有通知下游仍然会误读。可信指标不仅要准时还要可解释、可追踪。最后可以给核心指标做可用性月报准时率、质量通过率、延迟原因、影响看板、平均恢复时间。数据团队用这些指标管理自己的交付质量才算把工程化落到实处。SLA 还要和指标等级绑定。核心经营指标可以要求更早产出、更严格质量校验和更快恢复低频分析指标则可以接受较长延迟。所有指标使用同一套 SLA看似公平实际会浪费资源。metric_sla_tier: p0: ready_before: 09:00 max_recovery_minutes: 30 p2: ready_before: 12:00 max_recovery_minutes: 240分级之后团队才能把工程投入放在真正影响决策的指标上。为什么 SLA 分级不是内卷而是资源优化一个常见的错误是给 200 个指标全设ready_before: 09:00。结果 ETL 每天早上 6 点到 9 点跑满集群资源所有指标都抢计算和 IO。P0 指标比如 GMV、DAU可能只需要 5 个表的数据但因为 P2 指标比如新手引导第 37 步的点击率也在同时跑全量聚合占用了大批资源导致 P0 被拖慢了 20 分钟。SLA 分级就是给 P0 留快车道8:00-9:00 集群只跑 P0 任务9:00 以后再来跑 P2。这不是优待某个指标是保证最重要的事情先完成。 踩坑提醒不要把ready_before设成任务的schedule_interval 1 分钟。许多团队设任务 8:00 跑SLA 9:00 前完成看起来留了一小时 buffer。但上游日志如果延迟了 40 分钟才到任务 8:40 才开始跑9:00 根本完不成。ready_before应该从业务的用数时间倒推而不是从调度时间正推。如果业务 9:00 开会要用数SLA 至少设 8:30预留 30 分钟应急窗口。partial 状态不标注原因等于没标注。看板上显示数据部分可用但不说哪些维度缺失、缺了多少运营还是不敢用。标准格式是2026-07-01 GMV已完成省份维度31省中有 28省缺失广东/浙江/江苏上游支付流水延迟预计 10:30 补齐。给具体的、可操作的信息。SLA 违约告警不能只发钉钉/企微要落到 BI 看板的指标状态栏上。因为业务方开会时不一定看手机但一定在看报表。如果看板上每个指标旁边有一个小绿灯/黄灯/红灯看一眼就知道哪些指标能信、哪些不能信——这才是 SLA 的最终价值不是给数据团队看的是给用数的人看的。五、总结数据指标 SLA 要覆盖任务、质量、上游、BI 刷新和口径变更最终面向使用者给出可用状态。报表准时不代表指标可信。真正的 SLA是让读者知道什么时候可以放心用数据做决策。