一篇文章带你了解什么是平台工程，实施平台工程你需要具体做什么？

介绍

在这篇博文中，我们将讨论DevOps 和云领域中一个相对较新的热门话题，即“平台工程”。

当前有很多讨论，其中一些人正在询问平台工程是否取代了DevOps。许多人认为这两者是相辅相成的，更像是对DevOps的一种补充，但实际上情况要复杂得多。平台工程实际上改变了我们所熟知的许多关于DevOps、SRE和云工程的既定规则，它改变了游戏规则，并引入了一些新的规则。

那么，让我们明确地定义一下平台工程到底是什么，更有趣的是，为什么会出现对这一新角色的需求，它是如何演变而来的，当然还有它与DevOps和云工程相比有何不同，以及它是否真的会取代这些角色中的任何一个？🤔

为什么选择平台工程？

传统开发和运维团队中的问题

最初，开发人员和运维人员是分开工作的，开发人员负责编写应用程序。当应用程序准备好后，他们会将打包好的应用程序交给运维团队，由运维团队负责部署和运行该应用程序。

所以，尽管你有一个专门的运维团队，他们具备专业知识来妥善管理基础设施，或者为整个公司运营CI/CD平台或其他应用程序团队所需的平台，但这个过程是不灵活且缓慢的。

• 开发人员在需要对基础设施进行任何更改或需要任何基础设施资源（如额外的服务器或Jenkins流水线）时，必须等待运维团队。
• 或者另一方面，运维团队在等待开发人员修复应用程序中的某些问题，这些问题影响了部署或应用程序运行时等。

因此，当引入 DevOps 时，它将这些团队团结起来，消除了那些僵化和限制性的流程。

DevOps 团队中的问题

DevOps 消除了这两个部分之间的沟通障碍和知识孤岛，即开发应用程序以及运行和作应用程序。因此，这是 对传统工作方式的巨大改进。 ✅

这导致现在有一个DevOps团队，他们不仅负责应用程序本身，还负责底层的运行时环境和基础设施。换句话说，这个团队负责应用程序及其运行所需的一切。

这更加灵活、快速，对工程师来说是一种很酷的工作方式。😎

但是，随着选项和所有权的增多，随之而来的也是大量的责任和认知负担。现在你有一个DevOps团队，每个人都在开发应用程序，并运行应用程序下的整个技术栈。

所以你有一个团队，其中要么是开发人员，要么是一名专职的DevOps工程师来设置：

• CI/CD平台和创建流水线
• 为基础设施代码编写 Terraform 脚本
• 启动 Kubernetes 集群
• 使用最佳实践配置集群
• 配置日志记录和监视
• 添加安全扫描
• 维护Helm charts
• 随着工具的发展和新版本的出现，还要维护所有这些基础设施代码脚本，对吧？
• 管理 Docker 仓库

并且所有这些工作都是在实际的应用开发之外进行的 🙉 这就是为什么我们还要做所有这些其他事情的原因。

这增加了工作的灵活性和速度以及效率，但自然也给团队增加了**巨大的认知负担 **，因为太多的事情需要少数角色负责。

其他 10 个 DevOps 团队也面临同样的挑战

但这还不止于此。现在想象一下，你有另一个应用开发团队正在开发一个完全不同的应用程序，他们面临着相同的挑战和任务。为了提高他们的效率，一名DevOps工程师为这个项目设计了同样的CI/CD工作流程，设置了集群，这次可能是使用托管的EKS服务而不是自管理的服务，配置了与AWS云的所有集成，配置了存储，增加了安全扫描步骤，监控整个密钥管理等等。也许他们会使用不同的Docker仓库，比如ECR，以便于与EKS集群轻松集成。

所以他们面临着相同的挑战，对应用程序的运行也有相同的需求，因此他们用自己的技术栈以自己的方式来完成所有这些工作，对吗？

也许你的组织里还有10个类似的团队，现在他们都需要为各自的项目解决所有这些问题。最终，你可能会有10个DevOps团队各自构建和运营10个不同的平台来交付和运行他们的应用程序。这样做不仅效率极低而且非常浪费资源，同时也会给这些团队中的工程师带来巨大的认知负担。 🤦🏼‍♂️

