您的平台不是孤岛：拥抱生态系统中的演进
Rachael Wonnacott：我叫 Rachael Wonnacott，是富达国际（Fidelity International）Kubernetes 平台的技术产品负责人。作为容器平台的副总监，我专注于开发者体验、应用生命周期和供应链安全的所有事务。
回想过去，我曾有 10 年时间作为一名亲力亲为的平台工程师。尽管“平台工程”这个术语在近 3 到 5 年才真正流行起来，但我自 2013 年以来就一直与平台打交道。这让我在职业生涯中获得了一个独特的视角，来理解我们所采用的所有不同方法论（特别是 DevOps）最终如何引领我们走向今天所知的平台工程。
在这些会议上讨论平台工程时，我们常常谈论如何“兜售”开发者体验。虽然我不会争辩说这不重要，但本次演讲要论证的是，它不是最终目标，而是一个杠杆。事实上，平台应该做的是交付业务价值。
凭借我在企业内领导战略性平台计划的第一手经验，我想分享平台设计只有在考虑到以下三点时才能成功：组织成熟度、组织结构和您的文化。本演讲将探讨如何在技术经验、开发者生产力和可衡量的业务影响之间权衡取舍，并认识到“一刀切”的情况很少见。
一点背景信息：富达国际是一家国际资产管理公司，成立于 1969 年，业务遍及 27 个国家，为个人和机构管理着超过 9500 亿英镑的资金。
今天的演讲，我想让大家了解为什么开发者体验很重要，但并非一切。如何根据对业务利益相关者的价值来规划平台投资。如何设计与更广泛的软件交付生命周期的集成，以及将您的平台视为孤立产品的潜在风险。在本次演讲中，我将引导您了解如何为您的特定组织构建平台。
您的组织是一个生态系统
我要在演讲一开始就给出结论：您的平台不是一个孤岛，但您的组织是一个生态系统。对于那些学习过生物学的人来说，您可能熟悉生态系统的以下定义：一组生物有机体在其物理环境中的相互作用。在组织中，这可以类比为您的人员、您的各个团队以及它们所处的组织结构。对我而言，我很喜欢生物学这个主题，因为组织往往是有机增长的，随着时间的推移，您的团队互动将经历演变。
那么问题就变成了：它们能生存下来吗？在初创公司中，有些人可能在初创公司工作，您可能实际上只是一个团队，每个人都要身兼数职。随着公司的发展，您可能没有明确的团队边界，甚至可能团队数量超过一个。在较大的初创公司或成长期公司，您可能会开始看到团队自然涌现，但您可能会发现这些团队倾向于按技术划分。我并不是说这是坏事，但如果您没有对组织设计给予有意的关注，这些日后最终会变成孤岛。大型组织，仅凭其规模，就拥有更多可能的团队和结构组合，因此以后想要有意识地进行组织设计将会困难得多。
小型组织与大型组织面临的挑战截然不同，而对平台的需求通常表明您拥有多个团队，因此在初创公司中您可能并不真正需要一个平台，特别是如果您有一位“十项全能”的全栈开发人员身兼数职。本次演讲的重点是企业。我想非常明确这一点。简单来说，当我提到“企业”时，我真正的意思是一个拥有许多团队、同时也可能有许多年历史的大型组织。拥有多年历史意味着您有很长一段以往的工作方式和实践历史，因此您的生态系统不再仅仅是您的人员和组织结构，还包括您的流程和成熟度。
早于云计算出现的组织，其结构往往深受其本地基础设施的影响，这是有道理的。我们公司成立于 1969 年，当时我们的大部分（如果不是全部）基础设施都是内部管理的，需要一个高度专业化的技能团队来操作。那时，您可以是一名专业的网络工程师，但随着我们转向云部署，仅仅懂网络工程已经不够了（尽管它仍是一项基本技能）。技术的功能、人员的技能组合以及当时接受的工作实践，共同界定了应用团队和基础设施团队之间更紧密或更严格的关系。正如许多人可能记得的那样（或许并不怀念），应用团队会编写代码，将其打包成一份小礼物，然后“扔过墙去”。他们希望能有好结果。
云世界中的遗留结构
在云世界中，这些原本清晰的技术边界，或者说可能是堆栈的不同层级，实际上已经被融合在一起，变得模糊了。就像我前面说的，在以前的世界里，您可以只专注于一项技能，也许是网络工程（我通常提到这个是因为我职业生涯的起点就是网络工程）。而在云世界中，我们需要掌握多项技能。这也意味着，即使组织的某些部分已经转向 DevOps，或者更好的是转向产品模型，可能仍然存在模仿原有技术划分的遗留组织结构。这两者现在会变得不协调，最终会创造多个摩擦点。
在我看来，可能也公平地说，那些较老的组织或企业将需要经历混合模式，才能达到云原生的理想境界（如果这仍然是目标的话）。我们常常看到这些技术孤岛，但由于康威定律，这会影响到软件和应用程序的设计。应用程序对本地环境的依赖会增加接口数量，并导致我们戏称为“应用蔓延”和过度分布式架构的情况。团队越多，您可能需要沟通的人员就越多，不幸的是，这也意味着工作实践的数量会增加，可能更难达成任何共识。如果您在大型组织工作，我相信您会有共鸣。
企业内部的现实
那么，为什么在大型企业中构建平台？我认为很简单：我们试图减少摩擦并放大流动。我们希望更快地交付、减少重复、并穿透这种复杂性。我们希望我们的工程师在解决业务问题，而不是在样板文件上浪费时间或等待其他团队。我相信他们也有同感。我们希望以一致的方式做到这一点，这样每个团队就不会一次又一次地重复发明同一个轮子。平台可以帮助我们扩展最佳实践、降低成本，并创建更顺畅、更可预测的交付流水线。
可以合理地说，虽然 DevOps 对单个团队来说效果非常好，特别是当您能够自己管理所有依赖项而不必与其他人沟通时。我工作的第一个团队就是这样。效率非常高，但走得不够远。在某个时刻，您将需要与另一个团队沟通，这意味着您需要进入您的生态系统。最终，您的组织可能希望解决我之前阐述的重复、复杂性和成本挑战。同样，您需要考虑您的平台位于何处以及它将如何在您的企业内运作。也就是说，您的平台不是一个孤岛。
容器平台案例研究
我已经为平台工程以及开发者体验在其中的位置设定了场景。现在，我想根据过去两年在富达国际与我所负责的团队一起获得的所有经验，为您提供一个容器平台的案例研究。
曾经有过公有云之前的时代。如果您记得云基础设施的原始定义就是“别人的电脑”，那么富达在当时是相当前沿的。我们在 2012、2013 年就开始做这件事了。我们在物理服务器上托管私有云，就像电视剧《IT 狂人》里一样（因此用了那张图），使用的是开源技术 Cloud Foundry。还有一个小趣闻：当我从物理学转向软件工程时，我那爱欺负人的导师开始叫我“Jen”（如果您知道这部剧，就知道这不是恭维）。平台工程已经变得非常流行，但正如我已经说过的，它并不是一个全新的概念。
平台即服务（PaaS）由 Pivotal 公司推广，他们与 Pivotal Cloud Foundry 所做的出色工作。当我们开始涉足云时，我们实际上使用的就是那个商业产品。我们最初使用商业产品，然后最终迁移到一个完全开源的平台，仍然在物理服务器上。这个平台确实成功地减少了认知负荷，并且很受我们开发人员的欢迎。我们什么都想要：公有云承诺的成本节省、消费 IaaS 带来的基础设施责任减少。我们真的希望每个团队都采用 DevOps 模式并作为产品团队运作。这要求不算太高。
我们如何尝试实现这一点？我们通过自动配置 AWS 云账户来实现，这些账户本质上为每个团队（每个团队是一个应用工作负载团队）创建了迷你数据中心。我们实施了共享责任模型，这个概念是从 AWS 本身借鉴的。这种关系定义了工作负载团队和平台团队之间的交互，平台团队负责设计、部署和支持所有核心基础设施服务，比如路由、DNS、通过代理的互联网出口、与本地环境的连接等等那些无聊的网络工作。工作负载团队负责他们部署的任何额外资源、他们的应用程序代码和配置、他们的数据，但最关键的是，他们的应用程序的可用性和性能。
这对一些团队来说确实很有效，现在仍然很有效。但同样，只对一些团队有效。我之前提到，大规模组织很可能存在成熟度的交叉分布，富达当然也不例外。我们发现，确实没有“一刀切”的解决方案。
新云运营模式类比
我们提出了这个新的云运营模式。同样，这张幻灯片直接来自一次架构评审委员会会议。我只想说明我们与“Kubernetes 酒店”和“公有云房子”进行的对话。我们在这里认识到存在一个岔路口，开发人员应该有选择：他们想去 Kubernetes 酒店还是想去房子？我们使用这个类比的原因是，这就像现实中去酒店一样。服务是提供给您的。您不能选择床单的颜色，也不一定能选择餐厅的菜单，但您能获得非常高质量的服务并享受这种体验。相比之下，当您购买房子时，您会为拥有房子感到自豪并享受装修的过程。也许您的墙是紫色的。如果您出生在 80 年代，也许您的沙发有毛皮。我不做评判。如果遇到风暴，屋顶受损，绝对需要您自己负责修复。没人会替您做。
我们当时是说：您是想在基础设施方面几乎一切都被代劳（这最终意味着更少的创造性和指定的服务），但没有管理开销？还是想要公有云的完全创造性和自主权，但需要承担确保这些工作负载和后端基础设施的责任？
当我反思在这个职位上 18 个月的经历时，我开始以一种可能被认为比技术更哲学的方式来思考。作为一名产品负责人，我认识到您的客户永远不会真正满意。当我在会议上演讲后，许多人问我：我们是否过早发布了最小可行产品？我的回答是：不。定义“最小可行产品”中的“最小”部分始终是您旅程中最困难的部分。我从中得到的经验是，比定义更重要的是清晰地阐述它，并确保您和您的客户群之间的期望明确。
您越是想提前预测更多功能，您就越有可能构建客户实际上不想要的东西。您的 MVP 越精简，您的客户就越有可能将其视为汽车旅馆，而不是酒店。这就是我当时的情况。来自不满意的早期采用者的反馈最终推动了最大的业务成功。或者更具体地说，如何构建最佳的开发者体验。如果您想成为一名产品负责人，请准备好不被喜欢。我可不是在交朋友。学到的教训是：对您的 MVP 中包含哪些功能要非常非常清楚。虽然您可能向高管和高级管理层兜售酒店或其他愿景，但要非常非常清楚，版本一可能离那还很远。
应用生命周期
让我们从更技术的细节来看待这一点。Kubernetes 承载容器。这是我关注的应用生命周期的一小部分。我承认这不是完整的软件开发生命周期。为什么我们的 MVP 让用户如此失望？虽然我们承诺在公有云中托管 Kubernetes，但我的绝大多数客户实际上来自那个本地 Cloud Foundry 平台。期望很大程度上是由 Cloud Foundry 决定的。Cloud Foundry 实际上做了很多事：处理构建镜像、扫描和存储镜像、部署镜像和运行镜像。Kubernetes 提供了什么？突然看起来不那么好了。特别是当高级管理层认为 Cloud Foundry 的容器编排和 Kubernetes 的容器编排是一回事时，我现在向开发人员提供的服务实际上相当令人失望。毫不奇怪，MVP 没有达到他们的期望，尽管我觉得我已经涵盖了所有核心工程需求。
如果我们把应用生命周期看作是提交、测试、构建、存储、部署和运行，考虑到我作为产品负责人的角色，我真正需要关心的是运行镜像。我只负责 Kubernetes。我不负责其他任何事情。这就是将我的平台视为一个孤岛。我在演讲开头说过，您不应该这样做。回到我演讲的标题，我需要开始与参与此应用早期部分的所有其他团队沟通，以弄清楚我们如何能一起完成这件事。
从采用的角度来看，这很合乎逻辑，因为如果没有人登上平台，我的平台扩展得再漂亮也没用。我们真的需要关注应用生命周期的“左侧”。首先，我们是在什么样的生态系统中构建的？由于富达现有的组织结构，负责“运行镜像”左侧许多工具的实际所有权和运营属于不同的团队。这些工具中的每一个都具有非常不同的自助服务和运维管理水平。鉴于我们的运营模式规定人们希望从 Kubernetes 获得酒店般的体验，他们自然也希望在左侧的一切获得酒店般的体验，这并不奇怪。我们当时尚未实现这一点。这不一定在我的影响范围内。我需要去公司里交一些朋友。正如我已经说过的，我并没有交到什么朋友。由于不同的工作方法、现有的参与流程以及工具自助服务水平的差异，开发者体验确实有待提高。
最终，开发人员希望在应用生命周期中获得顺畅一致的体验，一条黄金路径。我喜欢 Kasper 的这个说法：软件开发生命周期中的任何流程，用户都可以以最小的认知负荷遵循（不是没有），这推动了标准化。要做到这一点，我们需要沿着整个生命周期进行设计。想想我已经在屏幕上展示的那些步骤。将每个阶段连接在一起。为此，您可以采用动态配置生成方法，甚至使用简单的 GitOps。
如何将其应用到您的企业
我在谈论富达，但您如何将其应用到您的企业呢？在屏幕上，您可以看到我标记了多个团队。我特意没有给它们贴上具体是哪个团队的标签，因为这对我论证的观点有些多余，而且每个组织的具体情况会略有不同。这些团队可能是安全、工具、IaaS 提供商，或者是您组织内的任何其他团队。绘制出您的开发人员作为应用生命周期一部分需要经历的所有步骤，然后映射拥有这些服务和技术的不同团队。如果可能，减少团队之间的步骤和交接。这张图展示了我们大约九个月前在 PlatformCon 上展示相同幻灯片时的中间状态。我们现在有三个团队而不是四个，所以我们略微减少了人数。
关键的是，每个团队之间只有一次交接。您需要了解不同的交互期望。所涉及的这些团队可能期待不同的工作方式。这既可以是联系人员的流程，也可以是技术本身与系统交互的方式。您需要将人们聚集在一起。请不要低估这一点。我绝对低估了。这需要强有力的领导。需要耐心。需要同理心，以及愿意构建一个最适合您的应用开发者的生命周期，而不是为了您玩技术的欲望、构建您的简历或您的兴趣。
如果您身处一个成熟度交叉分布的企业，您可能正在构建一些您认为在技术上并不完全优雅的东西，但也许它正在驱动最大的业务价值。为了更成功地做到这一点，您能“兜售”开发者体验吗？看看在哪些地方可以标准化人际互动。我仍然认为，最大的挑战通常是标准化系统之间的接口，当您使用第三方时，这可能并不总是可行。相反，回到我之前提出的观点，考虑是否可以让它成为单一入口点，至少可以将一些混乱从您的开发人员那里抽象出来。提醒一下，考虑可以在哪里实施声明式配置、动态配置管理，或者甚至是 GitOps。
平台真正有价值的是什么？
是什么让一个平台真正有价值？实际上，它只在于开发者体验、您的业务成果和您的组织适应性这三者的交汇处。当我说业务成果时，我指的是什么呢？比如更快的上市时间、交付新功能的更低边际成本、减少的协调开销和提高的团队自主性、改进的风险状况以及更少的交付障碍。
最后，可能是 CEO 最关心的一点：超越竞争对手进行创新或执行的能力，因为归根结底，我们是一家企业，我们想要生存。当我们谈论开发者体验时，我们指的是什么呢？比如流行的现代工具、最少的文书工作（再次强调）、减少的协调开销和提高的团队自主性、由平台为您处理的安全与合规性、开箱即用的可观测性，以及入职时即准备好的功能。这个列表可以更长，但我之所以特别指出这些，是因为这是我们个人的开发人员最常要求的。最后一点“入职时即准备好的功能”，就是 MVP 期望差距所在的地方。
工程成熟度 —— 房间里的大象
如果那么容易，为什么我还要给你们做这个演讲？我认为我们需要解决房间里的一只小大象：工程成熟度。因为如果您在工程圈和领导圈都待过，您会知道这里存在着一种张力。开发人员依赖自主性，乐于构建。工程不仅仅是一份工作，它是一种身份认同，这也是我过去 10 年所持有的身份。我们想要赋能我们的工具，而不是拖慢我们的流程。企业不仅仅看重自由，它还看重一致性。可预测性、合规性和成本控制不仅仅是可有可无，当您在受监管的环境中运营时，尤其是在大规模运营时，它们是必不可少的。在这些真理之间，是您谦逊的平台团队，试图调和自由与一致性、工艺与合规性、自主性与问责制。
这真的很难。这正是为什么开发者体验不能成为最终目标，因为纯粹为 DevEx 优化而不考虑其周围的系统，将导致您达到局部最优解。您会让开发人员满意，直到事情不再能够扩展、不再安全或不再支持业务为止。平台实际上不仅仅是一个产品，它是一个更大系统内的系统。要取得成功，它必须尊重这种张力的双方。这正是为什么平台工程不能仅仅是关于开发者体验，它还必须是关于平衡体验与成果。不仅为“好”而设计，更要为能为您的生态系统带来实际业务价值而设计。
关键要点
平台工程不仅仅是构建黄金路径或内部产品。它实际上是塑造工程发生的环境。抽象复杂性，不是为了优雅，而是为了让事情能在规模上变得可能。这通常需要比技术更多的对文化和运营方式的关注。当我们孤立地设计平台，或将其视为一个孤岛，脱离交付流水线、团队结构或业务目标时，我们创造的是没人使用的精美工具，或者更糟，是拖慢我们速度的工具。当我们把我们的平台视为生态系统的一部分，视为与我们组织的契约，视为业务目标的倍增器时，它才成为战略优势。不，您的平台不是一个孤岛，它是一座桥梁，连接工艺与合规、交付与方向、自主性与一致性。只有当我们完全拥抱整个背景时，我们才能将我们的平台转变为真正可持续价值的引擎。