DevOps 运动自 2009 年诞生以来,已深刻改变了软件交付的方式。然而,经过十余年的实践,组织在推进 DevOps 时普遍面临一个困境:文化倡导容易,落地执行困难。 DevOps 强调打破 Dev 与 Ops 之间的壁垒,但当团队规模扩大、系统复杂度提升时,仅靠文化驱动已不足以维持高效的交付节奏。
Platform Engineering(平台工程)正是在这一背景下兴起的实践方向。它将 DevOps 的文化理念转化为可落地、可度量的平台产品,通过构建内部开发者平台(Internal Developer Platform, IDP),为开发团队提供自助式的基础设施与服务能力。
本文要解决的核心问题是:DevOps 与 Platform Engineering 的关系是什么?组织应如何从 DevOps 文化演进到 Platform Engineering 实践?
业界对 DevOps 的理解历经演化,形成了四种主要认知:
| 维度 | 核心主张 | 局限性 |
|---|---|---|
| 一组技术 | DevOps = 自动化运维 + CI/CD + Docker + IaC | 忽视了技术背后的文化和组织问题 |
| 一个职能 | 设立 DevOps 工程师/部门 | 违背了 DevOps 打破壁垒的初衷,形成新孤岛 |
| 一种文化 | 鼓励 Dev 与 Ops 协作、信任、共担 | 文化难以量化和复制,无法规模化 |
| 一种组织架构 | 将 Dev 与 Ops 置于同一团队 | Ops 资源稀缺,无法为每个团队配备 |
本质定位:DevOps 首先是一种鼓励协作的研发文化——这一认知已成为业界共识。但文化的传播需要载体,这正是 Platform Engineering 的价值所在。
Platform Engineering 是一种以产品思维构建内部开发者平台的工程实践:
Platform Engineering 是设计并构建工具链和工作流的学科,旨在为软件研发组织提供自助服务能力。平台团队将基础设施、流水线、环境配置等能力封装为可复用的服务,使开发团队能够自主完成从代码到生产的全流程,无需提交工单或等待运维支持。
| 对比维度 | DevOps | Platform Engineering |
|---|---|---|
| 核心关注 | 破除 Dev 与 Ops 壁垒 | 构建自助服务平台 |
| 方法论 | 文化运动 | 产品思维 |
| 目标 | 协作 | 自助 |
| 适用范围 | 团队级 | 组织级 |
| 落地载体 | 流程和工具链 | 内部开发者平台(IDP) |
| 度量方式 | DORA 指标 | 开发者体验(DevEx)+ DORA |
Platform Engineering 的核心产出是 IDP,其典型架构如下:
| 能力域 | 具体服务 | 底层技术 | 自助程度 |
|---|---|---|---|
| 应用创建 | 项目脚手架、服务模板 | Backstage Templates, Cookiecutter | 全自助 |
| CI/CD | 标准化流水线模板 | GitHub Actions, GitLab CI, Tekton | 全自助 |
| 环境管理 | 临时环境、预发布环境 | Kubernetes Namespace, vcluster | 全自助 |
| 数据库 | 数据库实例创建与迁移 | Cloud SQL, Crossplane | 半自助 |
| 可观测性 | 日志、指标、链路追踪接入 | OpenTelemetry, Grafana Stack | 全自助 |
| 安全扫描 | 代码扫描、镜像扫描、依赖检查 | Trivy, Snyk, OPA | 全自动 |
| 密钥管理 | 证书签发、密钥轮转 | Vault, External Secrets Operator | 半自助 |
| 成本管理 | 资源配额、成本归集 | Kubecost, Cloud Billing API | 可视化 |
| 组件 | 推荐方案 | 备选方案 | 说明 |
|---|---|---|---|
| 开发者门户 | Backstage | Port, OpsLevel | Backstage 是事实标准,CNCF 孵化项目 |
| 基础设施编排 | Crossplane | Pulumi, Terraform | Crossplane 原生 Kubernetes,适合 GitOps |
| 密钥管理 | HashiCorp Vault | AWS Secrets Manager, External Secrets | Vault 功能最全面,社区版即可满足 |
| 策略引擎 | OPA / Kyverno | Datree, Checkov | Kyverno 原生 Kubernetes,策略即资源 |
| CI/CD 模板 | GitHub Actions Reusable Workflows | GitLab CI Templates | 可复用工作流是平台化的关键 |
| 环境管理 | vcluster / Namespace | Signadot, Quali | vcluster 提供轻量级虚拟集群 |
以下是一个 Backstage Software Template 的配置示例,用于创建标准化的微服务项目:
# templates/microservice/template.yaml
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
name: microservice-go
title: Go Microservice
description: 创建一个标准化的 Go 微服务项目,包含 CI/CD、Dockerfile 和 Kubernetes 部署清单
spec:
owner: platform-team
type: service
parameters:
- title: 服务基本信息
required:
- name
- owner
- description
properties:
name:
title: 服务名称
type: string
description: 服务的唯一标识,将用于仓库、镜像和 Kubernetes 资源命名
pattern: '^[a-z][a-z0-9-]{1,31}$'
owner:
title: 负责团队
type: string
description: 负责此服务的团队
ui:field: OwnerPicker
ui:options:
allowedKinds:
- Group
description:
title: 服务描述
type: string
description: 简要描述服务的功能
- title: 基础设施配置
required:
- environment
properties:
environment:
title: 目标环境
type: string
default: staging
enum:
- staging
- production
enumNames:
- 预发布环境
- 生产环境
steps:
- id: fetch-base
name: 获取模板
action: fetch:template
input:
url: ./skeleton
values:
name: ${{ parameters.name }}
owner: ${{ parameters.owner }}
description: ${{ parameters.description }}
environment: ${{ parameters.environment }}
- id: publish
name: 发布到 Git 仓库
action: publish:github
input:
allowedHosts: ['github.com']
description: ${{ parameters.description }}
repoUrl: github.com?owner=${{ parameters.owner }}&repo=${{ parameters.name }}
defaultBranch: main
repoVisibility: private
- id: register
name: 注册到服务目录
action: catalog:register
input:
catalogInfoUrl: https://github.com/${{ parameters.owner }}/${{ parameters.name }}/blob/main/catalog-info.yaml
output:
links:
- title: 仓库地址
url: ${{ steps.publish.output.remoteUrl }}
- title: 在目录中查看
icon: catalog
entityRef: ${{ steps.register.output.entityRef }}以下示例展示如何通过 Crossplane 定义一个标准化的云基础设施组合:
# composite-resources/database-xrd.yaml
apiVersion: apiextensions.crossplane.io/v1
kind: CompositeResourceDefinition
metadata:
name: standarddatabases.platform.example.com
spec:
group: platform.example.com
names:
kind: StandardDatabase
plural: standarddatabases
claimNames:
kind: DatabaseClaim
plural: databaseclaims
versions:
- name: v1alpha1
served: true
referenceable: true
schema:
openAPIV3Schema:
type: object
properties:
spec:
type: object
properties:
engine:
type: string
enum: ["mysql", "postgresql"]
default: "postgresql"
size:
type: string
enum: ["small", "medium", "large"]
default: "small"
environment:
type: string
enum: ["staging", "production"]
required:
- environment# composite-resources/database-claim.yaml
apiVersion: platform.example.com/v1alpha1
kind: DatabaseClaim
metadata:
name: orders-db
namespace: orders-service
spec:
engine: postgresql
size: medium
environment: staging
# 开发者只需声明需求,平台自动配置底层资源
# 包括:实例规格、备份策略、网络策略、监控告警第一阶段:识别黄金路径(Month 1-2)
第二阶段:构建最小可行平台(Month 3-6)
第三阶段:扩展与成熟(Month 7-12)
| 反模式 | 表现 | 危害 | 规避方法 |
|---|---|---|---|
| 平台孤岛 | 平台团队闭门造车,开发者不用 | 投入产出比极低 | 用户调研驱动,定期用户访谈 |
| 过度抽象 | 一层又一层抽象,开发者无法理解底层 | 调试困难,黑箱效应 | 透明化设计,提供"逃生舱"(escape hatch) |
| 强制迁移 | 要求所有团队必须在某个时间点迁移 | 引发抵触,影响业务交付 | 渐进采纳,新项目默认使用平台 |
| 工具堆砌 | 引入大量工具但缺乏集成 | 开发者体验碎片化 | 以开发者工作流为中心设计集成 |
| 忽视开发者体验 | 只关注平台功能,忽视使用体验 | 平台采纳率低 | DevEx 度量(DX 框架) |
| 指标类别 | 指标名称 | 定义 | 目标 |
|---|---|---|---|
| 采纳 | 平台采纳率 | 使用平台服务的团队数 / 总团队数 | > 70% |
| 采纳 | 自助服务率 | 无需平台团队介入完成的操作占比 | > 80% |
| 效率 | 环境就绪时间 | 从申请到环境可用的时间 | < 15 分钟 |
| 效率 | 新服务上线时间 | 从项目创建到首次部署的时间 | < 1 小时 |
| 满意度 | 开发者 NPS | 平台用户净推荐值 | > 30 |
| 满意度 | 工单减少率 | 平台上线后运维工单的下降比例 | > 50% |
| 质量 | 黄金路径覆盖率 | 走黄金路径完成的工作流占比 | > 60% |