(相关资料图)

【编者按】对于平台工程师而言，最重要的是什么？

原文链接：https://chadxz.dev/platform/

未经允许，禁止转载！

作者 | Chad McElligott 译者 | 弯月责编 | 夏萌出品 | CSDN（ID：CSDNnews）

我是 Sotheby 平台工程团队（团队内部称为 ThunderCats）的一名基础设施工程师。

Sotheby 是一家主营艺术品、珠宝、服装和汽车等奢侈品拍卖的公司，全球约有 2,000 名员工，其中包括 70 名工程师，主要负责为移动应用程序、拍卖体验、金融服务和内部业务工具提供支持。我们平台工程部有 4 个人。我在这家公司工作了大约一年半，我想通过本文分享一下我所学到的有关平台工程运作的知识和经验。我曾是一名产品工程师，去年在转型平台工程师后，我问老板：“对你来说，平台工程意味着什么？”他简洁地答道：“速度和稳定性”。在我看来，这个答案确实很合理。但在开始工作后，我一遍又一遍地重新审视这个答案，发现这句话包含很多深意。一年后，反思平台工程意味着什么，我的看法如下：平台工程是产品思维模式的应用，旨在支持工程组织的软件交付速度和系统稳定性。

我认为将产品思维融入平台工程是做好这项工作的关键。下面，我们来深入探讨一下这三个主要品质：速度、稳定性和产品思维。

