一个价值70亿美元的教训！如何避免平台工程变成“大灾难”？

经过几年发展，平台工程终于成为了一个重要的趋势。

去年，软件工程师兼 DevOps 评论员 Sid Palas 在推特上写道，“DevOps 已死，平台工程才是未来。”这引起了广泛关注，并在中文技术圈引起了话题的讨论。一些正在实施平台工程的企业对这个话题感到“相见恨晚”，而另一些人则持相当抵触的态度，但他们的意见总结起来就是困惑于平台工程的定义：“平台工程到底是什么？谁来主导？这是否只是相同的东西换了个概念？”他们认为平台工程很可能只是“新瓶装旧酒”。

自那之后的小半年里，我们看到到处都在宣传和讨论“平台工程”，它成为了一个真正的“热点议题”。但同时其实我们正处于另一个关键节点上——大家觉得平台工程很好、很有热度，但目前我们缺少指导性路线，大家并不清楚接下来该朝哪里去，市场上也没有参考架构和清晰的设计模式。

另一方面，在探讨国内平台工程实践案例的过程中，InfoQ 也发现国内外无论是在技术整合策略、平台解决思路，还是文化方面，都存在明显的差异。

在海外，开源社区非常火爆，存在不少开源工具如 Argo CD、Backstage，特别是围绕 Backstage 的插件体系非常丰富，已经出现了上百种插件，看起来海外的研发工程师更注重底层工具的开发和优化，工具会做得更加可对接。相比之下，国内的工具链相对复杂，为了提升端到端的体验，通常需要一个整合层或平台层来更好地组合这些工具。而且在国内平台工程主要以代码和自我品牌为中心，比如阿里内部的 Aone、阿里云外部的云效、腾讯云的 Coding 等产品。这些平台以开发者视角为出发点，围绕着代码管理、项目管理、需求设计、缺陷管理、测试管理和制品管理等核心特性构建。在这些平台中，代码和制品形式的流转更多地发生在不同的产品模块之间。每个产品内部都有非常丰富的功能机制，这种商业软件的玩法是开源平台无法做到的。

基于以上原因，InfoQ 采访了 Humanitec 的产品负责人 Luca Galante。Humanitec 公司做的是平台编排器，大家可以理解成服务于企业平台层中内部开发者平台的核心引擎，是平台工程、团队和组织中的领先解决方案之一。更重要的是，Luca Galante 本人是平台工程社区的主要贡献者，他每个月都会定期与数十个工程团队交谈，从数百个 DevOps 实施案例中总结经验，然后再将这些清晰、有见解的知识传递给业界。

Luca 认为，现在的软件开发环境与 15 年前 DevOps 刚刚出现时，已经完全不一样了。运营（运维）占据了开发人员太多精力，企业也需要不断地聘请更多的运维人员满足运维需求，但“很多企业甚至没有意识到这个现实问题。”“但在深入挖掘并意识到开发团队的一半精力实际是在做运营的时候，那管理者就能算出运营体系的真实规模了。”

正因为如此，Gartner 预测到 2026 年时，将有 80% 的软件工程组织会建立平台团队。

Luca 提到，当企业开发人数发展到了 50 到 100 名的时候，投资并建设平台就成了一种必需。但自主研发并不总是成功的，例如，去年在 PlatformCon 上的主讲人 Steve Pereira 分享了通用电气如何在类似平台项目上浪费了 70 亿美元的案例。

那么，企业是否应该自己构建平台工程？如何让领导更加重视开发者体验？如何进行技术选型？是否有可供参考的架构？如何判断平台工程的实施是否成功？针对这些问题，Luca 提供了一些很好的建议。

以下为 InfoQ 与 Luca Galante 的访谈实录，经编辑。

