通过平台工程提升开发者体验_AI阅读总结 — 包阅AI

企业越来越倾向于采用平台工程来帮助他们的开发团队提升开发者体验和效率。但平台是如何运作的？应该由谁来构建？平台工程应该更多地关注技术还是人？在这个虚拟小组讨论中，我们将讨论如何构建平台，如何为他人取得成功铺路，如何与使用平台的开发人员合作，如何衡量他们的进展，以及如何适应新的挑战。

我们将从开发者体验的角度审视平台，并探讨领先的公司如何帮助他们的工程师避免瓶颈和减少摩擦。其中有许多进展顺利的故事，也会涉及一些意外的麻烦和困难。

讨论小组成员

• Aviran Mordo，Wix 工程副总裁

• Jemma Hussein Allen，平台工程技术负责人

• Ana Petkovska，Nexthink 开发者体验团队工程经理

• Andy Burgin，Flutter 首席平台工程师

Aviran Mordo：早在 2010 年，当我们开始学习如何进行 CI/CD 时，我们就意识到我们想要的不仅仅是自动化。我们想要为我们的开发人员提供我们能想到的最好的体验来管理他们的工件。

2011 年，我们完全采用了微服务架构并掌握了 CI/CD 交付方法，所以我们开始构建第一个平台和开发者门户。

几年后，我们开始关注开发者速度，并在平台工程方面跨出了另一步。我们将抽象层次提高到更高级别，从基础架构层面到代码层面，并构建了平台，从代码层面一直延伸到基础架构层面。

Jemma Hussein Allen：我所在的组织大约在 5 至 10 年前开始构建平台。最初，平台化倡议是在我们将工作负载从本地迁移到云端虚拟机时启动的。等到容器化的工作负载被广泛采用，我们就从本地或虚拟机云工作负载迁移到容器化的云工作负载。

平台经过调整，可以适应特定的应用用例。组织使用的平台发生了变化，以便可以更好地利用不同项目所需的技术和集成。

Andy Burgin：我的组织已经存在了很多年，经营着许多博彩产品，所以我们从未在某个时刻突然“转向平台工程”——这更像是一个渐进的过程。

举个具体的例子，2016 年，我们希望有一个能让我们的开发人员快速前进的平台，减少开发人员之间的依赖。我们的目标是特性和用户之间的价值流不应该有人的干预。基于这个定义，我们创建了我们的第一个 Kubernetes 平台，并取得了巨大成功。它被开发团队广泛采用，至今仍然持续发挥着价值。

Ana Petkovska：我们于 2022 年 2 月启动了第一个专注于平台工程和开发者体验的团队。那时，我们的集中式 DevOps 团队因产品工程组织的增长和多年来拥有的各种领域的所有权变得难以伸缩。因此，我们成立了一个工程效率团队（受谷歌和 GitLab 等公司的启发），专注于内部工具的构建。团队开始围绕呼吁声最高的请求和可能带来最高生产力增益的领域构建自助式平台。

Aviran Mordo：开发者通常不喜欢过多的抽象，所以为了赢得他们的信任，我们在培训方面投入了大量精力，向他们解释平台背后的工作原理。在 Wix，我们有非常强大的公会，因此利用公会作为教育渠道确实很有用。

此外，我们有一个非常活跃的支持渠道，开发者可以向平台团队提出任何问题。

另外，我们将我们的平台视为内部开源项目，因此开发者始终可以看到我们正在开发什么、请求开发新特性和参与贡献。

Jemma Hussein Allen：我们发现，吸引开发者的最佳方式是让每个人了解平台当前的实现情况和未来的路线图。除此之外，关键在于定期征求开发者的反馈和建议，特别是要解决的痛点，并确保路线图中包含了这些改进。

Andy Burgin：从构建 Kubernetes 集群开始，我们就是一个非常以用户为中心的团队。事实上，最初构建集群是将其作为特定产品的平台；因此，我们一直有用户（开发团队），并与他们建立了良好的工作关系。随着时间的推移，我们意识到现在的“DevEx”是运行平台的重要组成部分，因此我们专门成立了一个团队来与开发者合作。

