详解平台工程的概念及其正确的实施策略

目录

1 为什么是平台工程？传统团队和 DevOps 团队中的问题

1.1 传统组织中略显僵化的流程

1.2 DevOps 带来的认知负担和重复劳动

DevOps 带来的认知负担

DevOps 带来了较高的人力和一致性的成本

2 平台工程如何“拯救世界”

2.1 标准化工具使用

2.2 接管运维工作

3 平台工程的本质 - 内部开发者平台（IDP）

3.1 构建一个具备产品思维的 IDP

3.2 平台工程不是传统的把研发和运维再次分离

3.3 基础设施即代码带来的灵活性

4 如何将平台工程的理念落地

4.1 把平台看作是一个有生命周期的产品

4.2 平台的 1.0 版本是什么？应该从哪里开始？

5 平台工程会取代 DevOps 吗？

6 平台工程师 vs 云计算工程师

7 总结

---

最近平台工程这个概念越来越火爆，Gartner 的预测，到 2026 年，80% 的软件工程组织将拥有平台工程团队，来提供内部服务、组件和应用程序交付工具，作为可重复使用的资源。

平台工程到底是什么？根据 Red Hat SRE 高级总监 Narayanan Raghavan 的说法，平台工程的主要功能是创建和提供一套通用的工具或构件，例如持续集成/持续部署（CI/CD）或开发工具链等软件组件，开发人员可以将其作为产品开发的基础。

本文详细地阐述了为什么需要这个平台工程师这个新角色，真实世界的平台工程团队是做什么的，如何正确地实施平台工程，当然还有它与 DevOps 和云工程师的区别与联系，以及它是否真的取代了这些角色？

1 为什么是平台工程？传统团队和 DevOps 团队中的问题

每当出现新的角色或概念时，第一个问题总是：我们为什么需要它？因为其背后一定存在着用现有的解决方案无法解决的问题。

1.1 传统组织中略显僵化的流程

在传统组织中，开发人员和运维人员归属于不同的团队。开发人员负责应用程序的编程，完成后将打包好的应用程序交给运维人员负责部署和运行。虽然有专门的运维团队来管理基础设施、维护全公司的 CI/CD 平台或其他平台，但整个流程仍然比较僵化和缓慢。例如，开发人员需要对基础设施进行任何变更或申请基础设施资源时，需要等待运维人员的操作。反过来，运维团队也需要等待开发人员的操作才能修复影响部署或应用程序运行的问题。

1.2 DevOps 带来的认知负担和重复劳动

DevOps 带来的认知负担

DevOps 的出现消除了僵化、充满限制的流程，加强了开发和运维之间的沟通，也消除了开发和运维这两个部分之间的通信挑战和知识孤岛。并构建了统一的 DevOps 团队，同时开发应用程序和管理底层基础设施。这种理念是对传统工作方式的巨大改进。虽然这种方式更灵活、更快速、更酷，但也带来了大量的责任和认知负担。

在一个 DevOps 团队中，每个人都开发应用程序并在应用程序下运行整个堆栈。这包括设置 CI/CD 平台、创建脚本、配置 Kubernetes 集群、添加安全扫描、维护 Helm 图表等。当团队规模扩大时，比如说你有十个这样的团队，如果每个团队都在构建自己的平台，将会非常低效，浪费并且会给工程师带来很高的认知负担。尤其像 Kubernetes 这样的复杂系统，管理基础设施的部分甚至变得比编写应用程序代码和生成业务逻辑本身更加困难。导致您的团队忙于构建平台，而没有时间在应用程序中构建业务价值。

DevOps 带来了较高的人力和一致性的成本

如果团队必须管理应用程序下的整个基础设施堆栈，就需要大量的专业知识，这意味着需要雇佣更多经验丰富的工程师，也就是更高的人力资源成本。每个新项目团队在发布应用程序之前都会花费相同的时间和精力来设置基础设施。即使您让这些团队管理自己的基础设施和平台，他们可能没有足够的专业知识来正确完成所有事情。这可能导致 Kubernetes 配置错误，缺乏监控和日志记录，或者整个系统出现安全问题。当整个公司只有一个合规或安全团队，而数十个团队用不同的技术堆栈和方式运行应用程序时，合规或安全团队会很难形成对应用程序的见解，也很难帮助所有这些团队实施合适的安全措施。

SRE 提倡“谁构建，谁运行”的概念是在应用程序不像今天那么复杂并且底层运行环境也不像今天那么复杂时创建的。在当今高度复杂的多云、多集群或者混合云的世界，有成千上万的微服务，以及为这些微服务提供服务的数百个服务，要求开发者将这个概念融入到他们的工作中就有点过分了，也并不能最有效地利用该工程师的技能。

