当我谈论平台时，我谈论的是什么

什么是“平台”？

语言似乎很难。“平台”可能是我们用来描述一种方法的最模糊的术语，这种方法对于提高大规模交付速度和效率至关重要。因此，本文的标题，这是我最近一直在谈论的内容。

软件和硬件平台的定义比比皆是，通常描述一个应用程序可以在其上执行的操作环境，并提供可重用功能，例如文件系统和安全性。

从组织层面来看，“数字平台”具有类似的特征——一个操作环境，团队可以在其上构建，以更快地向客户交付产品功能，并得到可重用功能的支持。

数字平台是自助式 API、工具、服务、知识和支持的基础，这些基础被组织成一个引人入胜的内部产品。自主交付团队可以使用该平台以更快的速度交付产品功能，并减少协调工作。

在 Thoughtworks，我们开发了一个模型，其中包含 平台能力的五个关键支柱。这些能力包括交付基础设施、API 和架构修复、自助式数据、实验性基础设施以及客户接触点技术。我们通过全球经验了解到，这些是最重要的共享能力，需要投资才能解锁成为数字公司的能力。

本文重点介绍我们归类为交付基础设施的平台能力——包括云托管和 DevOps 工具，尽管相同的定义特征也适用于其他平台能力。

首先，一个非平台

几年前，我被聘请到一家大型澳大利亚金融服务机构进行咨询。我们称他们为 BigCo。我到达现场后的首要目标是了解应用程序基础设施、托管和运营领域正在发生的事情。为了真正了解挑战所在，我们决定跟踪一个真实的变更，看看事情是如何完成的。

尽管在云和自动化方面投入了巨资，但 BigCo 保留了基础设施和运营领域团队的传统安排。团队按技术能力划分。我们跟踪了一些典型的变更，每个变更都涉及到这些团队中的许多团队。如果应用程序服务器配置发生了变更，这由“中间件”团队负责。但是，中间件团队无权访问底层操作系统配置，这是“中端”团队的责任。数据库变更必须由 DBA 团队完成。网络变更必须通过网络团队进行。负载均衡器变更必须由托管服务提供商完成，而防火墙变更则由不同的提供商完成。当然，还有一个独立的自动化团队，他们拥有某些自动化能力——主要限于编排。当然，还有独立的企业监控、安全、变更和发布管理团队。

图 1：独立的、高度专业化的基础设施和运营团队

BigCo 的每个团队都在其自身的管理结构下，拥有独立的工作方式。每个团队都在努力在其自己的技术领域实现高度的效率，集中专业化，外包非差异化能力，应用治理，并降低成本。但是，BigCo 的没有人以向客户交付功能的端到端有效性为衡量标准。

涉及基础设施的小型变更需要数周甚至数月的时间，这对客户的响应能力产生了巨大影响。这会产生很大的影响，但并非全部。我们注意到，当变更变得困难且缓慢时，变更过程中的任何故障都会导致进一步的延迟。这促使工程师和经理尽可能减少变更次数，只对应用程序和基础设施进行绝对必要的变更。

图 2：应用程序交付团队所需的变更需要数周或数月的时间

在 BigCo，这显然导致了应用程序和基础设施内部质量的逐渐下降——环境和配置设置到处都有很多细微的不一致。团队停止了进行小的改进和重构，这些改进和重构将保持或提高质量和一致性。这在实践中是自我强化的：由于质量影响可预测性，因此增加了变更风险，因此团队变得更加谨慎，改进变得更加困难。

总之：在 BigCo 处理基础设施和托管很慢且困难。

“积压耦合”的影响

敏捷软件交付的低垂果实一直都在数字渠道，小型自主团队与业务领导密切合作，识别客户需求并构建满足这些需求的功能。但是，数字产品团队变得越快、越有响应能力，施加在其身上的外部约束就越明显。

数字团队通常在三个主要领域受到限制：缓慢移动的核心交易系统记录、访问高质量数据和分析以及共享基础设施和运营。

我使用“积压耦合”一词，其中积压是敏捷交付团队经常使用的规划工具。

图 3：当变更在多个团队的积压（工作队列）之间存在依赖关系时，就会发生积压耦合

这是一个简单的概念——如果数字产品团队积压中的大量项目需要在另一个团队中提出相应的积压项目，那么生产力和响应能力就会受到极大的影响。积压在整个组织中相互关联，每个积压都根据不同的系统进行优先级排序。任务在看板上获得大的红色“阻塞”贴纸，利益相关者感到愤怒，共享服务提供商尽其所能做出反应——通常是对最响亮的声音做出反应。

积压耦合有多糟糕？在一间澳大利亚电信公司，我的同事对数百个通过交付中心的工作或任务进行了研究。一些任务可以由单个团队完成，而无需依赖，特别是无需安排其他团队成员的工作。必须等待另一个团队的任务在经过时间上慢了 10-12 倍。因此，依赖关系确实会产生重大影响。

