1. 课程导入与验收交付全景

企业数据平台验收，不是项目收尾时的一次性签字动作，而是围绕“可交付、可运行、可审计、可交接”四个目标，对数据平台从设计到上线全过程进行证据化确认的工程活动。它要回答的核心问题不是“系统能不能跑”，而是“在约定的业务范围、数据规模、SLA 与安全合规约束下，平台是否持续满足要求，并且具备被接手、被运维、被追责的条件”。

与之对应，工程交付的边界必须提前定义清楚。AWS 上的数据平台通常由多个托管服务组合而成，交付边界既包含代码与配置，也包含数据、权限、监控、成本与文档。若边界模糊，验收时极易出现“功能已上线但无人能运维”“数据已入湖但口径无人认领”的争议。因此，本章先建立全景认知：验收对象是什么、交付物有哪些、典型架构如何分层、生命周期如何推进。

一、验收的定义与四类对象

验收的本质是“以证据换确认”。在企业数据平台中，验收对象可归纳为四类：

• 功能与数据正确性：ETL/ELT 作业、数据质量规则、指标口径、报表与 API 输出是否符合需求说明。
• 非功能与运行质量：性能、并发、容错、恢复时间目标（RTO）、恢复点目标（RPO）、SLA 达成情况。
• 安全与合规：IAM 权限最小化、KMS 加密、Lake Formation 细粒度授权、CloudTrail 审计、数据分级与脱敏。
• 可运维与可交接：监控告警、Runbook、IaC 代码、数据字典、血缘、成本归属与值班机制。

这四类对象决定了验收不是单点测试，而是“测试 + 审查 + 演练 + 交接”的组合。例如，数据正确性靠对账与抽样验证；容错能力靠故障注入演练；安全合规靠权限矩阵与审计日志抽查；可运维性靠让接手团队按 Runbook 独立完成一次故障处置。

二、工程交付的边界

交付边界建议用“三层清单”界定，避免口头承诺：

边界之外的内容要显式列为“不在本次交付范围”，例如源系统改造、业务侧报表设计、第三方 SaaS 配置等。边界之内则要求每项交付物都有唯一责任人、存放位置与验收证据。

三、AWS 上数据平台的典型架构

下图给出一个典型的分层架构与数据流关系，用于建立后续章节的共同参照。数据从源系统经摄取层进入存储层，再经处理层形成服务层，最终支撑分析与应用；贯穿各层的是安全、治理与可观测能力。

该架构的关键在于：数据流是单向推进的，但治理与安全能力是横向贯穿的。验收时若只检查“数据是否到达服务层”，而忽略横向能力，平台上线后往往在权限、审计或成本上暴露问题。

四、交付生命周期与验收节奏

交付生命周期通常包含八个阶段：需求澄清、架构设计、环境搭建、数据接入、加工建模、测试验证、验收交接、运维迭代。验收并非只在“验收交接”阶段发生，而是分阶段嵌入：

• 需求澄清阶段：确认验收标准与数据口径，形成可测量的 SLA 指标，例如“核心报表 T+1 08:00 前可用，延迟不超过 30 分钟”。
• 架构设计阶段：评审安全边界、网络拓扑、加密方案与成本模型，避免后期返工。
• 数据接入与加工阶段：每接入一个源系统，即执行一次数据对账与质量规则验证，而不是全部堆到最后。
• 测试验证阶段：执行功能测试、性能压测、故障演练与安全扫描，形成测试报告与缺陷清单。
• 验收交接阶段：以验收清单逐项确认，完成文档、代码、权限与值班交接，签署验收结论。

五、一个可参考的验收清单示例

以下清单可作为验收启动时的检查框架，具体字段需按项目实际调整：

验收结论通常有三种：通过、有条件通过、不通过。有条件通过需明确整改项、责任人与复验时间；不通过则需回到对应阶段修复后重新提交。无论哪种结论，都应保留完整的验收记录，作为后续运维与审计的依据。