世界上最古老的拍卖行苏富比缘何采用平台工程？丨Part 2

平台工程社区

已于 2023-09-25 11:20:36 修改

阅读量53

点赞数

文章标签：运维大数据网络

于 2023-09-25 11:19:18 首次发布

本文链接：https://blog.csdn.net/PE_community/article/details/133269510

版权

作者｜Chad McElligott

翻译｜平台工程社区

链接｜https://chadxz.dev/platform/

在上一篇文章中，我提到了关于平台工程的两个重要课题，根据结果而非产出设定目标及真正了解平台用户的需求。今天我们将继续分享另外两个要点，为您及您所在企业的平台工程项目及团队提供一些想法与灵感，为平台工程打下坚实的基础，并建立高效的平台工程团队。

01 第3课：不只是回应，更要发明

我这里所说的“发明”并不是指全球范围内的新发明，而是指对企业组织而言的新的解决方案。因为我们可以投入时间、精力和资源来解决这些跨领域的问题，为平台用户——软件工程师们提供解决方案，提高他们的开发体验。这就是平台工程的乐趣所在！在这里，您将运用创造力和技术能力为企业创造真正的价值。我们可以通过以下方式做到这一点：从更广泛的技术社区引入已知的良好实践，为现有解决方案带来新思路以获得更好的结果，以及尝试有前途的下一代技术。

引入已知的优秀实践

在企业中引入已知的良好实践时，对企业所面临的问题类型有广泛的了解以及对解决方案空间有扎实的了解有助于进行模式匹配。没有任何东西可以替代良好实践的经验，但阅读书籍、收听播客和探索您所选择的云供应商提供的解决方案是将更多优秀实践引入好方法。如果您有兴趣了解更多信息，我已经深入介绍了与技术社区保持联系的技巧。

在苏富比，我们认识到缺乏跨团队的高级工程师之间的知识共享，以及对知识共享的强烈兴趣。我们决定引入“意见征询（RFC）”流程。我的团队开始以 RFC 的形式分享我们的重大想法，以便将其社会化并征求反馈意见。我们还创建了一个 RFC 模板和一些轻量级文档，如果工程师希望在流程入职方面获得一些帮助，可以参考这些文档。最后，我们创建了一个 Slack 频道，用于社交和讨论提案。我们并没有发明 RFC 的概念，也没有发明我们决定使用的特定 RFC 模板，而是使用了我过去在前一家公司使用过的模板。这个模板来自于 Phil Calcado 的出色工作以及他在博客上分享的 Meetup 工作经验。好的想法可以而且应该传播开来。

但请记住，无论您希望从组织外部引入什么创新理念，都需要小心不要一次引入太多，并确保您解决的是当前存在的问题。在我的案例中，我决定以选择加入的方式引入 RFC 流程，以测试这个想法，看看它是否会自然而然地流行起来。如果我试图以某种方式强制推行，那么这项举措可能会从一开始就失败，或者损害我在工程师心目中的良好形象。相反，随着工程师们开始意识到在这一工具的帮助下，他们能够做出更好的决策，这一举措正慢慢获得认可。

因此，在解决工程师的问题时，要寻找工艺或工具方面的差距，并引入现有的、已知的优秀解决方案！但您的大部分时间都将花在对现有解决方案的迭代上。

迭代现有的解决方案

迭代是产品思维模式的核心，因为它使我们摆脱了过去 "一劳永逸 "的项目思维模式。正如他们所说：

Software is never done, only abandoned.

在过去的一年中，我的团队迭代了我们的一些产品，如保持第三方软件的最新版本，但有一个项目特别突出：我们从 Jenkins 迁移到了 GitHub Actions。2022年初，我们在 CI/CD 系统中添加了服务级别目标。其中一个目标是每月主分支的构建失败次数少于50次，但我们发现我们的失败次数超出了我们的预期。为此，我们决定放弃使用 Jenkins 和 Kubernetes 插件进行构建，转而使用 GitHub Actions。这不仅解决了不稳定的构建问题，还减轻了管理 Jenkins 的负担，为工程师调试构建提供了更好的用户体验，并使构建过程更易于理解和定制。我们迁移的第一次迭代是开放 GitHub Actions，用于我们所谓的“独立”构建，即在我们的主 Bazel 构建系统之外的构建。这种较小的“垂直切片” GitHub Actions 支持为我们提供了集成经验，也让我们测试了工程师对它的反应。我们收到的反馈非常积极，因此我们计划在今年秋天完成迁移，将 Bazel 构建迁移过来，并关闭 Jenkins 设置。

