平台团队如何完成工作

"平台" > 内部开发者平台

目前围绕平台工程有很多炒作，主要集中在内部开发者平台 (IDP) 上。我想明确说明的是，这里对“平台”的讨论要广泛得多；它涵盖了其他内部产品，例如数据平台、前端设计系统或实验平台。

事实上，虽然我们将主要关注技术平台，但这里介绍的许多想法也适用于提供共享业务功能的内部产品 - 金融科技公司的资金流动服务，或电子商务公司的产品目录服务。统一的特征是平台是组织内部其他团队使用的内部产品。因此，平台团队正在构建产品，其客户是公司内部的其他团队。

迁移工作的示例

我们正在讨论哪种类型的更改？一个相对简单的迁移将是版本升级 - 升级共享组件库，或升级服务的底层语言运行时。

一个常见的、更大的迁移将是将第三方系统的直接集成替换为一些内部包装器 - 例如，将日志记录、分析或可观察性检测迁移到使用平台团队维护的共享内部库，或将与支付处理器的直接集成替换为通过某种内部网关服务的集成。

另一种类型的迁移可能是将对已弃用的内部服务的现有集成替换为对它的替换的集成 - 也许是从旧的User服务迁移到新的Account Profile服务，或者将credit-puller和credit-reporting服务的用法迁移到新的合并的credit-agency-gateway服务。

最后一个例子将是基础设施级别的重新平台化 - 将产品团队拥有的服务容器化，引入服务网格，将服务的数据库从 MySQL 切换到 Postgres，诸如此类。

请注意，对于平台迁移，产品团队通常没有特别积极地进行这些更改。有时他们会这样做，如果新平台将提供一些特别令人兴奋的新功能，但通常他们被要求作为更广泛的架构计划的一部分进行这种转变，而实际上并没有获得很多价值。

协作模式

让我们看看哪些跨团队协作模式适用于平台迁移工作。

外包工作

平台团队可以在产品团队的积压工作中提交工单，要求他们自己进行必要的更改。

这种方法有一些优势。它是可扩展的 - 实现工作可以外包给所有需要进行代码库工作的产品团队。它也是可跟踪的，易于管理 - 工单提交通常可以由项目经理或其他项目管理类型完成。

但是，也有一些缺点。它非常慢 - 在某些产品团队开始工作之前，会有很长的等待时间。此外，它需要优先级排序的争夺 - 被要求做这项工作的团队通常不会获得切实的利益，因此他们倾向于将这项工作降级到其他更紧急或更有影响力的任务，这是很自然的。

平台团队完成工作

平台团队可以选择自己对产品团队的代码库进行更改，使用三种类似但不同的模式 - 轮岗、可信的局外人或内部开源。

使用轮岗，平台团队的工程师将“嵌入”到产品团队中，并从那里进行工作。

使用可信的局外人和内部开源，产品团队将接受来自平台团队工程师对其代码库的拉取请求。

与采用提交工单的方式一样，让平台团队完成工作也有一些利弊。

从积极方面来说，这种方法通常可以缩短完成更改的等待时间，因为需要完成工作的团队（平台团队）也是完成工作的团队。一致的激励意味着平台团队比拥有代码库的产品团队更有可能优先考虑他们的工作。

从消极方面来说，让平台团队自己完成迁移工作只有在产品团队能够支持的情况下才有效。他们要么需要对平台工程师加入他们的团队一段时间感到满意，要么需要已经与平台工程师共事了一段时间，以至于他们信任他们独立地对他们的代码库进行更改，要么需要对支持内部开源方法进行必要的投资。

另一个负面因素是，这种自己动手策略不可扩展。平台团队的工程能力始终低于产品交付团队，不将工程工作委派给产品团队会浪费所有这些能力。

实际上，情况要复杂一些

实际上，通常发生的是这些方法的组合。一个负责迁移的平台团队可能会有一个项目经理向 15 个产品交付团队提交工单，然后花一段时间说服他们完成工作。一段时间后，一些团队会自己完成工作，但会有一些落后者，他们可能特别忙于其他事情，或者只是特别不愿意承担迁移工作。然后，平台团队将撸起袖子，使用一些其他不太可扩展的方法，并自己进行更改。

协作模式

