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

作者｜Chad McElligott

翻译｜平台工程技术社区

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

2023年6月，在苏富比担任平台工程团队的基础架构工程师 Chad 在 DevOps Days  上发表了他的第一次公开会议演讲。他分享了第一年在苏富比中学到的教训，关于如何使平台工程发挥作用，下面是他的演讲内容。

01 介  绍

Hi，我是Chad。我在苏富比（Sotheby's）担任平台工程团队的基础架构工程师，我们内部称之为 ThunderCats。

苏富比拍卖行成立于1744年，主要从事艺术品、珠宝、服装和汽车等奢侈品的拍卖。我们在全球拥有约2000名员工，2022年的销售额约为80亿美元。我们有大约70名工程师，负责支持我们的移动应用程序、拍卖体验、金融服务和内部业务工具。我们平台工程部有4名工程师。

我已经在苏富比工作了大约一年半的时间，我想和大家分享一下我所了解到的平台工程是如何工作的。

作为一名前产品工程师，过去一年在苏富比担任平台工程师对我来说是一个学习和拓展技能的绝佳机会。我所获得的洞察力为我们构建平台和整个工程组织奠定了基础。我很高兴能与大家分享我所学到的关于平台工程的核心定义，以及我如何在日常工作中应用这些原则。

成为平台工程师后，我问我的老板：“平台工程对您来说意味着什么？”他简明扼要地回答：“高效和稳定”。我觉得很有道理。但在我工作的过程中，我一遍又一遍地重温这一描述，发现这些词有很多深意。 因此，一年后的今天，当我思考平台工程对我的意义时，我想到了这一点。

“平台工程是将产品思维应用于支持工程组织的软件交付速度和系统稳定性。”

虽然没有那么朗朗上口，但我认为将产品思维纳入定义是做好我们工作的一个关键方面。因此，让我们深入探讨一下这三个主要品质：速度、稳定性和产品思维。

速度和稳定性是平台工程的核心成果

速度和稳定性描述了平台工程团队的核心成果。

速度代表了我们提供满足客户需求的解决方案的速度，从想法到交付。为了让工程师成功领导平台工程工作，我们必须学会身兼数职。但最重要的是，我们必须高度关注我们的客户，务实地了解我们能够实现的目标，迭代地改进我们的工作，并将我们的目标设定为结果而非产出。简而言之，我们必须采用产品思维。 软件开发生命周期的许多方面都可以通过改变来提高交付速度，例如项目管理或敏捷实践、本地开发环境、技术选择、审查流程、部署管道等等。平台工程的许多分支学科都以提高交付速度为主要目标，例如构建工程、DevOps、开发人员体验和开发人员生产力团队。

另一方面，系统稳定性代表了为公司客户提供一致体验所需的工作。虽然稳定性主要受到操作实践的影响，但也受到文化规范的影响，例如事件响应流程以及通过事后回顾从事件中学习。平台工程中专门研究稳定性的一个常见分支学科是 "基础设施工程"。通常作为 DevSecOps 组成部分的安全实践也在平台工程的旗帜下支持系统稳定性，而 SRE 虽然不一定是一个子学科，但却与之紧密相关。

您可能会把这里提到的指标称为 DORA 的“4个关键指标”。DORA 的《 DevOps 现状报告》证明保持速度和稳定性是维持高绩效软件交付组织的关键。这就是为什么在您的组织中建立平台工程学科如此重要的原因。当团队专注于交付公司的核心价值时，对保持这些特性的关注可能会有所松懈。拥有一个平台工程团队能够帮助我们的组织专注于交付其价值，同时使所有团队不断提高交付速度和系统稳定性。

但是，平台工程师要想取得成功，需要克服许多挑战。他们主要从事面向内部的工作，与之共事的工程师人数较少，而且往往缺乏其他团队类型所获得的管理支持，例如产品和项目管理。平台工程也是一门典型的“工程主导型”学科，工程师们因过度建设、设计不足、“追逐新奇技术”以及因缺乏对客户的关注而陷入其他误区。

