最近某位大神在推特上发了一个帖子，结果引来了国内众多卖课机构、培训机构的狂欢，开始贩卖焦虑，其实「平台工程」也不是什么特别高深莫测的东西。闲得无聊，把这位大神的几个帖子薅了下来，你看过之后就会觉得也没啥，都是熟悉的东西。
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)平台工程师围绕复杂的基础架构配置构建工具和抽象，这样大多数软件工程师就不必担心这些方面。由此产生的系统就是所谓的“内部开发者平台”（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）大的公司则不必说，不但有专门平台，甚至每个专项都会有专门的团队来支撑。
另外就是国内研发效能团队的业务边界是比平台工程范围广的。不仅仅负责底层基础设施IaaS、k8s、PaaS、FaaS这些，所有和产研相关的平台都有涉及，比如测试相关、项目协同等。
优化开发者体验
平台工程是一套用来构建和运营支持软件交付和生命周期管理的自助式内部开发者平台的机制和架构。平台工程的目标是优化开发者体验并加快产品团队为客户创造价值的速度。
对我个人而言，我更喜欢《Gartner发布2023年十大战略技术趋势》这篇文章中给出的平台工程的解释(如上）。因为相对于之前的很多概念和实践，这里不但提到了交付价值，更是首次提到了「优化开发者体验」。这一点是非常难能可贵的。之前很多公司都没有注意到这一点。
内部开发者平台反例
现在很多公司都开始做内部开发者平台，有的叫发布系统，有的叫项目管理平台，叫什么无所谓，但都有一个共同点就是做得太「烂」了。这些平台没有聚焦到导致开发进度放缓的开发痛点和阻力的解决方案上，反而是拍脑门想了很多看上去「高大上」实际上对一线产研工作没有毛作用反而加重了一线产研工作量让大家怨声载道的功能上。让一线产研小伙伴苦不堪言，内网骂完外网骂。这就是内部开发者平台的典型反例。
相关文章
scmroad 主要关注领域 { 研发效能、研发工具链、持续交付、DevOps、效能度量、微服务治理、容器、云原生}
| 感谢点赞、转载 |
|---|
| 关注我，了解最新研发效能发展动向 |
| 欢迎进入「DevOps研发效能」一起探讨 |
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。