平台工程不能强制推行，因为你得不到必要的反馈来鼓励进一步采用。要以平台即产品的思维。

译自 Platform Engineering Demands a Product Mindset 。

伦敦 - 如果你建立了，他们不会来。成功的平台工程师一直在敲打这一鼓点。不那么成功的平台工程师仍然认为他们知道最好的方式 - 毕竟，他们是工程师，所以他们肯定比开发者自己更了解开发者想要什么。

平台工程 - 这一专门致力于减少软件开发生命周期中的摩擦和烦恼的学科，以改善开发者体验 - 需要以平台即产品的思维方式。这意味着你的内部开发者平台不仅仅是在开发者的“思考中”构建，而是在整个过程中都有演示、原型和持续反馈。基本上，你的开发者变成你的客户。你会想方设法确保你正在构建他们想要的，因为否则他们不会使用它，你就会回到起点，除了浪费每个人的时间、金钱和信任。

在 CIVO Navigate 上，Syntasso 的首席工程师 Abigail Bangser 反映了真正采用平台即产品思维方式意味着什么，以及在多年平台工程角色中她在哪些方面做得不够好。

在数学中，拓扑结构即使被拉伸和挤压，也能保持牢固，即使在持续的压力和变化下也是如此。认识到软件开发团队可以以不同的方式布局，在压力下可以更可持续和灵活地适应变化，Matthew Skelton 和 Manuel Pais 创造了一系列他们称之为团队拓扑的原则和模式。

“团队的形状在整个组织中看起来有点不同，他们的互动方式也有点不同，所以他们将这些年来我们看到的模式编纂成码，”Bangser 解释道。

团队的形状可能各不相同，但大多数组织都有共同的团队类型。团队拓扑结构所说的流式组团队，通常称为应用开发团队，专注于为终端用户提供价值的产品和功能。

“在理想的世界里，100% 的工程师都会从事这件事，因为这是客户支付的，”她说。 “但现实情况是，你不能让 100% 的人从事面向客户的功能，因为他们需要依赖的基础要求有很多。” 随着云原生图景不断复杂化，你的依赖项也有依赖项，这就是为什么你要有其他团队来支持这些价值驱动的应用团队。

大多数组织都必须建立专业化团队，如测试、敏捷教练或数据库。还有一些复杂的子系统团队，在内部功能如 AI 或安全方面具有专业化。最后，有平台团队，它不断壮大，为大多数如果不是所有的应用团队提供基础服务，以交付价值。

在 DevOps 和持续交付管道的时代，特性团队越来越依赖这些支持的跨职能团队创建的工具，以便将自己的代码投产。

这三个团队努力减少流式组团队的认知负荷，其中平台团队通常将使能和复杂子系统团队的工作抽象和合并成更易于消费的工作流程和工具链。

团队拓扑结构还强调平台团队与其应用团队客户交互的三种方式:

1. 协作 - 是人与人之间的，比如请求特定的人做一些事情，像是提供一个容器。当你是初创公司，每个人都坐在一起时，这种互动模式就够好了。无论公司大小如何，这对头脑风暴和测试新想法也很有好处。然而，协作无法扩展。它也可能是一个主要的摩擦源，通常会减慢部署并打断流状态。
2. 促进 - 这遵循一对多的人际互动模式，其中文档、培训和实践社区可以扩展信息和知识。这在人员规模上是可扩展的。而开发人员出了名地推迟编写文档，而且通常没有时间进行额外培训。
3. X 即服务 - 从人与人的互动转变为开发人员通过 API 与内部平台进行交互。当考虑到开发团队客户时进行，这可以具有无限的可扩展性。

“作为一个拓扑结构，平台团队通常在不同阶段都运作这三种模式，” Bangser 说。这三种方式都很重要，在平台工程的世界中，并非一切都应该自动化，以免与客户疏远。