对于像Kubernetes这样的复杂系统，有时候管理基础设施的工作比编写应用程序代码和生成业务逻辑本身还要耗费精力。因此，团队可能会忙于构建平台，而没有足够的时间去开发应用程序中的业务价值。 😟

难以扩展

另外，如果一个团队需要管理应用程序之下的整个基础设施堆栈，那么他们就需要掌握很多方面的专业知识，这意味着要为许多团队增加许多有经验的工程师，这自然也意味着更高的人员成本，对吧？

最后，这变得难以扩展，因为每个新的项目团队在能够向最终用户发布应用程序之前，都需要花费初始的时间和精力来设置基础设施。还有一个非常重要的点是，尽管这些团队自己管理着基础设施和平台，但他们可能实际上并没有足够的专业知识来正确地完成所有工作。因此，你可能会遇到Kubernetes配置错误、完全缺乏监控和日志记录，或者系统中普遍存在安全问题等情况。

另外，当整个公司只有一个合规或安全团队，而有数十个技术栈完全不同的团队，并且每个团队运行应用程序的方式也各不相同，那么这个安全团队要获取洞察并帮助所有这些团队实施适当的安全措施将会非常困难。因为他们很难理解所有这些独立项目中正在发生的事情。因此，由于缺乏标准，这变得难以扩展。

此外，当每个团队使用具有不同配置的不同技术堆栈时，这会导致整个组织的不一致。

最后，我想提到的是，“你构建它，你运行它”这一概念源自SRE（站点可靠性工程），当时的应用程序和运行应用程序的底层环境都没有今天这么复杂。因此，在当今高度复杂、多云、多集群或混合云的世界中，有成千上万的微服务以及为这些微服务提供支持的数百种服务，要求开发者将这一概念融入到他们的工作中有些过于苛求了。

让一位资深的前端工程师停止手头的工作，而去专注于正确配置Kubernetes集群，这并不是一个很明智的做法，也不是对该工程师技能最有效的利用。

所以快速总结一下： ➡️ 要么我们有自主的DevOps团队放任自流，追求速度和灵活性，但这也会导致一个团队承担过多的责任，承受巨大的认知负荷，并且在整个组织中造成不一致性。 ➡️ 或者我们有传统的独立开发（Dev）和运维（Ops）模式，在这种模式下，基础设施被管理和保护，但是过程极其缓慢，这实际上限制了开发人员的工作。

而这正是平台工程发挥作用来拯救局面的时候，但前提是必须正确实施！

平台工程是如何解决这些问题的？

标准化工具的使用

平台工程师采用部署和运行应用程序所需的工具，并在团队之间标准化其使用。

所以，如果有10个团队使用10种不同的CI/CD解决方案，那么可以制定一个标准的CI/CD方案；或者如果每个团队都使用Kubernetes，但使用方式不同，那么可以标准化Kubernetes的使用。基本上，平台工程师会将应用程序非功能性需求的所有部分进行标准化。

非功能性需求

那么我们需要的是什么，或者说应用程序所谓的“非功能性需求”是什么呢？基本上，这些是指那些不是业务逻辑，但对于将应用程序交付给最终用户来说是必需的事项。

• 每个应用程序都需要一个版本控制系统
• 每个应用程序都需要 CI/CD 流水线
• 应用程序需要在某个地方运行，例如在 Kubernetes 等运行时环境中运行
• Kubernetes 集群当然需要底层基础设施，例如 AWS 云平台，甚至是多云平台
• 应用程序和底层基础结构还需要日志记录和监视
• 应用程序还需要适当的安全性

所以正如你所见，为了让应用程序正常运行，有很多事情需要设置，并且每个类别都有许多不同的工具和技术，对吧？ 那里有大量的 CI/CD 平台，有不同的云平台等等。

所以平台工程师会标准化提供这些服务的工具的使用。现在，平台团队接管的服务列表相当庞大。

那么，这是否意味着平台团队现在要完全负责所有这些事情，还是他们具体接管了哪些工作？ 🤔

• 他们是否创建并配置 Kubernetes 集群？
• 他们是否负责创建整个CI/CD流水线并为团队管理及运维这些工具，还是说平台团队和产品团队共同承担这些服务的责任？
• 那么，我们该如何界定这些责任之间的界限呢？

