数据 SLA 是什么
SLA 把「什么时候必须可用」变成可度量的承诺：按表或按数据产品设定承诺时间、依赖上游、责任人与违约动作，再统计达成率与超时原因分布。它不只是对外的承诺，更是内部资源分配的依据——SLA 高的任务优先获得算力与调度优先级，长期超时的链路必须有人跟进优化。没有 SLA，数据可用时间就只能靠感觉，业务与数据团队之间也就没有共同的判定标准。
基本信息
| 要素 | 承诺时间、依赖上游、责任人、违约动作（升级路径） |
|---|---|
| 指标 | 达成率、平均产出时间、P90 产出时间、超时原因分布 |
| 机制 | 临近承诺时间的预警与超时后的升级通知 |
| 记录 | 产出时间自动登记到配置表对应的日志表 |
| 分级 | 核心表与次要表设置不同的承诺时间与违约动作 |
| 复核 | 定期复核承诺时间是否仍与数据量与上游节奏匹配 |
典型使用场景
- 核心报表保障：明确早间报表所依赖表的承诺时间，倒排调度优先级
- 对外承诺：面向业务或客户的数据交付时间需要书面化
- 资源分配依据：按 SLA 级别划分队列与算力优先级
- 运维改进：用超时原因分布定位长期拖尾的链路
- 复盘依据：事故复盘时用 SLA 达成与否作为客观判定标准
承诺时间登记与统计
承诺时间登记与统计
CREATE TABLE etl_sla_config (
table_name STRING, promise_time STRING, owner STRING, level STRING
);
-- 达成情况：ready_time 为产出时间，promise_time 为承诺时间
SELECT c.table_name, c.level, c.promise_time, l.ready_time,
CASE WHEN l.ready_time <= c.promise_time THEN 1 ELSE 0 END AS sla_ok
FROM etl_sla_config c
JOIN etl_task_ready_log l ON c.table_name = l.table_name
WHERE l.dt = '2026-10-11'
ORDER BY sla_ok, c.level;达成率与超时原因分布
达成率与超时原因分布
-- 近 14 天达成率与平均延后时长
SELECT dt,
COUNT(1) AS cnt,
ROUND(SUM(sla_ok) / COUNT(1), 4) AS sla_rate,
ROUND(AVG(TIMESTAMPDIFF(MINUTE, promise_time, ready_time)), 1) AS avg_delay_min
FROM etl_sla_daily
WHERE dt >= DATE_SUB(CURRENT_DATE, 14)
GROUP BY dt ORDER BY dt;
-- 超时原因分布：定位是上游延迟、资源竞争还是数据量激增
SELECT delay_reason, COUNT(1) AS cnt
FROM etl_sla_daily
WHERE dt >= DATE_SUB(CURRENT_DATE, 30) AND sla_ok = 0
GROUP BY delay_reason ORDER BY cnt DESC;SLA 要素与判定
| 要素 | 说明 | 常见问题 |
|---|---|---|
| 承诺时间 | 必须可用的时刻 | 定得过紧，长期在违约边缘 |
| 依赖上游 | 决定承诺时间是否可达 | 上游无承诺，下游承诺就是空头 |
| 责任人 | 超时后的第一联系人 | 无责任人，告警无人认领 |
| 违约动作 | 升级路径与通知范围 | 只告警不升级，问题反复出现 |
| 统计口径 | 产出时间的定义 | 按任务结束时间算，实际数据还不可查 |
SLA 谈判要留出上游波动余量：把承诺时间卡在上游平均完成时刻，遇到数据量增长就会长期处于违约边缘，最终双方都不再认真对待这个指标。
SLA 只统计任务结束时间而不统计数据真正可用的时间，报表仍可能读空：产出时间应以数据对下游可见为准，而不是以任务进程退出为准。