“我认为平台工程有很大的潜力，但我不认为我们总是利用这种潜力。” 最终， Bangser 认为，如果平台团队不将自己视为产品团队，平台工程计划最终往往会失败。

Bangser 反思了她在十几家公司建立平台的八年时间。在一家扩张的公司，通常会有几个应用团队致力于交付业务价值，这些团队由其他团队提供支持，如客户支持、财务和营销。或许更不寻常的是，每个不同的功能交付团队都有一个不同的亚马逊网络服务(AWS)账户。

“当我们还是一家小公司时，我们想让人们保持自治权并快速轻松地行动，但我们也想确保我们不会存在权限问题和相互践踏。让人们启动和运行的最快最简单的方式就是账户，” Bangser 说。随着团队的增长和分割，新的 AWS 账户被开设。

平台团队使用 Jira 提出新 AWS 账户的请求，然后平台团队会查看 Confluence 中的运行手册，然后再将适当配置的账户返回给功能团队。这种影子 IT 流程一直“足够好”，直到财务部门开始询问为什么它收到费用报告和要求报销 AWS 收费的个人信用卡。我们都知道云费用会如何积累。

Bangser 和她的团队深入研究了 Jira 数据兔子洞。正如她在 Syntasso 的同事 Paula Kennedy 之前对 The New Stack 所说，Jira 是平台团队发现重复工作、广泛疼痛和漫长瓶颈的绝佳第一步。

他们意识到，这不仅是不理想的财务跟踪，而且花费两周时间让这些团队使用新的 AWS 账户启动和运行。

“因此，我们检查了我们的流程，并意识到导致问题的就是这个手动运行手册，” Bangser 说。 “不仅仅是手动的。对我们来说很疲惫，因为人们不确定它。这也很麻烦，需要大量时间，所以人们避免使用它，”从而增加了平台团队的待办事项积压。

于是，他们自动化了运行手册，这最初似乎限制了意外开支，使财务部门感到满意。它为平台团队消除了一项令人沮丧、重复和手动的任务，这意味着更少的苦差事和更低的错误风险。

“现在，当一条 JIRA 工单进入时，我们点击一个按钮，运行一个脚本，就可以离开了，” Bangser 说。 “作为一个单独的团队，这大大减少了我们的上市时间。”

三个月后，财务部门重新审视了这个问题，意识到他们的问题并没有真正为他们解决。他们仍在收到意外的财务报告。

“问题是，我们解决了一个问题，而不是问题本身，”她说。 “我们需要从客户的角度来看这个问题，而不是从技术实施的角度 - 如何加快速度? - 我们需要考虑的是，试图创建账户的客户需要什么，以及我们作为一个产品团队该如何提供。”

他们正确地认为这两周的滞后时间是一个问题。 但他们将解决方案的重点放在平台工程师的经历上，而不是软件开发人员的动机上。

平台团队遵循要做的工作理论(Jobs-to-be-Done Theory)的发现之旅，这是定义、分类、捕获和组织客户需求的结果驱动创新框架。记住，对于平台团队来说，你的同事就是你的客户。

“要做的工作理论上说：无论数据对人们多大的意义，如果你不了解是什么驱动他们，也不知道他们需要通过你的产品来完成什么，那么你将不足以解决问题。” Bangser 解释道。

这种 Tony Ulwick 在本世纪之交开发的策略认为人口统计信息不是你最重要的潜在客户信息。重要的是回答：他们试图做什么工作?

Bangser 解释了工作的四个特征:

1. 与解决方案无关 - 有许多方法可以完成该工作。
2. 你需要完成工作 - 必须有所进展。
3. 工作随时间保持稳定 - 你可以创新以更好地完成工作，而不是为了创新。
4. 没有需求仅仅是功能性的 - 也有社交和情感方面。的确，平台工程总是一个社会技术努力。

她使用日常生活示例解释了工作的不同之处:

• 一次性或意外的 - 骨折。
• 定期、重复或预期的 - 税季。
• 小的 - 做饭。
• 大的 - 搬家。