Luca Galante：我们关注平台工程大概是在 2017 到 2018 年左右，那时候 DevOps 还没有真正在市场上发挥作用。但我们面对的云计算技术和发展趋势已经越来越复杂，导致“谁构建、谁运行”的理念很难实际落地。我们注意到，那些领先技术公司和工程组织都有自己的办法，包括一些来自谷歌的同事，他们在谷歌那边建立了 Buffer。通过观察，我发现这些领先企业似乎找到了答案。也就是在开发和运营团队之间构建某种平台层，确保组织能够使用云原生进行扩展，而不断扩大的工程师规模意味着不可能每个人都端到端理解整个设置体系。为此，这些领先企业开始构建平台，相应思路也向着市场主流渗透。但坦率地讲，当时人们还没有一套用于讨论和思考这些问题的框架。于是我们决定给予关注，也就是帮大家打造一个框架，引导人们思考这些问题。这也相当于给人们创造了一个空间，用来分享真知灼见和最佳实践。

我们就是从那个时候开始关注平台工程的，这股潮流很快席卷整个世界。现在这是个真正的全球化议题了，我们大概有 36 个小组，世界各地共有 1.1 到 1.2 万名社区成员。总之，平台工程社区一直在快速增长。

Luca Galante：这是个好问题。以汽车为例，它的整个系统就像一根主干开枝散叶，结出累累果实。其中每个分支都需要得到解决。软件工程也是一样，平台是非常重要的。平台一直存在于渐进抽象的发展历程当中，比如在基础设施之上构建平台、再在平台之上构建别的东西。

您刚刚提到，说平台工程到底是新鲜事物还是 DevOps 的变体。我觉得 DevOps 是一种文化，一种理念。我觉得平台，特别是平台工程，是我们实现“谁构建、谁运行”的唯一方式。这是 DevOps 的核心初衷，也是后来企业级规模和云原生时代的实现基础。所以我真心认为，平台工程是 DevOps 自然演化的结果。

Luca Galante：我觉得 SRE 强调的是维持生产系统的可靠性，关注整套设置的可靠性、可扩展性和可维护性。我们之前提到，DevOps 代表一种文化或者说理念，它从来就不是特指某种职能角色。事实上，它所对应的职能角色是比较抽象的。而平台工程，代表的则是一门学科，用来塑造我们的思考方式。我觉得平台工程像是一种纪律和约束，源自在云原生时代以企业规模实施 DevOps 的必要性。

因此，平台工程有点像是设计和构建工具链的学科，目标就是真正实现“谁构建、谁运行”。有了平台工程，核心软件工程部门才有机会获得自我服务能力。

至于 DevOps 和平台工程有什么异同的问题，我们主要关注的是如何维护相对较大系统的可扩展性。在大多数情况下，DevOps 更侧重于为支持开发人员。但我觉得这是个常见的错误，相当于是指导开发者们喜欢上复杂的设置，再教他们如何运用各种各样不同的技术。恰恰相反，我觉得平台工程才更有意义，也就是让开发人员在企业中以自我服务的方式掌握应用和服务运行所需要的技术和工具。

也就是说，平台工程关注的不一定是教你怎么用工具，而是构建起一套能够实现这种自我服务能力的平台。

这种观念上的转变，也契合我们在社区中提出的概念，就是说平台即产品。要把自己的平台视为一种产品。

既然是产品，那产品管理层面的最佳实践当然适用。我们需要将开发者当作客户，倾听他们的意见并据此迭代产品。一切就从这里开始发展壮大，最终形成了平台工程和 DevOps 工程之间的关键区别。

Luca Galante：那肯定会（带来新的启示）。就像之前说的，DevOps 在 15 年前刚刚出现时，技术环境还完全不同。我们当时在裸机上做开发，我们的基础设施根本不像现在这么复杂，我们没有 Kubernetes，没有 IaC，没有 CNCF 种种。DevOps 最初的想法非常简单，基本目标就是消除开发人员和运营人员间的障碍，促进双方协作。