这对我们有很多负面影响：它损害了对客户需求的纯粹吞吐量和响应能力，并促使我们进行更多长期规划，以更有效地管理依赖关系。它还会损害团队对结果的责任感，对于我观察到的许多团队来说，这是一个动力杀手。团队很容易推卸责任，停止寻求自身的持续改进。

为许多嘈杂的内部客户提供服务的超负荷团队之一也不好受。

最近的“扩展敏捷”传统试图以一种方式解决这个问题——通过引入规划仪式，试图在多个团队之间协调优先级。这明确地以降低自主性、响应能力和应对变更的能力为代价，提高了协调性。这不能是唯一的方式。

因此，一个好的平台的特征显然必须是减少积压耦合。该平台必须提供不需要提出工单和分配工作的服务。自助服务是良好平台的关键定义特征。

该平台应为团队提供自助服务访问。具体来说，它应该允许自助式配置、自助式配置以及平台能力和资产的自助式管理和运营。

该半吊子表面私有云

BigCo 认识到对自助服务的需要，但难以想象如何在根深蒂固的传统基础设施和思维方式的大型基础设施和运营组织中实现这一点。已经对集中式自动化工具进行了投资，因此第一个努力是为应用程序交付团队创建自助式功能，以便他们能够自助式配置基础设施。

构建了一个自助式工具，允许交付团队根据非常固定的模板请求计算实例。配置的虚拟机实例在配置方面是固定的，并且被安全地锁定，以确保对集群的控制权仍然掌握在中央中端团队手中。为了对实例做一些有用的事情——例如安装软件包、将其连接到网络、附加存储、配置负载均衡器、配置监控工具或任何其他事情——交付团队需要提出工单。

图 4：BigCo 构建了一个基本的自助式 API，但没有改变应用程序和基础设施运行方式的基本原理。结果并没有显著改变交付速度。

您可以争辩说这仅仅是第一个迭代，这是真的——但是意图很明确。BigCo 基础设施和运营团队当时还没有准备好打破自己的组织孤岛，并将重大责任（以及因此的访问权限）转移到交付团队。即使意图良好，逐步构建该 API 以达到所需丰富程度所需的巨大努力也是不可行的。

我们将这种方法称为“表面私有云”——重新标记现有的虚拟化平台，以便交付团队以非常受限的方式使用，而没有真正意图减少集中式控制。

与此同时，BigCo 在一项并行工作中，一个交付团队解锁了直接使用 Amazon Web Services (AWS) 进行生产系统的能力。一旦先例确立，交付团队就加入了使用 AWS 的热潮。

AWS 是一个引人入胜的平台，可以供交付团队直接使用：它完全是自助式的，并且具有明确的责任边界。“您构建它，您运行它”成为口号，亚马逊构建并运行平台直到 API，并确保它具有高可用性，而您的应用程序交付团队构建、配置和运行位于其顶部的应用程序。

故事结束了吗？

自主性加快上市时间，促进创新

我遇到的大多数组织都有一个默认设置：“构建以供重复使用”：由风险规避和成本降低相结合驱动的能力集中化。

图 5：大多数组织默认情况下会集中强制执行技术选择，以提高成本效率

在过去几年中，我有幸成为一家大型澳大利亚（和全球）科技公司的技术领导团队的一员，该公司拥有巨大的在线业务，我们称之为 WebBiz。拥有数百名工程师，他们足够大，可以面临与 BigCo 相同的许多挑战，在基础设施、应用程序和数据方面也存在着不可忽视的传统——但 WebBiz 规模足够小，可以见证快速的变化和改进。

在我任职于 WebBiz 的期间，我们启动了一个为期多年的迁移项目，将大部分应用程序从租赁数据中心的虚拟化平台迁移到 AWS 作为新的默认部署目标。我们还将应用程序和（大部分）基础设施的构建和运行职责移交给了产品团队，这是我所见过的最完整的从传统集中式运维到 DevOps 的转变。我认为，从一开始就建立一个“你构建，你运行”的思维模式并不难，但要完成这种转变需要勇气和持续的愿景。WebBiz 在这方面做得很好。

作为迁移的一部分，WebBiz 的产品团队获得了对其堆栈各个部分的配置和运行的完全自主权。这种方法被称为“团队管理基础设施”——虽然在早期建立了一些默认设置，但每个团队都可以对堆栈的各个部分做出自己的决定，几乎没有中央指令。

WebBiz 成功地扭转了组织的典型默认偏好：偏爱技术多元化和创新。这提高了员工参与度，工程师获得了更深入的技术堆栈的经验，推动了创新，迅速建立了对部署内容的责任感，并消除了大部分团队依赖性。这也吸引了对承担运行责任、对自主权反应良好以及对解决困难的业务和技术问题感兴趣的工程师加入 WebBiz。