一个应用团队将(希望)采用内部开发者平台来完成运维工作。

“当涉及到内部平台时，我们需要了解客户 - 这些应用程序开发人员 - 需要实现的工作以及......他们希望如何构建和操作他们的软件，”Bangser 说。团队需要问：你为什么要创建一个 AWS 账户？

就像所有良好的客户关系一样，这需要进行对话，每天需要花费 15 分钟时间。

“你正在建立关系。表明你关心他们试图做什么，并且实际上关心他们试图做什么，因为他们是你的客户，对吧?你不想告诉他们他们是对是错。你不想与他们解决问题。你只想听听他们的想法。” —— Abigail Bangser，Syntasso

他们意识到，不同的应用团队具有不同的工作要完成，这导致他们打开 AWS 账户。他们可以在扩展超过两个披萨大小时分割团队。 一些项目想更快进入生产。有些想复制一个项目在新国家/地区推出。其他人想在所有产品中支持更多的身份验证选项。

Bangser 和她的团队意识到 AWS 账户是达到目的的一种手段：“他们实际上不知道为什么需要一个账户，当他们实际上只需要一个 S3(AWS 云计算存储)中的文档源，或者他们实际上只需要访问一台服务器就足够了。”

他们还意识到，团队仍在绕过平台引导的云访问路径，因为 Jira 会让他们感到害怕，而复制旧票证、使用个人信用卡并申请报销或者手动联系平台团队的朋友以帮助他们完成工作要容易得多。

“他们需要服务，而不是账户。”她解释说，这些应用程序开发人员“不是云专家。他们希望这个流程更容易接近和使用他们的用例。”

平台团队开始头脑风暴解决方案。

“我们对平台的发展方向有很多宏伟的愿景和想法，”Bangser 说，“但财务部门有时间表，我们必须尽快找到解决方案。”

他们确定了 8 种可能的解决方案:

• 简化 Jira。
• 创建一个 Slackbot 界面。
• 创建一个导师制度，现有的自信用户成为新用户的导师。
• 平台团队提供服务。
• 改变拉取请求服务。
• 与应用团队和平台工程师进行配对编程。
• 构建配置模板。
• 吸收账户。

然后他们比较了这些解决方案，考虑了成本与价值的关系，就是改进平台产品所带来的价值。并决定简化 Jira 作为一种平衡迅速安抚财务部门的需求与投资清晰接口以满足应用团队需求的方式。

“除了 Jira 很难自动化，”她说，听众都心知肚明地嘲笑道。 “我们遇到了任何代码都会遇到的同样问题，那就是我们想要快速反馈，但这并不总是易于获得的。” 因为代码需要花费时间编写、测试、实施和维护，她解释道，尤其是如果你不确定这是客户想要的。

“你必须给人们一些有形的东西来看，以获得现实的反馈。如果你告诉他们一个想法，他们要么有些心不在焉，要么确实不知道该如何回应你，”她继续说道。

因此，他们制作了 Jira 原型。反馈显示，在他们努力简化的过程中，实际上造成了更多压力。原型仅要求开发人员确定一个账户类型，但它没有解释这意味着什么，应用团队 - 他们了解组织的约束和工具的复杂性 - 甚至不相信这是对现实的准确描述。

他们返回到他们的理想决赛者，接受他们将不得不使用需要更多时间和资金的东西。他们选择聊天机器人，Bangser 在采访中进一步说明：“这允许与造成摩擦的现有界面保持更大距离，并为用户在提出请求时提供更多互动反馈循环。”

这第二轮发散思维获得了积极的反馈，他们继续实施了这种基于聊天机器人的平台工程解决方案。

她提醒 CIVO Navigate 的听众：“与您的客户交谈并尝试获取更快的反馈循环。平台被视为强制性的。即使不应该这样，如果它们是强制性的，产品就不会获得反馈。”