第一步：问题定义与范围界定
数据质量根因追踪，说白了就是一场「破案」。
你想想看，如果连案发现场都描述不清楚，连受害范围都搞不明白，那后面的调查方向肯定跑偏。我见过太多团队，一上来就急着查代码、翻日志，结果忙活了两周，发现查的根本不是同一个问题。
所以，第一步必须稳。咱们得把三件事做扎实：清晰描述问题、界定影响范围、设定可量化目标。
1.1 清晰描述数据质量问题
很多同学描述问题时喜欢说「数据不准」「报表有误」。这种描述太模糊了，没法定位。我个人习惯用 5W1H 框架来结构化描述：
| 要素 | 说明 | 示例 |
|---|---|---|
| What | 什么数据出了问题？ | 订单表中的「实付金额」字段 |
| Where | 在哪个系统/环节发现的？ | BI 报表系统，每日销售看板 |
| When | 什么时间发现的？持续多久了？ | 2024-03-15 发现，至少持续 3 天 |
| Who | 谁发现的？谁受影响？ | 运营部张经理，影响财务对账 |
| Why | 初步判断原因是什么？ | 疑似上游接口字段映射错误 |
| How | 具体表现是什么？ | 实付金额比实际少 10%，约 5000 条记录异常 |
我的小习惯：每次接到数据质量工单，我都会先拿这个框架填一遍。填完之后，问题基本就清晰了。如果某个要素填不出来，说明信息还不够，需要继续追问。
1.2 界定影响范围
问题描述清楚后，下一步就是「画圈」。这个圈画多大，直接决定了后续排查的资源投入。
我建议从三个维度来界定：
- 数据维度：涉及哪些表？哪些字段？数据量有多大？
- 业务维度：影响了哪些业务流程？哪些部门？哪些下游系统？
- 时间维度：从什么时候开始出问题的？是偶发还是持续？
举个例子。我在项目中遇到过类似情况：某电商平台的「用户积分」字段出现异常。一开始运营说「积分不对」，范围很模糊。后来我们按三个维度一梳理：
- 数据维度：涉及用户积分表、积分流水表，约 12 万条记录异常
- 业务维度：影响积分商城兑换、会员等级计算、大促活动发券
- 时间维度：从 3 月 10 日系统升级后开始，持续至今
这么一圈定，排查范围就清晰了。我们直接锁定了 3 月 10 日的系统升级，而不是漫无目的地查所有代码。
注意：范围界定要「适度」。圈太大，排查成本高；圈太小，可能漏掉根因。我曾经就吃过亏，一开始只圈了「订单表」，结果根因在「商品表」的关联逻辑里，白白浪费了两天时间。
1.3 设定可量化的目标
没有目标，就没法判断问题是否解决。我建议用 SMART 原则来设定目标：
- S（Specific）：目标要具体。比如「修复订单金额字段」而不是「修复数据」
- M（Measurable）：目标要可量化。比如「准确率达到 99.9%」
- A（Achievable）：目标要可实现。别一上来就定 100% 准确率
- R（Relevant）：目标要和问题相关。别跑偏去优化性能
- T（Time-bound）：目标要有时间限制。比如「48 小时内修复」
举个例子，一个完整的目标描述应该是：
目标：在 48 小时内，将「订单实付金额」字段的数据准确率从当前的 90% 提升至 99.9%，并确保积分商城兑换功能恢复正常。
你看，这个目标具体、可量化、有时间限制，后续验证起来也很方便。
1.4 知识体系总览
下面这张图，把第一步的核心逻辑串起来了。你可以把它当作一个检查清单，每次做问题定义时对照着走一遍。
1.5 避坑指南
做这一步时，有几个坑我踩过，分享给你：
- 描述太笼统：「数据不对」这种描述，排查时根本没法用。一定要具体到字段、时间、表现。
- 范围界定太窄：只盯着眼前的问题表，忽略了上下游依赖。我建议至少问一句「这个数据被谁消费了？」
- 目标定得太虚：「尽快修复」不是目标，「48 小时内修复到 99.9% 准确率」才是。
我的经验：这一步花的时间越多，后面排查就越快。我一般会花整个根因追踪 20% 的时间在问题定义上。别急着动手，先把问题说清楚。
嗯，到这里，第一步的核心内容就讲完了。记住：问题定义清晰了，根因追踪就成功了一半。