Kubernetes 被 AI 打回“半成品”！K8s 之父发出警告：代码生成越快，程序员越危险

整理 | 傅宇琪、褚杏娟

很多人提起 Kubernetes，第一反应还是云原生时代最成功的开源项目之一、容器编排的事实标准、现代基础设施的“操作系统”。但在 Brandon Burns 看来，AI 的到来，正在把这套系统重新推回“未完成”状态。

长期从业的开发者对 Burns 并不陌生，他是 Kubernetes 的联合创始人之一，当年在 Google 和 Craig McLuckie、Joe Beda 等人一起做出了这个项目，然后他们离职创业，Burns 去了微软。

Burns 将自己当前的职责概括为两部分：一部分是云原生，另一部分是资源管理，涵盖 Azure Kubernetes Service（AKS）、Azure Linux，以及 Azure control plane 等核心体系。他表示，尽管业界十年前就已普遍意识到，开源和 Linux 是云计算走向成熟绕不过去的基础能力，但真正困难的是如何将其系统性落地，这也是他加入微软的重要原因之一。目前，他手下大约有 1400 名工程师和产品经理。

此外，Burns 加入微软的另一层考虑，是希望补上自己在大规模组织管理上的经验。他坦言，此前自己并未真正管理过如此大体量的团队，而微软在培训、辅导和导师机制上的系统性支持，帮助他快速完成了角色转换。在他看来，组织管理与技术系统一样，规模一旦变化，问题本身也会随之变化：带领 10 人、100 人和 1000 人团队，所面对的复杂度完全不同，而疫情又让这一过程额外增加了一层特殊挑战。

很多人对 Burns 的印象，可能还停留在那几年到处参加 Kubernetes 大会、演讲的时候，但他近期开始活跃，分享了自己作为开发者的成长，AI 对自己、对 Kubernetes 这些基础设施的影响。

• AI 不是在“推翻” Kubernetes，而是在逼它补课。Kubernetes 原来最擅长的是在线业务调度，现在不得不开始理解 GPU、高速互联、训练作业、checkpoint 和数据缓存这类新问题。

• Burns 做高管后依然自己写代码，除了性格使然，也是为了不失去对真实开发体验的感知。

• AI 的效率提升是真实存在的，而且有时很惊人；但它远不完美，真正的问题在于你会不会用、怎么用、怎么和它磨合。

• 未来每个人的工作，都会越来越多地变成 review code，而不是单纯“写 code”。code review 正在从资深工程师的附加技能，变成所有工程师都必须明确训练的核心能力。

• 97% 代码是机器生成的”并不新鲜，你早就接受过“100% 机器生成的汇编。

• 你可以把 10% 的精力“藏起来”。不是先写 PPT 申请资源，而是先做出一个能跑的原型，一个能运行的系统，比 10 页解释材料更有说服力。

我们从两期播客中各自截取了一些问题，进行翻译和整理，以飨读者。

1 依然喜欢自己写代码

主持人：你现在自己还能下潜到技术细节里吗？感觉你还是挺愿意碰细节的。

Burns：对，这可能真的是我性格使然。我天然就是会被这些东西吸过去。但我也觉得，等你开始带团队之后，你迟早会意识到一件事：你必须放弃自己继续站在关键路径上。因为你一旦还把自己放在关键路径上，你就成瓶颈了，而且你会真的把整个组织拖慢。

你会有一个很明确的顿悟时刻：原来我的工作不再是“亲自把事做掉”，而是确保很多人可以并行把事做掉。因为不管你个人多强，10 个人、15 个人、20 个人、30 个人并行起来，产出一定远远超过你一个人。所以到某个阶段，你就会意识到：我的职责不是自己做，而是让更多人能顺畅地做。当然，你还是得帮大家把方向指准。

但与此同时，我确实又很喜欢写代码。我前面也说了，我就是喜欢做东西。我真的很喜欢写代码。说实话，我更愿意自己写代码，也不太愿意只是站在旁边看别人写。

所以这些年我一直给自己留了一些项目。比如 Kubernetes 的几个 client，我已经维护差不多十年了。我会维护 Java client、C client，还有 .NET 那边的 client。C client 用的人其实不算多，但我自己会用。.NET 那个用的人就不少。

我很喜欢这种事情，因为它正好能满足我“还想写代码”的那股劲儿。而且这些东西是真有用户的。这会让你一直保持脚踏实地。因为总会有人跑来找你，说“我卡在这个 issue 上了”“这个 release 什么时候发”。这些反馈会让你一直记得，一个真实开发者每天面对的，到底是什么体验。这不光会让你理解用户，也会让你更能理解自己团队里的人。

主持人：也能理解给你干活的人到底在经历什么。

Burns：没错。比如你会重新感受到，那种“又得去研究一遍发布工具链，因为它又改了”的烦躁。职级高了以后，有时人很容易忘掉这些细碎但真实的麻烦，会下意识觉得：“这不就很简单吗，去做不就行了。”但其实不是。

所以我一直保留这样一块自己亲手做的事，它能让我持续接触那些底层、真实、很具体的挫败感。而且它又没有重要到我必须天天盯着。如果我哪周突然得去救其他地方的“大火”，或者要处理客户反馈临时消失一两周，也不会有人真的气死。因此，这对我来说刚刚好：既让我有真实工作体验，也让我有参与感，又不至于让我真的挡在前面，变成别人的阻碍。

最近还有一点我觉得特别有意思，就是这些项目也成了我真正上手 AI 工具的最好场景。

因为我觉得，AI 工具这件事，其实也有类似的风险。很多高层管理者看新闻标题，会很容易得出一个结论：哇，那大家不就应该立刻提升 30% 的效率吗？但真实情况要复杂得多。

我可以非常明确地说，这些工具确实能提升效率，而且提升幅度有时候真的很惊人。但它不是完美的。三年前当然远远不完美，就算是今天，也还远远谈不上完美。你得知道怎么用它，也得知道怎么接近它。

而且我觉得，真正亲手用过之后的价值，不只是我自己知道这件事，而是我还能拿出具体东西给别人看，因为这些都在 GitHub 上，我可以直接跟人说：你去看这个 PR。这里面完整记录了我从 A 走到 B，前后用了 15 个 prompt。里面不全是那种特别漂亮的 prompt，有些就是非常真实的那种：“不对，你先编译一下。”“你能不能真的把你刚才说要做的事做出来？”

有时候你甚至会忍不住对着它说：“不是，你到底在干吗？”但恰恰是这些东西，会让别人看到，AI 工具在真实使用中到底是什么样的，它是怎么被真正用好的。

另外，还有一件事，我一直挺坚持的。它更像是组织管理层面的事，但其实也和我以前当教授有关。

教授都有 office hours，学生什么时候需要帮助就什么时候来。我以前也是这么做的。开始我管理的人不多时候，我就是跟每个人都做 1:1，真的就是每个人都聊。但大概到了 50 人往上，你就会发现，这件事开始非常耗时间，所以后来我改成 office hours。现在，我会固定开 office hours，团队里谁都可以预约，一个月里想约多少时段都可以。名额会很快约满，我们还会排队，尽量做平衡。