而这正是它变得有趣的地方，也是为什么我提到平台工程只有在正确实施的情况下才能奏效。 💪

那么让我们来谈谈并真正理解平台工程负责什么？

职责分离 - 平台工程负责什么

当我们考虑应用程序所需的工具时，比如GitLab、Kubernetes、Jenkins、云平台、数据库等，这些工具都有两个方面：

1. **管理端 **
2. 用户端

工具管理员负责设置和配置该工具，确保已做好备份、访问安全，并安装任何所需的插件等。总之，他们会完成所有必要的准备工作，以确保该工具能够用于其预期的实际任务。

因此，例如需要配置Kubernetes集群，安装网络插件，为安全起见配置访问和权限，为集群配置负载均衡器，以及完成许多其他工作以使集群准备好部署应用程序。

因此，一旦管理员设置并准备好要使用的工具后，用户就可以来使用这些工具以实现他们的目的，比如应用程序开发者访问Jenkins并为他们的应用程序创建流水线。

所以你有一个角色负责操作和管理这个工具，另一个角色则使用这个工具。这样一来，这两个职责就可以很容易地被分离开来。

2 个独立的角色 - 平台接管管理员端

正如我所提到的，在DevOps团队中，这两种责任都集中在同一个自给自足的团队里。这意味着单个应用程序团队可以决定如何操作以及如何使用工具。但正如我所说，这实际上是两套不同的技能，每种都需要独立的知识基础。甚至对于管理Kubernetes集群和在集群中部署应用，还有单独的认证。前者是“Kubernetes管理员”证书，后者是“Kubernetes应用开发者”证书。因为再次强调，你需要专门学习该工具的每个方面。

因此，为了在各个团队间标准化工具，平台工程师需要接管这些工具的操作方面，这意味着选择标准工具，并以一种标准的方式进行设置，同时遵循生产和安全的最佳实践。

同时，这对应用团队来说也是一种改进，因为它减轻了应用开发人员的负担。因此，至少有一部分服务他们不再需要负责了。😌

因此，减少认知负担，增加创造商业价值的能力。

此外，您可以更高效地利用您的工程师的专业知识，因为现在您不需要每个团队都有一个Kubernetes集群管理专家，而是在平台工程团队中配备较少的专家，他们可以为所有应用团队承担这项工作。对于CI/CD工具、数据库管理等工作也是如此。

你基本上是将管理这些工具所需的专业知识从应用团队中抽离出来。因此，与其让每个团队中的工程师半懂不懂地使用这些工具，不如设立一个专家团队，他们具备正确操作这些工具的专业技能。✅ 此外，因为这是他们的核心职责，所以他们也有更多的时间专注于此，因为他们不需要承担发布新功能的额外压力。

因此，这将压力、责任和专业知识的需求分散给多个应用程序团队和一个组织范围的平台团队.

现在，各个团队不再需要自行决定使用哪种CI/CD工具或哪种Kubernetes集群设置，平台团队为应用团队提供了一个现成的解决方案。

而不是让每个团队在构建他们的流水线步骤时都加入安全扫描，平台可以标准化这些扫描，使其成为每个团队流水线的一部分。例如，如果公司所在行业或国家有特定的法规要求，那么符合这些法规要求的安全扫描将默认成为每个流水线的一部分。

但是等等！

但是等等，我们不是把开发（Dev）和运维（Ops）合并在一起，就是为了避免那些职责分离的孤岛团队吗？🤔 因为现在听起来好像有一个独立的平台团队来决定整个公司要使用哪些工具，并根据他们的判断来设置所有这些工具，然后给应用团队提供这些工具的访问权限。这听起来有点像那种传统的做法，而我们绝对不想回到那种方式！

好的，没问题，因为从这里开始会继续进行，这只是基础。

那么现在应用团队如何访问这些服务呢？

平台工程的工作原理 -标准化而不创建孤岛

显然，如果我们回到那种缓慢且不灵活的过程，即开发者需要向平台团队请求资源来获取某些服务的访问权限，那么这将不会有任何改进。

那么这是如何运作的呢？

自助服务平台

