平台工程团队面临的主要挑战及应对策略概览。
译自 How to Be an Effective Platform Engineering Team，作者 Nočnica Mellifera 在转入开发者关系之前是一个开发者七年。她专门从事容器化工作负载、无服务器和公共云工程。Nočnica 长期以来一直是开放标准的倡导者，并就此举办了演讲和研讨会......
平台工程是一门专注于为开发者打造可扩展、可靠和高效的基础平台的专业学科。它与更关注应用程序部署和运维的 DevOps 不同，平台工程关注的是构建开发者所依赖的基础设施和工具。平台工程师不关注产品的改进和交付，而是像希腊神话中为众神制造武器的火神赫菲斯托斯一样，为其他人制造最佳的工具。
本文不会深入探讨为什么需要一个平台工程团队，或者一个开发者平台的益处，而是想概述他人平台工程实践过程中的一些经验教训、一个平台工程团队将面临的主要挑战以及处理这些挑战的一些策略。这些挑战包括:
平台工程团队面临的一大紧迫挑战是在打造一个全面、功能齐全的平台与尽快让用户采用之间找到适当的平衡。一个过于基础的平台可能无法满足开发者的需求，而一个功能过于复杂的平台则需要太长时间才能打造，这将成为早期采用的障碍。关键是优先提供最大用户价值的功能，并以一种鼓励平台早期且积极的使用方式来推出这些功能。
与其一开始就追求一个功能齐全的平台，不如关注为用户不断提供增量价值。确定平台可以解决的最迫切用例，并重点打造解决这些特定问题的功能。这种方法不仅可以加速开发周期，还可以促进早期采用。即使平台还不够成熟完整，用户也更愿意使用一个能解决他们当下需求的平台。
与其一开始就定位为一个功能全面的平台，不如先集中精力为用户提供增量价值。确定平台最迫切能解决的用例，并构建专门解决这些特定问题的功能。这种方法不仅可以加快开发周期，还可以鼓励早期采用。即使功能还不完整，用户也更有可能使用解决他们当前需求的平台。
这里的关键挑战是首先倾听开发者，解决他们最迫切的需求。几年前，我与一个团队合作，由于一些集群 DNS 的问题，你需要手动复制粘贴三个不同的本地 IP 地址来运行调试器。这很麻烦，也没有简单的脚本化解决方案。我们在那一年晚些时候工作的开发者平台完全解决了这个问题，调试器可以在 IDE 中通过一个按钮激活。这个痛点如此之大，以至于每个人都立即采用了该工具。即使其他组件比较简陋，一个可以解决团队面临的前两三个问题的基本平台也会被所有人采用。
平台可能同时被需要大量指导的新手开发者和需要高级功能及定制能力的专家开发者使用。这种多样性要求平台设计要灵活、适应性强，以满足不同技能水平的需求，而又不会过于简单或过于复杂。
我和其他那些完全通过终端工具编写代码的人会感到非常舒服，如果我们的开发工具是以一个复杂的命令行界面(CLI)的形式出现的。我们习惯于翻阅命令历史记录，将输出管道到其他工具，并从终端扫描日志。其他开发者可能只会使用命令行启动服务，通过 git 提交，其他很少涉及。我们想要给所有工程师提供强大的工具，而不会让其中一些人感到被排除在外。
挑战在于创建一个对初学者来说直观易用，但仍然为有经验的开发者提供预期的深度和灵活性的平台。
为了适应不同的用户基础，可以考虑实现双层 API 设计。基础层应提供复杂用例所需的原始功能，为有经验的开发者提供他们所寻求的灵活性。在上面的 CLI 示例中，对于诸如直接部署等最基本的任务，构建一个 Web GUI 可能是有意义的，同时通过命令行启用更完整的配置。你的预算可能不允许采用这种完整的双层方法，所以可以考虑为不太熟悉运维工具的工程师设置默认配置值并分发完整的脚本。
平台工程团队通常依赖第三方服务来提供某些功能，例如包管理、源代码控制自动化和用户帐户控制。虽然这些服务可以加速开发，但也带来供应商锁定的风险。这种依赖关系会使得切换供应商或采用新技术变得困难，限制了平台的未来适应能力。更糟糕的是，如果您使用专有 SaaS 工具构建开发者平台，那么如果该供应商想提高您的费率，您合理地担心您将无能为力。
无可否认，供应商锁定是一个重大问题，特别是当现有工具可以通过您提供很少的工程工作来解决大多数问题时。注意上述关注采用的重点，现在可用的好解决方案要比六个月后推出的绝佳解决方案要好得多。两种可能的解决方案:
- 抽象: 为了减轻供应商锁定的风险，你可以对第三方服务使用抽象层或包装器。这使您可以在对平台或其用户的影响最小化的情况下切换供应商。例如，如果您使用特定云提供商的存储服务，可以创建一个与该服务交互的内部 API。如果您有必要切换供应商，您只需要更新这个内部 API，而不是在整个代码库中进行更改。
- 开源: 开发者平台 Backstage 以一种如此完整的方式解决了这么多问题，以至于一旦您的团队采用它，您将很难脱离该平台。好消息是 Backstage 是开源的，所以您不会发现您的平台 SaaS 账单每季度神秘地上涨 20%，直到它超过您的基础设施成本。采用开源工具作为您的开发者平台有助于确保用于采用的时间是值得的投资。
确定平台的成功并不简单。很难从单个冲刺或季度中普遍化开发者速度；毕竟，在那个时间窗口面临的挑战可能异常困难或异常容易，这就解释了性能的变化。平台改进的效果甚至更难衡量：考虑到采用新平台和培训团队所需的时间，通常没有明确的信号显示“在我们采用此平台后，一切是如何改变的”。
正常时间和延迟等传统指标虽然重要，但并不能提供整体情况。挑战在于确定正确的 KPI 集合并用其来指导平台的持续改进。
虽然正常时间或延迟不会显示平台工程的有效性，当然也不会立即显示任何信号，但谷歌云团队建议更好的指标来衡量开发者编写、测试和交付代码的便利性。DORA 指标自身需要实现要求，但如果您需要可衡量的结果，那么这是值得做的工作。有关详细信息，请参阅下一节关于衡量成功的内容。
虽然我最近发表了一整篇关于这个主题的文章，但关于如何使用 Dora 指标的简要总结是回答有关您的工程团队的四个问题:
- 你部署新代码的频率是多少？
- 从“通过单元测试”到“在生产环境上部署”需要多长时间？
- 一旦代码被部署，回滚的可能性有多大？
- 如果有错误的部署、故障或其他问题，解决事故需要多长时间？
对于如何测量这些值有一些具体的建议，这些指标目前可能无法从您的源代码控制或可观察性工具获取，但我认为通过查看这四个问题很容易看出它们如何让您了解我们在何种程度上支持开发人员完成他们的工作并交付生产功能，同时保持可靠性。
在这篇中型文章中，Stefan Krawczyk 描述了他的团队如何在不需要数据科学家“移交”模型的情况下为数据科学家创建一个平台。这种关注提高开发者体验的团队的哲学转变是基础性的，改变了他们的整个方法。
在高层次上，平台团队没有产品经理运营，必须提出平台功能才能推动数据科学家向前发展，而数据科学家反过来推动 Stitch Fix 业务向前发展。
Stefan 的文稿中有许多我在本文中使用的教训，包括在决定何时以及如何向团队发布工具时那个绝妙的“关注采用，而不是完整性”。
在 2021 年的一篇文章中，Gergerly Orosz 写道，Uber 创建了一个与现有团队截然不同的平台工程团队，主要原因在于它不是以项目为基础工作的，而是处理有关技术债务和开发者启用功能的持续问题。这项工作在进行商业论证方面提出了真正的挑战，毕竟，这些工程师明确不负责交付功能。但通过仔细观察，益处是明显的:
平台团队提高了组织效率。它们减少了工作重复并有助于方法的标准化，当标准化对组织有利时。例如，建立一个后端安全平台团队可以帮助标准化公司范围内的安全漏洞检查。
平台团队在 Uber 面临特定挑战。我发现有趣的是高级人员过度饱和：由于他们很少需要处理紧迫的最后期限或业务利益相关者，因此高级工程师倾向于平台工程，从而失衡了组织。整篇文章是令人着迷的阅读材料，并讨论了 Uber 如何从纯创业文化转变为需要保护其巨大的技术和业务成就的文化。
Netflix 的开发者生产力经理 Mike McGarr 在 QCon 上发表了演讲，讲述该公司如何通过创建开发者平台实现多语言开发。通过容器化，Netflix 的团队能够从 Java 商店转向在工程师现有基础上满足他们的需求，并允许团队使用最适合其挑战的语言开发。Mike 从平台工程的最初阶段开始就有一些见解。这里有一个很棒的教训清单:
Netflix 发现:
- 多语言支持会增加开销
- 容器可以很好地分发工具
- 构建平台，而不仅仅是工具
- 提供本地(或类本地)解决方案
- 降低认知负荷
结果是一个作为这么多其他大型工程组织的模型的团队，一个几年前面临和克服了平台工程挑战的团队。
有效的平台工程通常被称为“工程领域的创业公司”，随着我们研究成功案例，这一观察仍然正确。成功的 PE 团队在其更大的组织中发现了未满足的需求，用一种非常出色地完成一项工作的产品解决了这些问题，并且具有足够的吸引力以实现广泛采用。成功的平台工程的结果是一个更加密切的团队，在试图使其工作面市时遭受的压力更小。
工程师得到了更好的支持，可以做更多最好的工作，而无需通过平台工具解决的任意繁重工作。
随着您追求平台工程，供应商工具锁定和记录好处等挑战都在您的未来。如果您想加入一个致力于支持开发者的志同道合的工程师社区，请查看 Signadot Slack 以继续交流。