这当然很有意义，而达成目标的方法基本就是做左移，实现“谁构建、谁运行”。但现实情况是，当所有这些云原生趋势融合在一起之后，就有了云原生、Kubernets、容器化、基础设施即代码和 GitOps 等等，包括大家能想到的其他云原生流行词。反正企业如今发现，根本就不能指望刚刚入职的新开发者能接纳和喜爱这套日益复杂的云原生体系。至于 15 年前，那时候我们只需要一个脚本加一个部署工具，就能把代码变更新部署到应用程序中并进行测试。情况已经完全不同了。

如今，我们已经有了非常复杂的工具链，需要面对大量脚本和 helm chart。在 Kubernetes 中，大家可能会使用多个 IaC 模块，接触不同的工具。要想上手必须成为专家，但这完全没有必要。相反，应该把底层基础设施的复杂性从开发者那里抽象出来，为他们提供一条最佳路径，由开发者自己决定最适合的上下文层级。

比如说，对于高级工程师，大家肯定想深入研究某些东西。那我们平台团队就给你更多的灵活性。但作为初级工程师，你可能根本不想去碰那么多复杂性元素，那平台团队就帮你简化流程。

Luca Galante：其实我们讨论的所有内容，都可以总结成最终产品给开发人员带来的额外认知负荷，对吧？开发人员常常不知所措，而且害怕做出改变。因为他们不想搞砸现有的东西，不想某个模块或者基础设施中的某个部分在他们手里发生故障。

所以，开发人员开始害怕去修复这些东西。那最终事态就会朝着以下两种情况之一，甚至兼而有之的方向发展：他们不断向运营同事求助，导致运营部门压力增大。那么随着开发人员数量的上升，运营团队的压力会越来越大，最终成为业务体系中的瓶颈，成为等待和摩擦的来源。

另一种情况是，有人会转而采取“影子运营”的办法。敢这么干的一般都是高级工程师，那些高级后端工程师。他们悄悄用自己的办法接管了这些运营任务。

然后可能就有初级开发者向这帮高级工程师求助，说“嘿，能不能帮我看看这个问题”。于是乎，高级工程师们的工作就成了一半开发、一半运营的形式。这就是我所说的影子运营，它会在系统中产生更多摩擦，因为现在有一部分运营工作被分配给了另一个群体。而且这个群体是企业中的高级开发人员，是我们最宝贵的资源，他们并没能把所有精力都投入到编码当中，而是在努力为开发团队中的其他成员解决问题。

因此，技术债务问题不断增加，认知负荷也随之而来。最终，令系统陷入恶性循环。

Luca Galante：从个人角度来看，我觉得好的平台工程师应该掌握两大主要技能。

首先就是我们之前提到的产品思维，我认为这也是最重要的转变所在，特别是对之前 10 年、15 年长期从事 DevOps、云运营和基础设施开发的资深人士而言。在大多数情况下，他们并没有做好构建产品的心理准备，虽然他们也在构建产品、也在打造平台，但关键在于他们是否在以主动、有意的方式做这件事？或者说，你只是在到处救火、疲于修复，努力保证愈发复杂的系统维持正常运转？

因此当建立平台团队时，大家必须对这样一个事实建立起明确的认知：我们的使命和愿景，就是构建和成就一款产品，也就是内部开发者平台，当然可能在不同的市场和行业中有其他名称。这才是重点，要把平台视为你的产品。你得意识到这款产品的客户就是其他开发者同事，他们就是内部客户，也是产品将要面向的受众。这种转变将推动产品思维，把以往四处救火的基础设施团队真正转化成产品部门和平台部门。坦率地讲，在不少组织内，基础设施部门其实就是个加了滤镜的服务台。这就是我认为最重要的转变所在。

第二点是，平台工程师们一定要重视沟通能力。想想平台工程师和平台团队的日常工作吧，其实质就是把复杂的多个利益相关方管理起来。你需要面对自己的开发团队，需要跟他们建立起非常密切的关系，并想清楚设置怎样的抽象级别、具体能够讨论哪些问题等。

