1. 平台工程概述
平台工程（Platform Engineering）是近年来云原生领域发展最快的实践方向之一。它并非推翻 DevOps，而是将 DevOps 中“平台化”的缺失环节补全，通过构建内部开发者平台（IDP），让开发者专注于业务逻辑，而非基础设施的复杂性。
1.1 平台工程的定义
平台工程是一门设计和构建“内部开发者平台”的学科。该平台是一套由工具、服务、流程和自动化组成的层，抽象底层基础设施的复杂性，为开发者提供一致、安全、高效的自助服务体验。
核心公式： 平台工程 = 内部开发者平台（IDP） + 黄金路径（Golden Path） + 自助服务（Self-Service）
1.2 平台工程的核心价值
| 价值维度 | 说明 | 典型收益 |
|---|---|---|
| 加速交付 | 提供标准化环境、CI/CD 流水线、基础设施即代码模板 | 新服务上线时间从周级降至小时级 |
| 降低认知负荷 | 屏蔽 Kubernetes、网络、存储等底层细节 | 开发者无需成为基础设施专家 |
| 保障一致性 | 统一的安全策略、合规检查、资源配额 | 减少配置漂移和安全隐患 |
| 提升开发者体验 | 自助服务门户、一键部署、内置监控 | 开发者满意度提升 30%+ |
| 资源利用率 | 平台统一管理资源配额与回收 | 云成本降低 20%~40% |
1.3 平台工程与 DevOps 的关系
平台工程不是 DevOps 的替代品，而是 DevOps 的“产品化”演进。DevOps 强调文化和协作，平台工程则通过构建产品化的平台，将 DevOps 原则落地为可重复、可度量的工程实践。
关键区别： DevOps 回答“如何协作”，平台工程回答“用什么工具和抽象层来支撑协作”。
- DevOps 阶段： 团队自建脚本、手动配置、工具碎片化、重复劳动多。
- 平台工程阶段： 平台团队构建 IDP，提供标准化 API、UI 和自动化工作流，开发者自助使用。
- 共同目标： 缩短交付周期、提高部署频率、降低故障恢复时间。
1.4 内部开发者平台（IDP）的演进
IDP 的演进经历了从“脚本集合”到“产品化平台”的四个阶段。理解这一演进，有助于我们定位容量压测作业平台在 IDP 中的角色。
1.5 容量压测作业平台在 IDP 中的定位
容量压测作业平台是 IDP 中“质量与可靠性”黄金路径的关键组成部分。它不是一个独立的压测工具，而是作为 IDP 的一个原生服务，提供以下能力：
- 自助压测： 开发者在 IDP 门户中一键发起压测任务，无需登录第三方工具。
- 环境感知： 自动获取被测服务的部署环境、版本、资源规格。
- 结果回写： 压测报告自动关联到服务元数据，形成容量基线。
- 门禁集成： 压测结果作为发布流水线的质量门禁，不达标自动阻断。
常见误区： 不要将容量压测平台做成一个“孤立的压测工具”。它必须深度集成到 IDP 的开发者门户、CI/CD 流水线和可观测性体系中，才能真正发挥平台工程的价值。
1.6 平台工程成熟度模型
评估一个组织在平台工程方面的成熟度，可以参考以下五个级别：
| 级别 | 名称 | 特征 | 压测平台状态 |
|---|---|---|---|
| L1 | 临时脚本 | 每个团队自行维护压测脚本，无共享 | 无统一平台，压测结果不可追溯 |
| L2 | 工具标准化 | 统一压测工具（如 JMeter / Locust） | 工具统一，但需手动配置环境 |
| L3 | 平台化 | 压测作为 IDP 服务，支持自助发起 | 自动获取环境信息，结果自动归档 |
| L4 | 智能化 | 基于历史数据推荐压测参数 | 自动生成压测报告，识别容量瓶颈 |
| L5 | 自治化 | 压测结果驱动自动扩缩容 | 容量基线自动调整，无人值守 |
课程目标： 本课程将帮助你从 L2 或 L3 起步，逐步构建一个与 IDP 深度集成的容量压测作业平台，并具备向 L4/L5 演进的能力。