这件事的好处非常大。有时候大家只是想听听我的经历，想知道我是怎么一步步走到今天的。我很愿意讲这些，但对我自己来说最大的价值其实是：我能直接听到一线到底是什么感觉，而且我能横向听到很多人的一线感受。

我有一个很强的习惯，就是如果我在 10 个 1v1 里听到同一件事，那我就知道这不是单点问题了，我得去处理。哪怕那只是个 5% 的摩擦点，只要大家都感受到了，那它就是值得解决的。你把这个小摩擦去掉，整个组织的运行就会顺很多。

AI 也是一样。尤其在 AI 刚起来那阵子，很多人会担心：这东西是不是要把我工作替掉？你直接面对面回应这种担忧，讲清楚你自己的判断和看法，这样的效果与你站在季度全员大会上高高在上地说一遍，是完全不一样的。

当然，我也会在全员大会分享，有些人确实就喜欢这种方式。但带大组织这件事，本质上就是你得用很多种不同的方法，来确保你的想法、方向和判断真的传到组织里。

2 AI 怎么从底层改变“做工具”这件事？

主持人：AI 显然已经改变了我们对基础设施的理解。不只是规模，还有 workload 的形态、运行方式，全都变了。而你又正好在微软负责很大一块 Kubernetes 和容器基础设施。那 AI 到底是怎么从底层改变你们做工具这件事的？

Burns：有些变化，确实是那种非常底层、非常“螺丝钉级”的，但它们又实实在在地带来了明显不同。

拿 Kubernetes 来说，最早设计那会儿，主要关心的是 CPU 和内存调度这些核心问题，但现在还得把 GPU 考虑进去。而 GPU 可不是“另一种 CPU”那么简单。

很多 GPU 之间都有高速互联，所以现在你琢磨的就不光是“我要把这个东西放到某台机器上”，而是“我要把这两个东西搁在同一台机器上，具体哪台无所谓，但它俩必须在一起”。所以你会看到像 gang scheduling 这种机制开始进来，也会冒出一些别的新做法。

再比如训练这类 workload，本质上更像是 batch workload。可 Kubernetes 一开始其实是给在线业务设计的，训练和微调就不是这个节奏。很多人就想，能不能趁推理空闲的时候去跑这些事——白天大家都在用，推理流量很高；到了半夜，流量下来了，GPU 开始闲着。可这些 GPU 就算闲着，你钱还是照付的。这就要求调度器得支持某种意义上的时间切片。可这个能力，Kubernetes 最初并没有为它设计好。GPU 切分本身也是，最开始压根不是这个思路。

还有一点，你得真懂硬件。

所以我们后来必须得跟 Nvidia 这类厂商更紧密地合作，也得跟其他硬件伙伴配合。我们还在 Kubernetes 里引入了一些更底层的能力，比如 DRA（Dynamic Resource Allocation），这样，那些真正懂 GPU 长什么样、怎么切分的厂商，比如 Nvidia，就能用一种更通用的方式，把“这台机器上的 GPU 到底是什么资源形态”暴露给 Kubernetes。

另外一个很有意思的变化是：以前我们总喜欢把很多东西理解成无状态的，但训练看起来是，但根本不是。因为你一旦失败了就得从 checkpoint 恢复，而这件事成本很高，所以训练场景对失败的容忍度非常低。对很多人来说，失败已经不是什么“小问题”了，而是很严重的事。这件事带来的一个明显变化就是：大家看待失败的方式已经变了。

数据也是一样。比如以前大家通常不太在意 pod 在不同机器之间迁移，但如果某台机器上已经缓存了很多数据，哪怕这些数据别处也有，你重新下载一遍还是很花时间。这时候你可能就会更希望它尽量留在原地，而不是像以前那样，觉得随便漂一漂问题不大。

所以我会说，这里面确实有一些很深刻的变化。但我觉得它更像是“适配”，而不是“革命”。

Kubernetes 想解决的一件事，本来就是让很多人能用上复杂的能力，但不需要每个人都自己从零搭建。现在也一样。

很多人希望用微调，但不想亲自研究一遍微调到底怎么搞；也有人想做分布式推理，但并不想自己把整套东西摸透，他们单纯因为模型大到一定程度确实需要这个能力。所以另一个趋势就是，大家开始通过插件、定制资源（Custom Resource）这些方式，往 Kubernetes 之上叠加新的 AI 原生能力。

以前 service mesh 这些东西是这么加进来的，现在 AI native primitives 也开始这么加。我们自己也在做一些这样的项目，比如 Kaito，我们还在跟 Ray、vLLM 合作项目，让这些能力更容易用起来，包括 PyTorch Foundation 那边的一些项目也都在里面。

这点我其实看着挺开心的。我一直很喜欢云原生这套生态，但做到某个阶段你也会意识到，它不可能永远是唯一的基础。现在出现一些更聚焦别的方向的基金会、项目、生态，我觉得挺好。

但这背后说明的一件事，其实特别明确：vendor-neutral 的开源，对整个行业成功非常关键。你必须得让多家公司能围绕同一个方案下注。没有这个前提，很多生态其实长不起来。

3Kubernetes 如何适应 AI ？

主持人：OpenAI 曾发布过一篇文章介绍如何将 Kubernetes 扩展到数千节点规模。随着 AI 工作负载的出现，例如大规模训练和低延迟推理，Kubernetes 是如何适应这些新需求的？

Brendan：早期 Kubernetes 的规模上限大约只有一百个节点，因此后续的发展本质上是持续优化的过程。我们需要减少 API 噪声，将部分组件拆分出来，以支持更大规模。其中，etcd 往往成为扩展的主要瓶颈，因此如何高效运行 etcd，是实现大规模 Kubernetes 的关键。整体而言，大规模系统的演进方式并没有本质变化：运行系统、发现瓶颈、解决问题，然后不断迭代。

虽然 AI 训练通常涉及超大规模集群，但在云环境中，许多用户实际上运行的是大量小型集群，而非单一超大集群，这与传统数据中心模式不同。在云平台中，创建集群的成本极低，用户更倾向于按需创建多个集群。

这带来了新的挑战：如何管理“成百上千个集群”。过去我们关注的是“单个集群的规模”，而现在还需要解决“集群数量的规模”。例如，需要确保所有集群的监控系统一致、版本统一、权限配置一致等。这也是后来 Kubernetes 生态重点投入的方向之一。

主持人：随着 AI 需求持续增长，计算规模可能进一步扩大。如果规模提升一个数量级，Kubernetes 是否会遇到极限？