因此，快速总结一下，如果我们拥有自主 DevOps 团队，会让整个流程快速和灵活，但也会导致单一团队承担过多责任，认知负荷高，以及组织范围内的不一致性。如果我们拥有的是传统的独立开发和运维团队，基础设施得到管理和保护，但流程极其缓慢，也限制了开发人员的工作。这就是平台工程可以拯救世界的地方，但只有在正确实施的情况下才能拯救世界。

2 平台工程如何“拯救世界”

2.1 标准化工具使用

那么平台工程是如何解决这些问题的呢？平台工程师采用部署和运行应用程序所需的工具，并在团队之间标准化其使用。因此，如果 10 个团队使用 10 种不同的 CI/CD 解决方案，平台工程师则制作一个标准的 CI/CD 产品。或者，每个团队都使用 Kubernetes，但方式不同，平台工程师则标准化 Kubernetes 的使用。因此，平台工程师标准化了应用程序非功能性需求的所有内容。那么我们需要的东西或者所谓的应用程序的非功能性需求怎么办？

非功能性需求基本上是指那些非业务逻辑，但却是将应用程序交付给最终用户所必需的部分。首先，每个应用程序都需要一个版本控制系统。每个应用程序都需要 CI/CD 管道。应用程序需要在某个地方运行，比如运行时环境、Kubernetes。当然，Kubernetes 集群需要底层基础设施，比如 AWS 云平台，甚至是多云平台。应用程序和底层基础设施也需要日志记录和监控。该应用程序还需要适当的安全性。正如您所看到的，需要设置很多内容才能使应用程序正常运行，并且每个类别都有许多不同的工具和技术，还有大量的 CI/CD 平台、不同的云平台等等。

那么这是否意味着平台团队现在对所有这些负全部责任，或者他们到底接管了什么？他们是否创建 Kubernetes 集群并配置它？他们是否创建整个 CI/CD 管道并为团队进行管理以及操作这些工具？或者平台和产品团队是否共同承担这些责任？我们如何在这些责任之间划清界限？那么平台工程师的职责到底是什么？

2.2 接管运维工作

当我们考虑应用程序需要的工具时，例如 GitLab、Kubernetes、Jenkins、云平台、数据库等。这些工具都有两个方面，即管理端和用户端。该工具的管理端设置和配置该工具，确保备份到位，访问安全，并安装好所需的所有插件等等。

管理员设置并准备好要使用的工具，用户就可以根据自己的意图使用。职责自然地分为操作和管理工具的角色和使用工具的角色。但是，在 DevOps 团队中，您在一个自给自足的团队中承担这两项职责，但这其实是两组独立的技能，您需要两组知识领域来完成每一项任务。对于 Kubernetes 而言，它们甚至是不同的认证，管理集群的认证是 CKA，而部署到集群的是 CKAD。

因此，为了标准化跨团队工具，平台工程师需要接管这些工具的运维，挑选标准工具，并使用最佳实践的统一标准方式重新设置它们，保证生产效率和安全性。

同时，这对于应用程序开发团队来说也是一项进步，因为平台工程减轻了他们的负担。至少不再需要负责运维服务了，认知负荷更少，创造业务价值的能力也就更强。

此外，您可以更有效地利用员工的专业知识，您只需将需要专家管理这些工具的需求从应用团队抽离出来，创建一个针对这些工具非常专业的专家团队，而不是每个团队中都配有对该工具一知半解的工程师。由于平台是这些专家的核心责任，他们也有更多的时间和精力把这项工作做好。

平台还可以实现标准化，例如，如果公司对其行业或国家/地区有特定的法规，那么这些法规要求的扫描将默认成为每个团队发布管道的一部分。

3 平台工程的本质 - 内部开发者平台（IDP）

3.1 构建一个具备产品思维的 IDP

显然，如果我们回到开发人员向平台团队请求资源以允许他们访问某些服务的缓慢而不灵活的流程，就回到了传统的方式，也就不会有任何改进。

更好的方式是，平台团队采用应用程序开发团队所需的所有这些工具，例如云平台、Kubernetes 和数据库，运用他们的专业知识并正确配置它们，以确保它们是安全的、最新的。然后，他们在顶部创建一个抽象层，并提供用户友好的界面（例如 UI 或 API），以便应用程序开放团队现在可以自助服务他们需要的任何服务和工具。通过一个可以轻松交互和访问它们的接口，开发人员只需登录并自助服务，而无需向平台团队请求资源，它是一个为内部开发人员打造的PaaS，也称为内部开发人员平台或 IDP。