1. 平台团队负责处理应用程序团队所需的各种工具，如云平台、Kubernetes和数据库等。他们运用自己的专业知识对这些工具进行适当的配置，以确保它们的安全性和时效性等
2. 然后，他们在其上创建了一个抽象层，并提供了一个用户友好的界面（如UI或API），这样应用程序团队就可以自助获取他们所需的各种服务和工具了。

内部开发人员平台 （IDP）

因此，那些已经配置好并保障了安全的服务，并提供了一个易于交互和访问的接口来供应用程序使用，这被称为“平台”。由于开发者只需登录即可自助服务，而无需向平台团队请求资源，所以对于内部开发团队来说，这就是所谓的“平台即服务”，也称为“内部开发者平台”或“IDP”。

所以平台团队实际上是在构建IDP（内部开发者平台），这个平台隐藏并抽象了操作和管理开发人员所需服务的复杂性，以便他们能够发布和运行应用程序。基本上，应用团队不再需要直接登录到AWS云来配置EKS集群，而是可以登录到这个平台或IDP，并使用由平台团队预先配置好安全设置、备份等功能的EKS集群。这样，应用团队可以在几分钟内独立完成这些操作，而无需向平台团队提出任何请求。

因此，应用程序团队可以灵活、快速地访问其应用程序的服务，而无需担心作这些服务 😎

现在让我们来看看这一切在现实世界中是什么样子，并思考以下实际场景。

平台工程在现实生活中的样子

记得我说过，平台的作用是标准化跨团队使用的工具，而不是让五个团队使用五种不同的CI/CD工具。现在假设平台提供GitLab CI/CD作为标准解决方案，但如果应用团队A说“我想用CircleCI”。基本上，团队希望有自由选择使用新的、现代化的酷工具，或者更适合他们工作流程的工具。也许他们想为他们的微服务应用程序使用Argo CD或特定的服务网格。

所以看起来，通过平台团队和整个标准化流程，我们正在确定选择并声明：“这就是我们公司在用的，仅此而已。所有人都必须遵守。”

当然不是。这样做实际上并不会带来改进，反而会剥夺自主DevOps团队的很多灵活性和创造力。而平台工程师最不想做的就是成为阻碍，并与应用团队形成一种奇怪的关系，因为这会破坏整个概念。

选择自由

所以，与其说你只能使用这种CI/CD工具或只能使用这个云平台，平台团队会说：“哦，你想用Circle CI吗？好的，我们会帮你设置并按照最佳实践进行配置。” 一旦他们完成了这些，就可以将Circle CI集成到平台上，并提供给其他团队使用，这些团队也可能从在工作流中使用Circle CI中受益。

这样，当平台添加新服务时，不是限制应用团队只能使用CI/CD工具或这个Docker仓库等，而是说你可以使用我们平台提供的任何这些仓库、CI/CD工具或其他服务。因为这样一来，我们知道它们都在后台被正确配置和操作了。随着时间的推移，平台可能会增加更多这样的工具供应用团队选择。

在现实生活中，可能会有这样的情况，即某个特定工具可能只被一个团队所需要。在这种情况下，平台团队可以决定让该应用团队继续拥有这个特定于他们团队的工具，并且自行操作它，而不是将其集成到平台或IDP中。

避免旧的工作方式

因此，在任何情况下，平台工程都不应与旧的工作方式混淆。在旧的方式中，基础设施或运维团队会分析多个工具（如安全合规性等），然后决定使用某个特定工具的唯一正确方法，并将其固定下来，告诉开发人员：“这是你使用该工具的唯一方式”，因为“我们已经完成了分析，这就是应该遵循的方法”。

所以在您的公司实施平台工程师团队时，您希望保持平台的灵活性，同时添加防护措施和预配置以确保安全一致性、正确的配置等。

因此，重要的是要理解，平台工程是DevOps的进一步发展，而不是让开发（Dev）和运维（Ops）再次分离的倒退。

但我要说的是，实际上我认为如果人们不能正确理解平台工程的概念，它有可能会走向倒退。我谈到了正确的做法，但在博客的后面部分，我会更详细地讨论如何以正确的方式构建平台工程团队，以避免这种情况。

基础设施即代码的灵活性

现在，这些严格的规则不仅适用于开发者可以选择哪些工具，还适用于这些工具的使用方式。就像说：“这是你唯一被允许使用的EKS配置。”