许多平台团队的一个值得的目标是构建一个完全自助服务的平台 - 类似于 Stripe 或 Auth0，它文档齐全且易于使用，产品工程师无需任何直接支持或与平台团队协作即可使用该平台。

实际上，大多数内部平台还没有达到这个水平，尤其是在早期。产品工程师在开始使用内部平台时，经常会遇到文档不足、错误消息晦涩难懂以及令人困惑的错误。通常，这些产品团队会束手无策，并要求平台团队介入帮助他们开始使用内部平台的功能。[1]

当平台消费者向平台所有者寻求实际支持时，我们又回到了跨团队协作，并且再次出现了不同的模式。

专业服务

有时，产品团队可能会要求平台团队为他们编写平台消费代码。这可能是因为产品团队难以弄清楚如何使用该平台。或者，这可能是因为这种方法需要产品团队付出更少的努力。有时这只是一个误解，产品团队认为他们不应该自己做这项工作 - 当转向 DevOps 模型时，产品团队可以自助服务他们的基础设施需求，例如，这种情况就会发生。

在这种情况下，平台团队在某种程度上成为工程组织内部的一个小型专业服务团队，代表客户将他们的产品集成到客户的系统中。

这种专业服务模式使用多种协作模式。首先，产品团队通常会提交工单，请求平台团队的服务。这是我们之前在平台迁移工作中看到的相同模式，但反过来了 - 在这种情况下，是产品团队向平台团队提交工单，请求他们的帮助。然后，平台团队可以使用可信外部人员或内部开源模式来执行实际工作。

这种协作模式的一个常见例子是，当产品团队需要一些基础设施更改时。他们想要启动一项新服务，在 API 网关中注册一个新的外部端点，或者更新一些配置值，因此他们向平台团队提交工单，要求他们进行相应的更改。

这种模式在基础设施领域很常见，因为它延续了现有的习惯 - 在自助服务基础设施之前，提交工单是产品团队进行基础设施更改的标准机制。

白手套式入职

对于处于早期阶段且缺乏良好文档的平台，平台团队可以选择使用“白手套”方法来引导新的产品团队，与这些早期采用者并肩工作，帮助他们入门。这可以通过减少首批采用者的工作量来帮助启动新平台的采用。它还可以为平台团队提供有关其首批客户如何实际使用平台功能的宝贵见解。

这种白手套模式通常使用轮岗协作模式来实现 - 一名或多名平台工程师将花费一些时间嵌入到消费团队中，在该团队内部执行所需的平台集成工作。

实践社区

随着平台的成熟和易用性提高，平台团队可以从进行实际集成工作中抽身，转而扮演更具咨询性的角色。

这种咨询模式包括举办“办公时间”，消费团队可以参加并提出问题，或者让平台代表为消费团队的规划和设计会议提供有针对性的建议和指导。在团队拓扑术语中，这将是平台团队以促进交互模式运行。

对于大型、丰富的平台，最终会转向同行支持模式，平台团队会投入时间为其平台的用户建立一个实践社区。这可能包括一些事情，例如社区 Slack 频道或邮件列表，定期举行实践社区会议以寻求帮助并展示有趣的想法，甚至可能举办年度从业者线下活动。

动手操作无法扩展

我们可以看到，平台团队需要为消费者提供的实际支持程度会因平台的开发者体验成熟度而异 - 文档的完善程度，与之集成和操作的难易程度。

在平台的早期，平台消费需要平台团队本身投入大量精力是有道理的。开发者体验仍然有点不稳定，平台功能可能仍在开发中，消费团队可能有点犹豫，不愿意将自己的时间作为小白鼠投入其中。更重要的是，与产品团队并肩工作是平台团队了解客户及其需求的好方法！

但是，实际支持无法扩展，如果广泛的平台采用是目标，那么平台团队必须投资于其平台的开发者体验，以避免陷入实施工作的泥潭。

清楚地向平台用户传达他们应该期望的哪种支持模式也很重要。在平台采用初期获得白手套支持的产品团队，除非另有通知，否则会期待将来再次享受这种体验！

提交工单