当然，我们并不总是有先前的经验可以借鉴，也不总是有现有的解决方案可以迭代。或者，您觉得您的现有解决方案已经达到了局部最大值，需要对同一问题采用全新的解决方案。在这种情况下，我们需要进行实验。

实验新技术

将任何新的变革视为一种尝试是健康的。变革的风险越大，试验就越能缓和紧张局势并鼓励行动。在苏富比，今年我们计划尝试一种新的基础设施配置方法，我一直称之为“抽象基础设施（manifest infrastructure）”。这包括使用 Kubernetes 运营商，如开源的 AWS Controllers for Kubernetes（ACK）或 Crossplane，将基础设施定义为 Kubernetes 清单，并由运营商管理基础设施本身。我们对这一解决方案感到兴奋，因为它将提供机会，为工程师构建更高层次的抽象，让他们能够与之交互，而将管道设计留给实施细节。Whitney 和 Mauricio 在2022年底特律 KubeCon 大会上的主题演讲很好地说明了这一点。我们计划在我们的部分应用中试用，如果进展顺利，我们将在更大范围内部署。

作为一名平台工程师，实验是一个关键步骤，既可用于您自己的工作，也可用于增强工程师的能力。考虑如何实现蓝/绿或资源交付、功能标记、“双向门”决策和增量交付。您的团队和您的工程师将感谢您带来的心理安全、学习、交付速度和系统可靠性。

因此，通过应用这些核心原则，可以确保我们的工作能够取得具体成果，能够通过开发人员的意见来指导我们的工作，从而能够带来新的想法来满足企业的需求。作为一名高效的平台工程师，最后一个关键要素是通过扩大我们的影响。

02 第4课：扩大影响力

软件工程的强大之处在于能够“自动解决”我们的问题。传统的 IT 操作员并没有接受过软件工程方面的培训，但平台工程师却接受过培训，因此人们期望这门新学科的规模能够与工程组织的规模成线性关系。但是，我们不能因为有能力就“建造所有的东西”。要使这一模式奏效，平台工程师必须认识到，我们应该偏向于“做能够扩展的事情”。

我们可以再次运用我们的产品思维，务实地对待我们所构建与购买的产品，并保护我们的时间，以便我们能够专注于重要的事情。

做出正确的构建和采购选择

在我们的工作范围内解决问题的同时，我们希望尽可能少地构建软件，在可用和可行的情况下依靠成熟的产品和开源解决方案。构建和维护软件是一项劳动密集型工作，因此我们只为那些收益远高于成本且没有替代方案的问题保留软件。接受一个仅达到我们希望解决问题的80%的解决方案可能会让我们感到痛苦，但这样做往往“足够好”，可以让我们腾出时间来解决其他问题。一个特别相关的例子是，我们选择采用 OpsLevel，而不是 Backstage 这样的定制工具。我们采用这种工具的业务目标是建立一个服务目录，以便更广泛地了解我们组织中的系统以及它们如何相互配合。虽然定制化程度远不及使用 Backstage 框架构建开发人员门户，但采用该工具解决了我们的主要业务需求。而且 OpsLevel 还在不断改进和增加功能--我们的平台工程团队不需要做这些工作。我们的组织在其他地方也采取了同样的方法，混合采用 SaaS 产品（如Datadog、Algolia和Auth0）和开源工具（如 Linkerd、Jaeger 和 Spinnaker），为常见需求提供强大的解决方案。我们仍在构建软件，但通常是将服务拼接在一起，以获得集成、完美的感觉，例如 Slack bot、CI/CD 定制和抽象，以创建良好的开发人员体验。

知道何时构建与购买才有意义对我来说很有挑战性，尤其是在购买解决方案最有意义的时候，提出购买解决方案的商业案例。平台团队或小组规模越大，定制开发工作负载就越大，但这始终是平台工程师成长的关键技能。

避免中断过载

我们扩大影响力的另一个重要方法是保护我们的工作时间，以完成计划中的工作。我们每周只安排部分团队成员回复问题，避免支持频道过多地分散我们的精力。有时我们会全力集中处理问题，在这种情况下，我们会优先解决任何反复出现的问题。同时，我们会时常让寻求帮助的同事明确哪些我们能够参与支持的。

做出明智的构建与购买决策以及保护我们的时间只是确保扩大影响的众多可能方法中的两种。如果您发现自己在一些超级棘手的问题上陷入困境，请不要灰心丧气，因为你的工作可能会为企业带来巨大的价值，完全值得付出努力。但不要忘了偶尔出来透透气，与你的团队一起理智地检查一下正在发生的事情，这样你们就可以一起决定如何更好地开展工作。