1. 平台工程与开发者自助服务导论
在云原生与微服务架构普及之后，开发者面对的不再是"能不能上云"，而是"上云之后如何高效、安全、可重复地交付软件"。传统模式下，每个团队各自搭建 CI/CD、申请云资源、配置网络与权限，重复劳动多、标准不统一、安全策略难以落地。平台工程（Platform Engineering）正是为回应这一矛盾而出现的工程学科：它把基础设施、运行时、交付流水线、可观测性、安全合规等能力，抽象为面向开发者的产品化服务，让开发者通过自助方式获取所需环境与工具，而不必深入底层云资源的细节。
一、什么是平台工程
平台工程的核心是"把平台当作产品来运营"。平台团队是内部产品的提供方，开发者是用户。平台团队需要像产品团队一样理解用户需求、设计接口、度量体验、持续迭代。其交付物通常被称为内部开发者平台（Internal Developer Platform，IDP）。IDP 不是单一工具，而是由门户、模板、编排引擎、策略引擎、云资源抽象层等共同组成的能力集合。
一个典型的 IDP 至少覆盖四类能力：环境供给（按需创建命名空间、数据库、消息队列）、交付流水线（标准化构建、测试、部署）、可观测与运维（日志、指标、告警、回滚）、治理与合规（权限、配额、成本、审计）。这些能力通过声明式接口暴露给开发者，例如一份服务描述文件即可触发环境创建与流水线绑定。
二、自助服务能力成熟度模型
自助服务并非"有门户就等于成熟"。可以按能力成熟度划分为五个层级，用于评估组织当前状态并规划演进路径：
- L1 手工申请：开发者提交工单，运维人工创建资源，周期以天计，标准依赖个人经验。
- L2 脚本化：存在 Terraform/CloudFormation 脚本，但由开发者自行复制修改，缺乏统一入口与校验。
- L3 标准化自助：平台提供模板与自助门户，开发者按模板申请，资源自动创建，策略自动校验。
- L4 产品化运营：平台有明确 SLO、使用度量、反馈闭环，模板可版本化，能力按需扩展。
- L5 智能化与自适应：平台根据负载、成本、合规态势自动推荐或调整配置，开发者只需声明意图。
多数组织处于 L2 到 L3 之间。从 L2 迈向 L3 的关键不是引入更多工具，而是建立"唯一入口 + 标准模板 + 自动校验"三件套，并把平台变更纳入版本管理与评审流程。
三、传统运维与平台工程的对比
传统运维以"保障系统稳定"为中心，开发者与运维之间是请求—响应关系；平台工程以"提升开发者交付效率与体验"为中心，平台团队与开发者之间是产品—用户关系。前者关注单次操作是否正确，后者关注能力是否可复用、可度量、可持续演进。下表从多个维度对比两者差异：
| 维度 | 传统运维 | 平台工程 |
|---|---|---|
| 交互方式 | 工单、邮件、口头沟通 | 自助门户、API、声明式模板 |
| 交付周期 | 天级到周级 | 分钟级到小时级 |
| 标准化程度 | 依赖个人经验，差异大 | 模板化、版本化、可审计 |
| 责任边界 | 运维承担资源正确性 | 平台提供能力，开发者承担服务结果 |
| 度量指标 | 可用性、故障恢复时间 | 开发者上手时间、交付频率、平台采用率 |
| 演进方式 | 被动响应需求 | 主动规划路线图，持续迭代 |
四、AWS 在平台工程中的角色定位
AWS 在平台工程中扮演"能力底座 + 参考实现"的双重角色。一方面，AWS 提供构建 IDP 所需的原语：IAM 负责身份与权限，VPC 负责网络隔离，EKS/ECS 负责运行时，CodePipeline/CodeBuild 负责交付，CloudFormation/CDK 负责基础设施即代码，Service Catalog 负责产品化目录，Backstage 等门户可对接 AWS 资源。另一方面，AWS 通过 Well-Architected、Control Tower、Landing Zone 等方案，给出多账号治理与合规的参考架构，帮助平台团队少走弯路。
需要明确的是，AWS 提供的是"积木"而非"成品 IDP"。平台团队仍需根据组织实际，决定抽象层级、模板粒度、策略强度与开发者体验。把 AWS 服务简单堆叠并不等于平台工程，只有围绕开发者自助服务这一目标进行产品化设计，才能真正释放价值。
五、从概念到落地：一个最小可行示例
假设一个团队希望把"新建一个微服务"从三天缩短到三十分钟。在 L3 成熟度下，平台团队可以提供一份服务描述模板，开发者填写服务名、语言、副本数、是否需要数据库后提交。平台侧执行流程如下：
# service.yaml（开发者填写）
name: order-service
language: java
replicas: 3
database: postgres
env: dev
# 平台侧自动执行（示例逻辑）
1. 校验 name 唯一性与命名规范
2. 在 EKS 集群创建 namespace: order-service-dev
3. 通过 CDK 创建 RDS 实例（dev 规格）
4. 生成 CodePipeline，绑定仓库与构建规格
5. 注入 IAM Role，限制仅访问本服务资源
6. 注册到 Service Catalog，输出访问地址与监控面板链接开发者拿到的是可访问的服务地址、流水线链接和监控面板，而不是一堆待配置的云资源。平台团队则通过模板版本、策略校验和采用率指标持续改进。判断是否达到 L3 的关键信号是：开发者无需提交工单即可获得标准环境，且环境创建过程可审计、可重复、可回滚。