共计 2985 个字符，预计需要花费 8 分钟才能阅读完成。
最近某位大神在推特上发了一个帖子，后果引来了国内泛滥卖课机构、培训机构的狂欢，开始贩卖焦虑，其实「平台工程」也不是什么特地高深莫测的货色。闲得无聊，把这位大神的几个帖子薅了下来，你看过之后就会感觉也没啥，都是相熟的货色。
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 已死，平台工程才是将来
“扯淡的 DevOps，咱们开发者基本不想做运维！”
Gartner 公布 2023 年十大策略技术趋势
聊聊“DevOps 已死”
| 感激点赞、转载 |
|---|
| 关注我，理解最新研发效力倒退动向 |
| 欢送进入「DevOps 研发效力」一起探讨 |
