摘要：平台工程需“销售思维”以证价值。许多团队因无法向高管展示成果而失败。应聚焦高管、安全等利益相关者问题，而非仅技术方案。通过量化问题，用速度、可靠性、成本指标衡量平台影响，系统化沟通价值，确保支持并推动业务变革。

平台工程需“销售思维”以证价值。许多团队因无法向高管展示成果而失败。应聚焦高管、安全等利益相关者问题，而非仅技术方案。通过量化问题，用速度、可靠性、成本指标衡量平台影响，系统化沟通价值，确保支持并推动业务变革。

译自：Why Your Platform Engineering Career Is Really a Sales Job

作者：Jennifer Riggins

伦敦——事实证明，平台工程师也是一种销售工作。

我们撰写了大量文章，阐述 DevOps 工程师和平台工程师 角色之间的区别。但是，DevOps 团队主要只服务于开发人员和运维人员，而 内部开发者平台（IDP）团队则服务于许多利益相关者。而且，其 预算的维持也处于更加脆弱的境地。

本月在 Team Topologies 的 Fast Flow Conf 大会 上，Christopher Batey（Core Engineering Consulting Group 首席技术官）决定将对话引向超越与 IDP 关联最紧密的开发人员客户。毕竟，采用率不能成为你唯一的衡量标准——仅仅因为有用户，并不意味着你的 IDP 有用或能改善底线。

相反，Batey 专注于如何接触其他利益相关者——高级领导层、产品管理、变更管理和安全团队——以便在内部推销你的平台。

别担心，这不会是一门销售课程——至少不是明确的销售课程。它可能是一堂沟通课。他介绍了如何运用不同的平台指标来引导与平台众多客户的对话，向不同受众展示你的价值，并展示你的 平台工程 团队——有望——如何为业务创造持久影响的技巧。

平台项目有时会将其初始资金直接用于采用出色的技术。问题就可能从这里开始。

Batey 说：“许多平台工程团队正在交付出色的平台，但同时也挣扎着维持其存在。你觉得你做得很好，但你的价值对领导层来说仍然是隐形的。”

这种困境意味着 45% 的平台工程团队在 18 个月内被解散或重组。

由于平台工程在许多组织中仍处于早期阶段，任何内部销售策略都必须以解释“为什么”为基础，而不是倾泻式地介绍你拥有什么或承诺会做什么。

Batey 说：“我坚信平台工程是我们扩展 DevOps 的方式。”但他补充道：“但在实践中，至少以我的经验来看，我们仍然要求应用工程师思考太多、做太多。”

他表示，尽管 DevOps 已经打破了一些孤岛，但许多开发人员仍然在同时处理三个云账户——用于开发、用户验收测试和生产——同时还要编写 Terraform 或 Pulumi 代码，设置数据库和云身份与访问管理（IAM），然后还要弄清楚如何以多种方式中的哪一种来部署容器。

这些重要但重复、非差异化的干扰让开发人员每天花费不到 30% 的时间（或者，根据一些说法，甚至更少）来创造独特的业务价值。

Batey 说：“平台工程才是我们让应用工程师真正构建应用的方式。”

资金支持通常取决于你如何向整个组织的利益相关者展示平台工程的价值。这就是为什么，正如 Matthew Meckes（亚马逊网络服务 高级容器专家）在 Fast Flow Conf 的另一次演讲 中指出的那样，平台团队仅仅衡量其平台的吞吐量和稳定性是不够的。真正重要的是一个平台能以多快的速度帮助软件开发团队以安全、可靠的方式交付软件。

Batey 赞同更广泛地定义平台工程的影响。

他说：“我认为平台工程的目标是以速度为核心，内置安全性，并有望在保持或提高可靠性的同时实现变革。”“我更喜欢这种平台工程的定义，而不是‘我正在构建自助服务能力以使开发人员提高生产力’等等，因为它告诉我们我们为什么要做平台工程，而不是平台工程当前是什么，因为‘是’什么总会改变。”

一旦你和你的平台团队扎根于这个“为什么”，你就可以继续理解你的利益相关者的各种视角，以及对每个人来说成功意味着什么。从那时起，你就可以创建更多有意义的、基于他们需求的指标。

Batey 说：“我总是需要提醒自己，将这些讨论基于我正在与之交谈的人，而不是我想实现的解决方案。”“这是我为远程会议贴在显示器上的便利贴，在参加面对面会议之前，我都会对自己大声朗读五遍。”

他说，这张便利贴提醒他“不惜一切代价避免与利益相关者讨论你的解决方案。他们不关心你的解决方案，他们关心他们的问题。所以，让我们努力理解他们。”