为了让工程师成功领导平台工程工作，我们必须学会身兼数职。但最重要的是，我们必须高度关注我们的客户，务实地了解我们能够实现的目标，迭代地改进我们的工作，并将我们的目标设定为结果而非产出。简而言之，我们必须采用产品思维。

平台工程的工作方式——采用产品思维

采用产品思维是平台工程的工作方式。

初创工程师对此深有体会——作为一名工程师，打造一款产品不仅需要有好的技术想法和交付技能，还需要产品与市场契合，这就需要客户反馈、营销和支持。初创工程师很少有机会依靠他人来完成这些工作，而平台工程师也经常发现自己处于同样的境地。

围绕平台工程的许多讨论都建议我们将“平台视为产品”，就好像我们正在构建类似 Heroku 的内部 SaaS 产品。虽然这可能是某些组织的平台的样子，但更深层次的含义是，我们要通过产品经理的视角来思考我们的平台。这意味着我们需要放慢脚步，全面思考如何为我们的客户提供价值——组织内的软件工程师，但更广泛地说，是我们所有的同事和我们公司努力服务的客户。这将带来更好的结果，因为它将重点放在解决企业当前遇到的问题上。

我的团队一直秉承着提高速度和稳定性的宗旨，并认识到我们必须采用产品思维才能取得成功，我想与大家分享我们是如何将这些原则应用到工作中的。我希望我们的经验教训能够为理论增添一些色彩，并让大家了解平台工程的日常工作。

02 第1课：根据结果设定目标

在过去的一年里，我学到的最重要的一课就是要根据结果而不是产出来设定目标。

"结果重于产出 "是我们从精益产品管理领域学到的一句俗语，它有助于我们设定有意义的目标。我们肯定需要产出来实现我们的成果，但这句话的意思是提醒我们避免根据活动来设定目标；否则，我们最终可能会陷入一种 "生产力战场"，即有大量工作在做，却没有有意义的结果。我们需要确保我们所创造的任何产出都能实现我们所期望的结果，如果不能，就愿意重新评估并尝试完全不同的方法。

在苏富比，我们的平台工程团队将这种基于结果的目标设定融入到我们的年度 OKR 流程、季度规划和故事启动会议中。

使用 OKR 进行战略规划

在我们的 OKR 过程中，我们在线下聚在一起，通常是在冰岛，我们团队的两名成员就在冰岛。在这一周里，我们花时间重温团队章程，反思去年的工作，并就我们作为一个团队希望取得哪些成果以及我们希望看到工程组织如何取得进步制定愿景。

由于我们的目标是以结果为导向的，因此我们可以自由地创造性地实现这些目标。作为一个团队，我们在实现目标的过程中汲取每个人的想法，并将我们团结在我们选择的前进道路上。这种参与性使工程师们更加快乐，进而推动取得更好的成果。

执行季度战术规划

我们的季度规划遵循类似的流程，但更加细化。在季度回顾的基础上，我们会召开头脑风暴会议，最终确定优先顺序，将项目添加到路线图中。在协作会议上，我们检查整个季度收到的反馈，讨论我们看到的模式，并挖掘有前景的想法。这些会议将为下一季度制定计划。

利用 "故事开工会"进行校对

最后，我们在每个重大项目开始时都会召开项目启动会。我们要明确通过完成这项工作，我们希望取得什么样的成果，什么是范围内的工作，什么是范围外的工作，以及谁将参与这个项目。最后，我们为项目指定一名领导，作为“交付领导”，让每个人都按部就班地朝着目标前进。通过在每个项目开始时召开的会议，我们可以确保参与项目的每个人在开始工作之前都能围绕工作和我们所追求的结果达成一致。

这三个核心迭代流程帮助我们围绕目标进行自我组织。它们使我们的工作专注于我们所期望的结果，同时在整个年度中不断检查和调整，以确保我们取得进展，并确保我们的目标仍然具有相关性。

这种基于结果的目标设定推动了我想与您分享的下一课的重要性，即真正了解您的客户。

03 第2课：真正了解您的客户