此外还有另一个利益相关群体，就是现有的基础设施运营团队。你得向他们澄清，你的到来不是要替代掉对方。我们是来合作的，来帮助你缓解痛点，确保你能真正专注去做自己喜欢的工作、优化生产环境，或者添加开发者需要的新基础设施，而不再没完没了地救火和担惊受怕。

之后还有第三个利益相关方，也就是公司里的高管团队。比如说，你要怎么把平台主张推销给管理层？你要怎么获取高管团队的支持？因为面对的是多个不同的群体，所以你得掌握他们各自熟悉的语言。在跟开发人员交谈时，你要强调的是如何缩短等待时间、改善开发体验。而在跟运营团队交流时，你要告诉他们如何减轻压力并快速处理工单。

而在跟管理层沟通时，最重要的一点就是缩短产品上市时间。坦率地讲，这个指标类似于给平台设定投资回报率。这事并不简单，所以我才觉得平台产品经理真的非常重要，因为他们不单要管理产品，更要处理开发人员的反馈，还有处理其他运营部门和管理层的关系。

Luca Galante：跟构建平台一样，企业也可以根据运营人员配置进行非线性扩展。比如说企业该怎么支撑起自己的动态配置管理平台，但这是另一个问题了，我们可以稍后再谈。

总之，如果企业没有一套良好的平台来标准化处理配置、应用程序和基础设施，就无法让开发者通过清晰的最佳路径以标准化方式实现基础设施交互，对吧？在这种情况下，坦率地讲，大家要么牺牲掉 CI/CD 流程的可维护性，要么就得放弃运营团队的心理健康状态。因为如果没有这样一套平台，那么当更多开发人员加入进来后，你就得同步添加更多运营人员，或者承受更多影子运营元素，这一点我们之前已经聊过了。

这不单会拉高整个体系的运营成本，坦率地讲效率也不可能太高。而且你得按照开发规模配置运营规模，所以随着开发者和应用服务数量的线性增长，你的设施规模和设置也将愈发复杂。与之对应，如果你拥有一套平台，那运营规模就能相对更小，这就是问题中提到的“比例”。比方说每一到两名平台工程师，对应 100 或 200 位开发者之类。当然，也可能是每一到两位平台工程师对应 10 位开发者。

有趣的是，很多企业甚至没有意识到这个现实问题。但在深入挖掘并意识到开发团队的一半精力实际是在做运营的时候，那管理者就能算出运营体系的真实规模了。这个比例往往比很多人印象中要差得多。这就是内部开发者平台的真正意义所在，支持开发者进行自我服务，同时减少运营开销，确保用更少的人做更多的工作。当然，我不是说大家需要解雇运营人员，只是原本不可能的在平台的支持下变得可能，运营人员也能搞定更多问题、做出更多尝试，不再没完没了地配置数据库或者运行环境。

Luca Galante：绝对可以。它当然能节约劳动力，但好的平台工程首先能缩短上市时间、拉高经营收入。

也就是说，内部开发者平台会对开发者的交付速度和上市时间产生巨大影响。你能更快、更可靠地把软件推向市场，而这也是决胜当今这个残酷市场的关键。谁在这方面做得更好，谁的市场竞争力就越强。所以我认为，特别是考虑到当下的宏观经济形势，要想真正保持住竞争力，组织和个人都应该着手投资平台建设。

Luca Galante：这是个好问题。我觉得这是个经常被提起，但还没得到充分解答的问题。我觉得 20、30 人太少了，一般的临界点在 50 到 100 名开发人员。到了 100 人上下，平台有助于解决的痛点才开始真正出现。痛点出现了，摩擦出现了，开发人员开始陷入无意义的等待、运营团队开始承受压力并在工单中挣扎求存。面对快速积压的工单，投资并建设平台就成了一种必需。

