1. 平台工程概述
平台工程（Platform Engineering）是近年来在 DevOps 与 SRE 实践基础上演化出的新一代基础设施与交付方法论。它并非推翻已有体系，而是将分散的工具、流程与团队能力抽象为统一的“内部开发者平台（IDP）”，从而在规模化组织中实现更高效的软件交付与运维。
1.1 平台工程的定义
平台工程是一门设计和构建“内部开发者平台”的工程学科。该平台通过整合底层基础设施、CI/CD 流水线、可观测性、安全策略与自服务能力，为开发团队提供一条“黄金路径”（Golden Path），使开发者无需关心底层基础设施细节即可安全、快速地交付业务功能。
核心定义：平台工程 = 产品化思维 × 基础设施抽象 × 自服务体验。它不是一套工具，而是一种将运维能力封装为产品交付给开发者的工程实践。
1.2 平台工程的核心价值
| 价值维度 | 具体表现 | 关键指标 |
|---|---|---|
| 加速交付 | 消除环境配置、权限申请、部署审批等等待时间 | Lead Time 缩短 40%~60% |
| 降低认知负荷 | 开发者无需掌握 K8s、Terraform、可观测性栈等复杂技能 | 新成员上手时间减少 50% |
| 标准化与合规 | 内置安全扫描、成本标签、审计日志，默认合规 | 安全事件下降 70% |
| 提升可靠性 | 平台统一管理变更窗口、灰度策略、回滚机制 | MTTR 降低 30%~50% |
| 规模化治理 | 多团队共享同一平台，避免工具碎片化 | 平台复用率 > 80% |
1.3 平台工程与 DevOps、SRE 的关系
三者并非替代关系，而是层层递进、相互补充的演进路径。DevOps 打破了开发与运维的墙，SRE 用软件工程方法保障可靠性，平台工程则将前两者的实践固化为一套可复用的产品化能力。
实践建议：在组织内推行平台工程时，不要先建平台再推广。正确的路径是：先有 DevOps 文化基础，再引入 SRE 可靠性框架，最后将高频、重复的运维能力产品化为平台。平台工程是前两者成熟后的自然产物。
1.4 平台工程在变更窗口整合中的角色
本课程的核心议题——事故响应体系与变更窗口整合——正是平台工程价值的最佳体现。平台作为统一的变更入口，可以实现：
- 变更标准化：所有变更通过平台提交，自动关联审批、测试、灰度策略。
- 窗口统一管理：平台维护全局变更日历，自动避开已知风险窗口（大促、重大发布、节假日）。
- 事故联动：变更触发告警时，平台自动关联变更记录、回滚按钮、影响范围分析。
- 可观测性闭环：变更前后的黄金指标（延迟、错误率、流量）自动对比，异常即阻断。
常见误区：不要将平台工程等同于“搭建一个内部 PaaS”。平台工程的核心是产品化思维——平台需要像对待外部用户一样对待内部开发者，持续收集反馈、迭代体验。否则平台会沦为无人使用的“运维后台”。
1.5 平台工程成熟度模型
评估一个组织平台工程实践的成熟度，可以参考以下五个阶段：
- 阶段一：临时脚本 — 各团队自行维护部署脚本、配置文档，无统一平台。
- 阶段二：工具集成 — 引入 CI/CD、监控、容器编排工具，但工具间割裂，开发者仍需跨多个系统操作。
- 阶段三：平台雏形 — 构建统一控制台或门户，整合常用操作，但底层仍依赖人工审批和手动配置。
- 阶段四：产品化平台 — 平台提供自服务能力、黄金路径、内置合规与安全策略，开发者可独立完成端到端交付。
- 阶段五：智能平台 — 平台具备自适应变更窗口、自动故障预测、变更风险评分等 AIOps 能力，事故响应与变更管理完全闭环。