平台团队本质上是在构建 IDP 或 PaaS，隐藏和抽象开发人员发布和运行应用程序所需的操作和管理服务的复杂性。应用程序开发团队无需登录 AWS 云并配置 EKS 集群，而是访问平台或 IDP，登录到该平台，并使用由平台预先配置好了的 EKS 集群，无需向平台团队提出任何要求。

3.2 平台工程不是传统的把研发和运维再次分离

平台工程团队提供标准的 GitLab CI/CD 解决方案。但是，如果应用程序开发团队想使用 Circle CI 呢？应用开发团队希望能够自由地使用新的工具或更适合他们工作流程的工具。锁定选项并要求应用开发团队遵守平台团队的选择无法带来改进，还会剥夺 DevOps 团队的灵活性和创造力。

平台工程师不想成为阻碍者，也不想与应用开发团队产生大的分歧，进而毁掉整个概念。平台团队不会说“您只能使用 CI/CD 工具或者只能使用此云平台”，而是会说“您想使用 Circle CI？好的，我们将帮助您使用最佳实践进行设置和配置”。一旦实现了，就可以将其集成到平台中，并将其提供给其他团队，其他团队也可能会从在工作流程中使用 Circle CI 中受益。平台会不断添加新的服务，以供应用程序开发团队选择，而不是限制他们只能使用特定的工具或注册表。

也可能存在这样的情况：一个团队可能只需要某一种不通用的特定工具，这时，该应用程序团队仍然是该团队特定工具的所有者，他们完全可以自己操作该工具，无需集成到 IDP。

传统工作方式需要基础设施或运维团队使用多种工具来确保安全合规性。他们只允许开发人员遵循唯一的正确用法。相比之下，平台工程需要在保持平台灵活性的同时，添加安全规则和预配置来确保安全一致性和正确配置。平台工程是 DevOps 的进步，不是开发和运维再次分离。如果人们不能正确理解平台工程的概念，就有可能倒退。

3.3 基础设施即代码带来的灵活性

如何将正确使用工具的规则集成到 IDP 中，并将其成为产品的一部分？这就是基础设施即代码或配置即代码模板的用武之地。平台团队可以利用基础设施即代码工具（例如 Terraform、Ansible 或 Pulumi）来创建模板。这些模板具有内置的最佳实践配置。它们将用于自动配置资源，并为产品团队提供灵活性，使其能够根据各自的项目需求传递各种参数来创建和配置这些服务。

另一个例子是拥有各种管道模板。如果产品团队有 Python 程序，他们可以使用 Python 程序的管道模板，特别是预先配置了 Python 应用程序的安全扫描工具或测试步骤。这也引出了如何成功在公司落实这一概念的问题。

4 如何将平台工程的理念落地

要想成功地实现平台工程的理念，您最不该做的是从一个宏大的概念和创建理想的 IDP 平台开始。也不应一开始就计划该平台具有最酷的功能和最现代技术堆栈。

4.1 把平台看作是一个有生命周期的产品

恰恰相反，我们应该采用敏捷方法。您应该从一个小步骤开始，这个小步骤可以立即为至少一个团队增加价值。原因是，在很多情况下，应用开发团队使用过时的技术或者一个技术的所有版本时，他们很难一次性迁移到这个成熟的现代技术堆栈平台。因为他们需要付出很多的努力，做很多工作才能真正开始使用平台。作为平台团队或在组织中实施内部平台时，您应该首先考虑产品团队的现状，技术的使用现状是怎样的，然后一步步帮助他们从现在的状态走向理想的状态。

将 IDP 视为一种产品，这意味着 IDP 平台不是一个一次性的项目。而是一个 PaaS （平台即服务），需要持续的开发和优化。就像产品团队开发的应用程序一样，平台是平台工程师开发的产品；就像应用程序团队向应用程序引入、更新和改进新功能一样，平台团队也需要管理和升级他们向产品团队提供的服务版本，以及新服务、新工具、工具组合等。平台是一个有生命周期的产品，与所有其他产品一样，它需要持续的迭代和运营。

4.2 平台的 1.0 版本是什么？应该从哪里开始？

从容易实现的目标开始。例如，如果您确定了整个组织中许多团队使用的通用工具，就可以集成到平台中并作为服务提供的第一组工具。比如 Jenkins、GitLab CI/CD、Kubernetes、Vault，基本上是任何已经成为标准的工具。

多与应用程序团队合作，了解最阻碍他们的是什么、对他们来说最具挑战性的事情是什么，比如帮助他们管理 Kubernetes 集群。如果开发人员看到您的确在解决他们工作流程中的问题或瓶颈，他们将很乐意合作。

如果一开始你就说“你们都在使用不同的 CI/CD，所以我们想引入一些标准产品，你们都必须切换到我们选的产品”。就会给他们增加更多的工作内容，而非改进他们的流程。这样就会带来抵触。只有当你可以向他们证明你实际上使他们的工作变得更容易、更高效，并且已经减轻了一些工作的时候，你才能够更好的设计你的平台，才能成功地建立一个平台团队。并围绕它创造一种文化。