产品团队可以向平台团队提交工单，要求他们对平台进行必要的更改。这往往是一种非常令人沮丧的方法。通常，产品团队只在需要时才意识到平台缺少某些东西，而让平台团队优先处理并执行这项工作所需的时间可能太长了 - 平台团队通常会因传入的请求而不堪重负。这会导致平台团队成为瓶颈，阻碍产品交付团队的进度。

将工程师调到工作中

如果提前有足够的预警，团队可以通过暂时重新分配工程师来处理所需的平台增强工作，从而计划填补平台功能的空白。产品工程师可以到平台团队进行轮岗，或者平台工程师可以加入产品团队一段时间，担任嵌入式专家。

在团队之间调动工程师必然会导致短期内生产力下降，但从长远来看，拥有嵌入式工程师可以提高效率，因为减少了产品团队和平台团队之间所需的跨团队沟通。嵌入式工程师充当大使，使沟通渠道畅通，减少了传话游戏。

这种固定前期成本和持续收益的等式意味着，重新分配工程师是为较大的平台改进保留的最佳选择 - 将工程师调到另一个团队几周会比有益更具破坏性。

这些类型的临时分配还需要相对成熟的管理结构，以避免嵌入式工程师感到孤立。对于嵌入式专家 - 被重新分配到产品团队的平台工程师 - 也存在他们成为一般“额外人员”的风险，他们只是在做平台消费工作，而不是积极地进行产品团队需要的平台改进工作。

远程工作平台

如果平台团队已经采用了内部开源方法，那么产品团队可以选择直接实施所需的平台更改。平台团队的角色主要是咨询性的，提供设计建议并审查产品团队的 PR。在几个 PR 之后，产品工程师甚至可能从平台团队那里获得足够的信任，获得提交权限，成为可信外部人员。

许多平台团队渴望达到这种情况 - 如果您的客户能够自行实施改进，并让您免于进行这项工作，那不是很好吗！但是，内部开源的现实与一般开源类似 - 支持外部贡献需要令人惊讶的投入，而绝大多数消费者并没有成为有意义的贡献者。

平台团队应该谨慎，不要在没有对这些贡献进行一些深思熟虑的投资的情况下，将他们的代码库开放给外部贡献。如果平台团队在全体会议上自豪地宣布他们的代码库是共享资源，但随后发现自己反复地告诉来自其他团队的贡献者“不，不，不是那样！”，那么周围可能会出现深深的沮丧。

要协作，但只进行一小段时间

在团队拓扑结构中，他们指出设计两个团队之间良好边界最佳方式是最初以专注、高度协作的方式共同工作——想想像 嵌入式专家 和 轮岗 这样的模式。这段时间可以用来探索在系统之间以及团队之间创建最佳边界和接口的最佳位置（康威定律告诉我们，这两者是密不可分的）。然而，《团队拓扑结构》的作者也警告说，重要的是不要长时间停留在这种协作模式中。平台团队应该努力定义他们的接口，并努力快速转向“服务化”模式，使用像 提交工单 和 内部开源 这样的模式。正如我们在平台消费部分讨论的那样，更协作的交互模式对于平台团队来说，规模无法扩展到那么大。此外，协作模式会给消费团队带来更大的认知负担——转向更“放手”的交互方式，可以让产品交付团队将更多时间集中在他们自己的成果上。事实上，《团队拓扑结构》认为，这种认知负荷的减少是平台团队的定义目的——我非常同意这种观点。

在我看来，从高度协作到服务化的转变，是年轻平台团队面临的最大挑战之一。你的客户会习惯这种高触感体验。构建优秀的文档很难。说不也很难。

在协作模式下运营的平台团队应该密切关注扩展挑战。当向更可扩展、更“放手”的方式转变的需求出现在地平线上时，平台团队应该开始向他们的客户发出这种转变的信号。关于交互模式将如何改变以及为什么改变的早期预警，可以让产品团队有机会做好准备，并开始将他们对平台的心理模型转变为更自给自足的模型。

这种转变可能很痛苦，但犹豫不决会让它更糟。产品交付团队会感谢围绕平台提供商如何支持他们的清晰沟通的参与规则。此外，移除“亲力亲为”协作的拐杖，为改进自助服务界面、文档等提供了强烈的动力。康威定律在这里起作用——重新定义团队如何集成，将给团队的系统如何集成带来压力。