为了促进协作和收集反馈，我们开始每月举行会议。我们有一个基于聊天的支持功能，可以让工程师避免填写工单（由聊天机器人记录并提交工单）。我们还通过研讨会培训了数百名工程师，教他们如何在我们的集群上构建和运行应用程序。

Ana Petkovska：我们通过几种方式与开发者交流，具体取决于交流的目的。

我们每周举行一次 DevEx Connect 会议，我们在会上告知团队我们的团队正在带来哪些重要的变化。我们发现，当我们需要团队采用我们构建的平台时，这些会议会非常有用：告知开发者进展和重要变化，回答他们的问题并获取反馈。

对于较大的变化，我们会组织研讨会和培训会议。对于在日常工作中遇到的问题，我们有一个专门的 Jira 看板，开发者可以在这里提交工单。对于简单的问题，他们也可以通过公共通信渠道联系我们。

Aviran Mordo：平台比较死板。例如，一个微服务只能有一个实体。一些开发者觉得在平台上做开发有太多的限制。他们最初非常不愿意使用平台，我们也没有强迫他们。我们的使命是构建足够好的东西，让他们想要使用它。

为此，我们必须有一个响应迅速的平台团队，与所有开发者合作，解决他们的问题，无论是找到解决方法，还是改变设计决策。

我们始终在平台团队内留出多余的资源（约 30％），以便快速响应产品开发人员的紧急需求。如果开发者在平台上遇到困难，我们会像对待生产事故一样尽快帮助他们解决问题。

Jemma Hussein Allen: 我们发现的最大障碍是由于其他业务优先事项而导致集成减缓，以及在转向更标准化的平台部署流程时担心失去自由。

部署过程在业务的不同领域和团队之间有所不同，主要是因为不同的开发者偏好不同的工具，或者因为流程是在不同的时间设置的，这意味着旧的流程没有采用最新的推荐实践。

我们发现，在与已经在使用平台的其他团队交流并了解他们的经验后，开发者更愿意加入。他们可以从其他团队的经验中了解平台如何帮助减少部署时间和认知负担。解决特定团队的痛点确实有助于增加平台的采用率。

Andy Burgin: 许多开发团队以前没有使用过容器，因此培训研讨会是让开发人员走上正轨并帮助他们做好事情的关键。在研讨会的第一个小时，我们介绍了 12 要素原则。我们意识到，如果没有人写下“正确的事情”是什么样子，那么帮助开发者“做正确的事情”将是一项特别具有挑战性的工作，因此我们与开发团队合作创建了“良好实践”清单，作为我们构建、部署和运行的“最佳实践”。

我们很快意识到许多“运行”项可以被编码，因此我们实现了集群检查能力，检查工作负载与这些指标的符合度，并提供工具，让开发团队能够查看与最佳实践的“合规性”。

我所希望的是，如果你要“赋予”团队权力，就要给他们提供工具来帮助他们理解和采取行动。我常常听到“左移”被作为重新分配所有权的借口，我们不想成为那样的团队。

Ana Petkovska: 最困难的部分是从开发者那里争取时间来实现变更。开发者的主要关注点是公司销售的产品。因此，我们与产品开发团队产品路线图上所有最高优先级的项目争夺时间和资源。在这种情况下，如果平台的采用也得到上层管理人员的支持和认可，这将会非常有利。

我们还开始制定产品和工程工作的联合路线图。这样做可以更好地让所有工程计划项目得到关注，从而提高工程效率、产品质量和安全性。

Aviran Mordo：我们对开发者和经理进行定量和定性问卷调查。我们对开发速度进行比较，看看是否得到了改进。

我们将产品开发者视为合作伙伴和顾问。对于平台团队发布的每个新功能，都有一个来自产品团队的顾问委员会为他们提供有关功能的反馈，并成为他们的设计合作伙伴。这样，我们就可以知道我们正在为他们的问题提供正确的解决方案。

Jemma Hussein Allen：我们使用 Dora 指标来衡量平台的影响力，主要是部署频率和变更的交付时间，因为平台采用了蓝 / 绿部署，因此任何失败的部署都会自动回滚，不会对最终用户造成影响。

在业务方面，指标是通过项目管理级别的报告来收集的，例如燃尽图。