另外，我觉得还应该明确内部开发者平台和传统 PaaS 之间的区别。好像从古早时代人们就已经习惯了 PaaS 产品，比如说在电子商务、Netflix 和小团队场景下的应用。

市场上有不少号称能提供平台工程解决方案的参与者，但他们拿出的其实都是 PaaS 解决方案，也就是平台即服务，专门面向小型团队客户。

我觉得这不是问题，如果团队中只有 15 到 20 名工程师，而且不是每个人都熟悉 helm charts、IaC、Terraform 或者 Kubernetes，那 PaaS 挺好的。毕竟如果真的每个人都是专家大牛，那 DevOps 的基本诉求“谁构建、谁运行”早就自然实现了。问题在于，这个诉求无法扩展到更大的团队。而且毕竟不可能人人都是专家，这时候就一定得选择 PaaS。所以说哪怕规模不大，只要不想陷入影子运营的泥潭，那就可以选择 PaaS。我觉得 PaaS 是个很好的解决方案。但这只适用于工程师不超过 50 人的情况。而关键问题在于，随着业务的成长，大家必须确保建立起作为过渡计划的内部开发平台（IDP）。

IDP 也分独立和 PaaS 两个分支，后者的区别在于没那么灵活，无法随意构建不同类型的最佳路径。对大多数人来说，PaaS 只能提供一条路径，只能通过简单设置支持相对不那么复杂的用例。

而 IDP 则是企业的另一个平台层。内部开发者平台的目标是为工程师们提供类似于 PaaS 的使用体验和开发体验。但它基于更复杂的标签和工具堆栈，在企业中也可以理解成大家需要建立平台团队来交付这套专门的工具箱。其中不乏开源工具，比如 ArgoCD、Backstage 等等。大家也可以选择我们 Humanitec 这样的供应商，搞清楚工具箱里到底有着怎样的技术组合。

比方说，我们可以把 Backstage 跟 Argo 良好结合起来，这样就能把它们跟 Humanitec 配合使用，建立起相应的技术栈。平台团队的职责就是把整个栈接管过来，完成最后一英里的优化，通过微调为开发者构建起适宜的最佳路径。这就是关键区别所在，因为 PaaS 几乎不提供多少灵活性空间，而平台工程则支持通过微调为不同用户构建不同路径。这就是 IDP 的最大意义，例如我们如何保持住产品心态、听取开发者意见，并搞清楚怎样的抽象级别最适合等。我们可以为组织内不同类型的团队和不同类型的用户提供不同级别的上下文。

因此，当企业从 50 到 80 名开发者转变为成百上千开发者时，如果还没有任何平台，那真的需要赶快行动起来了，这一点非常重要。另外，如果您已经拥有 PaaS 解决方案，不妨考虑逐渐过渡到自建的内部开发者平台。这并不需要从零开始构建所有内容，毕竟没必要重新发明轮子。我觉得平台团队的价值并不止于做微调，而是在整个转型之旅中持续做贡献。平台团队就是这样建立起来的。

Luca Galante：我觉得这个问题非常棒。目前来讲，我觉得要下断言为时过早。Gartner 预计，到 2026 年，80% 的软件工程组织都将建立平台团队，基本相当于内部 IDP 供应商。我觉得平台工程终将解决开发者与运营者间的合作这一基本问题。

所以问题在于，如果你们的企业需要内部研发，那基本就是我们前面提到的重新发明轮子。这种自建平台的事情，只有谷歌或 AWS 才会去做。坦率地讲，根据我自己的实践经验，这类工作真的很容易出问题。请大家务必慎重考虑这种重新造轮子的决定。您的内部平台团队，很难跟 Argo 加 Backstage 再加 Humanitec 这类技术组合做竞争。所以，你为什么非得重新发明整个技术栈呢？既然有现成的工具箱可用，平台团队干嘛非得自己亲自动手开发？去年，我们在 PlatformCon 上做了一段精彩演讲，主讲人 Steve Pereira 就分享了通用电气是怎么在这类平台项目上烧掉 70 亿美元的故事。（该案例细节参看今天公众号的次条文章）

