了解平台工程策略中哪些部分是相同的，无论组织规模如何，以及大型组织需要关注哪些方面。
译自 Cloud Migration and Platform Engineering at Large Organizations，作者 Jennifer Riggins。
随着大型组织向云计算转型，平台工程作为一种促进迁移的有趣方式脱颖而出，并希望能够提前预测和解决迁移过程中通常带来的认知负担。
在 All Day DevOps 的主题演讲中，Google Cloud 的客户工程师 Yonit Gruber-Hazani 分享了她对公共部门经验的思考，以及平台即产品理念如何帮助组织实现迁移。在本文中，我们将总结她观察到的平台工程的一些模式和反模式，并探讨它们在不同规模公司中的相同点和不同点。
为什么需要平台工程？
Gruber-Hazani 以一个场景作为开场：“想象一下，一个新开发人员加入您的团队。您递给她一台新笔记本电脑，并说：‘这是一台全新的空笔记本电脑，请自行找到并安装所需的操作系统，执行安全强化，设置网络，安装防病毒软件和 IDE [内部开发人员环境]，并将自己添加到公司的 Active Directory 或任何用户管理系统中。然后，您就可以开始开发了。’”
当然，现实中我们不会这样做。IT 部门会提前准备好安装了所有必要软件并可以正常运行的笔记本电脑，为开发人员铺平道路。
“我们为他们提供所有他们需要的东西，让他们能够专注于自己的工作，并作为公司的开发人员开始他们的旅程，”她说。
Gruber-Hazani 提到了一个经常触发平台工程的反模式。我们永远不会让员工自己设置薪资和人力资源流程，那么为什么在 Syntasso 的 Abby Bangser 所谓的“非差异但并非不重要”的工作上，我们却要为他们提供如此多的选择呢？平台团队的目标是通过软件开发人员使能来解决这个问题，从入职到发布，为他们铺设一条“黄金之路”。开发团队仍然可以自主地为最终用户创造价值，但他们不需要了解云计算、运维、安全等方面的所有知识。
Gruber-Hazani 说，这种开箱即用的设置方式也适用于新应用程序、新开发人员和新应用程序团队的入职，目的是在他们开始在我们的生产系统中开发应用程序时，为他们提供最佳的开发体验。
这就是为什么大型组织不应该向开发人员或团队展示整个 Google Cloud 平台，尤其不应该展示庞大的开源云原生图景，让他们随意选择使用什么。
她说：“我们不想这样做，因为这样会形成一片混乱的局面，因为 DevOps 团队将不得不管理他们选择的每件事，我们需要支持它，我们需要维护它，并需要进行监控。而且，我们不想给开发人员带来这么多额外的负担。他们只想专注于应用程序及其背后的业务逻辑。”
那么，为什么需要平台工程？答案是：减少开发人员的认知负担，让他们能够达到一种流畅的状态，专注于构建他们的应用程序。
开发人员体验和不断增加的认知负担
Gruber-Hazani 将开发人员体验（DevEx）定义为：“是让我们每天早上都来上班的原因。是让我们一年又一年地继续工作的原因。它定义了我们在工作生活中的幸福感、成就感，以及在一天结束时对他人的帮助感。它是我们成为人并能够工作的原因。”
DevEx 反过来会影响以下因素：
- 绩效
- 生产力
- 工作中的幸福感
- 质量
- 留任率
她解释了三个用于衡量生产力的DevEx指标：
- 流畅状态： 即“进入状态”，是指开发人员完全投入并享受工作的状态。平均需要23分钟才能进入这种状态，而等待其他人完成某项任务等因素可能会迅速中断这种状态。
- 反馈循环： 对开发人员的操作作出响应的时间和方式。Gruber-Hazani提到了等待代码重新编译或等待访问另一个虚拟机的例子。代码审查是关闭重要反馈循环的一部分。事实上，今年的DevOps状况报告2023（也称为DORA报告）发现，进行更快的代码审查的团队软件交付性能提高了50%。
- 认知负荷： “执行任务所需的心理处理”，她解释说。“这可能阻止开发人员创造并提供价值。” 不良的文档和手动、不稳定的步骤会增加这种负面开发体验和工作倦怠。而今年的DORA报告发现，高质量的文档可提高25%的性能。
去年的StackOverflow调查发现，62%的受访者每天花费超过30分钟搜索答案或解决问题，而25%的人每天花费超过一小时。这种可避免的挫折既会打破流畅状态，又会增加认知负荷，使文档成为各大小公司平台战略的重要组成部分。
什么是平台工程？
如果每个组织的平台本质上都不同，那么是什么共同模式将平台工程的社会技术学科联系在一起呢？Gruber-Hazani列举了以下几点：
- 可重复的工具和模型，比如基础设施即代码和可重用的CI/CD流程。
- 通过API的自助服务。
- 一对多的“服务自动贩卖机”，特别是在需要为50到100个开发团队提供服务的大型组织中。
- 在警戒线内的平坦道路。
- 组织特定的工作流程。
在过去的几年里，Gruber-Hazani在与Google Cloud在公共领域的客户合作中发现，大多数应用都需要相同的警戒线：
- 监控
- 日志记录
- 调试
- 安全性、身份验证和授权
- 与后端系统的连接（如结构化数据库）
- 优雅降级和故障切换
- 负载分流和限制
- 共享的通用库
- 测试基础设施
- 发布基础设施
所有这些通常可以在一个平台或一组平台中解决，以帮助平台团队实现更好地为开发人员提供服务的目标：
- 驯服技术复杂性
- 降低成本
- 提高开发速度
- 强制执行安全和安全警戒线
- 降低认知负荷、疲劳和倦怠
这是通过为生产铺平黄金之路，采用最佳实践和安全警戒线来实现的。这通常包装在服务目录中，或通常是针对不同开发者组的一系列服务目录，这些目录抽象在内部开发者门户后面，比如Backstage或Spinnaker。
“我们希望开发人员更安全、更好、更快地工作。” — Yonit Gruber-Hazani, Google
平台工程与以前的自上而下平台的区别之一是平台即产品思维，Gruber-Hazani表示，这使得每个平台工程师至少是兼职产品经理。这要求每个平台团队平衡：
- 业务目标
- 内部客户需求
- 产品和团队能力
通过这种方式，开发团队能够理解如何更快地交付价值，而业务部门则能够深入了解工程部门通常的大量成本中心。
与用户交流
平台工程中的一个常见反模式是平台工程师也是工程师。这意味着他们可能认为自己最懂，但平台作为产品的思维依赖于与内部用户的交流。实际上，今年的DORA报告发现，专注于用户的团队性能提高了40% —— 无论这些用户是外部付费用户还是内部同事客户。
当你将平台视为产品时，你必须逐步构建，不断向内部开发人员征求反馈。Gruber-Hazani表示，这包括询问开发人员喜欢使用哪些产品、工具和语言，以及他们想使用哪些 —— 这反过来不仅有助于开发体验，还支持招聘和留任。询问你的开发人员是否想转移到容器上，或者他们希望在黄金之路中看到什么样的监控。这条黄金之路必须通过与开发者客户的持续对话来铺设，其中包括：
- 文档
- 支持
- 用户群
- 使用报告
- 缺陷报告
- 监控
- 站点可靠性工程（SRE）
- 新功能
- 评审
大型组织中的平台工程
但这些都是大多数平台策略中常见的模式。在大型组织中有什么不同？
您的组织越复杂，您的云成本就越复杂。这就是 FinOps 成为云迁移必不可少的工具，以便跟踪和优化谁在云中花费了什么。这种复杂性在大型组织中，尤其是公共部门中会增加，这涉及到复杂的采购流程，包括硬件、服务器和许可。大规模 FinOps 需要预算和警报。这也导致了不同的决策。Gruber-Hazani 以迁移到虚拟机作为降低成本的一种方式为例，或者团队如何使用现货机器来完成无状态工作。
“通常来自数据中心时期的的大型组织仍然保留这些做法，”她解释说，因此要尽早开始 FinOps，但要满足财务部门的现状。
她发现的另一个反模式是从最复杂的系统开始您的黄金路径工作。
“从更新依赖性较少的简单系统开始，将比从具有最多依赖性的最复杂系统开始获得更好的结果，”Gruber-Hazani 说。它还允许早期取得成功，从而培养内部平台倡导者。
这正是团队拓扑学中“最薄可行平台”概念的应用之处，您可以在更小的增量中构建，并通过紧密的反馈循环确保您正在构建和维护您的用户真正想要的东西，而不会太快创建过于复杂的东西，这只会增加技术债务。
在构建黄金路径时，逐步推进也很重要，因为她发现大型组织通常会在平台没有足够的弹性和信心时过早采用高价值服务。
然后，随着平台成熟度提高并进入第 2 天，Gruber-Hazani 说，会出现新的平台团队需求：
- SRE 值班轮换和事后调查
- 事件管理
- 更好的 CI/CD 管道
- 基础设施即代码
- DevSecOps
- 为平台维护人员和用户提供更多培训
- 跨组织架构标准
- 预算策略
- FinOps 计划和预测
- 贯穿始终的安全
最后，Gruber-Hazani 强调，知识可以减少恐惧，因此请花大量时间培养心理安全，始终让您的用户了解您的平台策略方向及其如何帮助他们实现目标。
“我们不是在取代人，”她说，强调自动化，尤其是在大型组织中，会引发对失业的恐惧。这条通往云的新黄金路径必须伴随着新技能的培训。
无论您的组织规模如何，都要不断收集有关内部客户对您的想法的反馈。