Andy Burgin：在成立 DevEx 团队时，我们做的第一件事就是确定开发团队对我们集群的看法。我们要求团队匿名提供针对集群的反馈（我们认为匿名方式更有可能获得建设性反馈）。我们记录了团队对平台的使用感受，并评估了可用性。为此，我们包含了九个有关可用性的问题，这些量化指标对于衡量采用率非常有用。

收集定性指标要更加微妙，因为需要不同的观点来评估 DevEx 是否提供了价值。公开拥有指标和反馈是我们查看整体“分数”看似很好，但理解到定性反馈表明努力的影响和价值是不可持续的，因此我们停止了这一角色，并将这些责任重新纳入工程团队作为业务的常规功能的一种方式。

Ana Petkovska：为了获得全面的了解，我们尝试获取定量和定性指标。

对于定量指标，我们主要关注跟踪采用度指标，了解不同团队所在的采用阶段、他们使用的平台基本功能的频率，以及与传统工具相比，它如何改善了我们组织的状态。

根据项目的不同，我们通过问卷调查或直接索取反馈来获取定性指标。目前，我们不需要特地收集来自开发者和高层的数据。

Aviran Mordo：由于 Wix 起步很早，我们不得不构建自己的解决方案（没有现成的商业或开源产品）。因此，实际上我们最终构建了两个平台，一个是给后端工程师使用的，另一个是给前端工程师使用的。如果我能改变一件事情，我可能应该坚持只构建一个统一的系统供所有开发者使用。

Jemma Hussein Allen：如果我能改变一件事，那就是实现更多基于组件的平台工具采用，团队可以在最适合团队和项目的时间接入各个平台组件。这将加快平台工具的采用，并使开发者更容易熟悉每个组件。

Andy Burgin：考虑到 Kubernetes 当时的生态系统，我认为我们做了一些很棒的工作。事后看来，我们应该更多地参与开发者工具链。但那时，我们从未将这视为平台团队的功能，在早期，因为开发团队拥有他们的 SDLC 和工具。这导致了 Kubernetes 工具的碎片化和重复，但随着时间的推移，这些整合成了一个黄金路径框架。

我希望平台团队能帮助更多的开发团队采用黄金路径框架。但我仍然认为，由开发者为开发者构建平台是正确的。我相信，如果我们作为一个平台团队强制要求这样的解决方案，它将被更广泛接受。

Ana Petkovska：我会改变的一件事是为进行强制采用做好准备。对于平台来说，最好将它们作为黄金路径的一部分，避免强制采用。然而，有时我们必须为采用设定严格的时间线。

一个典型的例子是当我们想要弃用现有的工具（以减少维护成本或避免与供应商延长合同）时。如果你没有为这样的大规模采用做好充分准备，你可能会给平台团队增加很多负担。

我们开始采取以下措施为这样的时刻做好准备。

1. 提前宣布时间线，并发送提醒，让开发团队为采用做好计划。

2. 尽早让各种用例成为平台的早期采用者，以满足不同需求。

3. 设定渐进式的里程碑，避免所有人都等到最后一天。

平台提供的不仅仅是自动化，它们还有助于提升开发者体验。它们让新技术的采用和集成变得更加容易。它们还可以消除开发者之间的依赖，从而提高生产力。

平台将开发方法论、工具集、流程和最佳实践标准化，帮助组织实现规模化。

组织通过培训等方式吸引开发者参与平台开发，例如解释平台背后的工作原理。他们通过内部开源和公会的方式来吸引开发者。为平台使用提供支持渠道和基于聊天的支持功能。经常性地举行会议有助于促进协作。确保从开发者那里获得反馈，以此来增强平台。

开发者自由度的丧失和业务优先事项是阻碍平台采用的主要因素。所以，不要强迫开发者使用平台，相反，应该与他们密切协作，构建出足够好的东西，让他们愿意使用它。

可以使用来自开发者和管理者的定量和定性指标来衡量平台的影响力。公司还可以通过采用度指标和开发速度指标，以及来自 Dora 的指标，如部署频率和变更的交付时间，来了解情况是否得到了改善。

出于效率的考虑，考虑构建一个统一的平台，而不是多个平台。基于组件的平台工具采用可以支持团队在最适合团队和项目的时间接入各个平台组件。让你自己参与开发者工具链开发，减少工具重复，并建立黄金路径框架。