Brendan：从架构上看，大多数组件都可以通过横向扩展来应对更高负载。例如，API 请求增加，可以增加 API Server；调度压力增大，可以增加调度器实例。真正的瓶颈仍然集中在存储层，也就是 etcd。如果系统规模提升一个数量级，就需要评估 etcd 是否还能支撑，或者是否需要替换为具备相同特性但更高扩展性的存储系统。因此，限制并不在整体架构，而在具体实现细节。

此外，有一个普遍规律：当系统规模提升一个数量级时，瓶颈会发生转移。原本的主要问题可能消失，而新的问题会出现，例如从网络瓶颈转变为 CPU 瓶颈，或从内存瓶颈转变为网络瓶颈。总体而言，只要架构本身没有根本性限制，随着需求增长，工程实践通常能够找到解决方案。

主持人：你曾说过“软件的必然轨迹是走向消亡。”但我很难想象 Kubernetes 会消亡。你怎么看待这件事？

Brendan：我依然认同这个观点。不过在那句话之前，我其实还说过一句：你不应该爱上你写的软件，因为它的最终归宿一定是消亡。这意味着，当软件进入衰退期时，不应执着于它，更不应因为它是自己写的就不愿放手。相反，我们应该始终保持愿意舍弃旧系统的态度。

从行业历史来看，这一规律是普遍存在的。即使在 Kubernetes 项目内部，我当年写的代码在十多年的发展过程中，也已经被重写过多次。

至于软件“消亡”的形式，可能有两种。一种是被新的技术彻底取代：新方案实现相同功能，但更简单、更高效、复杂度更低、实用性更强。另一种是它逐渐变得“隐形”，仍然存在，但不再被关注。例如，在 Kubernetes 之下是 Linux，再往下是处理器，但大多数人并不会关注这些底层。

我可以想象一种可能性：如果自然语言接口足够成熟，人们只需要说“我想要一个可靠的 Web 服务”，而不需要再编写复杂的 YAML 配置，那么 Kubernetes 的使用方式甚至存在的意义都会发生改变。

从当前趋势来看，这种变化已经在发生。随着 AI 的兴起，越来越多的关注转移到了上层应用，而 Kubernetes 逐渐成为底层基础设施的一部分。就系统演进速度而言，我感觉 Kubernetes 的发展已经趋于平稳，只有与 AI 相关的部分仍在快速变化。

如果从更长远的角度来看，比如一百年后 Kubernetes 仍然存在，我会非常惊讶。计算技术的发展历史还不够长，我们无法完全确定哪些技术会长期存在。确实也有一些东西延续了很久，比如插头的形态，但更多技术都会被替代。

例如，几年前如果你问我 x86 架构是否会消失，我可能会认为至少在服务器领域不会。但如今情况已经发生变化：一方面，GPU 在计算中占据越来越重要的位置；另一方面，ARM 架构也在服务器领域崛起。这说明，预测技术未来是非常困难的，变化往往比预期更快，或者更慢。就像自动驾驶技术，人们一直说“再过五年就能实现”，但这样的说法已经持续了十多年。

4 落地用户开始关心什么？

主持人：你们客户现在关心的核心问题是什么？会怎么跟你提需求，比如更高效运行、更好的监控、可观测性之类的？

Burns：我觉得差不多都有。

第一类很常见的对话是：token as a service 和自己部署运行模型，这两条路到底怎么选？

这背后有很多维度。比如一些 proprietary model，你根本就只能通过 token as a service 的方式去用。但如果你自己部署模型，那你就得有更多能力。不过这么做，你可能会在成本上更有优势，或者你就是想放在本地跑，因为有数据合规、数据不出域之类的考虑。

所以我们经常会跟客户讨论：这两套模式怎么一起用？比如你一边通过平台服务去调 OpenAI 的 token as a service，一边又在 AKS 的 GPU 上跑 Llama 2，或者跑 Phi 系列的小模型。

我之前还会跟人开玩笑说，你最好别每句“你好，在吗”都去调最贵的大模型，那根本不划算。

我觉得现在大家已经开始慢慢有这种“模型路由”的意识了，也就是你不能把所有请求都一股脑丢给同一个模型。一方面，不同模型擅长的事情本来就不一样；另一方面，成本曲线差别也大得离谱。所以像微软做的那类小模型，比如 Phi，用来做一般对话、做摘要、做很多包裹在主任务周围的基础型工作，其实完全够用。这是我们和客户经常聊的一类问题。

另一类问题是：AI 应用到底该怎么构建？

调用 API 这件事本身并不难，大家都知道怎么调。难的是，你怎么换模型、怎么改 prompt，以及你怎么在这个过程中别把系统搞坏。

过去 10 年，我们其实很大一部分时间都在教人一件事：怎么把代码发布出去，同时别把线上搞挂。当然现在大家还是会搞挂，我也不是说这个问题已经彻底解决了，我们自己也一样还是会踩坑。但到了 AI Ops 这个世界，事情又更难了一层，因为“它到底有没有正常工作”这件事，主观性强太多了。你可能 HTTP 200 全是绿的，系统看起来一切正常，可如果内容质量很差，那你其实就是没把活干好。这时候你的 monitoring 逻辑就得变。

以前你主要盯 error，现在不行了。现在你的监控体系里必须带“人”的维度。你不光要问：“有没有返回答案”，你还得问：“这个答案是不是个好答案”。而这件事又不能简单交给另一个模型替你判断，所以这变得很微妙。

我们现在有不少做法，很常见的一种就是让用户点赞 / 踩，但即便是这件事，你也得教用户怎么点。

我记得我最早有一个团队上线 AI 应用的时候，看到点踩的比例很高，大家都吓坏了，以为这产品是不是太烂了。后来才发现不是这么回事。因为如果答案挺好的，很多人压根不会点赞，就像你去理发，理发师正常发挥，你大概率不会特意冲回去给个五星好评。但要是理差了，你肯定会吐槽。

所以这个指标，本质上是个相对指标，不是绝对指标。比如你的点踩率从 50% 掉到 40%，那是好事；可如果它从 10% 涨到 20%，那就是坏事。哪怕你说“20% 也不算特别夸张”，但趋势错了就是错了。

因此，对于很多 AI 指标，你得从“绝对值思维”切到“相对变化思维”。

另外还得看行为层面，比如一个人和这个系统来回对话了多少轮。大多数时候，用户不是闲得没事在那聊天，他们是想把某件事办成。如果一个人为了拿到答案，和系统反复来回 10 轮、15 轮、20 轮，那很可能说明你没有在一开始就给对方向，用户一直在修 prompt、一直在补信息。这其实也是很重要的信号。

但问题又来了：你想看这些聊天内容，本身也不容易。因为隐私是个大问题。大家必须显式选择愿意把这些数据发给我们，我们才能看到真实交互，所以一下子就冒出来很多以前根本不存在的复杂度。以前做 Web 应用时，你只需要问：页面有没有渲染出来？HTML 有没有正确返回？现在完全不是这个层面的事了。

主持人：你有没有看到一些搭 AI 应用的最佳实践？

Burns：有的。我觉得现在越来越普遍、也越来越重要的一条就是：你的测试里必须包含大量不同的 prompt。

