3. SLA核心概念
在风险数据治理中，我们经常遇到一个尴尬场景：数据已经产出，但业务方拿到时已经错过了决策窗口。此时再讨论数据质量、准确性、完整性，意义都会大打折扣。SLA（Service Level Agreement，服务级别协议）正是用来解决“及时性”这一维度的核心治理工具。它把模糊的“尽快提供”转化为可度量、可追责、可改进的承诺。
一、SLA的定义与本质
SLA是服务提供方与消费方之间就服务内容、服务水平、责任边界达成的正式约定。在风险数据治理语境下，SLA特指数据从产生、加工、校验到交付给消费方的全链路时间承诺与质量承诺。它的本质不是一份文档，而是一组可观测的契约参数。
一个典型的风险数据SLA条款包含三个关键信息：交付物（哪张表、哪个指标、哪个接口）、时间窗口（每日几点前、T+几、事件触发后几分钟内）、达标标准（准时率、延迟容忍度、数据完整性阈值）。缺少任何一项，SLA都会退化为口号。
核心判断：SLA是否有效，不取决于写了多少页，而取决于是否能用一条SQL或一个监控指标直接判定“今天是否达标”。
二、SLA的组成要素
完整的风险数据SLA通常由以下要素构成，缺一不可：
- 服务对象：明确消费方是谁，如风控决策引擎、监管报送系统、反洗钱分析平台。
- 数据范围：表名、字段、分区、接口路径，避免“所有风险数据”这类模糊表述。
- 时间承诺：交付时间点、频率、时区、节假日规则。
- 质量阈值：准时率目标（如99.5%）、数据完整率、关键字段非空率。
- 度量方式：监控点位置、采集频率、计算口径、统计周期。
- 责任矩阵：数据产生方、加工方、平台方、消费方各自承担什么。
- 违约处理：告警升级路径、补偿机制、复盘触发条件。
| 要素 | 示例 | 常见缺失后果 |
|---|---|---|
| 服务对象 | 反洗钱报送系统 | 无人认领延迟告警 |
| 时间承诺 | 每日07:30前 | “尽快”无法考核 |
| 质量阈值 | 准时率≥99.5% | 偶发延迟被忽视 |
| 度量方式 | 调度完成时间戳 | 口径争议不断 |
| 责任矩阵 | 上游源系统负责推送 | 互相推诿 |
| 违约处理 | 延迟15分钟升级至值班经理 | 问题反复发生 |
三、SLA与OLA、UC的关系
很多团队把SLA、OLA、UC混为一谈，导致内部责任无法落地。三者是层层支撑的关系：
- SLA（服务级别协议）：面向外部或最终消费方的承诺，回答“用户能感受到什么”。
- OLA（运营级别协议）：内部团队之间的支撑承诺，回答“为了兑现SLA，各团队必须做到什么”。
- UC（支持合同/底层合同）：与供应商或第三方签订的支撑条款，回答“外部依赖如何保障”。
举例：风控决策引擎要求每日07:30前拿到风险名单，这是SLA。数据平台团队承诺06:50前完成加工，这是OLA。云厂商承诺数据库可用性99.95%，这是UC。三者时间必须逐层倒推、留出缓冲，否则SLA必然被击穿。
四、SLA在风险数据治理中的作用
SLA不是孤立的运维指标，它贯穿风险数据治理的多个环节：
- 定义及时性基线：把“及时”变成可量化目标，为监控和考核提供依据。
- 驱动链路优化：通过倒推各环节耗时，定位瓶颈任务和冗余依赖。
- 明确责任边界：当延迟发生时，快速判断是源系统、加工逻辑还是平台调度问题。
- 支撑监管合规：监管报送对时间有硬性要求，SLA是证明“可控”的关键证据。
- 促进跨团队协同：OLA把内部承诺显性化，减少口头约定和扯皮。
实践提示：建议把SLA监控点前移到“数据可用”而非“任务成功”。任务成功不等于数据可消费，中间可能还有校验、发布、缓存刷新等步骤。
五、常见误区与复盘
误区一：SLA只写时间，不写质量。结果数据准时到达但大量为空，消费方依然无法使用。时间与质量必须同时约束。
误区二：SLA与OLA时间相同。没有缓冲，任何上游抖动都会直接击穿SLA。正确做法是逐层预留5～15分钟缓冲。
误区三：监控点选在调度系统。调度显示成功，但数据实际未发布到消费方。监控点应尽量靠近消费方入口。
误区四：没有违约复盘机制。SLA告警后无人跟进，同样的问题每周重复。应设定延迟超过阈值自动触发复盘。
-- SLA达标率计算示例（按日统计）
SELECT
biz_date,
COUNT(*) AS total_tasks,
SUM(CASE WHEN deliver_time <= sla_deadline THEN 1 ELSE 0 END) AS on_time,
ROUND(SUM(CASE WHEN deliver_time <= sla_deadline THEN 1 ELSE 0 END) * 100.0 / COUNT(*), 2) AS sla_rate
FROM risk_data_delivery_log
WHERE biz_date >= DATE_SUB(CURRENT_DATE, INTERVAL 30 DAY)
GROUP BY biz_date
ORDER BY biz_date DESC;
复盘要点：一次SLA违约至少回答三个问题——延迟发生在哪个环节？该环节是否有OLA覆盖？监控是否提前发现？如果三个问题中有两个答不上来，说明SLA体系尚未真正落地。
总结来看，SLA是风险数据及时性治理的“契约层”，OLA是“支撑层”，UC是“依赖层”。只有三层对齐、时间倒推、监控前移、复盘闭环，SLA才能从纸面承诺变成可运营的治理能力。