当然，我们希望在工具的使用方面也给予开发者灵活性，而不仅仅是在选择工具时。正如我所提到的，如果我们分担责任，我们会发现平台的作用在于减轻应用团队的负担，并在整个组织中创建一致性。同样地，通过引入作为平台一部分的自动化防护措施，他们也在帮助产品团队正确地使用这些工具。

所以现在的问题是，他们如何才能将这些正确使用工具的护栏集成到 IDP 中，并将其作为产品的一部分？ 🤔

IaC 模板

而这正是基础设施即代码或配置即代码模板发挥作用的地方。平台团队可以利用像Terraform、Ansible或Pulumi这样的基础设施即代码工具来创建这些模板。这意味着这些模板中可以内置最佳实践配置。

它们将被用来自动化资源的分配，并且还提供了灵活性，让产品团队能够根据各自项目的需求传递不同的参数来创建和配置这些服务。

因此，我们拥有一个高度灵活的全自动自助服务流程。举个例子，我们可以提供多种流水线模板，这样如果产品团队有一个Python应用程序，他们可以专门使用针对Python应用的流水线模板，该模板已经预配置了安全扫描工具或适用于Python应用程序的测试步骤。

这就引出了如何在公司中成功实施这一概念的要点。

如何成功实施内部开发人员平台

你不应该采取的方法是，一开始就构思一个庞大的主概念，以及一个理想中的IDP（身份管理平台）或自助服务平台，这个平台集成了所有最酷的功能和现代技术栈，非常灵活且强大，能够做上千件事情。

这在几乎所有情况下都是行不通的，原因有很多，我们将在本节中讨论这些原因。相反，我们希望在这里也采用一种非常流行的敏捷方法。

从立即增加价值的小步骤开始

你应该从小步骤开始，这些小步骤可以立即为至少一个团队增加价值。原因是在很多情况下，当应用团队使用的是老旧、过时的技术，或者是现代技术的旧版本等等时，他们很难一次性完全迁移到一个完整的现代化技术栈平台上，对吧？

因此，这对他们来说不会有太大的改善，因为他们现在需要自己付出所有的努力和工作来开始使用这个平台。所以，作为平台团队或在组织内部实施平台时，你应该首先考虑产品团队实际上是从哪里开始的。也就是说，当前技术使用的现状是什么，然后帮助他们逐步从当前状态过渡到理想状态。这种方法效率更高。

将 IDP 视为产品

所以，首先你应该将IDP视为一个产品。这意味着什么呢？

IDP（内部开发者平台）并不是一个你一次性实施完就万事大吉的项目，让应用团队接手即可。实际上，它是一个需要随着时间不断发展和完善的服务平台。就像产品团队开发的应用程序一样，平台也是平台工程师所开发的产品。正如应用团队会为其应用程序引入新功能、更新这些功能并进行改进等，平台团队也需要管理和升级他们提供给产品团队的服务版本，同时还需要推出新的服务和工具，以及新的工具组合等等。

所以它是一个拥有自己开发和发布生命周期的产品。因此，他们正在为开发者开发一个内部产品或内部平台，这就是为什么它被称为IDP（内部开发者平台）。和其他所有产品一样，它需要持续的工作和迭代。

正如我所说，就像你开发一个应用程序一样，一步一步来，一次只做一个功能，从1.0版本开始并逐步改进，平台的开发也应该如此。

那么现在有趣的问题是：平台的 1.0 版本是什么？你从哪里开始？🤔

好吧，我有一些实际步骤可以回答这个问题。🤓

确定常用工具

从容易实现的目标开始！

例如，如果你识别出组织内许多团队共同使用的工具，这些工具就可以成为首批集成到平台中并作为服务提供的候选工具。

这可能是 Jenkins、Gitlab CI/CD、Kubernetes、Vault。所以基本上任何已经成为标准的工具。所以很多团队都在使用它。

为了做到这一点，你需要与应用团队紧密合作，因为你正在为他们开发平台，以使他们的工作更高效。因此，了解最阻碍他们的问题、对他们来说最具挑战性的事情（比如管理Kubernetes集群）并接手这部分工作是很有意义的。如果开发者看到你确实在解决他们工作流程中的问题或瓶颈，他们会愿意配合的。