当然，我不是说随便哪个 IDP 项目都能烧掉那么多钱。但问题是，你真的不是谷歌、也不是 AWS，大多数企业都没有那样的业务规模，何必要重新发明轮子呢？只要了解现有技术是什么样子，哪些是开源的、哪些是专有的，就可以遵循最佳实践将这些技术成果粘合起来，构建起属于自己的平台。

Luca Galante：我觉得主要问题在于，很多人在设计平台工程时，对技术选型操心过多。

很多人怕自己选错了技术，最终导致平台项目失败。其实问题很少出在技术上。转型工作不会单纯因为技术而失败，更多是因为文化问题而失败。

那要怎么强调文化这部分呢？之前我们讨论过不同的利益相关方，重要的就是在各个群体之间就最小公约数达成一致，比如他们到底想解决什么问题、什么挑战。我们希望在此基础上建立怎样的标准，确保我们专注于做正确的工作。这实际是个原则问题，要求在组织内制定出定义明确的平台工程原则。实际上，我们本周会和麦肯锡共同发布新的参考架构。很快我们就会向大家介绍 AWS 的企业级开发者平台是什么样子。

此外，我们还会介绍 AWS 上的 IDP 管线，以及多云用例等等。还有阿里巴巴等其他厂商的案例。在基础工程原理之外，麦肯锡还会发布一份其他事项和设计思路清单。

其实相信大家都能想到，我们的核心目标在于关注用户需求。最重要的是，公司的内部开发者就是我们的客户，我们需要集中注意力关注这部分受众，衡量采用率并构建起出色的产品。另一个原则，就是像初创企业那样运营自己的平台团队。我们要建立一个拥有平台并负责平台推广的核心团队。整个体系就像是独立的初创公司一样。毕竟我们的产品不可能在真空中诞生，我们得在构建的同时考虑如何适应市场需求。所以我们才强调最佳路径，而不是最佳“牢笼”，这一点非常非常重要。我们是要为开发者找到一条最佳路径，让他们能够自由选择合适的抽象级别和合适的上下文。

换言之，IDP 绝不能成为束缚开发者的牢笼，那样反而不利于他们在工作当中取得成功。比方说，我们打算通过设计推动标准化普及，想要实现自我服务。但与此同时，还得确保开发者使用基础设施资源的方式跟我们的标准要求相一致。另外，我们的平台得始终如一输出相同的配置文件。这实际上就是要把 DevOps 原则跟麦肯锡实施的动态配置管理对接起来。

动态配置管理的实质，在于每次部署时都能动态生成配置文件，这也是我们能够实现精确控制的唯一方法。包括谁部署了什么、在哪里部署、输出了什么。动态配置管理还能在每次 git 推送时执行策略和标准，在部署等环节之间建立约束。这里我没法一一列举所有原则，但麦肯锡已经把它们整理清楚，马上就会正式发布。

所以如果大家想了解更多信息，强烈建议各位参阅麦肯锡还有我们在 Humanitec.com/reference-architectures 上发布的内容。这一切可能会成为大家解决现实挑战的良好起点。

Luca Galante：没问题。我觉得最好是从参考架构起步，过去几年来我们整个社区就经历了这个阶段。如果想要真正实现“谁构建、谁运行”，如果想要真正实现企业级自我服务，就必须得建立起某种平台层。也就是 IDP，或者说内部开发者平台。

但很多人其实并没真正听进去。就像我上周在 QCon 上的体会一样，很多展位都在宣传类似的平台工程。InfoQ 在写相关报道，The New Stack 也在写，大家把平台工程当作是热点议题。好的一面在于，这样的人气意味着我们在社区中的努力终于有了回报。但我觉得现在我们正处于另一个关键节点上——人们觉得平台工程很棒、很好、很有热度，但不清楚接下来该朝哪里去。市场上确实缺乏参考架构和清晰的设计模式，所以人们不知道怎么入门、怎么看待企业级内部开发者平台的种种不同组件。

