平台工程侧重于为开发人员创建可扩展、可靠和高效的构建平台。相比 DevOps 更注重应用程序的部署和运行，平台工程则关注的是构建开发人员使用的底层基础设施和工具。平台工程师更是善于制作其他人所需的最佳工具。
这篇文章将从其他人的平台工程历程中吸取的一些经验教训，阐明平台工程团队将面临的最大挑战以及应对这些挑战的一些策略。
对于平台工程团队来说，最紧迫的挑战之一就是在构建一个全面、功能丰富的平台与尽快将其提供给用户之间找到正确的平衡。一个过于基本的平台可能无法满足开发人员的需求，而一个过于复杂的平台则可能耗费过长的时间来构建，从而阻碍用户的早期采用。关键是要优先考虑那些能为最多用户提供最大价值的功能，并以鼓励用户尽早但有意义地使用平台的方式推出这些功能。
与其一开始就追求功能齐全的平台，不如集中精力为用户提供增量价值。确定平台可以解决的最紧迫的使用案例，并构建解决这些具体问题的功能。这种方法不仅能加快开发周期，还能鼓励用户尽早采用。用户更愿意使用一个能解决他们当前需求的平台，即使它的功能还不完善。
这里的关键挑战在于，首先要倾听开发人员的意见，解决他们最迫切的需求。以往遇到一些集群 DNS 问题，需要手动复制粘贴三个不同的本地 IP 地址才能运行调试器。不仅麻烦，而且没有简单的脚本解决方法。后来，有开发人员平台完全解决了这个问题，调试器可以通过 IDE 中的一个按钮激活。这是个关键的痛点，以至于每个人都立即采用了这个工具。即使其他组件还很简陋，但一个基本平台如果能解决团队面临的前两三个问题，就会被所有人采用。
一个平台既可能被需要大量指导的新手开发人员使用，也可能被需要高级功能和定制能力的专家开发人员使用。这种多样性要求平台设计灵活、适应性强，既能满足不同技能水平的需求，又不会过于简单或复杂。
举个最基本的例子，对于完全通过终端工具开始编写代码的开发人员来说，如果他们使用的工具是复杂的 CLI 形式，他们会感觉非常舒适。他们习惯于在终端上翻阅命令历史记录、将输出导入其他工具并扫描日志。其他开发人员可能会使用命令行启动服务、通过 git 提交，除此之外几乎没有其他操作。
所面临的挑战在于创建一个既能满足初学者直观需求，又能提供经验丰富的开发人员所期望的深度和灵活性的平台。
为了满足不同用户群的需求，可以考虑采用双层应用程序接口设计。基础层应提供复杂用例所需的原始功能，为经验丰富的开发人员提供他们所需的灵活性。为直接部署等最基本的任务构建一个 Web GUI，同时通过命令行进行更完整的配置，这样做可能是合理的。您的预算可能不允许采用这种完整的双层方法，因此可以考虑设置默认配置值，并为对操作工具不太熟悉的工程师分发完整的脚本。
平台工程团队通常依赖第三方服务来实现某些功能，如软件包管理、源码管理自动化和用户账户控制。虽然这些服务可以加快开发速度，但也会带来锁定供应商的风险。这种依赖性会导致难以更换供应商或采用新技术，从而限制平台未来的适应性。更糟糕的是，如果您的开发者平台使用的是封闭源代码的 SaaS 工具，那么您有理由担心，如果该供应商想提高您的订阅价格，您将无能为力。
诚然，供应商锁定是一个重大问题，尤其是当现有工具只需少量工程工作就能解决大部分问题时。请注意上文对 “采用”?的关注，一个现在就可用的好解决方案要比六个月后推出的好解决方案好得多。两种可能的解决方案：
抽象层：为了降低锁定供应商的风险，可以采用第三方服务的抽象层或封装层。这样，您就可以在对平台或其用户影响最小的情况下更换供应商。例如，如果您正在使用特定云提供商的存储服务，可以创建一个与该服务交互的内部应用程序接口。如果您需要更换供应商，您只需更新这个内部 API，而无需对整个代码库进行更改。
开放源代码：开发人员平台 Backstage 以如此完整的方式解决了如此多的问题，以至于一旦你的团队采用了它，你将很难从该平台迁移出去。好在 Backstage 是开源的，所以你不会发现平台的 SaaS 费用每个季度都会神秘地上涨 20%，直到让你的基础架构成本相形见绌。采用开源工具作为您的开发人员平台，有助于确保在采用上所花的时间是一项良好的投资。
确定一个平台是否成功并不简单。要从一个冲刺阶段或一个季度来概括开发人员的开发速度可能非常困难；毕竟，在那个时间窗口内面临的挑战可能异常困难，也可能异常简单，这就是性能变化的原因。开发人员平台的改进可能更加难以衡量：由于采用新平台和培训团队需要时间，因此通常不会有一条明线显示 “我们采用这个平台后，一切都发生了变化”。
正常运行时间或延迟等传统指标固然重要，但并不能全面反映情况。我们面临的挑战是确定一套正确的关键绩效指标，并利用它们来指导平台的持续改进。
虽然正常运行时间或延迟无法显示平台工程的有效性，当然也不会立即显示任何信号，但 Google Cloud 团队建议采用更好的指标来衡量开发人员编写、测试和发布代码的难易程度。DORA 指标有其自身的实施要求，但如果您需要可衡量的结果，这就是值得做的工作。
简单总结一下如何使用 DORA 指标来回答关于工程团队的四个问题：
多久部署一次新代码？
从 “通过单元测试”?到 “部署到生产环境”?需要多长时间？
一旦部署了代码，需要回滚的可能性有多大？
如果出现糟糕的部署、故障或其他问题，需要多长时间来解决？
关于如何衡量这些值，有一些具体的建议，而且这些指标目前可能无法从源代码控制或可观察性工具中获得，但就这四个问题而言，应该不难理解它们是如何在保证可靠性的同时，让开发人员完成他们的工作并交付生产功能的。
Stitch Fix 团队为数据科学家创建一个平台，而无需 “移交”?他们的模型。这个团队的唯一关注点是改善开发人员的体验，这种哲学上的转变从根本上改变了他们的整个方法。
在高层次上，平台团队在没有产品经理的情况下开展工作，他们必须提出平台功能来推动数据科学家的发展，而数据科学家又反过来推动 Stitch Fix 的业务发展。
他们的项目发布提供了很多经验总结，包括在决定何时以及如何向团队发布工具时，“关注采纳性，而非完成度”?这一绝妙的观点。
Uber 创建了一个平台工程团队，该团队与现有团队有很大不同，主要原因是该团队不以项目为基础开展工作，而是处理有关技术债务和开发人员启用的持续问题。这项工作给业务论证带来了真正的挑战，毕竟，这些工程师的具体任务不是提供功能。但经过仔细观察，其好处显而易见：
平台团队提高了组织效率。当标准化对组织有利时，平台团队可以减少重复工作，帮助实现方法的标准化。例如，建立一个后端安全平台团队可以帮助整个公司实现安全漏洞检查的标准化。
在 Uber，平台团队面临着特殊的挑战。其中一个问题就是资历过度饱和：由于他们很少需要面对紧迫的截止日期或业务利益相关者，高级工程师们都倾向于平台工程，导致组织结构失衡。
Netflix 公司也通过创建开发人员平台来实现了 Polyglot 开发。有了容器化，Netflix 的团队就可以从 Java 开发团队转变为满足工程师需求的团队，并允许团队使用最适合其挑战的语言开展工作。这里有一份很好的经验教训清单：
Polyglot 可能很昂贵
容器使工具分布更加合理
构建平台，而不仅仅是工具
提供原生（或类原生）解决方案
减少认知负荷
这样的团队是许多其他大型工程组织的典范，也是多年前就面临并克服平台工程挑战的团队。
有效的平台工程通常被称为 “工程中的创业”，在我们研究成功案例时，这一观点依然适用。成功的平台工程团队发现了大企业中未被满足的需求，用一种产品解决了这些问题，这种产品能很好地完成一件事，并有足够的吸引力被广泛采用。工程师们也能得到了更好的支持，他们可以做更多自己最擅长的工作，而无需承担平台工具所能解决的繁重工作。因此，成功的平台工程的结果是团队之间的联系更加紧密，在努力将工作推向市场时所承受的压力更小。