尽管我们是工程师，我们的客户也是工程师，但这并不意味着我们可以认为我们知道他们最关心的问题是什么。作为平台工程师，我们通常不会与其他工程师从事同一类工作，因此他们所面临的挑战很可能与我们不同。为了与他们的实际需求保持联系，我们需要承认这种差距，并努力缩小这种差距。

在苏富比，我们采用三种主要策略来把握用户需求：为工程师提供直接支持，通过短期咨询与他们密切合作，以及开展一年两次的调查。

利用 Slack 为工程师提供支持

平台工程师通常是企业中资历较深的工程师，尤其是在像我们这样的小公司。这意味着我们经常被寻求帮助，尤其是在我们的专业领域，如基础设施、云、数据库，以及我们支持的工具，如 GitHub Actions、Terraform 和Kubernetes。为了支持这些需求，我们开设了一个共享的 Slack 频道。对于每个请求，我们保证在1个工作日内做出响应，但通常会更快。这种直接、低摩擦和基于 SLA  的支持方式，可以及时为我们的工程师提供所需的帮助，使他们不会被阻塞。作为一个公共渠道，如果工程师看到有人提出他们知道答案的问题，他们也可以互相帮助。

这是我们了解他们日常工作中摩擦根源的一个重要途径，并将其反馈到我们的优先级和规划中。但是，像这样提供非同步支持只能到此为止。

咨询，提供细致的支持服务

有时，细致的支持方式更适合支持工程师实现我们的组织目标。

例如，我们最近将4名工程师“嵌入”到2个不同的团队中，为期一个月，以支持他们建立服务水平目标（Service Level Objectives, SLO）。通过积极的结对和移动编程会议，我们能够共同探索实施策略，分享我们的 SLO 心智模型。我们还直接帮助他们实施 SLI、Datadog 仪表板，甚至是新的平台服务，以支持从我们的前端应用程序摄取 SLI 遥测数据。这种协作式的工作方式加强了我们团队之间的关系，建立了信任和相互理解。 

这也让平台团队近距离了解了产品工程师的生活，并对他们所面临的挑战表示理解。我们发现他们在调试应用程序和在集成开发环境中跳转到框架代码的实现时遇到了问题，这妨碍了他们的日常工作效率。我们还发现，测试 gRPC 端点也让他们感到沮丧。这些发现已反馈到我们的计划工作中，我们已在所有服务上启用了 gRPC 反射，并将花时间编写集成开发环境设置指南，以明确富有成效的构建/调试/测试流程的配置。 

通过支持活动，我们有机会直接了解需要什么样的解决方案来提高工程团队的速度。但是，我们对他们需求的了解仍然存在差距--那些没有主动寻求支持，但仍有反馈或未满足需求的人怎么办？ 

广视角调研

在这种情况下，进行工程范围内的调研会非常有帮助。

今年春天，我们进行了第一次工程调研，以公正地了解我们工程文化的各种高层次方面的状况。我们决定使用 Qualtrics 作为一种轻量级的调查方式（谷歌或微软表单也可以）。开展调查的难点主要在于知道要问什么问题，结合 SPACE 框架、DORA 能力模型，以及通读 Nicole Forsgren 等人的《Accelerate》和 Dan Pink 的《Drive》两本书，对了解高绩效的工程文化有很大帮助。如果能得到用户体验研究人员的支持，即使只是为了确保你的调查方法在统计学上是合理的，也会非常有帮助。

在此次调查之前，我们认为我们可能对少数人提出的问题过于优先考虑，而其他更紧迫的问题却在悄无声息地阻碍着我们的工作效率。第一组调查结果让我们确信，我们的路线图与最紧迫的问题是一致的。至此我们就将减少管理基础设施的工作量作为优先事项，这也是调查中强调的首要问题。

因此，通过调查、细致咨询以及与工程师在 Slack 中的日常协作，我们可以相对全面地了解我们应该在哪些方面做出努力。但问题并不总是与解决方案相伴而生，最需要解决的问题往往是那些没有明显解决方案的问题。这就是为什么除了了解我们应该解决哪些问题之外，平台工程的另一个重要组成部分就是代表我们的工程组织进行发明创造。