1. 平台工程与云原生交付导论

在传统交付模式中，开发团队既要写业务代码，又要维护 CI/CD 流水线、Kubernetes 清单、IAM 权限、网络策略、日志采集和告警规则。随着微服务数量增长，这种“每个团队各自造轮子”的方式会迅速带来三类问题：交付速度被基础设施细节拖慢、安全与合规标准难以统一、运维知识散落在少数人手里。平台工程（Platform Engineering）正是为应对这些问题而出现的工程实践：它把基础设施与应用交付能力封装成一套内部开发者平台（Internal Developer Platform，IDP），让应用团队通过自助、标准化、可审计的方式获得运行环境，而不是直接面对底层云资源的复杂度。

需要先厘清一个常见误解：平台工程不是“把运维团队改名为平台团队”，也不是简单地把 Terraform 和 Helm 打包成脚本仓库。它的核心价值在于把组织内反复出现的交付路径产品化。判断一个平台是否真正成立，可以看三个信号：应用团队能否在不提工单的情况下完成一次从代码到生产环境的部署；平台是否对“什么算合规的应用”给出明确约束；当出现故障时，责任边界是否清晰。若这三点都做不到，平台就只是又一层需要协调的中间环节。

AWS 云原生应用平台的整体架构

在 AWS 上构建应用平台，通常采用分层结构。最底层是账号与网络基线：通过 AWS Organizations 管理多账号，用 Control Tower 或自定义 Landing Zone 建立日志归档、安全审计、共享服务等账号，并用 VPC、Transit Gateway、Route 53 定义网络连通与隔离。中间层是运行与交付能力：EKS 承载容器化工作负载，ECR 存放镜像，CodePipeline/CodeBuild 或 GitHub Actions 负责构建，Argo CD 或 Flux 负责 GitOps 持续部署，IAM Roles for Service Accounts（IRSA）把 AWS 权限精确绑定到 Kubernetes ServiceAccount。最上层是开发者体验层：服务目录、应用模板、环境申请入口、可观测性面板和成本视图，让开发者用声明式方式描述“我要一个带数据库的订单服务”，平台负责生成对应的命名空间、流水线、密钥、监控和告警。

这套架构的关键不是组件数量，而是控制面与数据面的分离。平台团队维护控制面（账号、策略、模板、流水线定义、策略即代码），应用团队在数据面（自己的命名空间、服务、配置）内自主操作。两者通过契约交互：平台提供 Golden Path 模板和策略约束，应用团队按模板交付，平台自动校验并放行。下面这张图展示了从开发者意图到 AWS 资源落地的分层关系与关键控制点。

交付指南的定位与学习路径

本指南不是 AWS 服务手册，也不是 Kubernetes 教程，而是一份面向平台建设者与交付工程师的工程落地路线。它假设读者已经了解容器、CI/CD 和基本云概念，重点回答三个问题：平台应该建成什么样、每一步用什么工具和参数、如何验证平台真的被用起来并产生价值。因此，指南中的每个模块都会给出可操作的配置片段、判断标准和常见失败模式，而不是停留在架构图层面。

学习路径建议按“先基线、再交付、后治理”的顺序推进。第一阶段建立账号与网络基线，确保后续所有环境都落在受控的 Landing Zone 内；第二阶段打通从代码提交到 EKS 部署的 Golden Path，让第一个应用真正跑起来；第三阶段引入策略即代码、可观测性和成本治理，把平台从“能用”推进到“可运营”。这条路径的合理性在于：没有基线，交付会不断返工；没有交付，治理没有对象；没有治理，平台规模扩大后会失控。

下面给出一个平台建设初期的能力清单示例，可用于自评当前所处阶段。表中“判断依据”一列是实际可观察的信号，而不是主观感受。