如果你从随机的东西开始，比如“_ 嘿，团队，你们都在使用不同的 CICD，所以我们想引入一些标准产品，你们都必须切换到其中之一 _”。

当你那样做的时候，实际上是在没有改善他们工作流程的情况下增加了他们的工作量，至少短期内是这样的。因此，这类事情应该在后续的步骤中进行，可能是2.0版本的时候，一旦你证明了你确实让他们的工作变得更简单和更高效，并且已经减轻了他们的一部分工作负担。这样一来，他们就有了一点额外的能力来承担这种初始的额外工作。

因此，正如你所见，成功构建一个平台团队不仅关乎工具和技术（这些工具和技术使得实现自助式内部开发者平台成为可能），同样也关乎人的因素、如何与应用团队协作、如何围绕这一点创建文化、设定合作规则和明确责任。

从长远来看，你将拥有一个全公司的平台工程师团队和多个应用团队。与其让每个应用团队各自为政，以自己的方式处理应用程序运行时和基础设施，不如让他们使用预先配置好的服务。这些服务可以通过平台团队构建的平台来自助获取，该平台已经集成了最佳实践、标准以及所有专业知识。

所以现在一个非常有趣和合乎逻辑的问题是......

这是否意味着不再需要 DevOps 工程师？

我们讨论过平台团队和应用团队之间的共同责任，对吧？平台团队负责运维部分，而应用团队则负责正确使用这些工具并将它们集成到他们的开发工作流程中。

➡️ 因此，应用程序团队不需要设置和操作集群，但他们仍然需要知道如何正确地将应用程序部署到集群中，比如创建正确配置的清单文件。 ➡️ 他们不需要知道如何创建用于基础设施的Terraform模块，但他们仍然需要知道如何使用这些Terraform模块，并可能将它们集成到他们的流水线中。

➡️ 他们可能从平台获得一个CI/CD模板，但仍然需要对其进行设置，并为他们的应用程序添加额外所需的步骤。

因此，除了应用程序开发之外，他们仍然有一些非功能性需求需要考虑，尽管由于将这些需求分配给了平台团队，其范围已经大大减少了。

这意味着你仍然需要在产品团队中配备DevOps工程师，但他们现在分担了认知负担，不需要对云、Kubernetes、Helm chart、监控、安全、合规性、开发等上百种其他事项都有深入了解。因为他们现在专注于正确使用这些非功能性工具，而不是去操作它们。

所以通过这种负载分配，工作变得更加集中和简单，但他们仍然需要正确地完成这些任务，并且需要掌握使用这些工具的专业知识。

但这里的内容变得更加有趣了。

面向平台的DevOps

正如我所说，平台也是一个产品，对吧？

要添加功能，使 UI 更加用户友好，为新的酷工具提供服务，修复平台中的错误，开发 Terraform 模块并使用 GitOps，为其基础设施创建管道即平台底层的代码。

这是一个面向应用团队的产品。就像你需要添加功能、使用户界面更加友好、为新的酷工具提供服务、修复平台中的错误、开发Terraform模块并使用GitOps，以及为支撑该平台的基础设施即代码创建流水线一样。

再次说明，如果你有独立的云或本地基础设施团队或安全团队，平台团队需要与他们紧密合作来构建他们的平台产品。

这意味着平台就像应用程序一样，需要持续开发，并通过多次反馈迭代以及与最终用户的紧密互动来收集意见。这些最终用户主要是应用程序团队，但有时也包括治理和合规人员，因为他们需要了解系统在整个组织中的合规情况。

因此，我刚才描述和列出的所有这些实际上都是需要 DevOps 的流程， 因为它们与我们在应用程序开发中使用的流程相同。

因此，在平台开发过程中需要大量的DevOps流程，从逻辑上讲，这意味着你可能还需要在平台团队中设立一个独立的DevOps工程师角色。

不同公司的实施路径

实际上，我们知道，在实施DevOps方面，各个组织的做法不尽相同。

➡️ 有可能公司会雇佣平台工程师，他们负责执行DevOps和云工程任务，而公司只是将这个职位称为平台工程师。因此，尽管职位名称不同，但所需的技能是相同的。