5 平台工程会取代 DevOps 吗？

有了平台工程师是否意味着我们不再需要 DevOps 工程师了？平台工程师接管了运维部分，应用开发团队则负责使用这些工具并将它们整合到他们的开发流程中。应用开发团队不需要设置和操作集群，但仍需要知道如何将他们的应用正确部署到集群中，如创建正确的配置文件。他们不需要知道如何为基础设施创建 Terraform 模块，但需要知道如何使用这些模块，并将其整合到他们的 pipeline 中。他们可从平台上得到一个 CI/CD 模板，但仍需要设置它，并为他们的应用程序添加额外的所需步骤。

除了应用开发，仍然有一些非功能需求需要关注，而这意味着您仍然需要产品团队中的 DevOps 工程师，平台也是一种产品，这意味着平台就像应用程序一样，需要一个持续的发展，有许多反馈迭代，并需要从最终用户那里收集密切的输入，这些用户虽然主要是应用开发团队，但也有治理和合规人员。所有这些都需要 DevOps 的参与，因此，在平台开发过程中需要大量的 DevOps 流程，可能在平台团队中也需要一个单独的 DevOps 工程师角色。

在实施 DevOps 时，不同组织的方式各不相同。有些公司雇用平台工程师来完成 DevOps 和云工程的任务，有些将 DevOps 工程师转移到平台团队，但这样会导致应用开发团队出现真空。因此，一些公司将这些任务交给开发人员，使他们成为多面手。

但底线是，无论你在两个团队中是否有专门的 DevOps 工程师的角色，你都需要在应用和平台开发中使用DevOps流程。最后甚至会形成应用或产品 DevOps 团队及平台 DevOps 团队。

6 平台工程师 vs 云计算工程师

一般来说，平台工程是所有其他概念的增强，如 DevOps，和云 SRE。但是，如果我们把范围缩小到主要的区别：云工程师需要了解云服务，需要是这方面的专家，通常甚至专门关注某一个云平台。因此，他们需要知道如何从内部迁移到云，如何建立一个混合基础设施，管理存储和备份和云，管理云成本，几乎是所有与云有关的东西。而且他们应该能够结合云服务，搭建符合公司需求的基础设施。

但是平台工程师需要有除了云之外的、更广泛的工具知识。平台工程师们建立了一个平台，开发人员或产品团队可以用这个平台在云资源和其他各种工具的基础上自助使用需要的任何资源。所以基本上他们把 AWS 等提供的基础设施作为一种服务，为公司的内部团队定制平台即服务。从本质上讲，他们在云之上建立了一个层，有一堆云服务以及其他不属于云的服务和工具。

7 总结

针对平台工程的实施，每个项目都会有所不同，并以各种方式实现这个概念。许多公司会雇用 DevOps 工程师作为平台工程师，也会有许多公司的云计算工程师可能会成为平台工程师，在小公司中，平台工程师可能会接管 DevOps 的角色，在大公司中，云团队会与平台团队合作，分享他们的专业知识。在云层上设计有平台层。

这种情况可能会持续一段时间，直到形成一个标准的团队结构方式的行业标准。可能是一个大公司成功实现大规模实施之后，其他公司基本上可以复制这一成功模式。

对于平台工程会带来什么， Ambassador Labs 的开发者关系负责人 Daniel Bryant曾经做出了四个预测：

预测 1：开发者优先的 Kubernetes 会大力发展

预测 2：通过开发者平台释放开发者生产力

预测3：开发者与 DevOps 共存；DevOps 并未消亡

预测 4：API 的再次兴起——微服务测试

总体来说，平台工程是一个非常好的理念，是以提升开发者体验优先的一种理念。KubeBlocks 项目也是对平台工程理念的一个践行，将复杂的数据库操作抽象和管理起来，使用 KubeBlocks 您将无需担心复杂的数据库系统的管理，而是更多的专注在对您商业价值更重要的应用开发上。

内容来源：

https://www.youtube.com/@TechWorldwithNana

https://thenewstack.io/platform-engineering/

https://stackoverflow.blog/2023/07/26/platform-engineering-is-just-devops-with-a-product-mindset/

https://news.ycombinator.com/item?id=28137852

---

小猿姐也诚邀各位体验 KubeBlocks，欢迎您成为产品的使用者和项目的贡献者。跟我们一起构建云原生数据基础设施吧！

官网：www.kubeblocks.io

GitHub: https://github.com/apecloud/kubeblocks

关注小猿姐，一起学习更多云原生技术干货。