1. 数据质量事故的定义与分类
聊数据治理，绕不开一个话题——数据质量事故。说白了，就是数据出了问题，影响了业务决策，甚至造成了真金白银的损失。我在一线干了这么多年，见过太多因为数据质量翻车的案例。今天咱们就把这个基础概念掰开揉碎了讲清楚。
1.1 什么是数据质量事故
数据质量事故，指的是数据在采集、传输、存储、处理或使用过程中，偏离了预期的质量标准，导致数据不可用、不可信或产生错误业务结果的事件。
举个例子你就明白了。我曾在某电商平台遇到过这样的事：促销活动当天，后台的库存数据延迟更新了15分钟。结果呢？用户下单成功，仓库却没货可发。最后只能给用户赔券、道歉，活动ROI直接打对折。这就是典型的数据质量事故。
核心判断标准：数据是否满足业务场景的“适用性”。数据再全、再准，如果业务用不上，那就是质量事故。
我个人习惯把数据质量事故分成两类：
- 显性事故：一眼就能看出来，比如报表数字为负、字段全是NULL。
- 隐性事故：表面看着正常，但逻辑错了。比如订单金额汇总少了几个渠道的数据，这种最坑人。
1.2 常见事故类型
业内公认的数据质量维度有六个，但日常复盘时，我们重点关注四个最容易出事的维度。我按踩坑频率排个序：
| 维度 | 定义 | 典型场景 | 我见过的真实案例 |
|---|---|---|---|
| 完整性 | 数据是否缺失 | 用户注册信息缺少手机号 | 某CRM系统迁移后，20%的客户地址字段为空，销售团队无法做区域分析 |
| 准确性 | 数据是否真实反映客观事实 | 订单金额多了一位小数 | 财务对账时发现总账差了300万，最后定位是汇率表更新脚本写错了 |
| 一致性 | 不同系统间的数据是否对齐 | CRM和ERP中同一客户的名称不同 | 两个系统用不同的编码规则，导致客户画像合并时出现大量重复 |
| 时效性 | 数据是否在预期时间内可用 | 实时大屏延迟5分钟 | 双十一大屏数据延迟，运营团队凭经验调价，多花了200万营销预算 |
避坑指南：我曾经以为“准确性”是最重要的，后来发现“完整性”问题才是真正的隐形杀手。数据缺失了，你连错在哪儿都不知道。建议监控优先级：完整性 > 时效性 > 准确性 > 一致性。
1.3 事故等级划分
事故等级怎么定？不能拍脑袋。我建议按“影响范围”和“影响程度”两个维度来评估。下面这张图是我在团队里一直用的分级模型：
等级划分不是一成不变的。我建议每季度复盘一次分级标准，因为业务在变，数据的重要性也在变。举个例子，去年你们可能觉得用户画像数据是P3，今年上了精准营销，它就变成P2了。
我的经验：定级时别只看技术指标。一定要拉上业务方一起定。我曾经遇到过技术团队觉得是P4的事故，业务方直接炸毛——因为那条“异常数据”恰好是CEO要看的核心指标。所以，定级标准要业务和技术双签。
1.4 事故复盘的起点
搞清楚了定义和分类，下一步才能谈复盘。你想想看，如果连事故是什么、有多严重都说不清楚，复盘就是扯淡。
我个人习惯在事故发生后，第一时间做三件事：
- 定级：按上述模型确定P几，决定响应速度。
- 冻结现场：保留事故时刻的数据快照和日志，别急着修。
- 通知干系人：按等级通知对应层级的人，P1要直接拉群叫上CTO。
嗯，这里要注意一点：很多团队一上来就查代码、修bug，结果复盘时发现根因根本不在代码里，而是上游数据源的问题。所以，先定级、再定位，顺序别搞反了。