如今，每个人都在建立一个“平台”，以加快数字产品的大规模交付。但什么样的平台才是有效的数字平台呢？一些组织试图在现有共享服务的基础上进行平台建设时，因为没有解决组织结构和运营模式的问题，最终陷入困境。
“平台”到底是什么？
“平台”是个含糊不清的词，但对于提高大规模交付速度和效率而言，它却极其重要。因此，本文的标题就是我最近一直在谈论的“平台”。
满世界都是各种软硬件平台的定义，一般都是描述一种运行环境，在此环境上可以执行应用程序，并提供文件系统和安全等可重复使用的功能。
放大到组织层面，“数字平台”也具有类似的特征——团队在可重复使用的功能支持下，建立一个操作环境，从而更快地向客户提供产品功能。
数字平台是自助式 API、工具、服务、知识和支持的基础，是一种引人注目的内部产品。凭借平台的支持，自主交付团队能用更少的协调成本，更快地交付产品功能。
在 Thoughtworks，我们开发了一个包含五大平台能力支柱的模型。这些能力包括基础设施交付、应用程序接口和架构修复、自助服务数据、实验基础设施和客户接触点技术。通过全球验证之后，我们认为这些是值得投资的重要共享能力，这些能力能够帮助构建数字化组织。
本文的重点是我们归类为交付基础架构的平台功能，包括云托管和 DevOps 工具，尽管这些定义特征同样适用于其他平台功能。
非平台
几年前，我受聘为澳大利亚一家大型金融服务机构提供咨询。我们称他们为 BigCo。到达现场后，我的第一个目标是了解应用基础架构、托管和运维领域的情况。为了真正了解挑战所在，我们决定通过工作系统跟踪一个真正的变更，看看这里的行为方式。
尽管 BigCo 在云计算和自动化方面进行了大量投资，但在基础设施和运维领域仍保留了传统的团队安排。团队按照技术能力划分。我们跟踪了几个典型的变更，每个变更都涉及多个团队。例如由“中间件”负责更改应用服务器配置。但是，中间件团队无法访问底层操作系统配置，这属于“中段”团队的职责。数据库变更必须由 DBA 团队进行。网络变更必须通过网络团队完成。托管服务提供商进行负载均衡的变更，而防火墙的变更则是另一家提供商的任务。此外，还有一个独立的自动化团队，他们拥有一些自动化能力—主要限于协调。当然，还有独立的企业监控、安全、变更和发布管理团队。
图 1：将高度专业化的基础设施团队和运维团队分开
BigCo 的每个团队都有自己的管理结构和工作方式。每个团队都在自己的技术领域实现高效管理、集中专业化、无差异外包能力、实施管理和降低成本。然而，在 BigCo 公司，为客户提供端到端功能的效率却无人负责。
涉及基础设施的小改动需要花费数周到数月不等的时间，这对客户响应速度造成了巨大影响。影响很大，但这还不是全部。我们注意到，当变革艰难而缓慢时，变革过程中的任何失败都会导致进一步的延误。因此工程师和管理人员会尽可能减少变更次数，只对应用程序和基础设施进行绝对必要的变更。
图 2：应用程序交付团队所需的更改需要数周或数月时间
很明显，这会导致应用程序和基础架构的内部质量逐渐下降——环境和配置设置中随处可见许多不一致的地方。团队已经停止了能够保持或提高质量和一致性的微小改进和重构。这种情况在实践中会自我强化：由于质量会影响可预测性，从而增加变更风险，因此团队会变得更加谨慎，改进工作也会变得更加困难。
因此，总而言之：在 BigCo，基础设施和托管事务的处理缓慢而又困难。
Backlog 耦合的后果
数字化渠道一直是敏捷软件交付的法宝，小型自主团队与业务领导者密切合作，确定客户需求并构建满足这些需求的功能。然而，数字产品团队的速度越快、反应越灵敏，所受到的外部限制就越大。
数字团队受到几个方面的限制：核心系统进化缓慢、无法获取高质量数据和分析结果，基础设施和运维难于共享。
我称其为 Backlog 耦合，Backlog 是敏捷交付团队经常使用的一种规划工具。
图 3：当变更与多个团队的工作队列存在依赖关系时，就会发生 Backlog 耦合的情况
这概念很简单，一个工作队列中的的大量项目需要另一个团队提出相应的 Backlog 项目，那么生产率和响应速度就会大打折扣。Backlog 项目会在整个组织内串联起来，每个项目都根据不同的系统确定优先级。在看板上给任务贴上大红“阻塞”标签，利益相关者生气，共享服务提供商会尽力根据反馈音量做出反应。
Backlog 耦合能糟糕到什么程度？在澳大利亚的一家电信公司，我的同事对通过交付中心的数百件工作或任务进行了研究。有些任务可以由一个团队完成，无需依赖其他团队，特别是无需安排其他团队成员的工作。而那些需要等待其他团队完成的任务，耗时则要慢 10-12 倍。因此，依赖性确实会产生重大影响。
这种情况对我们造成了多种伤害：它损害了纯粹的吞吐量和对客户需求的响应速度，促使我们进行更长期的规划，从而有效地管理依赖关系。它还会损害团队自身对结果的责任感，据我观察，这对许多团队来说都是动力杀手。团队趋向于推卸责任，不再寻求自身的持续改进。
在一个超负荷团队中，为众多吵闹的内部客户提供服务，也没有什么乐趣可言。
最近的“扩展敏捷（Scaling Agile）” 试图通过一种方式来解决这个问题-引入规划仪式，试图在多个团队之间协调优先事项。很显然这种方式能够提高一致性但是降低了整体的自主性、反应能力和应对变化的能力。这不可能是唯一的方法。
因此，能够减少 Backlog 耦合的平台是好的。平台提供的服务必须不需要工单和分配工作。自助服务是优秀平台的一个关键定义特征。
平台应该团队提供自助式访问。具体来说，用户能够自助在平台上自助完成供给、配置、管理和运维。
半吊子私有云
BigCo 意识到自助服务的必要性，但是这个大型基础架构和运维组织中，传统基础架构和思维方式根深蒂固，要实现这一目标谈何容易。公司已经在集中自动化工具方面进行了投资，因此首先要做的是为应用交付团队创建自助服务能力，以便自助配置基础设施。
BigCo 构建了一个自助工具，允许交付团队根据非常固定的模板申购计算实例。配置的虚拟机实例在配置上是固定的，并被安全锁定，以确保中端团队对机群的控制。要实例进行一些有用的操作，例如安装软件包、连接网络、附加存储、配置负载均衡、配置监控工具或其他任何操作，交付团队都需要发出工单。
图 4：BigCo 在不改变应用程序和基础架构运行方式的基础上，构建了一个基本的自助服务应用程序接口。结果并没有明显改变交付速度。
你可以将这种情况归咎于首次迭代，这的确是个问题，但是这中间也有明显的取向问题。BigCo 的基础设施和运维团队还没有准备好打破自己的组织孤岛，将重要责任（以及访问权）转移给交付团队。而且，即使意图是好的，但要逐步将应用程序接口构建到所需的丰富程度，这个过程需要的巨大工作量也是难于承受的。
我们将这种方法称为“肤浅的私有云”——将现有的虚拟化平台重新贴上标签，供交付团队以非常受限的方式使用，并没有减少集中控制的真正意图。
与此同时，BigCo 公司的交付团队也在努力，他们解锁了在生产系统中直接使用 AWS 的能力。一旦有了这样的先例，交付团队纷纷加入了 AWS 的用户行列。
对于交付团队的直接消费而言，AWS 是一个极具吸引力的平台：它完全是自助式的，而且责任分工明确。谁构建、谁运行变成了口头禅。AWS 建设和运营平台以及 API，并确保其高度可用；应用程序交付团队则构建、配置并运行平台上的应用程序。
故事到此为止？
自主加快上市速度，提高创新能力
我遇到的大多数组织都有一个“为复用而构建”的默认思维：在规避风险和降低成本的双重驱动下的中心化趋势。
图 5：大多数组织默认通过集中方式来提高成本效益
在过去的几年里，我有幸成为澳大利亚（和全球）一家大型技术公司的技术领导团队的一员，这家公司拥有庞大的在线业务，我们姑且称其为 WebBiz。该公司拥有数百名工程师，规模庞大，面临着许多与 BigCo 相同的挑战，在基础设施、应用程序和数据方面都有不小的遗留问题，但 WebBiz 又小到足以见证快速的变化和改进。
我在 WebBiz 工作期间，我们开始了一项长达数年的迁移工作，原本在租赁数据中心的虚拟化平台上部署的大多数应用程序，被迁移到 AWS 这个新的默认部署目标。我们还将应用程序和（大部分）基础设施的构建和运行责任转移给了产品团队，这是我所见过的从传统中央运维到开发运维的最彻底转变。我相信，以“谁构建谁运行”的思维模式来创建一个小型组织其实并不难，但实现转型需要勇气和持续的愿景。WebBiz 在这方面做得很好。
作为迁移的一部分，WebBiz 的产品团队能够完全自主地配置和运行堆栈的每个部分。这种方法被命名为“团队管理基础设施”—虽然在早期建立了一些默认设置，但每个团队都可以在几乎没有中央授权的情况下，自行决定堆栈的每个部分。
WebBiz 成功让组织更倾向于技术多样化和发明。这提高了员工的参与度，让工程师在技术堆栈中获得更深层次的经验，推动了发明创造，迅速确立了对部署内容（应用和业务）的响应水平，并消除了团队的大部分依赖关系。同时，这也吸引了那些对自己的工作负责、对自主性反应良好、对解决棘手的业务和技术问题感兴趣的工程师到 WebBiz 工作。
技术多样化增加阻力
然而，尽管好处多多，转向完全自主还是要付出一定代价的。通过采用 AWS 作为平台，WebBiz 消除了与集中式基础设施团队的 Backlog 耦合。然而，WebBiz 的每个团队现在都不得不围绕构建和运营基础设施的各个方面做出一系列决策。
图 6：云原生全景图
上图是最新版本的“全景图”：这里包含一些常见的开源产品和产品，并按构建云原生架构时所关注的领域进行分组。这是一张拥挤的地图，而且只是最成熟的产品。对于上述每个领域以及更多领域，团队都必须评估各种选项，选择适合其需求的产品，然后学习如何集成和操作该产品。
除了重复基础设施的维护费用外，每个团队还需要不断研究和评估其基础设施选择。
WebBiz 现在正开始建立一个定义更加清晰的交付基础架构平台—一套令人信服的默认设置，产品团队可以使用这些默认设置来减少阻力，提高工作效率。
但是，他们是否有可能失去自主权带来的好处？
平台即产品
在自主多样化和中心化管理之间找到适当的平衡点，是个难度颇高、且不易预测的工作。成功找到这种平衡的一个关键因素是，平台必须令人信服，不能仅仅依靠授权。现有的共享基础设施功能处于垄断地位，交付团队没有可行的替代方案。竞争是推动产品思维的必要因素，可确保每个平台功能都能增加价值，而不是造成限制和耦合。
成功找到这种平衡的关键因素是，平台的使用必须具有吸引力，怎样才有吸引力？
- 该平台可为绝大多数使用场景提供自助服务。
- 平台是可组合的，包含可独立使用的离散服务。
- 平台不会强迫交付团队采用不灵活的工作方式。
- 平台上手快速、成本低廉，易于上手（如快速入门指南、文档、代码示例等）
- 平台拥有丰富的内部用户社区，便于共享
- 平台是安全的，合规的
- 平台是最新的
最终，当使用平台能力比构建和维护自己的东西更容易时，交付基础架构平台就会引人注目。Netflix 将其集中式工具称为“铺装路”-团队有权不使用这些工具，但要负责维护自己的替代工具的所有成本。
平台也不应仅仅是软件和应用程序接口，它还包括文档、咨询、支持和宣传、模板和指南。
等等——这不是“DevOps 团队”吗？ 做得不好？可能是的。
（我还没准备好在 DevOps 上认输：所以，如果你不确定，如果你有一个团队叫’DevOps’，那么这个词的意思并不是你想的那样）。
您可以选择组建一个团队来构建和运营交付基础架构平台—我认为在大多数情况下，这将是最佳的入门方式。如果是这样，你就应该非常清楚平台团队与其客户（为了清晰起见，我称之为应用团队）的职责范围。
应用团队负责构建、部署、监控和调用他们在平台上提供和部署的应用组件和应用基础架构。平台团队负责构建、部署、监控平台组件和底层平台基础设施，并随时待命。
理想情况下，平台团队甚至不知道平台上运行着哪些应用程序，他们只负责平台服务本身的可用性。
这样，应用团队和平台团队都有责任构建和运行自己的产品。这当然还是“谁构建，谁运行”。
如何开始？
成功建立交付平台有一些先决条件。首先，你可能已经开始摆脱以“项目”作为技术交付的主要资金和人员机制。平台是一种产品，需要一个长期稳定的产品团队来负责构建和运行。
其次，必须愿意将应用程序的部分或全部运维责任转移到应用程序团队，而不是集中化的运维和支持。平台提供的工具和服务可以让应用团队对他们所构建的内容负责，但如果集中提供支持，就无法做到这一点。
第三，你必须在实施的严格一致性与交给自主应用团队的自由和责任之间进行权衡。
还有些问题。
平台不仅仅是可以安装的基础设施、工具和应用程序接口。要想取得成效，必须回答交付团队的问题：如何快速采用新功能？如何独立做出哪些选择而不是使用合理的默认设置？以及您将如何持续维护这些功能。这将需要一些内部咨询技能、培训和宣传。
您不知道自己需要什么样的平台功能，因此应根据真正的成熟需求从小规模开始。从应用团队中收集已经验证的解决方案，并尝试与将使用这些解决方案的团队合资创建和测试功能。
请务必小心，在有限的虚拟主机和锁定的集中管理工具上贴个平台标签，并不是平台。
