沃尔玛的平台即产品实践｜最佳实践

作者｜Bryan Finster

翻译｜平台工程技术社区

链接｜https://itrevolution.com/articles/platform-as-a-product-at-walmart/

2015 年，我们开始在沃尔玛进行持续交付试点。我们有一个大型遗留系统，由数百名开发人员提供支持，部署到多个国家的数十个配送中心。我们每年都要发布三到四个版本，每个版本都需要有计划地全天候支持几个星期，需要巨大努力才能稳定下来。这时管理层向我们提出挑战，要求我们找到每两周交付一次的方法。因此，我们组建了一支由高级工程师组成的团队，研读了 Jez Humble 和 Dave Farley 合著的 Continuous Delivery 一书，并决定每天进行交付。因为更小批量的变更影响的范围更小，而且这是能有效地发现资源浪费和交付难题的更好方法。

想要实现这一目标，不能只是简单地告诉团队要更频繁地交付。我们的团队结构是围绕功能交付而不是业务能力来组织的，我们也没有持续集成工作流程方面的经验，而这正是持续交付（CD）的基础。因此我们向领导层提出了一个与业务领域相一致的新团队结构，以及一个开始为交付重新架构的计划。我们创建了一个小型平台团队，以建立符合 CD 原则的自助服务和意见交付流水线。

在新产品团队解决持续集成（CI）和 CD 挑战的同时，他们向平台团队提供反馈以改进流水线的默认设置。团队也因此能够专注于他们的领域能力，而不是如何交付这些能力，同时我们将学到的好模式嵌入到平台中，以帮助未来的团队。解决了每天多次交付非破坏性变更的所有问题后，这些团队的技能得到了迅速提高。这还带来了意想不到的好处，那就是提高了团队士气，因为大家喜欢看到自己的工作成果被运用。

 

01 持续交付

我们的经验表明，集中精力解决 "为什么我们不能每天提供可行的解决方案 "的问题，是推动改进的最有效方法。我们实施了一项战略，将 CD 作为主要方法，在整个企业推广相同的工程和业务改进。这一战略的挑战和优势在于，CD 不仅仅是一种工具，它还需要特定的工作流程和思维方式来实现最佳效果。其中一种方法就是创建一个大型的培训组织，并对每个团队进行培训。然而，即使能找到足够多的合格人员与团队合作，这种方法也会给大型企业组织带来巨大的开销。

我们需要合适解决方案来帮助团队自我提升。为此，我们创建了一个集中交付平台组织来实现这一战略。

集中式平台

标准化工具是一把双刃剑，如果使用不当，可能会导致糟糕的结果。但如果对平台施加过多限制或意见，就会扼杀创新，或迫使人们绕过平台完成工作。正确的做法是，为团队提供一套不那么繁琐且好用的工具。使用更少的工具意味着更低的运营成本和更少的集成工作，这也意味着团队之间的协作会变得更加容易。此外，它还能让我们将标准、政策和安全自动整合到一个平台中。

02 换位思考，而非强制要求

在提供解决方案时，不要试图疏远或忽视潜在用户，而强迫他们做出改变是最主要原因。即使解决方案再好，强迫他们更换也会适得其反。比起强制要求，我们希望建立吸引他们的解决方案。我们知道企业的目标是建立一个全球平台，而且必将使用该平台。为此，我们需要对用户遇到的问题感同身受。这种同理心和以用户为中心的理念并不局限于开发人员。

改善开发人员体验并不意味着我们的优化只是为了减少将代码交付到生产所需的时间或精力。我们要让团队出错的频率变得更低，让这些团队更容易操作他们的产品。我们与安全和合规领域合作，将他们关注的问题嵌入平台，以便根据他们的政策自动验证每项变更。这需要我们进行严格的变更管理。对于过去仅使用手动安全和合规流程的应用程序，不能采用严格的自动验证。稍后我们将详细介绍这一点。

当安全团队在不使用我们的解决方案时，他们需要付出更多时间和精力来根据政策验证变更。但使用我们的解决方案，这一切就自然而然地发生了。

03 范围和组织

另一个需要考虑的问题是如何避免解决错误的问题。正如我们之前所讨论的，内部平台并不产生收入。我们的价值主张是降低其他业务成本。

对于一个拥有企业资金的平台来说，很容易陷入遇到问题就无差别解决的困境中。在这一过程中，我们可能会头重脚轻地使用一些功能来解决一些实际不那么重要的问题，或者该问题实际只影响组织中的一小部分人。例如有一个可以创建服务的开发人员门户，是不是很酷？但有必要吗？如果它不能显著降低大多数团队的开发成本就没有太大的意义且增加成本消耗。这样一来，我们很快就会失去自己的价值主张。因此，我们需要明确使命和愿景。

我们有一个明确的使命：帮助推动企业的 CD 战略。我们还有一个明确的愿景：提高开发人员体验。接下来，我们需要确定我们的范围，并为进行组织和实施。

软件交付启用（Software delivery enablement, SDE）是大型的基础设施组织的一部分。我们的职责范围包括从版本控制到交付的所有功能。将与操作可观察性和工作流管理解决方案等功能对接，但我们并不对这些功能负责。有了已知的范围，我们就可以通过设计来快速实现目标，同时对如何实现这些目标保持灵活的态度。因此，我们定义了功能、版本控制、CI、安全、工件版本化、交付指标等，并围绕每项功能组织跨职能团队。

每个团队的产品负责人负责将团队的工作路径与平台的总体目标保持一致。团队交付他们所负责的功能，并对结果负责，包括运行稳定性和用户体验。通过对各个团队的信任，平台领导层建立了一种主人翁文化，促进了创新，改善了用户与交付平台内每个产品的互动。