速度和稳定性是平台工程的核心成果速度和稳定性描述了平台工程团队所追求的核心成果。速度代表我们提供能够满足客户需求（从创意到交付）的解决方案的速度。纵观软件开发的整个生命周期，许多方面都会影响到交付速度的提升，例如项目管理或敏捷实践、本地开发环境、技术选择、审查流程、部署管道等等。平台工程的许多子学科都以提高交付速度为主要目标，例如“构建工程”、“开发运维”、“开发者体验”和“开发人员生产力”团队。另一方面，系统的稳定性代表了为公司的客户提供一致体验所需完成的工作。虽然稳定性主要受到运维实践的影响，但也受文化规范的影响，例如事件响应流程以及通过事后回顾从事件中学习。平台工程有一个常见的子学科专门研究稳定性：“基础设施工程”。安全实践作为“开发安全运维”的一部分，也支持着平台工程的稳定性，而 SRE 虽然不一定是子学科，但也有着紧密的联系。你可能会发现，此处我们提到了 DORA 的四大关键指标。DORA DevOps 状况报告一次又一次地证明，保证速度和稳定性是维持高性能软件交付组织的关键。这就是为什么组织建立平台工程学科如此重要的原因。当团队专注于实现公司的核心价值时，对维护这些特征的关注可能就会减少。拥有平台工程团队可以让组织专注于交付价值，同时也能让所有团队不断提高交付速度和系统稳定性。但平台工程师要想取得成功，需要克服许多挑战。他们主要从事面向内部的工作，需要合作的工程师较少，通常缺乏其他团队能够获得的管理支持，例如产品和项目管理。平台工程是一门“工程主导”的学科，工程师经常受到的批评包括过度构建、设计不足、追逐新颖闪亮的技术、由于缺乏客户关注而陷入其他陷阱。为了让工程师成功地领导平台工程，我们必须学会身兼多职。但最重要的是，我们必须高度关注客户，务实地对待我们能够实现的目标，反复迭代改进，并根据结果而不是产出设定我们的目标。简而言之，我们必须采用产品思维。平台工程必须采用产品思维创始人工程师非常清楚这一点，作为工程师，构建产品不仅需要拥有良好的技术理念和交付技能，还需要保证产品与市场的契合度，这需要客户反馈、营销和支持。创始团队的工程师通常并没有足够的资源依赖他人做这些事情，而平台工程师也时常处于相同的境地。围绕平台工程的大部分讨论都会提到“平台即产品”，也就是说将平台视为一种产品。虽然某些组织的平台确实是产品，但更深层的含义是站在产品经理的视角来思考我们的平台。这意味着我们需要放慢速度，全面思考如何为我们的客户（组织内的软件工程师，以及更广泛的同事和公司正在努力服务的客户）提供价值。这样可以带来更好的结果，因为我们可以集中精力解决组织当前遇到的问题。我们团队一直非常重视提高速度和稳定性，而且也明白我们必须采用产品思维才能取得成功。下面，我想分享一下如何将这些原则应用到实际的工作中。第 1 课：根据结果而不是产出设定目标过去一年，我学到的最重要的教训是根据结果而不是产出设定目标。精益产品管理有一句话：“结果重于产出”，这个原则可以帮助我们设定有意义的目标。虽然我们需要产出来实现结果，但我们必须避免根据活动设定目标，否则就有可能陷入“生产力剧场”的陷阱，虽然完成了大量工作，却没能取得有意义的结果。我们必须确保我们创造的任何产出都能实现我们期望的结果，如果不能，则必须重新评估并尝试完全不同的方法。我们的平台工程团队将这种基于结果的目标设定整合到了年度 OKR 流程、季度计划和项目启动会议中。根据 OKR 规划战略我们的 OKR 流程是团队集体讨论出来的，我们会花时间重新审视团队章程，反思前一年的工作，并为我们作为一个团队想要实现的成果以及我们希望看到的工程组织的发展制定愿景。由于我们的目标以结果为导向，所以为了实现这些目标，我们可以自由发挥创造力。作为一个团队，我们会汲取每个人的想法，并保证我们选择前进的道路方向一致。这种参与感可以提高工程师的幸福度，进而带来更好的成果。执行季度战术计划我们的季度计划遵循类似的流程，但更加细致。在季度回顾会议上，我们会开展头脑风暴，划分最终优先级，将各项工作添加到我们的路线图中。在合作会议中，我们会检查整个季度收到的反馈，讨论我们看到的模式，并挖掘有前途的想法。然后根据这些想法制定下一季度的计划。通过启动大会进行协调最后，在每个主要项目的启动大会上，我们会阐明我们希望实现的结果、范围内和范围外的工作以及项目参与人。此外，我们还会给每个故事任命一名领导，担负起交付的责任，并确保每个人朝着相同的目标前进。每个项目之初举行这样的会议，可以确保参与该项目的每个人在深入开展工作之前，能够围绕工作和我们正在努力实现的结果达成一致。这三大核心迭代过程帮助我们围绕目标实现了自我组织。我们不仅可以专注于期望的结果，而且还可以全年不断检查和调整，以确保我们不断取得进展并实现我们的目标。这种基于结果的目标设定推动了我想与你分享的下一个心得，即真正了解你的客户。第 2 课：真正了解你的客户尽管我们是工程师，而且我们的客户也是工程师，但这并不意味着我们可以假定我们知道他们关心哪些问题。作为平台工程师，我们从事的工作不同于其他工程师，因此他们面临的挑战与我们不同。为了满足他们的真正需求，我们需要意识到这一差距并努力弥合。为了真正了解客户，我们主要使用了三种策略：直接为工程师提供支持，通过短期咨询活动与工程师密切合作，每年进行两次问卷调查。支持工程师平台工程师通常是组织中的一些高级工程师，这意味着经常有人向我们寻求帮助，特别是在我们的专业领域，比如基础设施、云、数据库，以及我们支持的工具 GitHub Actions、Terraform 和 Kubernetes 等。我们保证在 1 个工作日内回复每个请求，而且通常回复速度非常快。这种直接、低摩擦且基于 SLA 的支持方法为我们的工程师提供了及时的帮助，可以避免他们的工作受阻。作为公共渠道，工程师看到可以解答的问题，通常都会提供帮助。这是我们了解他们日常工作中摩擦来源的重要方式，我们的工作优先级和计划种反映了这些问题。但这类的异步支持所能提供的帮助很有限。咨询为了实现我们的组织目标，我们决定采用“White-Glove”（“白手套”，形容服务人员戴着干净的白色手套认真、谨慎地为客户服务，提供非常细致、贴心的服务）方法。例如，最近我们的四名工程师分别“嵌入”了两个不同的团队，与他们一起工作了一个月，以支持他们构建服务级别目标。我们通过积极的结对和群体编程会议，一起探索实现策略。我们还直接帮助他们实现了 SLI、datadog 仪表板，甚至新的平台服务，以支持从我们的前端应用程序获取 SLI 遥测数据。这种协作的工作方式加强了我们团队之间的合作关系，建立了信任，促进了相互理解。同时，平台团队也可以近距离了解产品工程师的工作，并尊重他们所面临的挑战。我们发现他们在调试应用程序和在 IDE 中跳转到框架代码实现时遇到了问题，这影响了他们的日常工作效率。我们还发现测试 gRPC 端点的工作很繁琐。这些发现都反馈到了我们计划的工作中，我们在所有服务上启用了 gRPC 反射，并花时间编写了 IDE 设置指南来说明如何配置高效的构建/调试/测试流程。通过这类接触活动，我们有机会亲眼目睹我们的工程团队需要什么样的解决方案来提高工作速度。但我们对他们的需求的理解仍然存在差距，那些没有积极寻求支持，但仍有反馈或未满足需求的人怎么办？通过问卷调查开拓视野问卷调查可以帮助我们解决上述问题。今年春天，我们进行了第一次工程调查，为的是了解公司工程文化各个高层方面的状况。我们决定使用 Qualtrics 作为简易的调查方法。Google 或 微软的 Forms 也同样适用。开展调查的难点主要是提出什么问题，同时还需要结合 SPACE 框架、DORA 能力模型，我们还通读了 Nicole Forsgren 等人的著作《Accelerate》和 Dan Pink 的著作《Drive》，帮助我们了解高绩效的工程文化。此外，获得用户体验研究人员的支持也非常有帮助。在开展问卷调查之前，我们担心可能过于优先考虑少数派的问题，实际上还有其他更紧迫的问题在悄悄地阻碍生产力。我们第一组的调查结果表明，我们的路线图确实能够解决最紧迫的问题。此后，我们优先考虑减少管理基础设施的工作量，这是此次调查强调的首要问题。综上所述，我们通过问卷调查、积极地咨询以及与工程师的日常合作，对全局有了基本把握，了解到我们应该在哪些方面投入精力。但有些问题并不一定有真正的解决方案。最需要解决的问题往往是那些没有明显解决方案的问题。这就是为什么除了了解我们应该解决什么问题之外，平台工程的另一个重要组成部分是从工程组织的角度出发进行发明创造。第 3 课：不只是回应，还要发明此处我所说的发明并不是指在全球范围内发明新的东西，而是对组织来说是新的东西。因为我们可以投入时间、精力和资源来解决这些跨领域的问题， 所以我们可以带来伟大的解决方案，服务于我们的工程师，并提升他们的满意度。这是平台工程的工作中最有趣的部分。你可以借此发挥创造力和技术力，为组织创造真正的价值。实践方法有很多，包括引入更广泛的技术社区已知的良好实践，在现有解决方案的基础之上提出新想法以获得更好的结果，以及尝试前景可期的下一代技术。引入已知的良好实践将已知的良好实践引入组织有助于广泛了解组织面临的问题类型以及相应的解决方案。良好的实践经验无可替代，但是你可以多看多学，比如阅读书籍、收听播客并探索云供应商提供的解决方案。我们认识到跨团队的高级工程师之间缺乏知识共享，而且很多人对此抱有浓厚的兴趣。于是，我们决定引入“征求意见”流程。我们团队分享了自己的一些想法，积极推动团队之间的交流，同时还可以征求反馈。此外，我们还创建了模板和一些轻量级文档，供其他工程师们在了解这个流程的时候参考。最后，我们还创建了一个 Slack 频道来社交和讨论这些提案。但请注意，无论你希望从组织外部引入什么样的创新想法，都需要谨慎行事，不要一次引入太多想法，而且还要确保这些想法是为了解决现存的问题，否则你的变革就会被视为“货物崇拜”（一种宗教形式，特别出现于一些与世隔绝的原住民中。当货物崇拜者看见外来的先进科技物品，便会将之当作神祇般崇拜），不会被认真对待或采用。在解决工程师的问题时，你需要搞清楚流程或工具中的缺口，然后找到已知的优秀解决方案，然后引入。但你的大部分时间都将花在迭代现有解决方案上。迭代现有解决方案迭代是产品思维模式的核心，因为迭代可以让我们摆脱了过去“一劳永逸”的项目思维模式：从来没有已经做完的软件，只有被弃用的软件。

