研发效能｜DevOps 已死平台工程永存带来的焦虑 _生活百科

最近某位大神在推特上发了一个帖子，结果引来了国内众多卖课机构、培训机构的狂欢，开始贩卖焦虑，其实「平台工程」也不是什么特别高深莫测的东西。闲得无聊，把这位大神的几个帖子薅了下来，你看过之后就会觉得没啥，都是熟悉的东西。
Sid Palas & 平台工程这位大神的名字叫 Sid Palas，一位专门做 DevOps 和 Cloud infra 相关工作的小伙伴。为了让大家了解他，他的 github 我附在最后了。下面就是这个非常有意思的帖子。原帖可以到推特上去围观。共有六部分，第一部分我贴了原图，后面的五部分我把文字复制了过来。

文章插图
DevOps is dead , long live Platform Engineering! 1) Developers don't like dealing with infra 2) Companies need control of their infra as they grow. Platform Engineering (and Internal Developer Platforms) enable these two facts to coexist.
DevOps 已死，平台工程永存。1) 开发人员不喜欢与基础设施打交道 2) 公司在发展时需要控制他们的基础设施。平台工程（以及内部开发者平台）可以同时满足这两个诉求。
Fact 1: Most developers don't like dealing with infrastructure. They want to write code and run it somewhere but don't care much where that is. Functions as a Service (e.g. Lambda) or Platforms as a Service (e.g. Vercel) provide this experience.
事实 1：大多数开发人员不喜欢处理基础设施。他们想编写代码并在某个地方运行它，但不太关心运行在哪里。函数即服务（例如 Lambda）或平台即服务（例如 Vercel）提供了这种体验。

文章插图
Fact 2: As a company/organization grows, its needs may "outgrow" the constraints imposed by the FaaS and PaaS offerings. The challenge then becomes moving up the control axis without exiting the Developer Comfort Zone. This is where platform engineering comes into play!
事实 2：随着公司/组织的发展，其需求可能会“超出”由 FaaS 和 PaaS 产品施加的限制。然后挑战变成在不离开开发者舒适区的情况下向上移动控制轴。这就是平台工程发挥作用的地方！

文章插图
Platform engineers build the tooling and abstractions around the complex infrastructure configurations such that most software engineers don't need to worry about those aspects as much. The resulting system is what is known as an "Internal Developer Platform" (IDP)
【研发效能｜DevOps 已死平台工程永存带来的焦虑】平台工程师围绕复杂的基础架构配置构建工具和抽象，这样大多数软件工程师就不必担心这些方面。由此产生的系统就是所谓的“内部开发者平台”（IDP）

文章插图
The exact form of an IDP will vary greatly from one organization to the next. At a small company, it could be a set of helm charts that prescribe best practices for deploying services. At a large company, it might be a fully automated Infrastructure as Code solution.
IDP 的形式因组织而异。在一家小公司，它可能是一组说明部署服务最佳实践的 helm charts 。在一家大公司，它可能是一个完全自动化的基础设施即代码的解决方案。
The key is that it provides the control the company needs while keeping the DevOps effort within the Developer Comfort Zone!
关键是它提供了公司所需的控制，同时将 DevOps 工作保持在开发人员舒适区内！

文章插图
平台工程价值观Sid Palas 的观点非常简单、直接、好理解：平台工程团队以及他们负责的内部开发者平台，向下维护底层基础设施，向上给开发人员提供服务。开发人员自助式使用这个平台，避免直接与底层基础设施打交道。
其实目前很多公司已经这么做了，这不是什么新鲜东西。只不过不同规模的公司，这个开发者平台的成熟度不一样。这一点 Sid Palas 自己也提到了。而在我了解到的公司一般分为三种情况。1）在公司规模比较小的时候，业务也比较少，谁来负责维护开发者平台是可以商量的。找几个开源工具就能满足需求，让开发团队或者运维团队哪个团队维护都可以。我见过研发实力强，让研发团队维护的，也见过运维实力强，让运维团队维护的；2）中等规模的公司，这个时候都会有专门的研发效能团队，或轻或重，也都会有自己的 IDP 平台了，哪怕是几个开源工具「粘合」到一起组装而成；3）大的公司则不必说，不但有专门平台，甚至每个专项都会有专门的团队来支撑。