2、数据质量规则体系
数据质量规则体系是灰度验证的核心骨架。在 API 发布前，我们需要从 质量维度 和 规则粒度 两个正交视角来构建规则，确保覆盖所有潜在的数据缺陷。
2.1 数据质量维度
数据质量维度定义了“好数据”的衡量标准。在 API 场景中，我们重点关注以下五个维度：
| 维度 | 定义 | API 场景示例 |
|---|---|---|
| 完整性 | 数据记录或字段是否存在缺失 | 用户注册接口中，手机号字段不可为 NULL 或空字符串 |
| 准确性 | 数据值是否真实反映客观事实 | 订单金额必须与实际支付金额一致，且符合业务精度（如两位小数） |
| 一致性 | 同一数据在不同系统或字段间是否逻辑自洽 | 用户主表中的“用户状态”与订单表中的“用户 ID”对应的状态必须匹配 |
| 及时性 | 数据从产生到可被访问的延迟是否在预期内 | 交易流水必须在 5 秒内写入数据库，否则视为超时异常 |
| 唯一性 | 数据实体是否存在重复记录 | 同一身份证号在用户表中只能出现一次 |
灰度验证提示： 在灰度阶段，建议优先验证 完整性 和 唯一性 规则，因为它们通常能快速暴露接口逻辑或数据映射的底层缺陷。
2.2 规则分类
根据规则作用的范围，我们将数据质量规则分为三个层级：字段级、记录级和跨表级。层级越高，验证的复杂度也越高。
- 字段级规则： 针对单个字段的值域、格式、长度、枚举值进行校验。例如：
age字段必须在 0-150 之间；email字段必须符合正则表达式^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$。 - 记录级规则： 针对单条记录内多个字段之间的逻辑关系进行校验。例如：
start_date必须早于end_date；total_price必须等于unit_price * quantity。 - 跨表级规则： 针对不同数据表或 API 响应之间的数据关联进行校验。例如：订单表中的
product_id必须在商品表中存在；用户表中的dept_id必须与部门表中的主键一致。
规则分类与维度的关系： 一个规则可以同时属于多个维度。例如，“订单金额必须等于商品单价乘以数量”既是 准确性 规则，也是 记录级 规则。
2.3 规则定义模板
为了在灰度验证中实现自动化执行，每条规则都需要按照标准模板进行定义。以下是一个推荐的规则定义结构：
{
"ruleId": "RULE-001",
"ruleName": "用户手机号格式校验",
"dimension": "完整性",
"category": "字段级",
"scope": "user_api_response",
"field": "phone",
"condition": "IS NOT NULL AND LENGTH = 11",
"severity": "ERROR",
"expectedResult": "PASS"
}
常见误区： 不要将规则定义得过于宽泛。例如，“所有字段都不能为空”是一条无效规则，因为它没有指定字段名和业务上下文。每条规则必须精确到具体的 API 字段和业务场景。
2.4 规则优先级与灰度策略
在灰度验证中，并非所有规则都需要同时执行。我们根据规则的 严重级别 和 影响范围 制定分阶段执行策略：
- P0（阻塞级）： 字段级完整性、唯一性规则。一旦失败，立即阻断灰度流量。
- P1（严重级）： 记录级准确性、一致性规则。失败后记录告警，灰度流量降级 50%。
- P2（警告级）： 跨表级一致性、及时性规则。失败后仅记录日志，不影响灰度流量。
最佳实践： 在灰度初期，建议只开启 P0 和 P1 规则，待 API 稳定运行 24 小时后，再逐步开启 P2 规则。这样可以避免因规则过于严格而导致灰度验证无法推进。