以前写单元测试的时候，你会说，“这个 case 有个单元测试就行了。”现在不是这样了。现在更像是：我手里有 1 万条 prompt，然后我要把这 1 万条全跑一遍。

其实我们做 Web 搜索的时候就是这么干的。你不会只测一个 query，你会测 1 万个 query。因为你每改一次系统，不是所有东西都会同时变好。有的变好，有的会变差。你关心的是整体上有没有变好，而不是某一个点是不是漂亮。AI 应用也是一样。

当然，真到了 1 万条 prompt、1 万种体验的时候，又会碰到另一个问题：你怎么评估结果？你让人一个个读吗？不现实。这时其实可以把结果再喂给一个 LLM，让它来做一层判断。你可以问它：“这是 prompt，这是回答，这个回答好不好？”

LLM 在这件事上，做得其实已经相当不错了。至少它能给你一个相对信号，告诉你这版是变好了还是变差了。所以我觉得，这已经是一个非常值得推广的最佳实践。

另外一个越来越重要的做法，就是产品测试，也就是在生产环境里测试。

什么 1% rollout、灰度实验，这些以前大家不是没聊过，也不是没人做。但在 AI 时代，它的重要性又往上升了一层。

对于做 AI 应用的人来说，除了示例 prompt 以外，他们唯一真正能看到“这个东西在真实世界里到底表现怎样”的方式，往往就是 1% 实验。以前这可能更像是 UX 团队或者某一小部分团队的工作；现在不是了。现在这件事得贯穿整条技术栈，让每一层开发者都能有机会接触到真实交互流。

5代码 review，成为新人必备技能

主持人：大家都在说一个问题，现在代码生成速度太快了，结果 code review、测试等反而成了新的瓶颈。有时候感觉，1% rollout 都快成了某种“先丢出去看看会不会炸”的方法了。当然不是说乱上，但大概那个意思。你在微软也看到这种情况了吗？

Burns：我先说清楚，我们肯定不会把开发者随手写出来的东西直接丢上线，没那么野。不过你说的现象，我确实看到了。

很多人，尤其一些资深 leader，会跑来跟我说：“我们是不是得多招点首席工程师、高级工程师？因为现在代码太多了，根本 review 不过来。”但我其实会直接跟他们说：我觉得你这个想法本身就错了。主要错在两个层面。

第一，他们默认 code review 这种事，只有首席或高级工程师才能做。这个想法以前某种程度上成立，因为初级工程师、应届生，或者刚入行两三年的人，以前的主要工作就是写代码。但我觉得现在，岗位本身已经在变了。未来每个人的工作，其实都会越来越多地变成“review code”。你当然还是会写一些代码，但越来越多代码会由自动化生成，而你的工作会变成判断、审阅、把关。而我不觉得 code review 是一种必须靠三年、五年经验慢慢熬出来的神秘能力。它就是可以教的。

所以我一直在推动一件事：你得主动教新毕业生、初级工程师怎么做好 code review。就像当年行业默认要教他们怎么用 CI/CD，或者我刚入行时，大家会教新人怎么用版本控制一样。这些东西没有人天生会，学校里也没教，大家已经默认企业得补这课。只是以前 code review 不在这份“必补清单”里，因为那时候它还不是岗位核心。

但现在， code review 已经成岗位核心了，所以它会从一种“默认你以后慢慢就会了”的隐性能力，变成一种要被明确训练的显性能力。当然我也希望，未来计算机科学教育能慢慢跟上，把 AI 和 code review 这些内容更系统地放进教学里，那样大家入职时可能就已经具备一部分能力了。但现在显然还没到那个阶段。

第二个我觉得大家也想错了的地方，是大家总在问：现在代码太多，怎么处理 review 压力？但我更喜欢反过来问：到底要满足什么条件，你才会不在意“这段代码有没有被人逐行 review”？

我觉得很多人都忘了一个事实：大家现在老在说，“我们 97% 的代码已经是机器生成的了”。

可你是不是忘了，只要用了编译器，你的代码就本来是 100% 机器生成的。汇编代码不就是机器生成的吗？而且我们早就不在意那层代码了。几乎没人去看汇编，也没人指望汇编可读、可 review，它本来就是瞬态的。你写高级语言，编译器把它翻译成汇编，然后你相信——而且通常这个信任是对的——编译器有足够好的测试，所以它产出的东西基本靠谱。

AI 代码生成这件事，未来我觉得也会往这个方向走。如果你的测试越来越强，spec 越来越清楚，验证输出正确性的框架越来越成熟，那到某个阶段，我们自然就会开始说：这段 AI 生成的代码本身其实也是瞬态的。下次我重新跑一遍，它还会再生成。真正重要的是 spec，是 tests。

6 未来的编程语言或为 AI 设计

主持人：这套说法我最近确实听到越来越多，这可能真的是未来要去的方向。

Burns：我觉得这就是我们正在走向的世界，而且这里面还有一个特别有意思的问题：编程语言本身会怎么变。

其实早就有一些语言在朝这个方向走了，像航空航天这类行业里就有很多更严格的语言设计，它们会在前置条件、后置条件、可验证性、可证明性这些地方做很多限制。关于“程序可证明性”这件事，计算机科学学界其实有很长的历史，但这些语言长期没真正普及的一个很大的原因就是限制太多了。

某种程度上，Rust 就是个很好的例子。Rust 通过更严格的语法限制，换来更强的可证明保证，尤其是在内存管理这件事上。但程序员很多时候并不喜欢这种感觉，因为它写起来不够顺手，会让人觉得被束缚。工程师天然就不太喜欢这种“你只能这样写”的感觉。

可问题是，人类程序员不喜欢，AI 也不喜欢吗？我不确定，也许 AI 根本不在乎。所以我觉得，未来一个特别值得看的方向，就是编程语言会不会开始朝着“更适合 AI 生成”的方向演化。

现在的 AI，本质上是在生成“原本为人类设计的编程语言”。我以前打过一个比方：我们想造自动驾驶汽车，结果选的方案是先造一个机器人，让它抓着方向盘开车。但真正的自动驾驶汽车不是这么造的。你看 Waymo，虽然还是车的样子，但它底层是另一套控制方式，是线控、传感器，是直接控制轮子的系统。我觉得编程语言未来大概率也会这样。

既然一定会有相当比例的代码是 AI 生成、机器生成，那真正有意思的问题就会变成：未来的编程语言长什么样？它到底还是不是那种主要给“人类团队手写”的语言？我觉得，这才是更深的一层变化。

7Kubernetes 如何从零开始？

主持人：我其实不完全理解 Kubernetes 背后的商业动机。假设我是你的主管，你如何说服我把这个东西做成一个面向整个行业的项目？

Brendan：在项目早期阶段，最困难的部分正是如何把这件事讲清楚。我们自己心里很清楚它的价值，但要说服他人却并不容易。为此，我们从多个角度进行了论证。

