平台工程是什么

CIT云原生平台工程社区，是中国最活跃的云原生社区之一，致力于推动平台工程在国内落地，提供工程师体验。

关于本文

这篇文章帮助你更好的理解：

• 为什么平台工程是该领域积极新兴的一门学科
• 平台工程到底指的是什么
• 为什么平台工程重要
• 如何实现

本文将为您提供从平台工程背后的理论到它如何与整个组织的团队合作的一切，以及如何创建正确的平台工程所需的技术栈。

平台工程的演变

平台工程——新的工作职能、新的能力、新的工程方法……但同时，也是新的让人困惑的名词。在中大公司有很多头衔、工作职能和方法论，虽然旨在帮助工程师让他们的生活更轻松，但最终却让每个人的工作都变得更加困难，其是那些崭露头角的工程师。

到目前为止，我已经从事科技行业十多年了，科技行业所发生的变化绝对是巨大的。尤其是最近10年，云原生AI席卷了整个行业，这是最好的时代，也是最差的时代。平台工程是我多年来亲眼所见的一种新兴实施方式，它实际上有助于有几个原因：

1. 它已经存在很长时间了； 它只是没有标题或成为焦点。
2. 实际上非常需要它，因为它有助于区分团队之间的关注点。
3. 在一个一切都在不断变化的世界里，它背后的工程是需要的。

平台工程目前仍然存在很多争议的地方，大多数工程师的困惑来自于想知道平台工程和DevOps、SRE和其他工程途径的区别。 随着某些事物的出现，每个人都或多或少地试图弄清楚它到底意味着什么。 这就是为什么我们最终会得到多个不同的定义。

然而具有讽刺意味的是，平台工程并不是什么新鲜事。 多年来，工程师们一直在构建自助服务功能。 它只是还没有成为自己的团队或焦点。 这或多或少是经理或领导层的某个人做的事情当问题变得很棘手时，团队会要求工程部门作为一个项目来进行兼职。 也许是需要使用系统或平台来部署代码的开发团队或其他工程团队，但他们没有了解底层系统，因此他们需要某种自动化、脚本或“单击按钮”来启动环境，以便他们可以运行他们的代码。

我认为最好的区别如下：

平台工程重点关注构建内部工具（例如自助服务工具），改善工程师的生活更轻松。 他们有一个自助服务方法（UI、CLI 或一些自动化/可重复过程）来创建他们想要的确切环境而不是被它的创建细节所困扰。

为什么你需要关心

从人工智能到 DevOps，再到任何其他流行和新兴的 IT 领域，技术世界正在发生一切，为什么你应该或者还有其他人关心平台工程吗？

原因有二：

1. 这或多或少感觉像是我们第一次真正关心工程师。
2. 我们想让工程师的生活变得更好。

首先，让我们从“关怀”因素开始。 一个基础团队花了很多钱，要求很多钱。目前众所周知，IT/技术/工程团队并没有得到真正的“照顾”。 平台工程的建立是为了真正关心技术团队。 这一切都是为了减轻认知负担，确保适当分离关注点，并像对待客户一样对待技术团队。

那么，为什么要关心平台工程呢？ 因为这是工程师的自我觉醒，我们不想再需要关心底层平台。 它将“关心”和“让我帮助你让你的生活更轻松”融入到平台工程中。

平台工程 vs DevOps

• 平台工程==部署系统/平台
• DevOps == 部署应用程序

DevOps 就目前而言，就是将应用程序和应用程序堆栈部署到 Dev 中所需的位置，登台/UAT、QA 和产品。 是的，DevOps 团队通常也会部署系统/平台，但他们部署它是为了运行将包含他们正在部署的应用程序的环境，通常是客户的应用程序/应用程序堆栈.