对于这个问题，我们还是回到即将发布的参考架构上来。这套架构将包含所有关键部分，类似于统一的控制面。

这个控制面将包含大家的 IDP、版本控制系统，还有类似于规范列表的内容，例如我们几个月前刚刚开源的 Score。

另外，如果需要，参考架构还可以提供 UI、开发者门户、后台之类的选项。这几乎就是一套完整的控制面了，引导开发者如何与之交互，所以我称其为开发者控制面。此外还有集成和交付面，这里有 CI 管线、注册表、平台编排器（例如 Humanitec）和管线部署工具。这是真正推动一切的核心配置引擎。在此之下，还得支撑起资源面，具体涵盖计算、数据、网络和服务。这部分一般是由大型云服务商负责提供。以 AWS 为例，他们提供 EKS、MySQL RDS 等等选项，还有 DNS 和 Route 53，Amazon SQS 等等。Google Cloud 和 OpenShift 也提供类似的方案选项。

之后是监控和日志面，还有行之有效的安全面。我们的安全面就类似于一个保险库，容纳散列的核心保险库。而在监控日志中，则存放着各种各样的有价值信息。纵观全局，这里有大概五个不同的面。在讨论开发者自我服务时，我们最常提到的就是如何帮助他们消除运营复杂性和负担。这就需要借助不同的界面让开发者与 IDP 进行交互，而集成和交付面则是 IDP 当中的核心配置引擎。

这就是我对于现代企业级内部开发者平台的理解。

Luca Galante：我觉得这跟我们之前的讨论也有关联，实质在于如何跟不同的利益相关者群体沟通。具体来讲，我觉得最核心的问题就是怎么说服高管层。我想再次强调，在大多数情况下，这种错位来自高管和平台工程师之间使用的并不是同一种语言。我有个朋友 Lee，他在 IBM 就建立过这样一套平台，面向的是大厂。他还专门为 InfoQ 写过一篇文章，应该不是 InfoQ 中国，可能是 InfoQ 美国吧。他认为作为平台工程师，最重要的是首先了解高管人员最关心什么问题。比如说，目前的优先事项是什么，业务重点在哪里。在弄清楚这个问题之后，才能据此设计自己的表达方式。

因此，假定他们想要推动整个组织的数字化转型，实现技术栈现代化，这可能是因为高管们从 cio.com 上读了些相关内容。或者说，他们可能只是想快速建立收入流以建立商业价值，或者想要关注网络安全和安全风险，包括如何留住更多人才等等。高管们关心的具体问题可能有所不同，所以如果你老是抱着自己那套思路来推销平台工程，那肯定不会有太好的效果。比如你总在那里强调它能减少工单积压、改善开发者体验，但人家 CTO 根本就不在乎，因为强调开发者体验就是无聊的废话。那他们更重视哪些问题？他们关心上限、下限，怎么留住人才，这才是最核心的问题。

很明显，软件开发是个很大的议题。那么，我们要如何把 DevOps 设计成让他们走心的东西。举例来说，很多工程师并不会认真考虑业务指标，但业务指标确实是重要的。最重要的业务指标之一就是 TTM，即产品上市时间。从这个角度入手，往往就能跟高管产生良好的共鸣。所以最好是强调当我们推出了 IDP，打造了工程组织平台，产品的上市时间能够得到怎样的改善。

沿着这个思路，高管们才会认真听你在说什么。

所以我觉得最重要的就是搞清楚你的高管关心什么，然后把精力都集中在这个方向上。

Luca Galante：如果从长远角度看，比如说上百年后，那我们肯定不知道。毕竟那时候我们已经不在了，无法亲眼见证。但换个角度，我们又不难预测出各类企业软件都将走上运营自动化的道路。

