1. 平台工程概述
平台工程（Platform Engineering）是近年来 DevOps 领域最重要的演进方向之一。它并非推翻 DevOps，而是将 DevOps 实践中积累的碎片化工具链、手动流程和重复性工作，抽象为一条内部开发者平台（Internal Developer Platform, IDP），从而让开发团队专注于业务交付，而非基础设施运维。
1.1 平台工程的定义
平台工程是一门设计和构建“内部开发者平台”的工程学科。该平台通过提供标准化的服务目录、自助化能力、自动化流水线和一致的安全策略，屏蔽底层基础设施的复杂性，使开发者能够以最小的认知负荷完成从代码提交到生产交付的全流程。
核心公式： 平台工程 = 标准化服务目录 + 自助化能力 + 自动化基础设施 + 可观测性 + 治理策略
1.2 平台工程的核心价值
| 价值维度 | 说明 | 典型收益 |
|---|---|---|
| 加速交付 | 通过预置 CI/CD 模板、环境模板和基础设施即代码模块，消除重复配置 | 新服务上线时间从周级降至小时级 |
| 降低认知负荷 | 开发者无需掌握 Kubernetes、Terraform、网络策略等底层细节 | 团队 onboarding 时间缩短 60% 以上 |
| 标准化与治理 | 统一的安全基线、合规扫描、成本标签和版本策略嵌入平台 | 安全漏洞发现到修复时间减少 70% |
| 可复用性 | 服务目录中的组件可在项目间、团队间跨组织移植 | 避免重复造轮子，平台 ROI 指数级增长 |
| 可观测性 | 内置日志、指标、链路追踪和成本可视化 | 故障平均定位时间（MTTR）降低 50% |
1.3 平台工程与 DevOps 的关系
平台工程不是 DevOps 的替代品，而是 DevOps 在规模化场景下的自然演进。两者关系可概括为下表：
| 维度 | DevOps | 平台工程 |
|---|---|---|
| 核心理念 | 打破开发与运维壁垒，强调文化、协作与自动化 | 构建内部平台，将 DevOps 实践产品化、服务化 |
| 主要受众 | 开发团队 + 运维团队 | 开发团队（作为平台消费者） |
| 交付物 | 自动化脚本、流水线、监控告警 | 内部开发者平台、服务目录、自助门户 |
| 关注点 | 如何让开发和运维高效协作 | 如何让开发者以最低成本获得基础设施能力 |
| 规模化能力 | 在中小团队中效果显著，大规模时易碎片化 | 专为多团队、多项目、多环境的大规模组织设计 |
实践建议： 如果你的组织已有 5 个以上产品团队、超过 20 个微服务，且每个团队都在重复编写类似的 CI/CD 配置和基础设施代码，那么平台工程就是你的下一个演进方向。
1.4 平台工程在大型组织中的角色
在大型组织中，平台工程通常承担以下关键角色：
- 生产力加速器： 提供标准化的 CI/CD 服务目录，使新项目无需从零搭建流水线。
- 治理与合规守门人： 将安全扫描、许可证检查、成本标签等策略内嵌到平台层，而非依赖人工审核。
- 技术债削减者： 通过平台升级统一推动底层基础设施版本更新，避免各团队长期停留在老旧版本。
- 知识沉淀载体： 将最佳实践、架构模式、故障处理经验编码为平台组件，实现组织级复用。
- 成本优化引擎： 提供资源规格推荐、闲置资源回收、预算告警等能力，帮助组织控制云支出。
1.5 平台工程与 GitLab CI 服务目录的关联
在本课程中，我们将聚焦于平台工程中的一个具体且高价值场景：GitLab CI 服务目录的跨项目移植。服务目录是平台工程的核心产出之一，而 GitLab CI 作为业界广泛使用的 CI/CD 工具，其流水线配置、模板、变量、环境定义等资产，天然适合被封装为可移植的服务目录组件。
常见误区： 很多团队将 GitLab CI 配置视为“每个项目自己的事”，导致大量重复的 .gitlab-ci.yml 文件散落在各个仓库中。平台工程视角要求我们将这些配置抽象为共享的服务目录，通过 include 关键字、模板继承和组件注册表实现跨项目复用。
1.6 本章小结
- 平台工程 是 DevOps 在规模化场景下的自然演进，核心是构建内部开发者平台。
- 核心价值 包括加速交付、降低认知负荷、标准化治理、可复用性和可观测性。
- 与 DevOps 的关系 是互补而非替代，平台工程将 DevOps 实践产品化。
- 在大型组织中，平台工程扮演生产力加速器、治理守门人、技术债削减者等关键角色。
- GitLab CI 服务目录 是平台工程在 CI/CD 领域的具体落地场景，也是本课程的核心实践对象。