平台工程并不关心应用程序/应用程序堆栈。 他们不是在部署应用程序，而是在部署系统，并且这些系统适用于内部工程/开发团队。 这不是为付费客户/客户部署系统，而是关于为内部工程/开发团队以及那些内部工程/开发团队部署系统/平台是平台工程师的“客户”。

平台工程 vs SRE

• 平台工程==部署和管理内部系统。
• SRE == 维护（有时是部署）并确保外部系统的性能

就目前而言，SRE 真正关注的是现有系统的性能和维护，而该系统通常是被外部顾客/客户接触。 这一切都是为了确保系统和系统上运行的应用程序正常工作预期的，或者从性能角度希望更好。

平台工程并不关心外部系统和应用程序。 它关心内部系统，包括这些系统的性能和维护。

什么时候公司需要实现平台工程

我相信时机是关键，如果您的团队很小以至于产品刚刚开发，那么很可能没有预算、能力或领导团队的支持来组建平台工程团队。一旦内部工程/开发团队扩大，大家被多个请求淹没，开发效率开始下降，互相开始扯皮，新人入职体验很差的时候，或许你该考虑下是否要投入资源开发平台工程了。

平台工程最终定义

平台工程是根据平台的内容来创建和管理集成能力通过自助服务功能满足用户需求（平台用户是使用该平台的内部工程师/开发人员）。

平台工程标准化

当您创建任何类型的系统、平台、工具、部署方法或技术中的任何其他内容时，都需要一些某种标准化。 否则，每个人都或多或少地使用不同的工具，并创建大量的技术负债。

标准有各种形状和尺寸。 例如，如何构建容器映像或如何部署 Kubernetes。 如果你有三位工程师，他们都使用三种不同的方法在生产中部署 Kubernetes 集群，肯定会有一个大量的混乱、沮丧、技术债务和停机时间。 这就是为什么工程师围绕诸如CICD。

对于平台工程来说， 您需要围绕您的组织的技术架构创建标准化使用。标准给我们带来的一大好处是能够高效地构建和使用工具。 你投入的工具越多混合，环境变得越麻烦。 工程师很困惑，开发人员也很困惑，没有人知道该做什么使用。 在部署生产级工作负载的组织中，确保部署不会按预期进行的首要方法是预期的结果是不引入标准。你在实现平台工程时候可能会参考下图，挑选合适的技术：

技术要求

• 云原生技术。
• 编程自动化功能。
• Kubernetes/Docker。
• CICD

平台能力

​
功能是平台根据开发人员/工程师的需求实现特定目的所需的能力。一旦平台本身确定下来，接下来要考虑的是平台需要哪些能力。 你必须从平台用户那里得到反馈，看看他们需要什么。监控，日志还是需要安装些第三方工具：argocd，crossplane。。。

平台交互

最后但同样重要的是整体平台交互。 这取决于开发人员/工程师的表现与平台互动。

• 他们需要 CLI 吗？
• 他们需要 API 吗？
• 他们需要用户界面吗？

工程师/开发人员的平台应该是以上所有。 应该有提供 CLI、UI 和 API 的功能。 一些开发人员/工程师会想要一些东西基于 CLI 或 API，他们可以使用它们，甚至可以根据自己选择的语言构建到不同的客户端中。 其他团队可能需要一个用户界面（如自助服务门户），他们可以登录、输入一些信息、单击按钮，然后获取资源。

提案

我计划提出一个可以包含所有组件的平台标准草案。 我的意思是，作为一个平台构建者，我们花费了太多的时间来学习每个组件的官方文档，如 argo、flux、port、backagestage…等。 是时候让世界变得更美好，让我们的生活变得更轻松。以下是我的最初想法，以平台为中心而不是以应用为中心！

platform enable workflow -t argoworkflow
platform enable cd -t fluxcd
platform enable ci -t github

api/workflow/template/create
api/workflow/insatance/run
api/workflow/instance/stop

---

我是南哥，日常分享高质量文章、架构设计、前沿资讯，加微信拉粉丝交流群，和大家交流！