在过去的一年里，我们团队迭代了我们的一些产品 ，其中包括一些比较无聊的工作，例如更新第三方软件，但有一个项目特别引人注目：从 Jenkins 迁移到 GitHub Actions。2022 年初，我们的 CI/CD 系统中添加了服务级别目标（SLO）。其中一个目标是每月主分支构建失败次数少于 50 次，但我们发现实际情况远超出了我们的预期。为此，我们决定放弃用于构建的 Jenkins 和 Kubernetes 插件，并开始使用 GitHub Actions。这不仅解决了构建不稳定的问题，还消除了管理 Jenkins 的负担，为工程师调试构建提供了更好的用户体验，而且构建过程也更加易于理解和定制。此次迁移的第一次迭代是开放 GitHub Actions，用于我们所谓的“独立”构建，这些构建位于主 Bazel 构建系统之外。在此过程中，我们学习了 GitHub Actions 的集成经验，同时也测试了工程师们的反应。我们收到的反馈非常积极，因此今年秋天我们计划全面完成迁移，包括移动 Bazel 构建并关闭 Jenkins 设置。

当然，有时我们并没有以前的经验可供借鉴，而且也不一定有现成的解决方案可供迭代。或者，你感觉现有解决方案有一定的局限性，需要针对同一个问题跳至全新的解决方案。在这种情况下，我们需要进行实验。通过实验尝试新技术将新的改变视为一次实验很有意义。变革的风险越大，就越需要进行更多的实验来缓解紧张局势并鼓励大家采取行动。今年我们计划实验一种新的基础设施配置方法，我称之为“清单基础设施”，其中包括使用 Kubernetes 操作器，例如开源 AWS Controllers for Kubernetes (ACK) 或 Crossplane，简单来说，就是通过 Kubernetes 清单定义基础设施，并通过操作器管理基础设施。我们对这个解决方案充满期待，因为它可以为工程师提供构建更高级别的交互抽象的机会，同时把细枝末节交给实现。作为平台工程师，实验是一个关键工具。考虑如何启用蓝绿部署或金丝雀部署、功能标记、“双向门”决策和增量交付等功能。你们可以通过实验学习，为团队和工程师们带来心理安全，同时还可以保证交付速度和系统可靠性。这些核心原则可以确保我们朝着某个具体的成果前进，听取工程师的声音，并提出新的想法来解决组织的需求。成为一名高效平台工程师的最后一个关键要素是，通过扩大影响力来确保我们的工作顺利推进。第 4 课：扩大影响力软件工程的力量在于“自动解决”问题的能力。平台工程师接受过软件工程培训，因此我们明白软件工程将随着工程组织的规模呈次线性增长。但平台工程师不能因为有能力就“构建所有东西”，而是应该注意可扩展性。这里，我们需要再次运用产品思维，从务实的角度出发考虑产品的构建和购买，并注意时间分配，专心做好重要的工作。构建还是购买在努力解决计划内的问题时，我们应该设法将构建的软件数量降到最低，并依靠现有的产品和开源解决方案解决问题。构建和维护软件费时费力，因此我们希望集中精力解决收益远远超过成本并且不存在替代方案的问题。接受一个只能解决 80% 的问题的解决方案可能会让人感到痛苦，但退一步可以腾出更多时间来解决其他问题。举一个这方面的例子，我们选择采用 OpsLevel 而不是 Backstage 等更依靠自定义的工具。我们采用此类工具的业务目标是构建一个服务目录，以更广泛地了解组织中的各个系统以及它们之间的协同工作。虽然 OpsLevel 不具备 Backstage 框架的可定制性，但该工具可以满足我们的主要业务需求。OpsLevel 不断努力改进并添加功能，所以我们的平台工程团队省却了很多工作。我们组织在选择其他工具时也采取了同样的方法，通过采用 SaaS 产品（例如 Datadog、Algolia 和 Auth0）和开源工具（例如 Linkerd、Jaeger 和 Spinnaker）的搭配使用，为常见需求提供强大的解决方案。另一方面，我们也会构建软件，但一般都是为了将服务拼接在一起，通过集成 Slack 机器人、CI/CD 定制和抽象，创造出色的开发人员体验。判断什么时候构建，什么时候购买，对我来说是一个挑战，尤其是对于一些业务案例来说，购买解决方案更为合理。平台团队越大，需要定制的开发工作就越多，但这也是平台工程师成长的关键技能。避免中断过载我们扩大影响力的另一个重要方法是合理计划时间，确保能够完成计划的工作。每周我们会单独分出一小部分人来回答问题，以防止共享支持频道过多地分散我们的注意力。有时候我们会“救火”，但出现这类情况，我们必须保持警惕，并优先解决重复出现的问题。此外，我们还会努力澄清和传达我们的团队章程，让大家知道应该让我们参与哪些对话，否则，我们的时间都会被会议和“支线任务”耗尽，没有太多余量来实现更广泛的计划 。确保扩大影响力的方法有很多，在构建还是购买的问题上做出明智的决策，以及合理计划时间，二者只是其中的两种。如果你在一些超级棘手的问题上陷入困境，千万不要气馁。你的工作会为企业带来巨大的价值，值得付出努力。但不要忘记抽空出来透透气，检查一下团队的情况，一起决定如何更好地向前迈进。总结我相信，遵循以下四大原则可以为建立有效的平台工程团队奠定坚实的基础：根据结果而不是产出设定目标；真正了解你的客户；不只是回应，还要发明；扩大影响力。这些原则可以确保平台工程的工作顺利推进，支持我们的工程师快速、稳定地交付软件。