我觉得这个目标可能会在未来 50 年内实现吧。但在短期内，情况不会有太大的变化。咱们不妨设想一下，目前软件工程创新面对的头号限制条件是什么？是工程师不足，对吧？每家产品公司都是这样，总是没有足够的工程师来及时完成交付。这才是真正限制业务成长和功能发布的瓶颈。

也就是说，有很多软件是因为我们人手不足、精力有限才没有被开发出来。所以我觉得 ChatGPT 和 AI 都不会很快取代软件工程师。大家都听说过硅谷的 10 倍工程师概念，也许未来人人都能成为 10 倍工程师，这才是 AI 的真正力量。而且这将是一场全面的变革，涵盖运营、云操作和平台工程等各类角色。而且着眼于短期，另一个重要问题在于我们要如何具体实现？就从之前提到的平台工程师角度出发，到底要如何利用 AI 更高效地建立企业级技术栈？

还是那句话，我觉得 AI 距离全面接管人类岗位还有很长的路要走，它更多只是种增强要素。但我认为短期内还有另一个值得关注的重点，就是怎么依托 AI 改善人类与技术栈或平台的交互方式。

在 AI 的帮助下，我们可以跟系统直接聊天，让对方知道我们想要什么。它能反过来适应人类。于是我们可以设想这样一个新世界，平台团队不再需要手动为不同类型的开发要素，包括工程师、开发者和系统，确定正确的抽象级别。到时候，平台自己就能确定正确的抽象级别，而且只需要通过聊天界面对话就行。我觉得这确实值得期待。另外我还有一点观察心得，就是每当有这种被大肆宣扬的技术出现时，都应该后退一步，想想它有哪些优势可供利用，有哪些亮点值得我们放弃原本的产品路线图、在它的帮助下真正解决客户问题。

这才是我最关注的问题。当然，AI 的发展确实令人兴奋，我也将时刻关注它的发展动向。

Luca Galante：首先，我觉得平台工程会长期存在。这一点从平台工程社区的发展速度，人们的讨论热情和它的普及广度就可见一斑。同样的，就像 QCon 上各个展位透露出的趋势一样，平台工程已经成为企业和新闻媒体的关注焦点。

所以平台工程肯定会长久存在。我觉得它已经掀起了一股热潮，而且这背后有着充分的理由。平台工程专注于实现 DevOps 最初的承诺，这非常重要。

“谁构建，谁运行”，还有消除开发者和运营者之间的摩擦。我觉得过去十年间，整个技术行业在这些问题上反而有所倒退，开发和运营间的摩擦变多了，人们的日常工作也越来越费劲。

我认为平台工程就是这个问题的答案。我很高兴能看到它真正成为主流，因为它现在已经开始融入主流，至少是变得越来越主流，广泛存在于云原生世界的供应商之间。

但对于真正服务对象的最终用户和从业者来说，平台工程的普及度还远远不够。因此，我很高兴看到平台工程能成为一种趋势，成为 Humanitec 等开源平台工程方案的组成部分，也期待着它能让更多人的生活变得轻松一点。

InfoQ：好的，问题就是这些。感谢您能接受采访。

什么是技术情怀？在很多人看来，是热爱、是思考、是卓越。这个时代或许有人功利、或许有人内卷，但我们依然愿意相信更多人依然怀揣着用技术改变世界的初心。
《The Great Geek》（了不起的极客）是 InfoQ 重磅推出的全新内容栏目，全年共 8 期。
自栏目推出至今，我们专访了 MySQL 数据库和 Maria DB 创建者 Michael “Monty” Widenius、iPod“之父”Tony Fadell、Thoughtworks 全球 CTO Rebecca Parsons、《代码大全》作者 Steve McConnell，如果你身处的企业中有这样的技术领袖想让我们报道或你希望看到哪位技术大佬的采访，请在公众号评论区留言联系我们。