其中一个重要论点与 MapReduce 白皮书有关。当时，以 Hadoop 为代表的大数据技术正处于风口，“大数据革命”被广泛讨论。Google 撰写了最初的 MapReduce 白皮书，但 Hadoop 作为开源项目，与 Google 并无直接关系，Google 也未因此获得相应的影响力。Hadoop 只是基于论文进行了复现，虽然相似，但本质上并不相同。由此我们意识到，如果我们只发布白皮书，而不提供可运行的系统，就无法真正主导技术的发展方向。因此，我们的一个核心论点是：既然我们拥有云平台，就应当通过可运行的技术来影响整个技术生态，而不仅仅停留在理论层面。

第二个论点围绕“为什么选择容器，而不是虚拟机”。当时已有大量用户使用虚拟机，但我们在内部实践中已经明确感受到，构建可靠的软件系统，需要一种类似“自动驾驶”的基础设施来管理应用运行。随着软件对企业的重要性不断提升，这种能力将成为刚需。因此，容器及其编排系统将具备长期价值。

第三个关键问题是“为什么要开源”。很多人认可前两个论点，也同意这个系统对行业有价值，但会进一步问：如果只在我们自己的平台上提供，不是更有利吗？答案是，虽然这样看似更有利，但实际上无法取胜。

因为市场上存在多个平台。如果将技术限定在自有平台上，那么那些出于各种原因使用其他云或本地部署的用户就会被排除在外，他们自然会选择自行构建替代方案。开源技术之所以能够胜出，正是因为它可以在任何地方运行。就像 Linux 的成功，本质在于其无处不在的适用性。

当时的 Google 云并非市场领导者，这意味着大多数用户并不在我们的平台上。如果我们构建的技术无法被多数人使用，他们就会忽视我们，转而开发自己的方案。相反，如果我们构建一个面向所有人的系统，同时确保它在我们平台上的体验最佳，就有机会吸引更多用户。

此外，这也与当时的技术氛围有关。几乎所有关键技术，无论是操作系统、容器，还是编程语言，都在走向开源。如果我们选择封闭，就会显得格格不入。历史上确实存在少数封闭技术也能成功的案例，但前提是其差异化必须极其显著，强到足以让用户忽略其封闭性，而我们当时并不具备这样的优势。

主持人：从当时的竞争格局来看，Amazon 已经占据主导地位，而 GCP 仍在追赶。因此，这一策略是否可以理解为：通过开源 Kubernetes 吸引开发者，从而带动他们向 GCP 迁移？

Brendan：更准确地说，是让他们开始关注我们，同时改变整个市场的讨论方式。如果只是跟随已有路径，比如在虚拟机领域与对手做微小差异化竞争，这种策略很难讲清楚，也很难取得突破。但如果我们开辟一个全新的技术领域，并成为其中的思想引领者，即使用户不在我们的平台上使用该技术，他们也会倾听我们的声音。这会显著提升我们在行业中的话语权，并改变市场叙事。

这种对“话语权”的掌控，是打破既有竞争格局的重要方式。当然，这并不意味着竞争会因此变得容易，事实上，即便今天，这种格局依然很难撼动。但至少，这一策略帮助 Kubernetes 成为整个云计算领域的基础设施，几乎所有云厂商最终都围绕它达成了共识。

主持人：你“思想引领者”带来的认知优势，这从结果看确实成立，但在当时向管理层汇报时，你们是否已经明确意识到这种价值？

Brendan：我们确实明确提出，希望在技术思想层面占据核心位置，并强调其价值。成为思想引领者，本身就是一项重要资产。

主持人：但这类价值似乎很难量化，该如何判断其投入产出？

Brendan：当时的投入其实非常有限，大约只有八到九名工程师。同时，我们刻意将 Kubernetes 作为一个独立品牌，与 Google 品牌区分开来。这一决策既是优势，也带来一定风险。一方面，它降低了失败成本，如果项目失败，可以直接终止，而不会对整体云业务造成负面影响；另一方面，它也为项目提供了更大的灵活性。

开源同样带来了多重好处：一是促进了技术的广泛采用；二是在引入 Linux Foundation 等中立组织后，使得包括 Red Hat、Microsoft Azure 以及 AWS 在内的厂商都能够放心投入；三是作为一种“风险对冲机制”，降低了项目失败的影响。

此外，这种相对独立的组织方式也提高了我们的敏捷性。当时我们实际上是在与像 Docker 这样的初创公司竞争，它们行动迅速，而大型企业通常较为迟缓。通过这种方式，我们在一定程度上获得了类似初创团队的灵活性。

主持人：项目最初的形态，是你和另外两个人快速搭建的一个原型吗？

Brendan：是的，本质上就是一个 Demo。我们只是将现有的一些开源技术组合在一起，展示如果这样整合，可以实现什么样的效果。

那个 Demo 实现的是一个非常基础的控制系统。当时甚至需要先向大家解释 Docker 的概念，说明如何通过 Docker 构建容器镜像，然后将其部署到集群中。系统可以将应用分发到多台机器上运行，并通过一个统一入口实现负载均衡，例如多次刷新请求会命中不同的副本，从而展示其分布式特性。此外，还包括基础的健康检查机制，即当实例被终止后能够自动恢复，以及简单的版本升级能力。整体功能非常精简，但已经能够体现系统的核心价值。

主持人：这个最初的 MVP 花了多长时间完成？

Brendan：大约四到五天时间。

主持人：你当时是暂停了原有的工作，专门来做这个项目吗？

Brendan：严格来说并没有完全中断原有工作，但在那个时间尺度下，是可以做一定调整的。例如一周的时间里，进度略有放缓是可以接受的。组织本身也具备一定灵活性，使我们能够抽出时间快速完成这个原型。

当然，这个 MVP 是非常粗糙的，几乎采用了所有可能的捷径。我个人一直比较擅长整合现有的开源项目，将现成组件拼接起来，用少量“胶水代码”连接，从而快速实现整体效果。因此，很多底层能力其实都来自已有的开源项目，这也是我们能够在短时间内完成原型的重要原因。

主持人：当时 Google 内部的 Borg 系统本身具有竞争优势，将类似能力开放出来是否会引发顾虑？

Brendan：确实存在这样的担忧。但我当时的一个观点是：技术并不会被永久封锁。员工会流动，经验会传播，这些能力迟早会在行业中扩散。事实上，当时我们与其他公司交流时发现，包括 Facebook、Twitter 在内的多家大型技术公司，都在构建类似系统，这并非真正的“秘密”。

此外，当时已经可以预见，行业中一定会出现一个开源解决方案，问题不在于“是否会出现”，而在于“由谁主导”。因此，我们将问题重新表述为：既然开源不可避免，那么我们是选择参与并施加影响，还是让别人来主导。这种表述帮助大家理解，所谓“保持封闭”其实并不是一个现实可行的选项。