他接着说，只有这样，平台工程团队才能承担责任，并作为变革的推动者而受到尊重。

他强调说：“作为平台工程师，我们应该始终知道我们正在构建的东西，将如何提高公司交付软件的速度。”“它将对安全性产生可衡量的改进，或者将提高可靠性。”

Batey 认为：“平台工程师需要与所有人交谈，因为平台工程的工作是让所有人齐心协力，真正将变更交付到生产环境。”

在大多数组织中，这包括但不限于：

首先，看看一个变更如何到达生产环境。平台团队的目标是降低 Batey 所说的“协调税”——即变更在推向生产过程中遇到的摩擦。请记住，这些步骤不仅基于技术，还包括沿途的许多人员和流程。

对于高管利益相关者来说，风险、投资回报率和速度是关键指标；而产品开发部门的工程负责人则关心可预测的入职、交付和质量。这两种利益相关者都非常关注实际花费在向最终用户交付价值上的时间百分比。

既然我们知道 编写代码从来都不是瓶颈，那么软件开发生命周期的其余部分——外循环——才是平台工程和 AI 这两种趋势能产生最大影响的地方。两者都能帮助缩短发布到生产环境的时间，或减少在其他关键领域（如生成文档和使所有内容更易于发现）的摩擦。

毫不奇怪，安全 最大的担忧通常包括覆盖范围、修复速度和端点漏洞的数量。Batey 说，特别是安全利益相关者希望更早地被纳入进来，以便真正将其融入平台。

变更管理从业者最关心高风险变更，以及平台如何整体上推动安全、可预测的生产交付时间。

基础设施负责人关心采用率、一致性和卓越运营。

Batey 承认：“我骨子里是一名工程师。默认情况下，我不是一个天生的沟通者，我更乐意编写代码，构建平台功能。”“我唯一能改进与这些人沟通方式的方法就是将其系统化。”

在讨论任何解决方案之前，他会与利益相关者一起将问题口头化。然后，他寻求量化问题。对于每个利益相关者，Batey 都提出了示例问题，然后说明了如何量化它们，以便衡量任何变化。

Batey 警告说，利益相关者不一定总是清楚他们面临的问题。例如，安全团队可能完全不知道每个团队都有不同的生产路径。他们只知道安全工具的采用率不够高，或者没有人负责修复缺陷。

他建议，你可以从量化有多少资产存在漏洞开始。然后，你可以引入外部证据，说明其他企业是如何解决相同问题的。最后，你可以通过一个简短的概念验证来创建内部证据。

最后，你们共同创建 Batey 所说的“指标库”，或者你们共同拥有的指标，并相信你们可以推动这些指标的改变。

你的平台计划需要展现可衡量的速度、性能、安全性和/或成本价值。在深入讨论安全性之后，Batey 为其他三个方面也提供了一些例子。

这种速度通常通过消除手动操作和审批来提高。

Batey 补充说，与应用工程师直接合作，你还可以设定：

总拥有成本（TCO）和投资回报率（ROI）是所有团队领导都应该理解的关键指标，尤其是在当前为自己的工作争取支持的时候。他提供了一些关键的成本指标：

Batey 说，平台工程最困难的部分是决定做什么以及按什么顺序做，这可能导致团队衡量过多。衡量需要一个层次结构，他以实际例子作为基础。

想象一下，产品发布正在放缓。高管们抱怨你的软件组织落后于竞争对手。但如果团队试图加快速度，可靠性就会下降，伴随着更多的漏洞。

他的诊断是，手动配置的环境导致了测试和生产环境的差异。开发人员跳过了自动化测试，而安全团队则不得不为每个环境采取不同的部署方式。他说，平台工程团队应该向高管们提出的解决方案是：为关键服务建立一个标准化、统一的生产路径，利用一致、轻量级的环境，这些环境以一致的方式自动创建。

Batey 建议：“永远从简单开始。”“选择一个关键的业务用例，找出其中涉及的组件，无论你正在做什么，只要确保它为这些关键用户旅程带来一些价值。”

衡量是传达平台项目价值的最佳方式，其基础是“为什么”的责任。他建议，要做到这一点，从简单开始，为每个利益相关者选择一个关键的、易于衡量的业务用例。

Batey 说：“请记住，目标不是衡量所有东西。而是衡量正确的东西，向关键人物展示你所构建平台功能的价值。”

当然，这包括所有掌握财政大权的人。但他还说：“你也不希望人们阻碍你正在做的事情。”

下载电子书《平台工程：您现在需要了解的一切》。

来源：相对教育