1. 平台工程概述
平台工程（Platform Engineering）是近年来 DevOps 与云原生演进中涌现出的核心实践。它并非推翻现有运维体系，而是将“开发者体验”与“内部开发者平台（IDP）”作为第一性原理，重新定义基础设施与应用的交付方式。
1.1 平台工程的定义
平台工程是一门设计和构建内部开发者平台（Internal Developer Platform, IDP）的工程学科。IDP 是一层由工具、流程、自动化与自服务能力组成的“黄金路径”，让开发团队无需关心底层基础设施细节，即可安全、高效地交付和运行应用。
核心公式： 平台工程 = 内部开发者平台（IDP） + 自服务能力 + 标准化黄金路径 + 持续演进
1.2 平台工程的核心价值
| 价值维度 | 具体收益 | 典型指标 |
|---|---|---|
| 开发者体验（DevEx） | 降低认知负载，减少上下文切换 | 部署频率、变更前置时间 |
| 标准化与治理 | 统一安全基线、合规策略、成本标签 | 合规通过率、安全事件数 |
| 自服务与自动化 | 消除人工审批与等待，提升交付速度 | 自服务采纳率、环境创建时间 |
| 可靠性保障 | 内置 SLO 与可观测性，减少故障 | MTTR、错误预算消耗率 |
| 成本优化 | 资源按需分配，避免闲置浪费 | 单位部署成本、资源利用率 |
1.3 平台工程 vs. 传统运维 vs. DevOps
三者在目标、角色和工具链上存在本质差异。下表从多个维度进行对比：
| 对比维度 | 传统运维 | DevOps | 平台工程 |
|---|---|---|---|
| 核心目标 | 系统稳定性与可用性 | 打破墙，加速交付 | 开发者体验 + 可靠性 + 标准化 |
| 交付对象 | 基础设施与监控 | CI/CD 流水线 | 内部开发者平台（IDP） |
| 用户 | 运维工程师 | DevOps 工程师 | 全栈开发者、SRE、平台用户 |
| 交互方式 | 工单、手动变更 | 自动化脚本、Pipeline | 自服务门户、API、CLI |
| 抽象层级 | 物理/虚拟服务器 | 容器、编排 | 应用环境、黄金路径 |
| 变更频率 | 低（周/月） | 中（天/周） | 高（持续部署） |
| 失败处理 | 回滚、故障转移 | 快速失败、回滚 | 错误预算、SLO 驱动 |
关键洞察： 平台工程不是 DevOps 的替代品，而是 DevOps 进入规模化阶段后的自然演进。DevOps 解决了“谁做”的问题，平台工程解决了“怎么做”和“如何规模化”的问题。
1.4 平台工程成熟度模型
平台工程成熟度模型帮助组织评估当前阶段，并规划演进路径。通常分为五个等级：
- L1 - 临时/手动： 无标准化平台，依赖个人经验与手工操作，环境创建以天/周计。
- L2 - 基础自动化： 引入 CI/CD 与 IaC，但缺乏统一入口，各团队自行维护工具链。
- L3 - 平台化： 构建内部开发者平台（IDP），提供自服务能力，标准化黄金路径。
- L4 - 产品化运营： 平台以产品思维运营，有明确的 SLO、用户反馈闭环与持续迭代。
- L5 - 生态化： 平台支持多集群、多云、多租户，具备插件市场与开放 API，成为组织内部的技术生态。
1.5 平台工程与 SLO、部署频率的关系
本课程的核心命题——SLO（服务等级目标）与部署频率——正是平台工程落地中的两个关键抓手：
- SLO 驱动可靠性： 平台通过内置 SLO 监控与错误预算机制，让开发者在不牺牲稳定性的前提下自主决策。
- 部署频率衡量交付效率： 平台的自服务能力直接决定了部署频率的上限，而 SLO 则定义了部署频率的安全边界。
常见误区： 不要将平台工程简单理解为“搭一个门户”或“写一堆 API”。真正的平台工程需要同时解决“开发者想要什么”和“平台能承诺什么”两个问题，而 SLO 与部署频率正是连接这两者的桥梁。
1.6 本章小结
平台工程是 DevOps 规模化后的必然产物，其核心是构建内部开发者平台（IDP），通过自服务、标准化与 SLO 驱动，实现开发者体验与系统可靠性的统一。本章为后续深入探讨 SLO 定义、部署频率优化以及平台自助服务设计奠定了理论基础。