4. 基础设施即代码交付验收

数据平台的基础设施通常包含VPC、子网、安全组、IAM角色、KMS密钥、S3存储桶、Glue Catalog、Redshift集群、EMR集群、MSK主题、Lambda函数以及各类事件规则。这些资源如果靠控制台手工创建，交付质量几乎无法复现。基础设施即代码（IaC）交付验收的核心，不是“模板能跑通”，而是模板在正确性、幂等性、回滚能力三个维度上都能被证明。

本节以CloudFormation、Terraform、CDK三种主流工具为对象，说明验收时应当检查什么、如何构造验证用例，以及如何判断结果是否达标。三种工具的验收逻辑相通，但检查点各有侧重：CloudFormation关注Stack事件与Drift，Terraform关注State与Plan，CDK关注合成产物与底层模板。

一、模板正确性验收：从语法到语义

正确性验收分三层。第一层是静态校验：CloudFormation使用aws cloudformation validate-template，Terraform使用terraform validate与terraform fmt -check，CDK使用cdk synth并检查生成的cdk.out模板。第二层是策略校验：用cfn-lint、tflint、checkov扫描硬编码密钥、开放安全组、未加密存储桶等风险。第三层是部署后语义校验：资源是否真正可用，例如Glue Crawler能否识别分区、Redshift能否被Lambda访问、MSK Topic是否可写入。

验收时不能只看“部署成功”。以数据平台常见的S3数据湖为例，模板中若只声明了Bucket而未声明BucketEncryption、PublicAccessBlockConfiguration、VersioningConfiguration，部署同样会成功，但不符合数据平台基线。因此正确性验收必须绑定一份基线检查清单，逐项核对模板中是否显式声明了加密、版本控制、生命周期、访问日志等属性。

二、幂等性验收：重复部署不应产生变更

幂等性指同一模板、同一参数重复执行，基础设施状态不发生非预期变化。验收方法是：首次部署成功后，立即再次执行部署命令，观察是否产生资源变更。

CloudFormation中执行aws cloudformation deploy后查看Stack事件，若出现No updates are to be performed，说明模板层面幂等。但要注意，若模板中使用了CustomResource或aws cloudformation update-stack强制更新，可能触发Lambda重复执行，造成数据重复写入。Terraform中执行terraform plan，理想结果是No changes. Your infrastructure matches the configuration.若Plan中持续出现~ update in-place，常见原因是属性由AWS自动生成（如tags_all、last_modified）或Provider版本差异，需要显式忽略或修正。

CDK的幂等性验收更特殊：cdk synth两次生成的模板必须完全一致（除时间戳、Asset Hash外）。若模板中嵌入了new Date()或随机数，会导致每次合成结果不同，进而触发不必要的更新。验收时应将两次cdk.out做diff，确认无实质差异。

# Terraform 幂等性验收示例
terraform apply -auto-approve
terraform plan -detailed-exitcode
# 退出码 0 表示无变更，2 表示有变更，1 表示错误
echo "exit code: $?"

三、回滚能力验收：失败后能否恢复

回滚能力是数据平台IaC交付中最容易被忽视、却最影响生产稳定性的能力。验收时不能只验证“成功路径”，必须主动制造失败。

CloudFormation默认在Stack创建失败时自动回滚，但更新失败时是否回滚取决于--rollback-configuration与DisableRollback参数。验收时应构造一个必然失败的更新，例如将Redshift节点数改为超出配额的值，观察Stack是否回到UPDATE_ROLLBACK_COMPLETE，并确认原有资源未被破坏。Terraform没有内置自动回滚，回滚依赖State与版本控制：验收时应确认terraform.tfstate已启用远程后端（如S3+DynamoDB锁），并验证terraform apply失败后State是否保持一致，能否通过terraform state pull恢复。

CDK的回滚能力最终由CloudFormation承载，但CDK的--rollback选项与cdk deploy --no-rollback行为不同。验收时应确认部署脚本中是否显式设置了回滚策略，并检查嵌套Stack的回滚是否级联。

四、验收结果判读与交付物

三项验收的判读标准可以归纳为：正确性看“基线属性是否齐全、部署后资源是否可用”；幂等性看“二次执行是否零变更”；回滚看“失败后是否回到已知良好状态且数据未受损”。任何一项不达标，都不应签署交付验收。

建议交付时附带一份验收记录，至少包含：模板版本号、部署命令、二次执行输出、失败注入场景、回滚后Stack/State状态、基线检查脚本执行结果。以下为可直接参考的验收记录示例。

需要强调的是，三种工具在回滚语义上并不等价。CloudFormation以Stack为单位自动回滚，Terraform以State为基准由人工或CI决定回滚，CDK则把回滚委托给CloudFormation。验收时应在交付文档中明确写出“本平台采用哪种回滚策略、回滚触发条件是什么、回滚后如何验证数据面”，而不是笼统写“支持回滚”。

最后，IaC验收不应是一次性动作。建议把上述检查嵌入CI流水线：每次模板变更自动执行静态校验与基线断言，合并到主分支后自动执行一次幂等性检查，发布前在预发环境执行一次失败注入回滚演练。这样，模板正确性、幂等性与回滚能力才能从“验收时证明”变成“持续可保证”。