主持人：在构建编排系统的最初 MVP 时并没有真实客户可供参考，你们是如何判断上线前所需的最小功能集的？

Brendan：我们在这方面其实受益于团队构成。当时只有三个人参与：Craig 更偏产品与业务，Joe 擅长工程实现与 API 设计，而我主要负责快速编写原型代码。这样的组合使我们既能从产品视角思考问题，也能在技术上迅速落地。

在功能选择上，我们主要基于自身经验，以及对行业痛点的理解。我们长期观察到，在传统虚拟机基础设施上部署应用存在诸多问题，这些痛点为我们提供了清晰的方向。同时，当时以 Netflix 为代表的一些公司，已经在推动“不可变基础设施”等理念，整个行业也在朝类似方向演进。因此，虽然当时并没有真实客户，但这些潜在需求实际上是存在的，只是尚未被正式表达。

从某种意义上说，Kubernetes 并不是一个全新的发明，而是对当时行业中多种已有理念的整合与系统化表达。它将这些分散的思想汇聚起来，形成了一个清晰的技术锚点。

主持人：在最初的 MVP 中，你承担了大部分开发工作？

Brendan：大致在 80% 以上，甚至可能更高。即使后来我已经很少直接参与 Kubernetes 的开发，在 GitHub 的贡献列表中仍然排名前列，早期更是长期位居第一。

主持人：当 Kubernetes 开始扩展时，你们是如何说服其他公司和开发者采用的？

Brendan：在早期阶段，一个非常有效的切入点是“非差异化重体力劳动”（undifferentiated heavy lifting）。对于许多公司来说，他们的核心目标并不在基础设施层。例如，OpenShift 想构建的是平台即服务，而其他早期用户也只是希望搭建可靠的 Web 服务。在这种情况下，底层编排系统并不是他们的核心竞争力。因此，我们的逻辑很简单：既然大家都需要构建这套基础能力，不如共同完成。相比各自重复建设，协作带来的收益更大。对很多早期合作伙伴而言，这一点非常有说服力。

与此同时，我们也强调“共同治理”。依赖一个外部项目，意味着某种程度上要依赖他人的路线图，这通常会引发顾虑。因此，我们明确传达：不仅可以使用 Kubernetes，还可以参与设计决策。当他们需要新功能时，可以直接贡献代码，并影响项目方向。这种“共建”关系，使 Kubernetes 与各方的技术路线形成对齐。

随着时间推移，生态效应开始显现。无论是网络厂商还是存储厂商，当他们的用户逐渐转向 Kubernetes 时，就必须确保自身产品能够与之良好集成。这种由用户需求驱动的生态扩展，进一步加速了 Kubernetes 的普及。

主持人：你们如何避免 Google 对 Kubernetes 的路线图形成过度控制？

Brendan：这是一个至关重要的问题，也是 Kubernetes 能够成为行业标准的关键因素之一，核心在于“独立性”。

首先，我们在项目发布仅一年后，就将 Kubernetes 捐赠给 Cloud Native Computing Foundation（隶属于 Linux Foundation）。包括代码、商标、品牌等在内的所有权，都转移至独立的基金会。这一点非常关键，因为如果某一公司掌握商标或法律控制权，其他企业很难放心参与。

其次，是治理机制的建立。早期 Kubernetes 并没有正式的治理规则，这是一个失误。直到 2016 年，我们才系统性地制定了治理框架。其核心原则是：不允许任何单一公司控制项目。我们构建了一套更加民主、分布式的治理体系，并将其写入正式文档中。

从一开始，我们就没有打算采用“仁慈独裁者”（BDFL）模式，而是希望打造一个多方共治的社区。这种治理结构，确保了 Kubernetes 既是行业标准，而非某一公司的专属标准。

法律上的独立性与治理上的开放性，是相辅相成的，缺一不可。

对于任何考虑采用 Kubernetes 的公司来说，核心问题是：我在押注谁的路线图？只有当答案是“一个开放且中立的社区”时，这种押注才是可接受的。

主持人：是否真的像政府一样，有类似“宪法”的文件？

Brendan：可以这么理解。我们确实编写了类似“宪章”的治理文档。那些是我们自己写的，大约由六到七位核心成员，在几次高强度会议中完成。我们参考了其他开源社区的经验，总结哪些做法有效、哪些存在问题，并明确我们希望实现的目标。一部分内容是对既有实践的制度化，另一部分则是全新设计，例如设立指导委员会（Steering Committee）。

我们当时还组建了一个“引导委员会”（Bootstrap Committee），大约七八个人。这些人都被社区广泛认可为技术领导者，彼此之间也没有明显分歧。这一点非常关键，使我们能够在没有内耗的情况下，构建一套被广泛接受的治理体系。这里也要特别提到当时的社区负责人 Sarah Novotny，她在推动这一过程上发挥了重要作用。

主持人：在 Kubernetes 中，社区贡献占比大概是多少？

Brendan：我没有具体数据，但从整体开源经验来看，通常是 80% 到 90% 的贡献来自核心贡献者，其他用户的贡献占比较低，推动广泛参与其实非常困难。

一个重要原因在于企业结构。例如微软这类公司会在战略层面投入资源参与开源，因此会组建专门团队进行贡献。但对于许多 Kubernetes 用户，例如零售或金融企业，技术只是业务手段，而非核心竞争力。在这种情况下，很难说服管理层将工程资源投入到上游开源项目中。此外，一些企业在法律层面也存在顾虑。例如担心代码贡献可能带来潜在责任风险，尽管开源许可证通常已明确免责条款，但这种担忧仍可能阻碍参与。

8 把你 10% 的精力“藏起来”

主持人：很多软件工程师听到这个故事时，往往会觉得自己已经有既定的工作职责，即使某个想法很好也很难抽身去实现。你会给这类人什么建议？

Brendan：首先，我一直告诉团队成员：你大致可以“隐藏”约 10% 的精力，不必完全向管理层披露。任何组织中都存在一定的弹性空间，而且组织越大，这部分空间往往越大。许多真正有影响力的想法，恰恰来源于这部分自主支配的时间。

本质上，这是鼓励人们在局部范围内自主决策，而不是事事向上请示。当然，这也意味着你会做出一些错误决策、浪费一部分时间，因此需要接受试错的成本。

从结果来看，这种方式的收益并不对称：你可能多次尝试，只有一次成功，但这一次的回报往往远超持续“稳健优化”带来的收益。你需要接受这样一种现实：部分尝试最终是无效的，甚至会影响绩效表现，比如从“超出预期”变为“符合预期”。但只要不跌破基本要求，这种风险是可以接受的。当然，这种路径并不适合所有人，它更适合愿意承担不确定性的人。

另一方面，我也会提醒大家：时间本身是可以重新分配的。很多人会说没有时间，但实际上大多数人每周至少有 10-20 小时用于娱乐，比如打游戏、看 Netflix 或刷 YouTube，而在那段时间里，我几乎只是在写代码和工作，外加基本的生活需求。因此，关键问题在于你愿意为此放弃什么。这并不意味着需要极端加班，但确实意味着要在一段时间内减少娱乐活动。