技术多元化增加阻力

然而，对于所有这些好处，向完全自主权转变也确实存在成本。通过采用 AWS 作为平台，WebBiz 消除了对集中式基础设施团队的积压耦合。但是，WebBiz 的每个团队现在都必须围绕构建和运行基础设施的各个方面做出一系列决策。

图 6：云原生景观（来源：www.cncf.io)

上面是 云原生景观 的最新版本：试图捕捉一些常见的开源和产品，按构建云原生架构的关注领域进行分组。这是一张拥挤的地图，而且只包含最成熟的产品。对于这些领域中的每一个，以及更多领域，团队必须评估选项并选择适合其需求的产品，然后学习如何集成和操作该产品。

除了重复基础设施的维护拖累之外，每个团队还必须持续研究和评估其基础设施选择，这会带来持续的开销。这也造成了摩擦，阻碍了在运行截然不同的堆栈的团队之间转移技能甚至人员。

WebBiz 现在开始建立一个定义更清晰的交付基础设施平台——一套引人注目的默认设置，产品团队可以利用它来减少拖累并提高生产力。

但他们是否冒着失去自主权带来的好处的风险呢？

平台作为内部产品

在自主多元化和强制性整合之间找到合适的平衡是一场真正的斗争，而且在事前预测这种平衡更加困难。找到这种平衡的关键要素是平台必须引人入胜，它们不能仅仅依靠强制性命令。你现有的共享基础设施功能拥有垄断地位，交付团队没有可行的替代方案。一点竞争是推动产品思维的必要因素，确保每个平台功能都能够增加价值，而不是造成约束和耦合。

是什么让平台引人入胜？以下是一些想法：

• 平台对于绝大多数用例来说都是自助式的。
• 平台是可组合的，包含可以独立使用的离散服务。
• 平台不会强迫交付团队使用僵化的工作方式。
• 平台快速且廉价地开始使用，并提供简单的入门方式（例如快速入门指南、文档、代码示例）。
• 平台拥有丰富的内部用户社区，用于分享。
• 平台默认情况下是安全且合规的。
• 平台是最新的。

最终，当平台功能比构建和维护自己的东西更容易使用时，交付基础设施平台就变得引人入胜了。Netflix 将其集中式工具描述为“铺好的道路”——团队不必使用这些工具，但要对维护自己替代方案的所有成本负责。

平台也不应该仅仅是软件和 API——它还包括文档、咨询、支持、宣传、模板和指南。

等等……这不是“DevOps 团队”吗？

做得不好吗？是的，可能。

我们完全输掉了“DevOps 不是角色/团队/工具”的战斗，不是吗？我们一直在输掉这些战斗。也许下次要采用新的策略？

-- Phil Calçado

（我还没有准备好承认在 DevOps 方面已经失败：所以，以防万一你不确定，如果你有一个名为“DevOps”的团队，那么这个词的含义与你所想的并不一样。）

你可以选择组建一个团队来构建和运营交付基础设施平台——我认为在大多数情况下，这将是开始的最佳方式。如果是这样，你应该非常清楚平台团队与客户（为了清晰起见，我称之为应用程序团队）的责任范围。

应用程序团队构建、部署、监控并负责其在平台上配置和部署的应用程序组件和应用程序基础设施的轮班。平台团队构建、部署、监控并负责平台组件和底层平台基础设施的轮班。

平台团队理想情况下甚至不知道平台上运行着哪些应用程序，他们只负责平台服务的可用性。

这样，应用程序团队和平台团队都对自身产品的构建和运行负责。“你构建，你运行”仍然适用。

我从哪里开始？

建立交付平台需要一些先决条件。首先，你可能已经在 从“项目” 作为技术交付的主要资金和人员配置机制中走出来。平台是一个产品，需要一个长期稳定且稳定的产品团队来负责构建和运行。

其次，你必须愿意将应用程序的运行责任部分或全部转移到应用程序团队，而不是集中式运营和支持。平台提供工具和服务，使应用程序团队能够对他们构建的内容负责，只要支持是集中的，这种情况就不会发生。

第三，你必须愿意在严格的实现一致性与你赋予自主应用程序团队的自由和责任之间进行权衡。

现在有一些需要注意的地方。

• 你的平台不仅仅是你能够安装的基础设施、工具和 API。为了有效，你必须回答以下问题：你的交付团队将如何快速采用新功能，他们将独立做出哪些选择，而不是使用合理的默认设置，以及你将如何持续维护这些功能。这将需要一些内部咨询技能、培训、宣传和推广。
• 你不知道你需要哪些平台功能，所以从基于真实证明需求的小规模开始。从应用程序团队那里收集已经验证的解决方案，并尝试与将使用这些功能的团队进行合资企业，以创建和测试功能。
• 要非常小心，不要仅仅将平台标签应用于你已经拥有的有限虚拟化托管和锁定式集中式管理工具。