2. 验收标准体系设计

数据平台验收最容易失败的方式，是把“系统能跑起来”当成“项目可以交付”。一个能启动的 Glue 作业、一张能查询的 Redshift 表、一条能触发的 Step Functions 流程，都不等于业务方可以放心把报表、风控或结算逻辑托付给它。验收标准体系要解决的，是把模糊的“可用”翻译成一组可测量、可复现、可判定通过或失败的条款，并明确每条条款对应什么交付物、由谁提供、在什么环境下验证。

四个维度不是并列清单，而是层层收敛的约束链

业务需求、SLA、数据质量、安全合规这四个维度，实践中并不是四张互不相干的检查表。业务需求决定“哪些数据、哪些口径、哪些时效是必须成立的”；SLA 把这些要求转成可观测的服务指标；数据质量把指标落到具体字段、分区和校验规则；安全合规则限定数据在采集、存储、计算、共享各环节的边界条件。四者共同收敛成一份验收基线。

以某零售企业订单域数据平台为例。业务需求是“每日 07:00 前，运营能看到前一日全渠道订单汇总，且退款订单必须单独标识”。这条需求向下拆解：SLA 要求 T+1 汇总表在 06:30 前完成产出，可用性不低于 99.5%；数据质量要求订单主键唯一、金额非负、退款标识与退款流水一致；安全合规要求消费者手机号在汇总层脱敏，且仅授权分析角色可读。任何一条不满足，业务需求就无法真正成立。

把业务需求翻译成可测量条款

业务需求通常以自然语言出现，例如“报表要准”“数据要新”“不能泄露客户信息”。验收标准设计的第一步，是逐条追问：这个需求对应哪个数据对象、哪个时间窗口、哪个可观测指标、阈值是多少、由谁判定。以“数据要新”为例，可以翻译为：订单汇总表 dwd_order_daily 的分区 ds=2025-06-01 必须在 2025-06-02 06:30 前可查询，且该分区记录数不低于源系统当日订单数的 99.9%。这样一条标准，既包含对象、时间、阈值，也包含可执行的验证方法。

建议为每条业务需求建立追溯关系：需求编号、需求描述、验收条款编号、验证方法、交付物名称。追溯矩阵的价值在于，当验收出现争议时，可以快速定位是需求本身未定义清楚，还是实现未达标，而不是陷入“我觉得可以了”的争论。

SLA 要写成可观测的服务指标

SLA 不是一句“系统要稳定”，而是一组带时间窗口和统计口径的指标。常见维度包括：数据产出时效、作业成功率、查询响应时间、系统可用性、故障恢复时间。每条 SLA 必须明确统计周期、计算方式和数据来源。

例如，数据产出时效可以定义为：每日 06:30 前完成 dws_order_summary 表产出，统计周期为自然月，达标率 = 按时产出天数 / 应产出天数，目标 ≥ 99.5%。作业成功率可以定义为：Glue 作业日调度成功率 ≥ 99%，失败后自动重试不超过 2 次，重试仍失败须在 15 分钟内告警。查询响应时间可以定义为：Redshift 上运营看板核心查询 P95 响应时间 ≤ 3 秒。

这些指标必须来自真实监控，而不是验收当天临时跑一次。验收时应提供至少连续 7 天的监控数据，覆盖正常工作日和一次计划内变更，以证明指标稳定而非偶然。

数据质量规则要落到字段和分区

数据质量是验收中最容易被低估的部分。很多团队只检查“表有没有数据”，却不检查“数据对不对”。可量化的数据质量规则通常包括：完整性、唯一性、有效性、一致性、及时性、准确性。

以订单域为例，可以定义如下规则：order_id 在主表中唯一率 100%；order_amount 非负且不超过 100 万元；refund_flag 为 Y 的记录必须能在退款流水中找到对应 refund_id；ds 分区连续 7 天无缺失；每日记录数与源系统对账差异率 ≤ 0.1%。每条规则都要有明确的校验 SQL 或 Glue Data Quality 规则集，并输出通过率、异常记录数和样本明细。

验收时不能只看“通过率 99.9%”这个数字，还要看异常样本是否属于可接受范围。例如，0.1% 的差异如果全部集中在某个渠道，可能意味着该渠道接口存在系统性问题，不能简单放行。

安全合规要提供可核查的证据

安全合规维度的验收，重点不是“我们做了脱敏”，而是“能证明脱敏有效、权限最小、审计可追溯”。可量化的条款包括：PII 字段在分析层全部脱敏或加密；IAM 角色权限与职责矩阵一致，无 * 通配符；S3 桶禁止公开访问；CloudTrail 日志留存 ≥ 180 天；KMS 密钥轮换周期 ≤ 365 天。

验收证据应包括：脱敏前后字段对比样例、IAM 策略 JSON、S3 桶策略、CloudTrail 日志查询截图、KMS 密钥配置。对于跨账号共享的数据，还要提供 Lake Formation 授权记录或 RAM 共享策略，证明访问边界清晰。

交付物清单与验收记录表

验收标准最终要落到一份可执行的交付物清单。清单中的每一项都应对应一个可检查的文件、看板、报告或配置。以下是一份可直接参考的验收记录表结构，字段可根据项目调整，但核心逻辑不变：条款编号、验收维度、验收内容、测试方法、期望值、实测值、判定结果、责任人、日期。

验收标准体系的价值，不在于文档有多厚，而在于每一条标准都能回答四个问题：测什么、怎么测、阈值多少、谁签字。当业务需求、SLA、数据质量、安全合规四个维度都能落到具体对象和具体数值时，验收才从“感觉可以”变成“证据充分”。