研发数据质量校验要长期运转，需要把规则、执行配置和问题处置沉淀成可复用的表格。本文提供规则清单、校验配置、问题记录三张空白表，用同一套规则编号串联，并给出字段口径、必填判断、一条规则的完整填写示例和维护方法。规则与问题记录可以承载在ONES的工作项和文档中，便于状态流转与复核留痕。
要点总览（TL;DR）
- 研发数据质量校验可沉淀三张表：规则清单定义校验什么、怎么判定、谁负责；校验配置落到数据源、执行频率与告警渠道；问题记录承接校验结果并闭环。
- 三张表用同一规则编号串联，规则编号一经分配不再复用，从任一问题可追溯到判定条件与责任人。
- 规则清单的规则编号、校验对象、字段、规则类型、判定条件、责任人为必填；校验配置的规则编号、数据源、执行频率为必填；问题记录的问题编号、关联规则编号、发现时间、修复状态为必填。
- 规则类型建议覆盖完整性、唯一性、有效性、一致性、及时性五类，一条规则只归一类。
- 规则增删改需留痕并设固定复核周期，建议每季度复核一次，数据源或流程大调整时临时增加。
可复制空白模板：规则清单、校验配置与问题记录
三张表分工明确：规则清单回答“校验什么、怎么判定、谁负责”，校验配置回答“在哪里执行、多久执行一次、异常通知谁”，问题记录回答“发现了什么问题、影响多大、是否修完”。填写顺序是先规则清单，再校验配置，最后用问题记录承接校验结果。三张表通过“规则编号”关联，规则编号一经分配不再复用。
表一：规则清单
| 规则编号 | 校验对象 | 字段 | 规则类型 | 判定条件 | 严重级别 | 责任人 | 处置方式 |
|---|---|---|---|---|---|---|---|
表二：校验配置
| 规则编号 | 数据源 | 执行频率 | 告警渠道 | 豁免条件 | 生效时间 |
|---|---|---|---|---|---|
表三：问题记录
| 问题编号 | 关联规则编号 | 发现时间 | 影响范围 | 修复状态 | 复盘结论 |
|---|---|---|---|---|---|
关联方式：规则清单中的一条规则对应校验配置中的一行执行设置，可以是一对一，也可以在多个数据源上分别配置；校验触发后产生的问题统一登记到问题记录，并回填对应的规则编号。这样从任一问题都能追溯到判定条件和责任人，从任一规则也能查到历史问题与修复情况。
字段说明：每个字段填什么、怎么判断
字段口径统一，不同团队填出来的表才能互相对照。以下按三张表逐项说明，规则类型单独列出取值。
规则清单字段
| 字段 | 填写口径 |
|---|---|
| 规则编号 | 唯一标识，建议采用“对象缩写-序号”形式，如 REQ-001，停用后编号保留不复用 |
| 校验对象 | 被校验的数据实体，如需求、缺陷、迭代、工时记录 |
| 字段 | 具体被校验的字段或字段组合，如“需求关闭时间”“缺陷所属迭代” |
| 规则类型 | 从完整性、唯一性、有效性、一致性、及时性中选取，一条规则只归一类 |
| 判定条件 | 可执行的判断表达式或自然语言描述，需能明确区分通过与否，如“关闭时间早于创建时间即判为异常” |
| 严重级别 | 按对度量结论的影响划分，如高（导致指标失真）、中（影响局部统计）、低（展示瑕疵） |
| 责任人 | 负责该规则定义与解释的角色或人员，通常为数据负责人或指标负责人 |
| 处置方式 | 校验不通过时的动作，如阻断入库、标记异常、通知责任人、进入问题记录 |
校验配置字段
| 字段 | 填写口径 |
|---|---|
| 规则编号 | 引用规则清单中的编号，不另行编码 |
| 数据源 | 规则实际执行的数据位置，如项目管理系统、代码仓库、工时系统或汇总数据集 |
| 执行频率 | 校验运行节奏，如每日、每周、每次数据同步后 |
| 告警渠道 | 异常结果送达的位置，如工作项、群消息、邮件 |
| 豁免条件 | 允许不触发告警的情形，如历史数据迁移期、特定项目类型 |
| 生效时间 | 该配置开始执行的日期，修改配置时保留原生效区间 |
问题记录字段
| 字段 | 填写口径 |
|---|---|
| 问题编号 | 唯一标识，建议按发现顺序编号，如 DQ-2024-001 |
| 关联规则编号 | 触发该问题的规则，一条问题对应一条主规则，涉及多条时在复盘结论中说明 |
| 发现时间 | 校验实际发现异常的日期，与规则执行时间一致 |
| 影响范围 | 受影响的数据量、时间区间、涉及项目或指标，用于判断优先级 |
| 修复状态 | 建议取值：待处理、处理中、已修复、已豁免、不修复（需注明理由） |
| 复盘结论 | 问题根因、修复动作与是否需要调整规则或配置 |
规则类型取值说明
- 完整性：必填字段是否为空，如需求必须有负责人。
- 唯一性：是否存在重复记录，如同一需求被重复创建。
- 有效性：取值是否在允许范围内，如状态值属于既定枚举。
- 一致性：跨表或跨系统数据是否吻合，如缺陷所属迭代与迭代起止时间匹配。
- 及时性：数据是否在规定时限内更新，如工时记录是否按周填报。
必填与选填：哪些字段不能空
必填的判断标准是：缺了它，规则无法被唯一识别、无法执行或无法追责。其余字段可按团队成熟度逐步补齐。
| 表 | 必填字段 | 选填字段 | 留空风险与补填时机 |
|---|---|---|---|
| 规则清单 | 规则编号、校验对象、字段、规则类型、判定条件、责任人 | 严重级别、处置方式 | 严重级别留空会导致问题优先级无法排序；处置方式留空会导致校验失败后无人跟进。规则上线前应补齐 |
| 校验配置 | 规则编号、数据源、执行频率 | 告警渠道、豁免条件、生效时间 | 告警渠道留空则异常只能靠人工查看；豁免条件留空可能造成历史数据误报；生效时间留空不利于追溯配置变更。涉及跨系统数据或存在豁免场景时必须补填 |
| 问题记录 | 问题编号、关联规则编号、发现时间、修复状态 | 影响范围、复盘结论 | 影响范围留空难以判断处理优先级；复盘结论留空则同类问题会反复出现。问题关闭前应补齐复盘结论 |
填写示例：一条规则从登记到闭环
以下示例为演示情景，展示三张表如何用同一规则编号串联，字段与前述说明保持一致。
规则清单中的一行
| 规则编号 | 校验对象 | 字段 | 规则类型 | 判定条件 | 严重级别 | 责任人 | 处置方式 |
|---|---|---|---|---|---|---|---|
| REQ-001 | 需求 | 关闭时间 | 有效性 | 需求关闭时间早于创建时间即判为异常 | 高 | 效能数据负责人 | 标记异常并登记问题记录 |
校验配置中的一行
| 规则编号 | 数据源 | 执行频率 | 告警渠道 | 豁免条件 | 生效时间 |
|---|---|---|---|---|---|
| REQ-001 | 项目管理系统需求数据集 | 每日 | 数据质量工作项 | 历史数据迁移期内的存量需求 | 2024-03-01 |
问题记录中的一行
| 问题编号 | 关联规则编号 | 发现时间 | 影响范围 | 修复状态 | 复盘结论 |
|---|---|---|---|---|---|
| DQ-2024-007 | REQ-001 | 2024-03-12 | 3 个项目的 12 条需求，影响需求周期统计 | 已修复 | 批量导入时未校验时间字段，已在导入环节增加校验，规则保持不变 |
一致性核对：示例中的规则编号、字段名、规则类型与判定条件均与字段说明一致；问题记录中的关联规则编号指向 REQ-001，修复状态使用建议取值，复盘结论说明了根因与是否需要调整规则。团队照此格式填写，即可保证三张表可互相追溯。
调整与维护方法：规则增删、版本与定期复核
规则清单会随组织流程和数据源变化而失效，维护机制要在建表时一并确定。
新增、停用与修改规则
- 新增：先分配新规则编号，填写规则清单，再补校验配置，确认执行后再纳入问题记录跟踪。
- 停用：在规则清单中标注停用日期与原因，保留原编号；同步停用校验配置，避免继续产生无效告警。
- 修改：判定条件或严重级别变化时，记录变更前后内容与变更人，校验配置的生效时间按新配置重新登记。
版本与变更留痕
建议在规则清单中增加版本列或单独维护变更记录表，记录每次变更的日期、变更人、变更内容与影响范围。规则编号不变、内容变化时，通过版本号区分，历史问题记录仍指向原规则编号，复盘时可对照当时版本。
定期复核
- 周期：建议每季度复核一次，数据源或组织流程发生较大调整时临时增加一次。
- 责任人：由效能数据负责人牵头，各规则责任人确认本人规则是否仍适用。
- 复核内容：规则是否仍对应有效字段、判定条件是否产生大量误报、豁免条件是否过期、问题记录中反复出现的问题是否需要新增规则。
规则增长后的分类与归档
规则数量增加后，可按校验对象或规则类型分组编号，便于检索；长期停用的规则移入归档区，保留编号与历史问题关联，不直接删除。规则与问题记录可以登记在ONES工作项中，通过状态字段推进修复与复核，相关口径说明沉淀在文档里，便于团队按同一版本执行。
常见问题
规则清单里的判定条件写成自然语言描述可以吗？
可以，前提是描述能明确区分通过与否。例如“需求关闭时间早于创建时间即判为异常”这类表述，人和校验程序都能据此判断。如果后续要接入自动校验，建议在自然语言描述旁补充可执行的表达式或字段比较逻辑，避免同一规则出现两种理解。判定条件涉及多个字段组合时，把参与比较的字段逐一写清。
一条规则需要在多个数据源上执行，校验配置表怎么填？
规则清单中仍只保留一条规则、一个规则编号；校验配置表中为该规则登记多行，每行对应一个数据源及其执行频率、告警渠道和豁免条件。问题记录中的关联规则编号仍指向同一条规则，影响范围中注明问题出现在哪个数据源。这样规则定义保持唯一，执行配置按数据源分别管理。
问题修复后，规则清单需要同步修改吗？
视根因而定。如果问题来自数据录入或导入环节，修复动作落在源头，规则本身保持不变，只需在问题记录的复盘结论中说明。如果复盘发现判定条件过严、误报频繁，或原有规则未覆盖该类问题，则按修改或新增流程更新规则清单，记录变更前后内容与变更人，并同步调整校验配置的生效时间。
豁免条件填了之后，被豁免的数据还需要记录问题吗？
豁免表示该情形不触发告警，不等于问题不存在。建议在问题记录的影响范围中注明豁免依据和豁免期限，便于复核时判断豁免是否仍然合理。豁免条件应写明适用对象和时间区间，例如历史数据迁移期内的存量需求；迁移结束后及时清理豁免，避免长期掩盖真实异常。
规则数量增长后，编号体系需要重新设计吗？
不必推翻原有编号。可按校验对象或规则类型分组扩展，例如在对象缩写后增加分段序号，新规则沿用新分段，旧编号保持不变。长期停用的规则移入归档区，保留编号与历史问题记录的关联，不直接删除。分组方式确定后写入维护说明，保证后续新增规则有统一位置。