通过围绕能力领域进行组织，能够在不影响用户体验的情况下更换底层基础设施为目标，我们没有被早期的技术选择所束缚。也改变了用于提供这些功能的工具。

04 更好的开发者体验

由于我们的目标之一是普及持续交付工作流程的知识，因此该平台使基于主干的开发等实践成为最简单的工作方式，并以评分的形式对 CD 的执行情况提供反馈。同时，该平台不明确支持其他工作流程，从而增加了工作难度。

使用 GitFlow 等做法与我们的目标不符，反而会增加工作量。但是，如果我们完全取消了使用其他工作流程的能力，又将导致其他团队无法采用。因此我们采取的方法允许团队根据需要以简单换灵活，同时还能确保安全和合规性。对工具的抽象层还允许我们在根据需求变化更换工具的同时保持一致的用户体验。

为了提高效率，避免 PaaS Ticket 系统的弊端，因此我们选择优先考虑团队根据其产品的需求配置交付流程的能力。我们提供了可扩展模板，允许团队使用简单的声明性命令来配置测试覆盖率报告等常见任务。基础模板可以使用一些简单的命令，同时还强制执行数据收集、安全扫描、合规性验证和业务规则。例如，我们可以创建并执行规则来阻止重大销售活动期间未经批准的更改。不过如果团队需要为其特定应用程序提供更复杂的行为，他们仍然能够为这些行为创建脚本，因为系统里二十年前的代码并不是针对持续交付模式构建的。

作为一个开源至上的组织，我们鼓励内部代码贡献。只要符合我们的总体使命，我们会欣然接受提交的代码，以改进我们对这些技术的支持。

05 安全与合规的实施

注重良好的开发人员体验并不意味着我们会忽视保护企业安全的责任。我们要通过在平台中嵌入安全和策略，尽可能轻松地保证企业安全。但是，如果团队以前的交付解决方案依赖于人工安全验证，那么就极有可能无法满足我们所期望的安全配置文件。如果我们通过阻止他们交付当前的应用程序来提高安全性，那么我们的平台除了用于全新开发外，将永远不会被采用。我们需要让他们在采用我们的平台的同时保持业务运行，同时提高我们的安全等级并自动合规。

想要让团队更容易交付安全的解决方案，我们在不断升级安全保障的同时，还需要考虑到团队的交付目标。为了保证企业安全、满足业务需求并帮助团队，我们需要一种更合理的方法。因为只要我们做的事情可能会对他们的交付流程造成干扰或增加摩擦，就需要额外的沟通。在实施新的安全或合规要求之前，我们会在 Slack、电子邮件以及其他任何我们知道团队可能会看到的途径，将实施新的强制实施的安全或合规信息广而告之。经过一个月左右，我们会在他们的流水线中以告警信息的形式实施了新的流水线安全或合规要求，其中包括何时将警告转换为错误。只有在此之后，我们才会对不合规的构建进行报错。通过这种方式，我们不断提高使用我们平台的每个系统的安全性和合规性。

我们的明确目标是转变企业的工作方式。CTO 将推动这一变革，要求每个团队解决每天向生产交付的问题。这与交付速度无关，而是解决阻碍每日交付的工程和沟通问题，从而改善整个组织。指标报告（Metrics reporting）是我们平台战略的重要组成部分，也是我们最早交付的功能之一。

交付指标视图有两个重要用途。首先，它能让团队了解其流水线的状态。流水线健康状况的单一视图对团队的工作效率至关重要，因为流水线故障的话则无法提供高质量的反馈，因此修复流水线是团队的首要任务。其次，这些指标向团队展示了他们执行 CD 行为的情况。例如，如果作为开发人员，你平均每天使用基于主干的开发和集成代码，那么你在源代码管理方面就能获得五颗星。

当然我们会不断审查评分机制，以防止出现不合理的激励措施。我们会展示一套平衡的指标，让指标结果与我们的业务目标重合。当希望隐藏指标结果时，我们会调整显示信息的方式，防止管理层利用评分来比较或指责团队。

06 打造 "简易按钮"

我们的下一项任务是实施一个多租户云解决方案，将容器化工作负载部署到公共云、私有云以及每个商店和配送中心的数据中心。我们希望解决方案能让团队无需知道或关心他们的应用程序在哪里运行，且更易于使用。毕竟平台工程就是为开发团队提供产品，让他们能够专注于试图解决的问题，而不是解决如何交付解决方案的问题。

2019 年，我们发布了沃尔玛云原生平台（WCNP）。从在虚拟机上部署转向在 Kubernetes 中部署容器，通常需要每个团队放慢脚步，学习新技术。我们希望让这种转变变得更容易。有了 WCNP，如果你想部署一个 React 应用程序，只需告诉 WCNP 交付一个由你的团队拥有的 React 应用程序，并告诉 ChatOps 向何处发送警报即可。WCNP 会处理其他一切。它将配置容器、日志、监控和警报，并分配域名。所有的交互都可以通过 ChatOps 来处理，包括批准向生产交付（如果未配置为持续部署）。

团队不需要学习如何构建高效的容器，也不需要学习任何有关 Kubernetes 的知识，就能交付解决方案。该平台为他们隐藏了这种复杂性。如果他们需要更复杂的流水线，可以尝试构建自己的容器，WCNP 将只负责交付和运营监控设置。同样，这也为团队提供了在需要时处理更复杂问题的选择，产品团队的反馈非常积极，开发团队也能够毫不费力地快速运行一次性的实验。这一系列正面反馈降低了变革成本，这对企业的创新也至关重要。