对我来说，更重要的是这个过程本身具有很强的吸引力。一方面，我本身就喜欢写代码，在“看视频”和“写代码”之间，我更倾向于后者。另一方面，当项目开始被用户使用，大家在 GitHub 上提交问题、表达兴趣时，这种反馈会带来持续的动力。我会不自觉地想去解决问题、帮助用户，甚至工作到深夜。这种投入更多源于兴趣，而不是对长期回报的理性计算。当时我并没有在思考职业收益，而是单纯希望把这件事持续推进下去。

主持人：“隐藏”10% 的时间，在实际操作中具体意味着什么？

Brendan：这意味着你应该始终有一个“自发项目”，即一个并非被指派，但你认为重要的事情，并持续投入时间去推进。

主持人：你说的“隐藏”是不是更像是管理预期，而不是字面意义上的隐瞒？

Brendan：不，我的意思是不要一开始就申请许可。你需要先花一段时间把事情做出雏形，再展示给他人。因为在 Word 或 PPT 中解释一个想法的价值是很困难的，而一个可以实际运行的系统更具说服力。因此，先构建出一个可用原型，再进行沟通，会大大提高成功概率。

此外，这种方式还会改变决策的结构。原本的问题是“是否应该投入时间去做这件事”，而当你已经完成了原型后，问题就变成了“是否要发布这个成果”。后者通常更容易做出判断，因为重点不再是资源分配，而是项目本身的价值。

主持人：从原型到获得管理层认可，中间经历了一段不短的时间。

Brendan：是的，大约经历了六个月的过程，从一个非常粗糙的原型，发展为一个我们认为可以被实际使用的系统。早期加入的许多工程师都曾构建过类似系统，这对他们而言是一次难得的“重做机会”。在工程师职业生涯中，很少有机会在没有历史包袱的情况下，从零开始设计一个系统。这就像获得第二次机会，可以按照自己理想中的方式去实现。因此，这种“干净环境”对团队成员具有很强的吸引力。

主持人：如果项目最终没有成功，这种做法是否存在风险？

Brendan：当然存在，这正是需要承担的代价。你可能花了时间写代码，却没有任何成果，也可能因此错失晋升机会。这本质上是一种风险投资，与创业类似。关键在于进入这一过程时的心态：你应该认为这是一个值得尝试的想法，但同时也接受失败的可能性。如果一开始就预期一定会成功，反而更容易失望。

主持人：在职业发展的后期，这种主动创造项目的能力，是否会成为晋升的必要条件？

Brendan：在一定阶段之后，确实如此。你不再只是执行他人提出的想法，而是需要自己提出并推动有影响力的项目。这是角色转变的重要标志。此外，如果一个项目完全由你发起并成功落地，其成果归因会更加明确；而参与他人主导的项目，即使取得成功，也较难完全归功于个人。但需要强调的是，这仍然是一种“概率游戏”。有些人可能多次尝试却未能成功，或者在错误的时间提出了正确的想法。创新不仅取决于想法本身，还取决于时机是否成熟。

主持人：你在机器人领域获得了博士学位，很多人对是否攻读博士持不同看法，你怎么看待？

Brendan：这是我最常被问到的问题之一，我通常会用两个方面来回答。

首先，有一次我在同一家公司遇到一位大学本科同学。他毕业后进入科技行业创业，辗转发展，而我则去攻读了博士学位，之后再回到工业界。最终，我们在同一家公司、同一职级上相遇。我们毕业于同一年、拥有相同的本科学历，职业发展路径不同，结果却相似。这从某种程度上说明，是否读博可能并不会对职业结果产生决定性影响。

但从另一个角度看，我在攻读机器人博士期间确实收获了很多乐趣，这本身对我来说就很有价值。同时，我也学到了很多在工业界不容易系统掌握的能力，例如如何清晰地写作、有效地表达和展示自己的观点。这些能力后来对我产生了实际帮助，比如在我们在花六个月时间争取将某个项目开源的过程中，我的表达和论证方面能力发挥了重要作用，并且这种能力一直持续影响着我的职业发展。

此外，我后来曾担任过几年教授，教授计算机导论课程，需要向几乎没有计算机基础的学生讲解概念。这段经历让我学会如何系统化地组织知识、从零开始解释复杂问题。这种能力在我参与 Kubernetes 项目早期阶段时也发挥了重要作用。当时很多人对容器、编排等概念一无所知，需要大量教学与引导，而我在教学中的经验帮助我更好地完成了这项工作。

主持人：关于“最常被问的问题”，排在第一的是什么？

Brendan：另一个非常常见的问题是：我应该学习什么？尤其是当我与实习生或刚入行一两年的新人交流时，他们常常会纠结。比如现在 AI 很热门，但自己更喜欢系统方向，那么是否应该转去学 AI ？

我的回答其实很简单：具体学什么并不重要，重要的是你是否在持续学习。关键在于找到真正让你感兴趣、能够激发你投入热情的方向。只有这样，你才会主动投入时间，而不是被动消耗时间。如果你对 AI 并不感兴趣，那么很可能也学不好，最终只是浪费时间；而如果你对系统领域充满热情，就更有可能投入精力并取得成果，而且行业依然需要系统工程师。

很多人内心存在一种对“选错方向”的焦虑。但我一直告诉大家，我的职业生涯从来没有一个明确的长期规划，我只是不断追随那些我认为有价值、有趣的事情。当然，这种方式未必适合所有人，但我希望大家明白，很多当初看似错误或死路的选择，实际上都成为了重要的学习经历。与其担心是否做出了错误选择，不如专注于持续学习。只要你在不断成长，方向通常不会偏得太离谱。

9one more thing：Burns 成长史

Burns 的成长路径，并不是一条标准意义上的“技术精英路线”。相反，他兴趣广泛、方向分散，甚至有点“不务正业”。

本科时期，他就读于位于马萨诸塞州西部的 Williams College。这所小型文理学院给了他很大的自由度，让他可以同时尝试多种不同的事情。除了主修课程之外，他还混过校园电台，也参与过不少别的活动。对 Burns 来说，这段经历最重要的意义，并不只是学到了什么具体技能，而是让他更早意识到，自己本来就是一个对很多事情都好奇的人。

艺术和计算机科学在在 Burns 身上汇合，因为它们都指向同一件事：“做东西”。他一直很喜欢创造，无论是做雕塑、做实体创作，还是写程序、搭系统，本质上都是在把一个想法变成一个可以被看见、被触碰、被运行的具体存在。也正因如此，艺术和计算机科学最终都对他产生了持续的吸引力。艺术让他学会如何塑造和驱动实体世界中的对象，计算机科学则让他能够在数字世界里构建系统、操控机器，两条线后来也慢慢在他的职业道路上合流。

