11.2 数据质量 SLO 与事件响应：检查失败后系统应该怎样做
清晨的任务表突然变成空表，下游报告仍按时发布，直到指挥官发现全军出勤率是零。管道“成功”只说明代码没有抛异常；数据服务是否可用，还取决于新鲜度、完整性、语义和可恢复性。
本课目标
- 根据用途选择质量维度与可计算 SLI；
- 区分 SLI、SLO、SLA 和 error budget；
- 为检查失败设计阻断、隔离、降级与告警；
- 建立从检测、处置到预防复发的数据事件流程。
1. 质量是相对于用途的适用性
常见维度包括：
| 维度 | 问题 | 例子 |
|---|---|---|
| 完整性 | 必需信息是否存在 | 已完成任务必须有 completed_at |
| 有效性 | 值是否符合声明规则 | 状态属于版本化枚举 |
| 准确性 | 是否反映现实 | 库存与经盘点的实物一致 |
| 一致性 | 系统/字段间是否矛盾 | 汇总金额等于明细合计 |
| 唯一性 | 业务实体是否被重复表示 | 每个任务版本键唯一 |
| 完整性约束 | 关系是否成立 | 每条日志的任务外键存在 |
| 新鲜度/时效性 | 是否在需要时可用 | 截止 08:00 已覆盖前一日 |
这些不是唯一“行业六维度”，也不能统一打分代替规则。age > 0 检查的是有效性，不证明年龄准确；字符串包含 @ 也不证明邮箱真实。
2. 从业务失败推导规则
优先问“什么错误会让决定失真”：
业务失败：出勤报告把未同步前哨当作零出勤
数据条件：每个应报前哨都有当日批次；批次状态为 complete
SLI：按时收到的应报前哨数 / 应报前哨总数
SLO：工作日 08:00 时覆盖率达到约定目标
处置：不足时冻结正式报告，展示上一成功版本和缺失前哨
owner：出勤数据产品负责人规则要说明粒度、窗口、分母、时区、例外和版本。泛泛的“NULL 率低于 5%”可能允许关键字段全空，也可能错误拒绝业务上允许缺失的列。
3. SLI、SLO 与 SLA
- SLI：实际测量，例如 30 天内按时批次数比例；
- SLO：内部目标，例如关键批次的及时可用率；
- SLA：与客户/组织约定的承诺及未达成后果；
- error budget：在目标窗口内允许的不可靠量，用于平衡变更与稳定性。
不要把响应时间、修复时间和数据可用时间混成一个字段。可分别定义：
detect time：异常发生到检测
acknowledge time：告警到有人接手
mitigate time：恢复可用或启用降级
resolve time：根因修复并补齐数据目标值必须来自消费者截止时间和错误成本，不应从一张模板复制。
4. 规则分层与处置动作
行级约束
类型、枚举、范围、条件必填、主外键等。错误行可隔离，但要避免其余行形成错误总体。
批次级约束
行数、分区覆盖、唯一键、对账、分布和新鲜度。失败可能阻止整批发布。
跨系统与业务约束
账实一致、漏斗守恒、状态机合法和关键指标关系。通常需要业务 owner 判断。
每条规则预先选择动作：
- fail closed：阻断发布，适合错误代价高且有 fallback；
- quarantine：隔离批次/记录并保留证据；
- degrade：使用上个成功版本或减少功能；
- warn：继续发布但显著标注限制；
- observe only：建立基线，尚不触发生产动作。
“先全部接受再慢慢改”和“任何异常都拒绝”都不是普遍正确，需根据可逆性、下游影响和恢复能力决定。
5. 契约检查与可观测性互补
契约检查验证已知不变量，例如键唯一、schema 兼容。可观测性用于发现未预先枚举的变化，例如分布、量级、延迟或血缘异常。
简单三标准差告警容易失败：样本太少、标准差为零、趋势和星期效应都会制造噪音。更稳妥的基线需要：
- 按星期、节假日和季节比较；
- 使用稳健分位数或适合计数的模型；
- 记录变更/活动日历；
- 对多指标告警做聚合和抑制；
- 在报警中附带受影响分区、血缘和 runbook。
异常检测只能提示“不同”，不能证明“错误”。
6. 质量结果本身也要版本化
一条检查记录至少包含：
dataset/version/partition
rule_id 与 rule_version
observed value 与 expected condition
sample denominator
status 与 severity
evaluation time
code/input version
owner、incident 和处置状态规则修改后，历史通过率可能不可直接比较。保留版本才能解释趋势，也能在争议时重放。
7. 数据事件响应
1. 检测：确认不是监控自身故障
2. 分级：按决定影响、范围、可逆性和敏感性
3. 遏制：停止错误发布、撤回版本或启用 fallback
4. 通知：告知 owner、消费者和预计下一次更新
5. 修复：修代码/来源并从可信 checkpoint 回填
6. 验证：规则、对账和下游关键指标通过
7. 恢复：按顺序重启消费者并监控
8. 复盘：补控制、负责人和截止时间质量修复不能只改当前表。通过血缘识别已经消费错误数据的报告、模型和外发文件，并决定是否重算、撤回或通知。
8. 避免告警疲劳
- 告警必须可行动且有 owner；
- 同一根因产生的下游告警应聚合；
- 维护窗口和已知变更应抑制预期噪音；
- 按严重性选择 pager、工单或仪表盘；
- 统计误报、无人认领和长期静音；
- 没有 runbook 的高优先级告警应降级或补齐处置。
严重性由业务影响决定，不是“偏离基线百分比”自动决定。
常见误区
- 管道成功就代表数据可用：代码完成与语义正确是两件事。
- 每张表跑同一套阈值最标准：质量依赖粒度、用途和错误成本。
- 准确性可由格式检查证明：需要权威来源、抽查或现实对账。
- 异常越多告警越安全：无人处理的告警等于没有控制。
练习
- 为每日出勤表定义三个 SLI、对应 SLO 和消费者截止时间。
- 给五条质量规则选择 fail、quarantine、degrade、warn 或 observe。
- 构造带星期季节性的行数序列，解释三标准差告警为何误报。
- 演练空表发布，列出所有需要撤回或重算的下游资产。
小结
数据质量不是一张维度评分表，而是一套服务运行机制：明确什么失败会伤害决定，用 SLI 测量，用 SLO 排序资源，并在失败后有可验证的遏制、修复与恢复路径。
下一章进入元数据与血缘：要找到受影响资产和负责人，系统必须知道数据是什么、由什么版本生成、流向哪里。