平台即产品

第 1 章. 平台的重要性：为什么 现在 内部平台 必不可少

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

近年来，软件交付所面临的挑战发生了变化。仅仅快速交付代码已远远不够。团队还必须确保交付的安全性、合规性、可观察性、适应性和弹性。传统上，企业通过增加更多的开发人员、服务和基础设施来扩大工程规模。最近，企业开始采用人工智能辅助开发、第三方服务和云资源。无论选择哪种方式，交付和运行软件的复杂性都在迅速增加。

正如卡米尔-福尼尔（Camille Fournier）和伊恩-诺兰（Ian Nowland）所著的同名书籍中讨论的那样，平台工程的概念是为了应对软件交付中日益严重的脱节而出现的。¹虽然云原生技术让基础设施变得更加强大和灵活，但也增加了开发人员独立交付软件的难度。Cloud、Kubernetes、Terraform、持续集成/持续交付（CI/CD）管道和云 API 都是功能强大的工具，但它们也带来了巨大的运营开销。如果没有正确的抽象，开发人员就不得不与 YAML 打交道、等待票据，或者承担他们从未接受过培训的运营责任。

这就是平台团队（或更大范围内的团队）的作用所在。平台团队的职责不仅仅是管理工具，还包括构建一个产品，即内部开发人员平台（IDP），以简化和规范整个组织的软件交付方式，缩小复杂性差距。

从 DevOps 到平台工程

许多组织都是通过 DevOps 的经验才接触到平台工程的。DevOps 倡导责任共担和更快交付的文化，但它往往被理解为意味着应用开发人员将或可以直接承担所有基础设施和运营问题。在实践中，这种模糊的责任导致了工具的断裂、环境的不一致和团队的超负荷。

有时被忽视的是，DevOps 原则应适用于两个层面：应用层，即应用团队拥有并运营其构建的服务；平台层，即平台团队构建、运行并持续改进平台本身这一产品。这两层都使用自动化、持续交付、可观察性和反馈回路，但它们是通过针对不同消费者的不同 API 来实现的。

这并不是要重新引入 "开发"、"运营 "或 "质量保证 "等旧的孤岛。平台工程涉及对 API 进行分层，以确保职责明确，使团队能够专注于开发和支持自己的领域，而不会与交付系统的其他部分脱节。应用团队通过定义明确的合同使用平台，而平台团队则以同样的方式使用基础设施。每一层都可以独立改进和发展，前提是 API 保持稳定且文档齐全。因此，每个团队都可以通过分离关注点来拥有自己的价值流。这样可以提高交付速度，并在不可避免地出现问题时限制爆炸半径。此外，松散耦合的团队最终会为其最终用户/消费者创造更具凝聚力的体验。

因此，平台工程并不能取代 DevOps。它以 DevOps 原则为基础，在平台层建立专门团队，创建可重复使用的构建模块和工作流程。这使应用团队能够快速行动，而不会被基础设施的全部复杂性所淹没。这种模式的基础是启用而不是强制执行，是自助服务而不是票据队列。

关键行业趋势：云、DevEx、PaaP、合规性和人工智能

一些行业趋势加速了 IDP 的采用：

云原生蔓延

微服务、多云战略和 Kubernetes 生态系统带来了复杂性，开发人员不应该独自管理这些复杂性。

开发人员体验 (DevEx)

工程领导者越来越意识到，良好的开发人员体验会直接影响工作效率、满意度和留任率。

平台即产品 (PaaP)

将平台视为产品而非项目已成为一种决定性趋势。它将平台团队重新定位为产品经理、设计师和工程师，为客户（应用开发人员、操作人员和内部贡献者）提供价值。 ...