本文主要是介绍SRE 的黄昏，平台工程的初晨，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
船停在港湾是最安全的，但这不是造船的目的
完成使命的 SRE
过去 10 年，SRE 完成了体系化保障系统稳定性的使命。但在这个过程中，SRE 也逐渐变成了庞大的组织。而 SRE 本身的定位是保障系统稳定性，许多时候会因为担心稳定性而减缓发布。虽然我们希望软件的发布又快又稳，但无论是根据日常经验，还是从 DORA 的报告中，我们都能看到软件交付表现 (Software delivery performance) 和运行表现 (Operational performance) 整体上还是此消彼长的情况。
那有什么可以打破这个困局呢，DORA 在 2023 年的报告中也给出了答案，引入以用户为中心 (user-centric) 这个元素。
到了实施层面，用户为中心对应的就是近两年逐渐兴起的平台工程 (Platform Engineering) 概念。
平台工程的崛起
平台工程最早能查到的系统性分享应该是 2017 年 The Paved Road at Netflix。
平台工程的出圈是由去年「DevOps 已死，平台工程才是未来」的一条宣言开始的。
当下平台工程已经成为了行业公认的趋势，就在前两天 Gartner 发布的 2024 技术趋势报告中，平台工程也是连续第二年上榜，还是在被 AI 相关的屠榜中占得一席之地（而去年爆炒的元宇宙已经不在了）。
而在稍早之前 Gartner 另一份 Hyper Cycle 报告中，Platform Engineering 以及它的载体 Internal Developer Portal (IDP) 也从 2022 的创新逐渐走向 2023 的高峰。
平台工程的背后有实力强大的商业公司背书，比如 HashiCorp, Harness。
还有日益壮大的 Platform Engineering 社区。
平台工程属于 PaaS 层，它的逐渐流行可以从三个方面来看：
- 在其之下依赖的 IaaS 层通常是各大云厂的 IaaS，这部分日趋成熟，所以使得精力可以上移到 PaaS。
- 在其之上被依赖的 SaaS 层则是各业务线，随着业务线的扩展，就希望提炼出一套可以复用的组件，这就是要下沉到 PaaS 层。
- PaaS 层本身的平台工具也日趋完善，从最底层的统一平面 Kubernetes 往上，已经有一组比较成熟的平台工具套件。
平台工程和之前的中台概念有类似之处，同样夹在底层 IaaS，上层业务 SaaS 之间。和中台业务的区别在于，之前的中台多面向业务层，是去整合上层散乱重复的业务系统。而平台工程则是面向基础层，去整合底层的基础设施系统。
现在拆中台的原因是虽然中台整合了，但离业务系统远了，无法响应前线的需求。平台工程崛起的原因，是因为下层的基础设施太复杂了，好不容易摸清门路，发现还有人挡路。Terraform 可以大获成功是因为它屏蔽了管理多云资源的复杂度。
平台工程要做的事情，就是把 Terraform 的成功泛化，把 SRE，PaaS，研发效能这些都整合在一起，提供一个对开发者友好，让他们可以自助的平台。
中台要拆的原因是业务的需求是各异的，电商，外卖，放贷有完全不同的业务逻辑。平台工程可以合的原因是研发的需求是共通的：大家都用 Git 做代码管理，用 Prometheus 看监控，用 Terraform 管云资源，用 Bytebase 管数据库，从否认开始解决 bug 的第一步。
结束语
平台工程会是未来，但在研发组织拥抱平台工程的过程中，也首先还需要经历一段 SRE, PaaS, 研发效能这几个团队整合的阵痛。早年的运维工程师叫做 PE，当中历经 SRE 的转型，如今又要迈向 PE。从 Production Engineer 到 Platform Engineer，历史的轮回，冥冥之中自有天意。
💡 你可以访问官网，免费注册云账号，立即体验 Bytebase。
这篇关于SRE 的黄昏，平台工程的初晨的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