Burns 算得上是很早就进入计算机科学的人。他从 1994 年开始读本科并选择这个专业，那时互联网才刚刚起步，差不多还是 Mosaic 浏览器刚出现不久的年代。等到 1998 年毕业时，外界很容易把他的选择理解为“看准了时代趋势”，好像他早早就预判到了互联网浪潮会席卷一切。但 Burns 自己并不这么看。他更愿意把这件事归结为一种朴素的迷恋：从小到大，他一直对这些机器着迷。和那个年代的很多年轻人一样，最初吸引他的，确实有电脑游戏的成分，但游戏并不是终点，真正让他留下来的，是想弄明白机器究竟是怎么工作的。他不满足于只是使用它，而是想理解它、控制它、摆弄它，想知道系统背后的逻辑到底是什么。

大学毕业后，他正好撞上互联网泡沫最热的时候。那几年，行业里的主流叙事几乎都是：一切都要变成 Web App。那还是动态 Web 应用最早的一段时期，整个技术世界都在快速试验、快速生长。Burns 也在那股浪潮中参与了 Web 应用开发。

但与此同时，他心里一直有另一个目标：当教授。于是，在产业界待了一段时间后，他又回到学校继续深造。后来他坦言，那段重新回到学术环境的决定，现在看起来像是很有先见之明，因为他是在 2000 年进入研究生院的，几乎踩在互联网泡沫破裂的前夜。一年之后，当他已经在招生委员会翻看下一届申请者材料时，甚至忍不住感慨：如果让那时的自己和这批人一起竞争，恐怕未必还能顺利进去。因为泡沫一破，原本冲向产业界的那批程序员，又有很多回流到了学校，而他恰恰是在那之前完成了转身。

在研究生阶段，Burns 继续沿着“实体世界”和“数字世界”结合的方向往下走，最终拿到的是机器人方向的 PhD，其中又包含了相当多 AI 和 robotics 的内容。这也成为他成长过程中非常关键的一段：他开始系统地研究，如何把 AI、机器人、物理系统和计算机系统真正接到一起。对他来说，这不是一条抽象的研究路径，而是一种非常具体的工程兴趣。他喜欢思考，也喜欢动手，把控制理论、规划、系统设计这些原本分散的知识点真正放进一个可运行的整体里。很多年后回头看，他也越来越意识到，那时候学过的控制理论、规划方法以及“规划和控制之间的差别”，并没有停留在机器人论文里，而是实实在在影响了他后来做系统架构的方式。

除了学术训练之外，Burns 还在很早的时候就接触了开源，这对他的职业观念影响极深。互联网泡沫时期，他在做 Web 应用开发时开始使用 JMeter——一个用 Java 写的负载测试工具。用着用着，他发现了一些 bug，于是开始往项目的邮件列表里发 patch。那是 1999 年，彼时没有 GitHub，甚至连 git 都还没出现，开源协作还停留在“靠邮件发 patch”的年代。Burns 后来回头去翻档案，发现自己当年真的是一封封邮件在往外发代码修改。最开始并没有人理会这些 patch，直到后来他主动去问，才得到回复：这个项目已经没人维护了，你要不要接手？年轻时的他，并不知道“当 maintainer”到底意味着什么，只是觉得听起来不错，于是就答应了。后来，他和另外一个人一起把这个项目接了下来，开始负责合并补丁、处理问题、维持项目运转。这段经历，让他第一次真正从“使用开源”走向了“维护开源”。

更有意思的是，这个项目后来并没有死掉，反而一路活了下来，甚至最终被整合进 Azure 的负载测试服务里。对 Burns 来说，这件事有点像一种奇妙的时间回环：他早年参与维护的一个开源工具，很多年后居然以另一种方式重新出现在自己的职业世界中。更有趣的是，这里面甚至还留着一点他本科时代“艺术”那一面的影子。因为刚接手项目时，他嫌原来的图标不够好看，索性自己动手画了一套带有浓烈早期 Java 风格的图标——有点像 Windows XP，再加一点紫色调。那套图标后来居然又陪着这个项目活了十年，直到风格彻底过时。这在 Burns 看来，几乎就是开源世界里“legacy”最生动的样子：很多东西不是因为谁精心设计成“历史遗产”，而只是因为它一旦真的进入系统，就会比你想象中活得更久。

后来，Burns 还做过几年教授，也认真投入过学术工作。但最终，他还是意识到两件事。第一，他非常想回到西雅图，那是他长大的地方；第二，比起留在学术体系里，他越来越确定，自己真正喜欢的是“做有人在用的软件”。在那段时间里，他曾在 Android 还没有真机普及、大家主要依赖模拟器的年代，做过一个可视化的 WYSIWYG 界面编辑器。那时候做 Android GUI 基本得手写 XML，而 Burns 觉得这件事太反人类，于是自己写了一个拖拽式的 GUI builder。后来开始有用户真的使用它、反馈它、喜欢它，这件事给他的刺激非常大。对 Burns 来说，一旦亲身体验过“有人真的在用你做的东西”，那种吸引力就会变得很难抗拒。

也正是在这种感受推动下，他慢慢意识到，自己最终还是应该回到产业界。后来他进入 Google，加入 Web 搜索基础设施团队。现在回头看，这个机会很大程度上来自他在机器人和系统编程上的积累——尤其是 C 和 C++。在那个年代，Google 的岗位分配还不是今天这种高度细分的模式。你申请的是 Google，而不是某一个具体团队；真正加入后，公司再根据你的背景和偏好分配岗位。Burns 选择了 systems 方向，而他过往在机器人上的底层编程经验，也让他很自然地被放到了对性能要求极高的搜索基础设施团队。

这段经历让 Burns 第一次真正体会到，“有人在用”和“几十亿人在用”完全不是一回事。此前他做的 Android 工具已经让他体会到了用户反馈的快感，但 Google 搜索的量级是另一种世界。对一个喜欢做系统的人来说，看着自己参与构建的东西被数十亿人使用，那种冲击力和成就感是完全不同的。更重要的是，Google 搜索基础设施的经历，让他真正积累了大规模分布式系统的经验。后来，当公司内部进行重组、他被调到 cloud 方向时，他过往在开源社区里的经验，和在搜索基础设施里打下的分布式系统能力，第一次真正合到了一起。再往后，这些积累逐渐汇成了 Kubernetes 的雏形。

https://www.youtube.com/watch?v=jXGoIqxe8eY

https://www.youtube.com/watch?v=FKijpCEH9D8

声明：本文为 InfoQ 编译，不代表平台观点，未经许可禁止转载。

会议推荐

世界模型的下一个突破在哪？Agent 从 Demo 到工程化还差什么？安全与可信这道坎怎么过？研发体系不重构，还能撑多久？

AICon 上海站 2026，4 大核心专题等你来：世界模型与多模态智能突破、Agent 架构与工程化实践、Agent 安全与可信治理、企业级研发体系重构。14 个专题全面开放征稿。

诚挚邀请你登台分享实战经验。AICon 2026，期待与你同行。