➡️ 可能是他们将DevOps工程师完全从产品团队中移出，以形成一个独立的平台团队。但这将在应用团队中造成空缺，因为正如我所说，你仍然需要有人来创建Kubernetes配置文件或构建CI/CD流水线，并将其与各种平台集成。

因此，公司可能会将这些任务作为开发人员工作的一部分。所以你可能会看到一些应用团队中没有专门的DevOps工程师角色，而是由开发人员接管这些任务，这在许多组织中已经是一种实践了。

但归根结底，无论两个团队中是否有专门的DevOps工程师角色，你都需要在应用程序和平台开发中实施DevOps流程。而且，公司如何决定团队结构以及角色分配，这在不同组织之间可能会有所不同。因此，根据这一点，你最终会拥有一个应用或产品DevOps团队和一个平台DevOps团队。

所以长期以来，DevOps 工程师需要同时具备这两方面的技能：搭建集群和使用集群，设置和保护 AWS 基础设施，并利用这些基础设施来部署和运行应用程序。

现在这些任务和角色被分开是合理的。这并不是因为同时掌握两者太难了，也不是因为你不能什么都懂。但在现实中，根据项目的复杂程度，一个人或一个角色在工作中可能没有足够的时间和能力来同时承担这两项工作。

➡️ 您可以加入平台团队 ，并利用您的知识来配置和管理工具，并利用这些知识构建开发人员平台。 ➡️ 或者，您可以加入开发团队并在那里简化应用程序开发和发布流程，同时成为平台团队和应用程序团队之间的接口或中介。

很明显，当你从两个角度全面了解这些工具并掌握整体情况时，你可以更好地完成这些工作。因为作为一名平台工程师，你需要与应用团队紧密合作，理解他们的流程，以发现任何瓶颈或所有团队中需要标准化的事物。因此，全面理解双方的情况，你就能更容易地完成工作，因为你理解了两方面的内容。

平台和云工程师有什么区别？

总的来说，平台工程是对我们在这篇文章中所看到的所有其他概念（如DevOps、云计算、SRE）的一种增强。

云工程师必须是云服务专家

但如果我们将其缩小到主要区别，云工程师需要了解云服务，并在这方面成为专家。通常甚至会专门研究某个云平台。因此，他们需要知道如何从本地迁移到云端，如何设置混合基础设施，管理云端的存储和备份，以及管理云成本。

所以基本上是与云相关的所有事情。并且他们应该能够结合云服务来构建符合公司需求的基础设施。

平台工程师在云计算领域之外还拥有更广泛的知识和工具

但平台实际上不仅仅局限于云之外的工具，**它拥有更广泛的知识范围 **并且实际上构建了一个平台，开发者或产品团队可以使用这个平台自助获取他们需要的任何资源，不仅限于云端资源，还包括各种其他工具。所以基本上，它们是在将像AWS这样的基础设施和服务定制为公司内部团队使用的平台即服务（PaaS）。

所以，他们实际上是在云之上构建了一层，这一层包含了众多的云服务以及一些不属于云的服务和工具。

总结

我确信，就像以往一样，每个项目看起来都会有所不同，并且会以各种方式实现这些概念。

• 许多公司会雇佣DevOps工程师作为平台工程师。
• 许多云工程师在较小的公司里可能也会成为平台工程师，而平台工程师可能会接管DevOps的角色。
• 在较大的公司中，云团队将与平台团队合作，并分享他们的专业知识。因此，云层之上是平台层。

并且这种情况可能会持续一段时间，直到行业内形成一种关于团队架构的标准方式。可能是一家大型公司成功地大规模实施了这种模式，然后其他公司就可以基本上复制这个成功的模式。 因此，我们在某种程度上实现了标准化，但从根本上说，这是基础。

从工程师的角度来看，理解这些差异以及职责的愿景不仅在找工作时对你有很大帮助，而且在你被聘用到特定职位后也能帮助你更好地完成工作。因为当你明白这些差异后，你可以引导你的团队或公司对这些角色有更清晰的认识。

在这篇文章中我们讨论了很多内容，我真的希望我能够帮助你理解平台工程究竟是什么，它是如何融入现有的DevOps和云计算世界的，并且我希望你能从中获得一些对你实际工作或职业生涯有用的信息。