随着平台工程话题热度上升，人们对它是什么以及它与SRE 和 DevOps 等有何不同存在很多困惑。事实上，随着许多 SRE 和 DevOps 专业人士进入平台工程角色，很容易将他们误认为是相同的。
平台工程只是一个可以用来加薪的头衔吗？
DevOps 是不是更名了？
这些差异比你想象的要微妙，但它们也是平台工程重要的原因。
DevOps
“你建造它，你运行它。” 2006 年，亚马逊的 CTO Werner Vogels如此描述公司的软件工程方法。亚马逊的开发者已经摒弃了传统的“翻墙”运维模式。相反，他们端到端地部署和运行他们的应用程序和服务。于是，DevOps 诞生了。
随着时间的推移，思想领袖为组织提出了不同的指标来衡量他们的 DevOps 设置是否成功。DevOps 圣经“加速”将交付周期、部署频率、变更失败率和平均恢复时间 (MTTR) 确定为标准指标。像Puppet的《DevOps现状》和Humanitec的《DevOps基准研究》[1]这样的报告使用这些指标来比较表现最好的组织和表现不佳的组织，并推断哪些实践对他们的成功程度贡献最大。
DevOps 为一些软件工程团队带来了更高水平的生产力和效率。但是对于许多组织来说，DevOps 的采用没有达到他们的期望。
Manuel Pais和Matthew Skelton在他们的《DevOps 拓扑》[2]一书中记录了这些反模式。在一种情况下，组织尝试实施真正的 DevOps 并移除专门的运维角色。开发人员除了之前的工作量外，现在还要负责基础设施、管理环境、监控等。通常，高级开发人员首当其冲，要么自己做这些工作，要么协助他们的初级同事。
这种所谓的“影子操作”反模式低效地分配了企业最昂贵和最有才华的资源。这是在 DevOps 设置中苦苦挣扎的企业中普遍存在的问题。Humanitec 的 DevOps 基准测试研究发现，虽然 100% 表现最好的组织报告说他们的开发人员可以自己完成所有 DevOps 任务，但 44% 的低绩效组织有影子操作。
影子操作表明 DevOps 的一个大问题：开发人员的认知负荷过大。认知负荷是一个人为完成一项任务必须处理的信息量。当认知负荷太高时，开发人员无法保留和处理完成工作所需的所有信息。
一些组织使用 DevOps 将一切都转移到开发人员身上，但许多开发人员不想做操作，或者无法兼顾额外的责任。随意的 DevOps 采用增加了开发人员必须与之交互的工具和工作流的数量及复杂性。云原生设置中的微服务架构通常需要 Kubernetes、配置管理、基础设施配置等知识。所有这些都会造成认知负荷，并阻碍开发人员完成最重要的任务：交付功能。
DevOps 文化表明，开发人员自助服务可以提高生产力和效率。同时，许多组织对开发人员的认知负担，凸显了对设置的需求，以提供一些结构、标准化和正确的抽象水平。
SRE
SRE 是由 Google 发明和推广的。与 DevOps 一样，这是一种文化转变。
根据Benjamin Treynor Sloss的说法，SRE 负责“其服务的可用性、延迟、性能、效率、变更管理、监控、应急响应和容量规划”。他们分别使用服务水平目标 (SLO) 和错误预算来设定对性能的共同期望，并平衡可靠性与创新。
理论上来说，SRE没有什么问题。但 SRE 采用不当会导致很多问题，尤其是对于缺乏与谷歌相同的资源或人才的组织。
雇用合适的 SRE 是困难且昂贵的。许多组织不能聘请经验丰富的 SRE 来满足其设置的需求。结果，一些运维人员承担了这些责任。这些企业中的 SRE 被迫更多地关注生存，而不是改善开发人员的体验。他们没有时间启用开发人员的自助服务和改进架构及工具。
这种“假”的 SRE 变成了一个非常严格的角色，让人想起了 DevOps 之前的软件工程方法。"DevOps拓扑"很好地总结了这一点。"开发人员仍然把仅有'功能完整'的软件扔到墙外给SRE。软件可操作性仍然受到影响，因为开发人员离实际运行他们构建的软件还差得远，而且 SRE 仍然没有时间与开发人员接触一起解决出现的问题。”
平台工程
所有这些历史都将我们引向平台工程。
Luca Galante 将平台工程[3]定义为“在云原生时代为软件工程组织提供自助服务功能的设计和构建工具链和工作流的学科。平台工程师提供的集成产品通常被称为“内部开发者平台”，涵盖了应用程序整个生命周期的运营需求。”
内部开发人员平台（IDP）以及构建它们的团队很重要，因为它们可以提高组织的绩效。Puppet 的 2020 年和2021 年 DevOps 状态报告说明了内部开发人员平台的使用与 DevOps 发展程度之间的密切关系。
Humanitec 首席技术官Chris Stephenson 将 IDP 描述[4]为“开发人员和平台团队之间的桥梁，以便开发人员可以在不受运维阻碍的情况下完成他们的工作。另一方面，运维可以确保应用标准并且事情是可扩展的，而不必将其放在开发人员的肩上。”
好的平台可以缓解因采用不当的 DevOps 和 SRE 而产生的问题。DevOps 给开发人员带来了过多的认知负担，平台工程试图通过找到正确的抽象级别和铺平黄金路径来解决这一问题。假 SRE 往往会给开发人员造成瓶颈，而平台工程则优先考虑开发人员的自助服务和自由。
这种改进可以归因于平台工程的产品思维。在PlatformCon 2022的演讲中，"Team Topologies "的共同作者Manuel Pais解释了平台即产品的方法。平台就像产品一样，依赖于自愿采用，设计为易于使用，并与技术一起变化。因此，适用于产品的原则和程序也应该适用于平台。
在实践中，这意味着进行用户研究、创建产品路线图、定期征求反馈意见、迭代、启动平台并在内部向开发人员推销。这个过程有助于平台团队避免常见的陷阱：成为一个美化的帮助台、不能获得足够的平台内部支持、建立开发人员不想使用的工具等等。它还迫使平台团队在开发人员的自由度和为其特定组织及其开发人员抽象出的复杂性之间取得适当的平衡。
这种方法可确保你的平台真正解决开发人员的问题。它还可以提高你对组织面临的限制的认识，防止了像SRE这样的胡乱实施，只是因为它对谷歌有用。
平台工程是 DevOps 演进的下一个阶段。它包含了之前文化转变的最佳意图。与 DevOps 一样，它支持开发人员自助服务。与 SRE 一样，它可以减少错误并提高运输的可靠性。
平台工程将成为下一件大事
原文链接：https://thenewstack.io/how-is-platform-engineering-different-from-devops-and-sre/
引用链接
[1]
《DevOps基准研究》: https://humanitec.com/whitepapers/2021-devops-setups-benchmarking-report
[2]
《DevOps 拓扑》: https://web.devopstopologies.com/#anti-types
[3]
平台工程: https://platformengineering.org/blog/what-is-platform-engineering
[4]
将 IDP 描述: https://platformengineering.org/talks-library/devops-is-dead-long-live-platform-engineering
