Kubernetes 被 AI 打回“半成品”！K8s 之父發(fā)出警告：代碼生成越快，程序員越危險(xiǎn)

整理 | 傅宇琪、褚杏娟

很多人提起 Kubernetes，第一反應(yīng)還是云原生時(shí)代最成功的開源項(xiàng)目之一、容器編排的事實(shí)標(biāo)準(zhǔn)、現(xiàn)代基礎(chǔ)設(shè)施的“操作系統(tǒng)”。但在 Brandon Burns 看來，AI 的到來，正在把這套系統(tǒng)重新推回“未完成”狀態(tài)。

長期從業(yè)的開發(fā)者對 Burns 并不陌生，他是 Kubernetes 的聯(lián)合創(chuàng)始人之一，當(dāng)年在 Google 和 Craig McLuckie、Joe Beda 等人一起做出了這個(gè)項(xiàng)目，然后他們離職創(chuàng)業(yè)，Burns 去了微軟。

Burns 將自己當(dāng)前的職責(zé)概括為兩部分：一部分是云原生，另一部分是資源管理，涵蓋 Azure Kubernetes Service（AKS）、Azure Linux，以及 Azure control plane 等核心體系。他表示，盡管業(yè)界十年前就已普遍意識到，開源和 Linux 是云計(jì)算走向成熟繞不過去的基礎(chǔ)能力，但真正困難的是如何將其系統(tǒng)性落地，這也是他加入微軟的重要原因之一。目前，他手下大約有 1400 名工程師和產(chǎn)品經(jīng)理。

此外，Burns 加入微軟的另一層考慮，是希望補(bǔ)上自己在大規(guī)模組織管理上的經(jīng)驗(yàn)。他坦言，此前自己并未真正管理過如此大體量的團(tuán)隊(duì)，而微軟在培訓(xùn)、輔導(dǎo)和導(dǎo)師機(jī)制上的系統(tǒng)性支持，幫助他快速完成了角色轉(zhuǎn)換。在他看來，組織管理與技術(shù)系統(tǒng)一樣，規(guī)模一旦變化，問題本身也會隨之變化：帶領(lǐng) 10 人、100 人和 1000 人團(tuán)隊(duì)，所面對的復(fù)雜度完全不同，而疫情又讓這一過程額外增加了一層特殊挑戰(zhàn)。

很多人對 Burns 的印象，可能還停留在那幾年到處參加 Kubernetes 大會、演講的時(shí)候，但他近期開始活躍，分享了自己作為開發(fā)者的成長，AI 對自己、對 Kubernetes 這些基礎(chǔ)設(shè)施的影響。

• AI 不是在“推翻” Kubernetes，而是在逼它補(bǔ)課。Kubernetes 原來最擅長的是在線業(yè)務(wù)調(diào)度，現(xiàn)在不得不開始理解 GPU、高速互聯(lián)、訓(xùn)練作業(yè)、checkpoint 和數(shù)據(jù)緩存這類新問題。

• Burns 做高管后依然自己寫代碼，除了性格使然，也是為了不失去對真實(shí)開發(fā)體驗(yàn)的感知。

• AI 的效率提升是真實(shí)存在的，而且有時(shí)很驚人；但它遠(yuǎn)不完美，真正的問題在于你會不會用、怎么用、怎么和它磨合。

• 未來每個(gè)人的工作，都會越來越多地變成 review code，而不是單純“寫 code”。code review 正在從資深工程師的附加技能，變成所有工程師都必須明確訓(xùn)練的核心能力。

• 97% 代碼是機(jī)器生成的”并不新鮮，你早就接受過“100% 機(jī)器生成的匯編。

• 你可以把 10% 的精力“藏起來”。不是先寫 PPT 申請資源，而是先做出一個(gè)能跑的原型，一個(gè)能運(yùn)行的系統(tǒng)，比 10 頁解釋材料更有說服力。

我們從兩期播客中各自截取了一些問題，進(jìn)行翻譯和整理，以饗讀者。

1 依然喜歡自己寫代碼

主持人：你現(xiàn)在自己還能下潛到技術(shù)細(xì)節(jié)里嗎？感覺你還是挺愿意碰細(xì)節(jié)的。

Burns：對，這可能真的是我性格使然。我天然就是會被這些東西吸過去。但我也覺得，等你開始帶團(tuán)隊(duì)之后，你遲早會意識到一件事：你必須放棄自己繼續(xù)站在關(guān)鍵路徑上。因?yàn)槟阋坏┻€把自己放在關(guān)鍵路徑上，你就成瓶頸了，而且你會真的把整個(gè)組織拖慢。

你會有一個(gè)很明確的頓悟時(shí)刻：原來我的工作不再是“親自把事做掉”，而是確保很多人可以并行把事做掉。因?yàn)椴还苣銈€(gè)人多強(qiáng)，10 個(gè)人、15 個(gè)人、20 個(gè)人、30 個(gè)人并行起來，產(chǎn)出一定遠(yuǎn)遠(yuǎn)超過你一個(gè)人。所以到某個(gè)階段，你就會意識到：我的職責(zé)不是自己做，而是讓更多人能順暢地做。當(dāng)然，你還是得幫大家把方向指準(zhǔn)。

但與此同時(shí)，我確實(shí)又很喜歡寫代碼。我前面也說了，我就是喜歡做東西。我真的很喜歡寫代碼。說實(shí)話，我更愿意自己寫代碼，也不太愿意只是站在旁邊看別人寫。

所以這些年我一直給自己留了一些項(xiàng)目。比如 Kubernetes 的幾個(gè) client，我已經(jīng)維護(hù)差不多十年了。我會維護(hù) Java client、C client，還有 .NET 那邊的 client。C client 用的人其實(shí)不算多，但我自己會用。.NET 那個(gè)用的人就不少。

我很喜歡這種事情，因?yàn)樗媚軡M足我“還想寫代碼”的那股勁兒。而且這些東西是真有用戶的。這會讓你一直保持腳踏實(shí)地。因?yàn)榭倳腥伺軄碚夷悖f“我卡在這個(gè) issue 上了”“這個(gè) release 什么時(shí)候發(fā)”。這些反饋會讓你一直記得，一個(gè)真實(shí)開發(fā)者每天面對的，到底是什么體驗(yàn)。這不光會讓你理解用戶，也會讓你更能理解自己團(tuán)隊(duì)里的人。

主持人：也能理解給你干活的人到底在經(jīng)歷什么。

Burns：沒錯(cuò)。比如你會重新感受到，那種“又得去研究一遍發(fā)布工具鏈，因?yàn)樗指牧恕钡臒┰辍Ｂ毤壐吡艘院螅袝r(shí)人很容易忘掉這些細(xì)碎但真實(shí)的麻煩，會下意識覺得：“這不就很簡單嗎，去做不就行了。”但其實(shí)不是。

所以我一直保留這樣一塊自己親手做的事，它能讓我持續(xù)接觸那些底層、真實(shí)、很具體的挫敗感。而且它又沒有重要到我必須天天盯著。如果我哪周突然得去救其他地方的“大火”，或者要處理客戶反饋臨時(shí)消失一兩周，也不會有人真的氣死。因此，這對我來說剛剛好：既讓我有真實(shí)工作體驗(yàn)，也讓我有參與感，又不至于讓我真的擋在前面，變成別人的阻礙。

最近還有一點(diǎn)我覺得特別有意思，就是這些項(xiàng)目也成了我真正上手 AI 工具的最好場景。

因?yàn)槲矣X得，AI 工具這件事，其實(shí)也有類似的風(fēng)險(xiǎn)。很多高層管理者看新聞標(biāo)題，會很容易得出一個(gè)結(jié)論：哇，那大家不就應(yīng)該立刻提升 30% 的效率嗎？但真實(shí)情況要復(fù)雜得多。

我可以非常明確地說，這些工具確實(shí)能提升效率，而且提升幅度有時(shí)候真的很驚人。但它不是完美的。三年前當(dāng)然遠(yuǎn)遠(yuǎn)不完美，就算是今天，也還遠(yuǎn)遠(yuǎn)談不上完美。你得知道怎么用它，也得知道怎么接近它。

而且我覺得，真正親手用過之后的價(jià)值，不只是我自己知道這件事，而是我還能拿出具體東西給別人看，因?yàn)檫@些都在 GitHub 上，我可以直接跟人說：你去看這個(gè) PR。這里面完整記錄了我從 A 走到 B，前后用了 15 個(gè) prompt。里面不全是那種特別漂亮的 prompt，有些就是非常真實(shí)的那種：“不對，你先編譯一下。”“你能不能真的把你剛才說要做的事做出來？”

有時(shí)候你甚至?xí)滩蛔χf：“不是，你到底在干嗎？”但恰恰是這些東西，會讓別人看到，AI 工具在真實(shí)使用中到底是什么樣的，它是怎么被真正用好的。

另外，還有一件事，我一直挺堅(jiān)持的。它更像是組織管理層面的事，但其實(shí)也和我以前當(dāng)教授有關(guān)。

教授都有 office hours，學(xué)生什么時(shí)候需要幫助就什么時(shí)候來。我以前也是這么做的。開始我管理的人不多時(shí)候，我就是跟每個(gè)人都做 1:1，真的就是每個(gè)人都聊。但大概到了 50 人往上，你就會發(fā)現(xiàn)，這件事開始非常耗時(shí)間，所以后來我改成 office hours。現(xiàn)在，我會固定開 office hours，團(tuán)隊(duì)里誰都可以預(yù)約，一個(gè)月里想約多少時(shí)段都可以。名額會很快約滿，我們還會排隊(duì)，盡量做平衡。

這件事的好處非常大。有時(shí)候大家只是想聽聽我的經(jīng)歷，想知道我是怎么一步步走到今天的。我很愿意講這些，但對我自己來說最大的價(jià)值其實(shí)是：我能直接聽到一線到底是什么感覺，而且我能橫向聽到很多人的一線感受。

我有一個(gè)很強(qiáng)的習(xí)慣，就是如果我在 10 個(gè) 1v1 里聽到同一件事，那我就知道這不是單點(diǎn)問題了，我得去處理。哪怕那只是個(gè) 5% 的摩擦點(diǎn)，只要大家都感受到了，那它就是值得解決的。你把這個(gè)小摩擦去掉，整個(gè)組織的運(yùn)行就會順很多。

AI 也是一樣。尤其在 AI 剛起來那陣子，很多人會擔(dān)心：這東西是不是要把我工作替掉？你直接面對面回應(yīng)這種擔(dān)憂，講清楚你自己的判斷和看法，這樣的效果與你站在季度全員大會上高高在上地說一遍，是完全不一樣的。

當(dāng)然，我也會在全員大會分享，有些人確實(shí)就喜歡這種方式。但帶大組織這件事，本質(zhì)上就是你得用很多種不同的方法，來確保你的想法、方向和判斷真的傳到組織里。

2 AI 怎么從底層改變“做工具”這件事？

主持人：AI 顯然已經(jīng)改變了我們對基礎(chǔ)設(shè)施的理解。不只是規(guī)模，還有 workload 的形態(tài)、運(yùn)行方式，全都變了。而你又正好在微軟負(fù)責(zé)很大一塊 Kubernetes 和容器基礎(chǔ)設(shè)施。那 AI 到底是怎么從底層改變你們做工具這件事的？

Burns：有些變化，確實(shí)是那種非常底層、非常“螺絲釘級”的，但它們又實(shí)實(shí)在在地帶來了明顯不同。

拿 Kubernetes 來說，最早設(shè)計(jì)那會兒，主要關(guān)心的是 CPU 和內(nèi)存調(diào)度這些核心問題，但現(xiàn)在還得把 GPU 考慮進(jìn)去。而 GPU 可不是“另一種 CPU”那么簡單。

很多 GPU 之間都有高速互聯(lián)，所以現(xiàn)在你琢磨的就不光是“我要把這個(gè)東西放到某臺機(jī)器上”，而是“我要把這兩個(gè)東西擱在同一臺機(jī)器上，具體哪臺無所謂，但它倆必須在一起”。所以你會看到像 gang scheduling 這種機(jī)制開始進(jìn)來，也會冒出一些別的新做法。

再比如訓(xùn)練這類 workload，本質(zhì)上更像是 batch workload。可 Kubernetes 一開始其實(shí)是給在線業(yè)務(wù)設(shè)計(jì)的，訓(xùn)練和微調(diào)就不是這個(gè)節(jié)奏。很多人就想，能不能趁推理空閑的時(shí)候去跑這些事——白天大家都在用，推理流量很高；到了半夜，流量下來了，GPU 開始閑著。可這些 GPU 就算閑著，你錢還是照付的。這就要求調(diào)度器得支持某種意義上的時(shí)間切片。可這個(gè)能力，Kubernetes 最初并沒有為它設(shè)計(jì)好。GPU 切分本身也是，最開始壓根不是這個(gè)思路。

還有一點(diǎn)，你得真懂硬件。

所以我們后來必須得跟 Nvidia 這類廠商更緊密地合作，也得跟其他硬件伙伴配合。我們還在 Kubernetes 里引入了一些更底層的能力，比如 DRA（Dynamic Resource Allocation），這樣，那些真正懂 GPU 長什么樣、怎么切分的廠商，比如 Nvidia，就能用一種更通用的方式，把“這臺機(jī)器上的 GPU 到底是什么資源形態(tài)”暴露給 Kubernetes。

另外一個(gè)很有意思的變化是：以前我們總喜歡把很多東西理解成無狀態(tài)的，但訓(xùn)練看起來是，但根本不是。因?yàn)槟阋坏┦×司偷脧?checkpoint 恢復(fù)，而這件事成本很高，所以訓(xùn)練場景對失敗的容忍度非常低。對很多人來說，失敗已經(jīng)不是什么“小問題”了，而是很嚴(yán)重的事。這件事帶來的一個(gè)明顯變化就是：大家看待失敗的方式已經(jīng)變了。

數(shù)據(jù)也是一樣。比如以前大家通常不太在意 pod 在不同機(jī)器之間遷移，但如果某臺機(jī)器上已經(jīng)緩存了很多數(shù)據(jù)，哪怕這些數(shù)據(jù)別處也有，你重新下載一遍還是很花時(shí)間。這時(shí)候你可能就會更希望它盡量留在原地，而不是像以前那樣，覺得隨便漂一漂問題不大。

所以我會說，這里面確實(shí)有一些很深刻的變化。但我覺得它更像是“適配”，而不是“革命”。

Kubernetes 想解決的一件事，本來就是讓很多人能用上復(fù)雜的能力，但不需要每個(gè)人都自己從零搭建。現(xiàn)在也一樣。

很多人希望用微調(diào)，但不想親自研究一遍微調(diào)到底怎么搞；也有人想做分布式推理，但并不想自己把整套東西摸透，他們單純因?yàn)槟Ｐ痛蟮揭欢ǔ潭却_實(shí)需要這個(gè)能力。所以另一個(gè)趨勢就是，大家開始通過插件、定制資源（Custom Resource）這些方式，往 Kubernetes 之上疊加新的 AI 原生能力。

以前 service mesh 這些東西是這么加進(jìn)來的，現(xiàn)在 AI native primitives 也開始這么加。我們自己也在做一些這樣的項(xiàng)目，比如 Kaito，我們還在跟 Ray、vLLM 合作項(xiàng)目，讓這些能力更容易用起來，包括 PyTorch Foundation 那邊的一些項(xiàng)目也都在里面。

這點(diǎn)我其實(shí)看著挺開心的。我一直很喜歡云原生這套生態(tài)，但做到某個(gè)階段你也會意識到，它不可能永遠(yuǎn)是唯一的基礎(chǔ)。現(xiàn)在出現(xiàn)一些更聚焦別的方向的基金會、項(xiàng)目、生態(tài)，我覺得挺好。

但這背后說明的一件事，其實(shí)特別明確：vendor-neutral 的開源，對整個(gè)行業(yè)成功非常關(guān)鍵。你必須得讓多家公司能圍繞同一個(gè)方案下注。沒有這個(gè)前提，很多生態(tài)其實(shí)長不起來。

3Kubernetes 如何適應(yīng) AI ？

主持人：OpenAI 曾發(fā)布過一篇文章介紹如何將 Kubernetes 擴(kuò)展到數(shù)千節(jié)點(diǎn)規(guī)模。隨著 AI 工作負(fù)載的出現(xiàn)，例如大規(guī)模訓(xùn)練和低延遲推理，Kubernetes 是如何適應(yīng)這些新需求的？

Brendan：早期 Kubernetes 的規(guī)模上限大約只有一百個(gè)節(jié)點(diǎn)，因此后續(xù)的發(fā)展本質(zhì)上是持續(xù)優(yōu)化的過程。我們需要減少 API 噪聲，將部分組件拆分出來，以支持更大規(guī)模。其中，etcd 往往成為擴(kuò)展的主要瓶頸，因此如何高效運(yùn)行 etcd，是實(shí)現(xiàn)大規(guī)模 Kubernetes 的關(guān)鍵。整體而言，大規(guī)模系統(tǒng)的演進(jìn)方式并沒有本質(zhì)變化：運(yùn)行系統(tǒng)、發(fā)現(xiàn)瓶頸、解決問題，然后不斷迭代。

雖然 AI 訓(xùn)練通常涉及超大規(guī)模集群，但在云環(huán)境中，許多用戶實(shí)際上運(yùn)行的是大量小型集群，而非單一超大集群，這與傳統(tǒng)數(shù)據(jù)中心模式不同。在云平臺中，創(chuàng)建集群的成本極低，用戶更傾向于按需創(chuàng)建多個(gè)集群。

這帶來了新的挑戰(zhàn)：如何管理“成百上千個(gè)集群”。過去我們關(guān)注的是“單個(gè)集群的規(guī)模”，而現(xiàn)在還需要解決“集群數(shù)量的規(guī)模”。例如，需要確保所有集群的監(jiān)控系統(tǒng)一致、版本統(tǒng)一、權(quán)限配置一致等。這也是后來 Kubernetes 生態(tài)重點(diǎn)投入的方向之一。

主持人：隨著 AI 需求持續(xù)增長，計(jì)算規(guī)模可能進(jìn)一步擴(kuò)大。如果規(guī)模提升一個(gè)數(shù)量級，Kubernetes 是否會遇到極限？

Brendan：從架構(gòu)上看，大多數(shù)組件都可以通過橫向擴(kuò)展來應(yīng)對更高負(fù)載。例如，API 請求增加，可以增加 API Server；調(diào)度壓力增大，可以增加調(diào)度器實(shí)例。真正的瓶頸仍然集中在存儲層，也就是 etcd。如果系統(tǒng)規(guī)模提升一個(gè)數(shù)量級，就需要評估 etcd 是否還能支撐，或者是否需要替換為具備相同特性但更高擴(kuò)展性的存儲系統(tǒng)。因此，限制并不在整體架構(gòu)，而在具體實(shí)現(xiàn)細(xì)節(jié)。

此外，有一個(gè)普遍規(guī)律：當(dāng)系統(tǒng)規(guī)模提升一個(gè)數(shù)量級時(shí)，瓶頸會發(fā)生轉(zhuǎn)移。原本的主要問題可能消失，而新的問題會出現(xiàn)，例如從網(wǎng)絡(luò)瓶頸轉(zhuǎn)變?yōu)?CPU 瓶頸，或從內(nèi)存瓶頸轉(zhuǎn)變?yōu)榫W(wǎng)絡(luò)瓶頸。總體而言，只要架構(gòu)本身沒有根本性限制，隨著需求增長，工程實(shí)踐通常能夠找到解決方案。

主持人：你曾說過“軟件的必然軌跡是走向消亡。”但我很難想象 Kubernetes 會消亡。你怎么看待這件事？

Brendan：我依然認(rèn)同這個(gè)觀點(diǎn)。不過在那句話之前，我其實(shí)還說過一句：你不應(yīng)該愛上你寫的軟件，因?yàn)樗淖罱K歸宿一定是消亡。這意味著，當(dāng)軟件進(jìn)入衰退期時(shí)，不應(yīng)執(zhí)著于它，更不應(yīng)因?yàn)樗亲约簩懙木筒辉阜攀帧Ｏ喾矗覀儜?yīng)該始終保持愿意舍棄舊系統(tǒng)的態(tài)度。

從行業(yè)歷史來看，這一規(guī)律是普遍存在的。即使在 Kubernetes 項(xiàng)目內(nèi)部，我當(dāng)年寫的代碼在十多年的發(fā)展過程中，也已經(jīng)被重寫過多次。

至于軟件“消亡”的形式，可能有兩種。一種是被新的技術(shù)徹底取代：新方案實(shí)現(xiàn)相同功能，但更簡單、更高效、復(fù)雜度更低、實(shí)用性更強(qiáng)。另一種是它逐漸變得“隱形”，仍然存在，但不再被關(guān)注。例如，在 Kubernetes 之下是 Linux，再往下是處理器，但大多數(shù)人并不會關(guān)注這些底層。

我可以想象一種可能性：如果自然語言接口足夠成熟，人們只需要說“我想要一個(gè)可靠的 Web 服務(wù)”，而不需要再編寫復(fù)雜的 YAML 配置，那么 Kubernetes 的使用方式甚至存在的意義都會發(fā)生改變。

從當(dāng)前趨勢來看，這種變化已經(jīng)在發(fā)生。隨著 AI 的興起，越來越多的關(guān)注轉(zhuǎn)移到了上層應(yīng)用，而 Kubernetes 逐漸成為底層基礎(chǔ)設(shè)施的一部分。就系統(tǒng)演進(jìn)速度而言，我感覺 Kubernetes 的發(fā)展已經(jīng)趨于平穩(wěn)，只有與 AI 相關(guān)的部分仍在快速變化。

如果從更長遠(yuǎn)的角度來看，比如一百年后 Kubernetes 仍然存在，我會非常驚訝。計(jì)算技術(shù)的發(fā)展歷史還不夠長，我們無法完全確定哪些技術(shù)會長期存在。確實(shí)也有一些東西延續(xù)了很久，比如插頭的形態(tài)，但更多技術(shù)都會被替代。

例如，幾年前如果你問我 x86 架構(gòu)是否會消失，我可能會認(rèn)為至少在服務(wù)器領(lǐng)域不會。但如今情況已經(jīng)發(fā)生變化：一方面，GPU 在計(jì)算中占據(jù)越來越重要的位置；另一方面，ARM 架構(gòu)也在服務(wù)器領(lǐng)域崛起。這說明，預(yù)測技術(shù)未來是非常困難的，變化往往比預(yù)期更快，或者更慢。就像自動駕駛技術(shù)，人們一直說“再過五年就能實(shí)現(xiàn)”，但這樣的說法已經(jīng)持續(xù)了十多年。

4 落地用戶開始關(guān)心什么？

主持人：你們客戶現(xiàn)在關(guān)心的核心問題是什么？會怎么跟你提需求，比如更高效運(yùn)行、更好的監(jiān)控、可觀測性之類的？

Burns：我覺得差不多都有。

第一類很常見的對話是：token as a service 和自己部署運(yùn)行模型，這兩條路到底怎么選？

這背后有很多維度。比如一些 proprietary model，你根本就只能通過 token as a service 的方式去用。但如果你自己部署模型，那你就得有更多能力。不過這么做，你可能會在成本上更有優(yōu)勢，或者你就是想放在本地跑，因?yàn)橛袛?shù)據(jù)合規(guī)、數(shù)據(jù)不出域之類的考慮。

所以我們經(jīng)常會跟客戶討論：這兩套模式怎么一起用？比如你一邊通過平臺服務(wù)去調(diào) OpenAI 的 token as a service，一邊又在 AKS 的 GPU 上跑 Llama 2，或者跑 Phi 系列的小模型。

我之前還會跟人開玩笑說，你最好別每句“你好，在嗎”都去調(diào)最貴的大模型，那根本不劃算。

我覺得現(xiàn)在大家已經(jīng)開始慢慢有這種“模型路由”的意識了，也就是你不能把所有請求都一股腦丟給同一個(gè)模型。一方面，不同模型擅長的事情本來就不一樣；另一方面，成本曲線差別也大得離譜。所以像微軟做的那類小模型，比如 Phi，用來做一般對話、做摘要、做很多包裹在主任務(wù)周圍的基礎(chǔ)型工作，其實(shí)完全夠用。這是我們和客戶經(jīng)常聊的一類問題。

另一類問題是：AI 應(yīng)用到底該怎么構(gòu)建？

調(diào)用 API 這件事本身并不難，大家都知道怎么調(diào)。難的是，你怎么換模型、怎么改 prompt，以及你怎么在這個(gè)過程中別把系統(tǒng)搞壞。

過去 10 年，我們其實(shí)很大一部分時(shí)間都在教人一件事：怎么把代碼發(fā)布出去，同時(shí)別把線上搞掛。當(dāng)然現(xiàn)在大家還是會搞掛，我也不是說這個(gè)問題已經(jīng)徹底解決了，我們自己也一樣還是會踩坑。但到了 AI Ops 這個(gè)世界，事情又更難了一層，因?yàn)椤八降子袥]有正常工作”這件事，主觀性強(qiáng)太多了。你可能 HTTP 200 全是綠的，系統(tǒng)看起來一切正常，可如果內(nèi)容質(zhì)量很差，那你其實(shí)就是沒把活干好。這時(shí)候你的 monitoring 邏輯就得變。

以前你主要盯 error，現(xiàn)在不行了。現(xiàn)在你的監(jiān)控體系里必須帶“人”的維度。你不光要問：“有沒有返回答案”，你還得問：“這個(gè)答案是不是個(gè)好答案”。而這件事又不能簡單交給另一個(gè)模型替你判斷，所以這變得很微妙。

我們現(xiàn)在有不少做法，很常見的一種就是讓用戶點(diǎn)贊 / 踩，但即便是這件事，你也得教用戶怎么點(diǎn)。

我記得我最早有一個(gè)團(tuán)隊(duì)上線 AI 應(yīng)用的時(shí)候，看到點(diǎn)踩的比例很高，大家都嚇壞了，以為這產(chǎn)品是不是太爛了。后來才發(fā)現(xiàn)不是這么回事。因?yàn)槿绻鸢竿玫模芏嗳藟焊粫c(diǎn)贊，就像你去理發(fā)，理發(fā)師正常發(fā)揮，你大概率不會特意沖回去給個(gè)五星好評。但要是理差了，你肯定會吐槽。

所以這個(gè)指標(biāo)，本質(zhì)上是個(gè)相對指標(biāo)，不是絕對指標(biāo)。比如你的點(diǎn)踩率從 50% 掉到 40%，那是好事；可如果它從 10% 漲到 20%，那就是壞事。哪怕你說“20% 也不算特別夸張”，但趨勢錯(cuò)了就是錯(cuò)了。

因此，對于很多 AI 指標(biāo)，你得從“絕對值思維”切到“相對變化思維”。

另外還得看行為層面，比如一個(gè)人和這個(gè)系統(tǒng)來回對話了多少輪。大多數(shù)時(shí)候，用戶不是閑得沒事在那聊天，他們是想把某件事辦成。如果一個(gè)人為了拿到答案，和系統(tǒng)反復(fù)來回 10 輪、15 輪、20 輪，那很可能說明你沒有在一開始就給對方向，用戶一直在修 prompt、一直在補(bǔ)信息。這其實(shí)也是很重要的信號。

但問題又來了：你想看這些聊天內(nèi)容，本身也不容易。因?yàn)殡[私是個(gè)大問題。大家必須顯式選擇愿意把這些數(shù)據(jù)發(fā)給我們，我們才能看到真實(shí)交互，所以一下子就冒出來很多以前根本不存在的復(fù)雜度。以前做 Web 應(yīng)用時(shí)，你只需要問：頁面有沒有渲染出來？HTML 有沒有正確返回？現(xiàn)在完全不是這個(gè)層面的事了。

主持人：你有沒有看到一些搭 AI 應(yīng)用的最佳實(shí)踐？

Burns：有的。我覺得現(xiàn)在越來越普遍、也越來越重要的一條就是：你的測試?yán)锉仨毎罅坎煌?prompt。

以前寫單元測試的時(shí)候，你會說，“這個(gè) case 有個(gè)單元測試就行了。”現(xiàn)在不是這樣了。現(xiàn)在更像是：我手里有 1 萬條 prompt，然后我要把這 1 萬條全跑一遍。

其實(shí)我們做 Web 搜索的時(shí)候就是這么干的。你不會只測一個(gè) query，你會測 1 萬個(gè) query。因?yàn)槟忝扛囊淮蜗到y(tǒng)，不是所有東西都會同時(shí)變好。有的變好，有的會變差。你關(guān)心的是整體上有沒有變好，而不是某一個(gè)點(diǎn)是不是漂亮。AI 應(yīng)用也是一樣。

當(dāng)然，真到了 1 萬條 prompt、1 萬種體驗(yàn)的時(shí)候，又會碰到另一個(gè)問題：你怎么評估結(jié)果？你讓人一個(gè)個(gè)讀嗎？不現(xiàn)實(shí)。這時(shí)其實(shí)可以把結(jié)果再喂給一個(gè) LLM，讓它來做一層判斷。你可以問它：“這是 prompt，這是回答，這個(gè)回答好不好？”

LLM 在這件事上，做得其實(shí)已經(jīng)相當(dāng)不錯(cuò)了。至少它能給你一個(gè)相對信號，告訴你這版是變好了還是變差了。所以我覺得，這已經(jīng)是一個(gè)非常值得推廣的最佳實(shí)踐。

另外一個(gè)越來越重要的做法，就是產(chǎn)品測試，也就是在生產(chǎn)環(huán)境里測試。

什么 1% rollout、灰度實(shí)驗(yàn)，這些以前大家不是沒聊過，也不是沒人做。但在 AI 時(shí)代，它的重要性又往上升了一層。

對于做 AI 應(yīng)用的人來說，除了示例 prompt 以外，他們唯一真正能看到“這個(gè)東西在真實(shí)世界里到底表現(xiàn)怎樣”的方式，往往就是 1% 實(shí)驗(yàn)。以前這可能更像是 UX 團(tuán)隊(duì)或者某一小部分團(tuán)隊(duì)的工作；現(xiàn)在不是了。現(xiàn)在這件事得貫穿整條技術(shù)棧，讓每一層開發(fā)者都能有機(jī)會接觸到真實(shí)交互流。

5代碼 review，成為新人必備技能

主持人：大家都在說一個(gè)問題，現(xiàn)在代碼生成速度太快了，結(jié)果 code review、測試等反而成了新的瓶頸。有時(shí)候感覺，1% rollout 都快成了某種“先丟出去看看會不會炸”的方法了。當(dāng)然不是說亂上，但大概那個(gè)意思。你在微軟也看到這種情況了嗎？

Burns：我先說清楚，我們肯定不會把開發(fā)者隨手寫出來的東西直接丟上線，沒那么野。不過你說的現(xiàn)象，我確實(shí)看到了。

很多人，尤其一些資深 leader，會跑來跟我說：“我們是不是得多招點(diǎn)首席工程師、高級工程師？因?yàn)楝F(xiàn)在代碼太多了，根本 review 不過來。”但我其實(shí)會直接跟他們說：我覺得你這個(gè)想法本身就錯(cuò)了。主要錯(cuò)在兩個(gè)層面。

第一，他們默認(rèn) code review 這種事，只有首席或高級工程師才能做。這個(gè)想法以前某種程度上成立，因?yàn)槌跫壒こ處煛?yīng)屆生，或者剛?cè)胄袃扇甑娜耍郧暗闹饕ぷ骶褪菍懘a。但我覺得現(xiàn)在，崗位本身已經(jīng)在變了。未來每個(gè)人的工作，其實(shí)都會越來越多地變成“review code”。你當(dāng)然還是會寫一些代碼，但越來越多代碼會由自動化生成，而你的工作會變成判斷、審閱、把關(guān)。而我不覺得 code review 是一種必須靠三年、五年經(jīng)驗(yàn)慢慢熬出來的神秘能力。它就是可以教的。

所以我一直在推動一件事：你得主動教新畢業(yè)生、初級工程師怎么做好 code review。就像當(dāng)年行業(yè)默認(rèn)要教他們怎么用 CI/CD，或者我剛?cè)胄袝r(shí)，大家會教新人怎么用版本控制一樣。這些東西沒有人天生會，學(xué)校里也沒教，大家已經(jīng)默認(rèn)企業(yè)得補(bǔ)這課。只是以前 code review 不在這份“必補(bǔ)清單”里，因?yàn)槟菚r(shí)候它還不是崗位核心。

但現(xiàn)在， code review 已經(jīng)成崗位核心了，所以它會從一種“默認(rèn)你以后慢慢就會了”的隱性能力，變成一種要被明確訓(xùn)練的顯性能力。當(dāng)然我也希望，未來計(jì)算機(jī)科學(xué)教育能慢慢跟上，把 AI 和 code review 這些內(nèi)容更系統(tǒng)地放進(jìn)教學(xué)里，那樣大家入職時(shí)可能就已經(jīng)具備一部分能力了。但現(xiàn)在顯然還沒到那個(gè)階段。

第二個(gè)我覺得大家也想錯(cuò)了的地方，是大家總在問：現(xiàn)在代碼太多，怎么處理 review 壓力？但我更喜歡反過來問：到底要滿足什么條件，你才會不在意“這段代碼有沒有被人逐行 review”？

我覺得很多人都忘了一個(gè)事實(shí)：大家現(xiàn)在老在說，“我們 97% 的代碼已經(jīng)是機(jī)器生成的了”。

可你是不是忘了，只要用了編譯器，你的代碼就本來是 100% 機(jī)器生成的。匯編代碼不就是機(jī)器生成的嗎？而且我們早就不在意那層代碼了。幾乎沒人去看匯編，也沒人指望匯編可讀、可 review，它本來就是瞬態(tài)的。你寫高級語言，編譯器把它翻譯成匯編，然后你相信——而且通常這個(gè)信任是對的——編譯器有足夠好的測試，所以它產(chǎn)出的東西基本靠譜。

AI 代碼生成這件事，未來我覺得也會往這個(gè)方向走。如果你的測試越來越強(qiáng)，spec 越來越清楚，驗(yàn)證輸出正確性的框架越來越成熟，那到某個(gè)階段，我們自然就會開始說：這段 AI 生成的代碼本身其實(shí)也是瞬態(tài)的。下次我重新跑一遍，它還會再生成。真正重要的是 spec，是 tests。

6 未來的編程語言或?yàn)?AI 設(shè)計(jì)

主持人：這套說法我最近確實(shí)聽到越來越多，這可能真的是未來要去的方向。

Burns：我覺得這就是我們正在走向的世界，而且這里面還有一個(gè)特別有意思的問題：編程語言本身會怎么變。

其實(shí)早就有一些語言在朝這個(gè)方向走了，像航空航天這類行業(yè)里就有很多更嚴(yán)格的語言設(shè)計(jì)，它們會在前置條件、后置條件、可驗(yàn)證性、可證明性這些地方做很多限制。關(guān)于“程序可證明性”這件事，計(jì)算機(jī)科學(xué)學(xué)界其實(shí)有很長的歷史，但這些語言長期沒真正普及的一個(gè)很大的原因就是限制太多了。

某種程度上，Rust 就是個(gè)很好的例子。Rust 通過更嚴(yán)格的語法限制，換來更強(qiáng)的可證明保證，尤其是在內(nèi)存管理這件事上。但程序員很多時(shí)候并不喜歡這種感覺，因?yàn)樗鼘懫饋聿粔蝽樖郑瑫屓擞X得被束縛。工程師天然就不太喜歡這種“你只能這樣寫”的感覺。

可問題是，人類程序員不喜歡，AI 也不喜歡嗎？我不確定，也許 AI 根本不在乎。所以我覺得，未來一個(gè)特別值得看的方向，就是編程語言會不會開始朝著“更適合 AI 生成”的方向演化。

現(xiàn)在的 AI，本質(zhì)上是在生成“原本為人類設(shè)計(jì)的編程語言”。我以前打過一個(gè)比方：我們想造自動駕駛汽車，結(jié)果選的方案是先造一個(gè)機(jī)器人，讓它抓著方向盤開車。但真正的自動駕駛汽車不是這么造的。你看 Waymo，雖然還是車的樣子，但它底層是另一套控制方式，是線控、傳感器，是直接控制輪子的系統(tǒng)。我覺得編程語言未來大概率也會這樣。

既然一定會有相當(dāng)比例的代碼是 AI 生成、機(jī)器生成，那真正有意思的問題就會變成：未來的編程語言長什么樣？它到底還是不是那種主要給“人類團(tuán)隊(duì)手寫”的語言？我覺得，這才是更深的一層變化。

7Kubernetes 如何從零開始？

主持人：我其實(shí)不完全理解 Kubernetes 背后的商業(yè)動機(jī)。假設(shè)我是你的主管，你如何說服我把這個(gè)東西做成一個(gè)面向整個(gè)行業(yè)的項(xiàng)目？

Brendan：在項(xiàng)目早期階段，最困難的部分正是如何把這件事講清楚。我們自己心里很清楚它的價(jià)值，但要說服他人卻并不容易。為此，我們從多個(gè)角度進(jìn)行了論證。

其中一個(gè)重要論點(diǎn)與 MapReduce 白皮書有關(guān)。當(dāng)時(shí)，以 Hadoop 為代表的大數(shù)據(jù)技術(shù)正處于風(fēng)口，“大數(shù)據(jù)革命”被廣泛討論。Google 撰寫了最初的 MapReduce 白皮書，但 Hadoop 作為開源項(xiàng)目，與 Google 并無直接關(guān)系，Google 也未因此獲得相應(yīng)的影響力。Hadoop 只是基于論文進(jìn)行了復(fù)現(xiàn)，雖然相似，但本質(zhì)上并不相同。由此我們意識到，如果我們只發(fā)布白皮書，而不提供可運(yùn)行的系統(tǒng)，就無法真正主導(dǎo)技術(shù)的發(fā)展方向。因此，我們的一個(gè)核心論點(diǎn)是：既然我們擁有云平臺，就應(yīng)當(dāng)通過可運(yùn)行的技術(shù)來影響整個(gè)技術(shù)生態(tài)，而不僅僅停留在理論層面。

第二個(gè)論點(diǎn)圍繞“為什么選擇容器，而不是虛擬機(jī)”。當(dāng)時(shí)已有大量用戶使用虛擬機(jī)，但我們在內(nèi)部實(shí)踐中已經(jīng)明確感受到，構(gòu)建可靠的軟件系統(tǒng)，需要一種類似“自動駕駛”的基礎(chǔ)設(shè)施來管理應(yīng)用運(yùn)行。隨著軟件對企業(yè)的重要性不斷提升，這種能力將成為剛需。因此，容器及其編排系統(tǒng)將具備長期價(jià)值。

第三個(gè)關(guān)鍵問題是“為什么要開源”。很多人認(rèn)可前兩個(gè)論點(diǎn)，也同意這個(gè)系統(tǒng)對行業(yè)有價(jià)值，但會進(jìn)一步問：如果只在我們自己的平臺上提供，不是更有利嗎？答案是，雖然這樣看似更有利，但實(shí)際上無法取勝。

因?yàn)槭袌錾洗嬖诙鄠€(gè)平臺。如果將技術(shù)限定在自有平臺上，那么那些出于各種原因使用其他云或本地部署的用戶就會被排除在外，他們自然會選擇自行構(gòu)建替代方案。開源技術(shù)之所以能夠勝出，正是因?yàn)樗梢栽谌魏蔚胤竭\(yùn)行。就像 Linux 的成功，本質(zhì)在于其無處不在的適用性。

當(dāng)時(shí)的 Google 云并非市場領(lǐng)導(dǎo)者，這意味著大多數(shù)用戶并不在我們的平臺上。如果我們構(gòu)建的技術(shù)無法被多數(shù)人使用，他們就會忽視我們，轉(zhuǎn)而開發(fā)自己的方案。相反，如果我們構(gòu)建一個(gè)面向所有人的系統(tǒng)，同時(shí)確保它在我們平臺上的體驗(yàn)最佳，就有機(jī)會吸引更多用戶。

此外，這也與當(dāng)時(shí)的技術(shù)氛圍有關(guān)。幾乎所有關(guān)鍵技術(shù)，無論是操作系統(tǒng)、容器，還是編程語言，都在走向開源。如果我們選擇封閉，就會顯得格格不入。歷史上確實(shí)存在少數(shù)封閉技術(shù)也能成功的案例，但前提是其差異化必須極其顯著，強(qiáng)到足以讓用戶忽略其封閉性，而我們當(dāng)時(shí)并不具備這樣的優(yōu)勢。

主持人：從當(dāng)時(shí)的競爭格局來看，Amazon 已經(jīng)占據(jù)主導(dǎo)地位，而 GCP 仍在追趕。因此，這一策略是否可以理解為：通過開源 Kubernetes 吸引開發(fā)者，從而帶動他們向 GCP 遷移？

Brendan：更準(zhǔn)確地說，是讓他們開始關(guān)注我們，同時(shí)改變整個(gè)市場的討論方式。如果只是跟隨已有路徑，比如在虛擬機(jī)領(lǐng)域與對手做微小差異化競爭，這種策略很難講清楚，也很難取得突破。但如果我們開辟一個(gè)全新的技術(shù)領(lǐng)域，并成為其中的思想引領(lǐng)者，即使用戶不在我們的平臺上使用該技術(shù)，他們也會傾聽我們的聲音。這會顯著提升我們在行業(yè)中的話語權(quán)，并改變市場敘事。

這種對“話語權(quán)”的掌控，是打破既有競爭格局的重要方式。當(dāng)然，這并不意味著競爭會因此變得容易，事實(shí)上，即便今天，這種格局依然很難撼動。但至少，這一策略幫助 Kubernetes 成為整個(gè)云計(jì)算領(lǐng)域的基礎(chǔ)設(shè)施，幾乎所有云廠商最終都圍繞它達(dá)成了共識。

主持人：你“思想引領(lǐng)者”帶來的認(rèn)知優(yōu)勢，這從結(jié)果看確實(shí)成立，但在當(dāng)時(shí)向管理層匯報(bào)時(shí)，你們是否已經(jīng)明確意識到這種價(jià)值？

Brendan：我們確實(shí)明確提出，希望在技術(shù)思想層面占據(jù)核心位置，并強(qiáng)調(diào)其價(jià)值。成為思想引領(lǐng)者，本身就是一項(xiàng)重要資產(chǎn)。

主持人：但這類價(jià)值似乎很難量化，該如何判斷其投入產(chǎn)出？

Brendan：當(dāng)時(shí)的投入其實(shí)非常有限，大約只有八到九名工程師。同時(shí)，我們刻意將 Kubernetes 作為一個(gè)獨(dú)立品牌，與 Google 品牌區(qū)分開來。這一決策既是優(yōu)勢，也帶來一定風(fēng)險(xiǎn)。一方面，它降低了失敗成本，如果項(xiàng)目失敗，可以直接終止，而不會對整體云業(yè)務(wù)造成負(fù)面影響；另一方面，它也為項(xiàng)目提供了更大的靈活性。

開源同樣帶來了多重好處：一是促進(jìn)了技術(shù)的廣泛采用；二是在引入 Linux Foundation 等中立組織后，使得包括 Red Hat、Microsoft Azure 以及 AWS 在內(nèi)的廠商都能夠放心投入；三是作為一種“風(fēng)險(xiǎn)對沖機(jī)制”，降低了項(xiàng)目失敗的影響。

此外，這種相對獨(dú)立的組織方式也提高了我們的敏捷性。當(dāng)時(shí)我們實(shí)際上是在與像 Docker 這樣的初創(chuàng)公司競爭，它們行動迅速，而大型企業(yè)通常較為遲緩。通過這種方式，我們在一定程度上獲得了類似初創(chuàng)團(tuán)隊(duì)的靈活性。

主持人：項(xiàng)目最初的形態(tài)，是你和另外兩個(gè)人快速搭建的一個(gè)原型嗎？

Brendan：是的，本質(zhì)上就是一個(gè) Demo。我們只是將現(xiàn)有的一些開源技術(shù)組合在一起，展示如果這樣整合，可以實(shí)現(xiàn)什么樣的效果。

那個(gè) Demo 實(shí)現(xiàn)的是一個(gè)非常基礎(chǔ)的控制系統(tǒng)。當(dāng)時(shí)甚至需要先向大家解釋 Docker 的概念，說明如何通過 Docker 構(gòu)建容器鏡像，然后將其部署到集群中。系統(tǒng)可以將應(yīng)用分發(fā)到多臺機(jī)器上運(yùn)行，并通過一個(gè)統(tǒng)一入口實(shí)現(xiàn)負(fù)載均衡，例如多次刷新請求會命中不同的副本，從而展示其分布式特性。此外，還包括基礎(chǔ)的健康檢查機(jī)制，即當(dāng)實(shí)例被終止后能夠自動恢復(fù)，以及簡單的版本升級能力。整體功能非常精簡，但已經(jīng)能夠體現(xiàn)系統(tǒng)的核心價(jià)值。

主持人：這個(gè)最初的 MVP 花了多長時(shí)間完成？

Brendan：大約四到五天時(shí)間。

主持人：你當(dāng)時(shí)是暫停了原有的工作，專門來做這個(gè)項(xiàng)目嗎？

Brendan：嚴(yán)格來說并沒有完全中斷原有工作，但在那個(gè)時(shí)間尺度下，是可以做一定調(diào)整的。例如一周的時(shí)間里，進(jìn)度略有放緩是可以接受的。組織本身也具備一定靈活性，使我們能夠抽出時(shí)間快速完成這個(gè)原型。

當(dāng)然，這個(gè) MVP 是非常粗糙的，幾乎采用了所有可能的捷徑。我個(gè)人一直比較擅長整合現(xiàn)有的開源項(xiàng)目，將現(xiàn)成組件拼接起來，用少量“膠水代碼”連接，從而快速實(shí)現(xiàn)整體效果。因此，很多底層能力其實(shí)都來自已有的開源項(xiàng)目，這也是我們能夠在短時(shí)間內(nèi)完成原型的重要原因。

主持人：當(dāng)時(shí) Google 內(nèi)部的 Borg 系統(tǒng)本身具有競爭優(yōu)勢，將類似能力開放出來是否會引發(fā)顧慮？

Brendan：確實(shí)存在這樣的擔(dān)憂。但我當(dāng)時(shí)的一個(gè)觀點(diǎn)是：技術(shù)并不會被永久封鎖。員工會流動，經(jīng)驗(yàn)會傳播，這些能力遲早會在行業(yè)中擴(kuò)散。事實(shí)上，當(dāng)時(shí)我們與其他公司交流時(shí)發(fā)現(xiàn)，包括 Facebook、Twitter 在內(nèi)的多家大型技術(shù)公司，都在構(gòu)建類似系統(tǒng)，這并非真正的“秘密”。

此外，當(dāng)時(shí)已經(jīng)可以預(yù)見，行業(yè)中一定會出現(xiàn)一個(gè)開源解決方案，問題不在于“是否會出現(xiàn)”，而在于“由誰主導(dǎo)”。因此，我們將問題重新表述為：既然開源不可避免，那么我們是選擇參與并施加影響，還是讓別人來主導(dǎo)。這種表述幫助大家理解，所謂“保持封閉”其實(shí)并不是一個(gè)現(xiàn)實(shí)可行的選項(xiàng)。

主持人：在構(gòu)建編排系統(tǒng)的最初 MVP 時(shí)并沒有真實(shí)客戶可供參考，你們是如何判斷上線前所需的最小功能集的？

Brendan：我們在這方面其實(shí)受益于團(tuán)隊(duì)構(gòu)成。當(dāng)時(shí)只有三個(gè)人參與：Craig 更偏產(chǎn)品與業(yè)務(wù)，Joe 擅長工程實(shí)現(xiàn)與 API 設(shè)計(jì)，而我主要負(fù)責(zé)快速編寫原型代碼。這樣的組合使我們既能從產(chǎn)品視角思考問題，也能在技術(shù)上迅速落地。

在功能選擇上，我們主要基于自身經(jīng)驗(yàn)，以及對行業(yè)痛點(diǎn)的理解。我們長期觀察到，在傳統(tǒng)虛擬機(jī)基礎(chǔ)設(shè)施上部署應(yīng)用存在諸多問題，這些痛點(diǎn)為我們提供了清晰的方向。同時(shí)，當(dāng)時(shí)以 Netflix 為代表的一些公司，已經(jīng)在推動“不可變基礎(chǔ)設(shè)施”等理念，整個(gè)行業(yè)也在朝類似方向演進(jìn)。因此，雖然當(dāng)時(shí)并沒有真實(shí)客戶，但這些潛在需求實(shí)際上是存在的，只是尚未被正式表達(dá)。

從某種意義上說，Kubernetes 并不是一個(gè)全新的發(fā)明，而是對當(dāng)時(shí)行業(yè)中多種已有理念的整合與系統(tǒng)化表達(dá)。它將這些分散的思想?yún)R聚起來，形成了一個(gè)清晰的技術(shù)錨點(diǎn)。

主持人：在最初的 MVP 中，你承擔(dān)了大部分開發(fā)工作？

Brendan：大致在 80% 以上，甚至可能更高。即使后來我已經(jīng)很少直接參與 Kubernetes 的開發(fā)，在 GitHub 的貢獻(xiàn)列表中仍然排名前列，早期更是長期位居第一。

主持人：當(dāng) Kubernetes 開始擴(kuò)展時(shí)，你們是如何說服其他公司和開發(fā)者采用的？

Brendan：在早期階段，一個(gè)非常有效的切入點(diǎn)是“非差異化重體力勞動”（undifferentiated heavy lifting）。對于許多公司來說，他們的核心目標(biāo)并不在基礎(chǔ)設(shè)施層。例如，OpenShift 想構(gòu)建的是平臺即服務(wù)，而其他早期用戶也只是希望搭建可靠的 Web 服務(wù)。在這種情況下，底層編排系統(tǒng)并不是他們的核心競爭力。因此，我們的邏輯很簡單：既然大家都需要構(gòu)建這套基礎(chǔ)能力，不如共同完成。相比各自重復(fù)建設(shè)，協(xié)作帶來的收益更大。對很多早期合作伙伴而言，這一點(diǎn)非常有說服力。

與此同時(shí)，我們也強(qiáng)調(diào)“共同治理”。依賴一個(gè)外部項(xiàng)目，意味著某種程度上要依賴他人的路線圖，這通常會引發(fā)顧慮。因此，我們明確傳達(dá)：不僅可以使用 Kubernetes，還可以參與設(shè)計(jì)決策。當(dāng)他們需要新功能時(shí)，可以直接貢獻(xiàn)代碼，并影響項(xiàng)目方向。這種“共建”關(guān)系，使 Kubernetes 與各方的技術(shù)路線形成對齊。

隨著時(shí)間推移，生態(tài)效應(yīng)開始顯現(xiàn)。無論是網(wǎng)絡(luò)廠商還是存儲廠商，當(dāng)他們的用戶逐漸轉(zhuǎn)向 Kubernetes 時(shí)，就必須確保自身產(chǎn)品能夠與之良好集成。這種由用戶需求驅(qū)動的生態(tài)擴(kuò)展，進(jìn)一步加速了 Kubernetes 的普及。

主持人：你們?nèi)绾伪苊?Google 對 Kubernetes 的路線圖形成過度控制？

Brendan：這是一個(gè)至關(guān)重要的問題，也是 Kubernetes 能夠成為行業(yè)標(biāo)準(zhǔn)的關(guān)鍵因素之一，核心在于“獨(dú)立性”。

首先，我們在項(xiàng)目發(fā)布僅一年后，就將 Kubernetes 捐贈給 Cloud Native Computing Foundation（隸屬于 Linux Foundation）。包括代碼、商標(biāo)、品牌等在內(nèi)的所有權(quán)，都轉(zhuǎn)移至獨(dú)立的基金會。這一點(diǎn)非常關(guān)鍵，因?yàn)槿绻骋还菊莆丈虡?biāo)或法律控制權(quán)，其他企業(yè)很難放心參與。

其次，是治理機(jī)制的建立。早期 Kubernetes 并沒有正式的治理規(guī)則，這是一個(gè)失誤。直到 2016 年，我們才系統(tǒng)性地制定了治理框架。其核心原則是：不允許任何單一公司控制項(xiàng)目。我們構(gòu)建了一套更加民主、分布式的治理體系，并將其寫入正式文檔中。

從一開始，我們就沒有打算采用“仁慈獨(dú)裁者”（BDFL）模式，而是希望打造一個(gè)多方共治的社區(qū)。這種治理結(jié)構(gòu)，確保了 Kubernetes 既是行業(yè)標(biāo)準(zhǔn)，而非某一公司的專屬標(biāo)準(zhǔn)。

法律上的獨(dú)立性與治理上的開放性，是相輔相成的，缺一不可。

對于任何考慮采用 Kubernetes 的公司來說，核心問題是：我在押注誰的路線圖？只有當(dāng)答案是“一個(gè)開放且中立的社區(qū)”時(shí)，這種押注才是可接受的。

主持人：是否真的像政府一樣，有類似“憲法”的文件？

Brendan：可以這么理解。我們確實(shí)編寫了類似“憲章”的治理文檔。那些是我們自己寫的，大約由六到七位核心成員，在幾次高強(qiáng)度會議中完成。我們參考了其他開源社區(qū)的經(jīng)驗(yàn)，總結(jié)哪些做法有效、哪些存在問題，并明確我們希望實(shí)現(xiàn)的目標(biāo)。一部分內(nèi)容是對既有實(shí)踐的制度化，另一部分則是全新設(shè)計(jì)，例如設(shè)立指導(dǎo)委員會（Steering Committee）。

我們當(dāng)時(shí)還組建了一個(gè)“引導(dǎo)委員會”（Bootstrap Committee），大約七八個(gè)人。這些人都被社區(qū)廣泛認(rèn)可為技術(shù)領(lǐng)導(dǎo)者，彼此之間也沒有明顯分歧。這一點(diǎn)非常關(guān)鍵，使我們能夠在沒有內(nèi)耗的情況下，構(gòu)建一套被廣泛接受的治理體系。這里也要特別提到當(dāng)時(shí)的社區(qū)負(fù)責(zé)人 Sarah Novotny，她在推動這一過程上發(fā)揮了重要作用。

主持人：在 Kubernetes 中，社區(qū)貢獻(xiàn)占比大概是多少？

Brendan：我沒有具體數(shù)據(jù)，但從整體開源經(jīng)驗(yàn)來看，通常是 80% 到 90% 的貢獻(xiàn)來自核心貢獻(xiàn)者，其他用戶的貢獻(xiàn)占比較低，推動廣泛參與其實(shí)非常困難。

一個(gè)重要原因在于企業(yè)結(jié)構(gòu)。例如微軟這類公司會在戰(zhàn)略層面投入資源參與開源，因此會組建專門團(tuán)隊(duì)進(jìn)行貢獻(xiàn)。但對于許多 Kubernetes 用戶，例如零售或金融企業(yè)，技術(shù)只是業(yè)務(wù)手段，而非核心競爭力。在這種情況下，很難說服管理層將工程資源投入到上游開源項(xiàng)目中。此外，一些企業(yè)在法律層面也存在顧慮。例如擔(dān)心代碼貢獻(xiàn)可能帶來潛在責(zé)任風(fēng)險(xiǎn)，盡管開源許可證通常已明確免責(zé)條款，但這種擔(dān)憂仍可能阻礙參與。

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

主持人：很多軟件工程師聽到這個(gè)故事時(shí)，往往會覺得自己已經(jīng)有既定的工作職責(zé)，即使某個(gè)想法很好也很難抽身去實(shí)現(xiàn)。你會給這類人什么建議？

Brendan：首先，我一直告訴團(tuán)隊(duì)成員：你大致可以“隱藏”約 10% 的精力，不必完全向管理層披露。任何組織中都存在一定的彈性空間，而且組織越大，這部分空間往往越大。許多真正有影響力的想法，恰恰來源于這部分自主支配的時(shí)間。

本質(zhì)上，這是鼓勵人們在局部范圍內(nèi)自主決策，而不是事事向上請示。當(dāng)然，這也意味著你會做出一些錯(cuò)誤決策、浪費(fèi)一部分時(shí)間，因此需要接受試錯(cuò)的成本。

從結(jié)果來看，這種方式的收益并不對稱：你可能多次嘗試，只有一次成功，但這一次的回報(bào)往往遠(yuǎn)超持續(xù)“穩(wěn)健優(yōu)化”帶來的收益。你需要接受這樣一種現(xiàn)實(shí)：部分嘗試最終是無效的，甚至?xí)绊懣冃П憩F(xiàn)，比如從“超出預(yù)期”變?yōu)椤胺项A(yù)期”。但只要不跌破基本要求，這種風(fēng)險(xiǎn)是可以接受的。當(dāng)然，這種路徑并不適合所有人，它更適合愿意承擔(dān)不確定性的人。

另一方面，我也會提醒大家：時(shí)間本身是可以重新分配的。很多人會說沒有時(shí)間，但實(shí)際上大多數(shù)人每周至少有 10-20 小時(shí)用于娛樂，比如打游戲、看 Netflix 或刷 YouTube，而在那段時(shí)間里，我?guī)缀踔皇窃趯懘a和工作，外加基本的生活需求。因此，關(guān)鍵問題在于你愿意為此放棄什么。這并不意味著需要極端加班，但確實(shí)意味著要在一段時(shí)間內(nèi)減少娛樂活動。

對我來說，更重要的是這個(gè)過程本身具有很強(qiáng)的吸引力。一方面，我本身就喜歡寫代碼，在“看視頻”和“寫代碼”之間，我更傾向于后者。另一方面，當(dāng)項(xiàng)目開始被用戶使用，大家在 GitHub 上提交問題、表達(dá)興趣時(shí)，這種反饋會帶來持續(xù)的動力。我會不自覺地想去解決問題、幫助用戶，甚至工作到深夜。這種投入更多源于興趣，而不是對長期回報(bào)的理性計(jì)算。當(dāng)時(shí)我并沒有在思考職業(yè)收益，而是單純希望把這件事持續(xù)推進(jìn)下去。

主持人：“隱藏”10% 的時(shí)間，在實(shí)際操作中具體意味著什么？

Brendan：這意味著你應(yīng)該始終有一個(gè)“自發(fā)項(xiàng)目”，即一個(gè)并非被指派，但你認(rèn)為重要的事情，并持續(xù)投入時(shí)間去推進(jìn)。

主持人：你說的“隱藏”是不是更像是管理預(yù)期，而不是字面意義上的隱瞞？

Brendan：不，我的意思是不要一開始就申請?jiān)S可。你需要先花一段時(shí)間把事情做出雛形，再展示給他人。因?yàn)樵?Word 或 PPT 中解釋一個(gè)想法的價(jià)值是很困難的，而一個(gè)可以實(shí)際運(yùn)行的系統(tǒng)更具說服力。因此，先構(gòu)建出一個(gè)可用原型，再進(jìn)行溝通，會大大提高成功概率。

此外，這種方式還會改變決策的結(jié)構(gòu)。原本的問題是“是否應(yīng)該投入時(shí)間去做這件事”，而當(dāng)你已經(jīng)完成了原型后，問題就變成了“是否要發(fā)布這個(gè)成果”。后者通常更容易做出判斷，因?yàn)橹攸c(diǎn)不再是資源分配，而是項(xiàng)目本身的價(jià)值。

主持人：從原型到獲得管理層認(rèn)可，中間經(jīng)歷了一段不短的時(shí)間。

Brendan：是的，大約經(jīng)歷了六個(gè)月的過程，從一個(gè)非常粗糙的原型，發(fā)展為一個(gè)我們認(rèn)為可以被實(shí)際使用的系統(tǒng)。早期加入的許多工程師都曾構(gòu)建過類似系統(tǒng)，這對他們而言是一次難得的“重做機(jī)會”。在工程師職業(yè)生涯中，很少有機(jī)會在沒有歷史包袱的情況下，從零開始設(shè)計(jì)一個(gè)系統(tǒng)。這就像獲得第二次機(jī)會，可以按照自己理想中的方式去實(shí)現(xiàn)。因此，這種“干凈環(huán)境”對團(tuán)隊(duì)成員具有很強(qiáng)的吸引力。

主持人：如果項(xiàng)目最終沒有成功，這種做法是否存在風(fēng)險(xiǎn)？

Brendan：當(dāng)然存在，這正是需要承擔(dān)的代價(jià)。你可能花了時(shí)間寫代碼，卻沒有任何成果，也可能因此錯(cuò)失晉升機(jī)會。這本質(zhì)上是一種風(fēng)險(xiǎn)投資，與創(chuàng)業(yè)類似。關(guān)鍵在于進(jìn)入這一過程時(shí)的心態(tài)：你應(yīng)該認(rèn)為這是一個(gè)值得嘗試的想法，但同時(shí)也接受失敗的可能性。如果一開始就預(yù)期一定會成功，反而更容易失望。

主持人：在職業(yè)發(fā)展的后期，這種主動創(chuàng)造項(xiàng)目的能力，是否會成為晉升的必要條件？

Brendan：在一定階段之后，確實(shí)如此。你不再只是執(zhí)行他人提出的想法，而是需要自己提出并推動有影響力的項(xiàng)目。這是角色轉(zhuǎn)變的重要標(biāo)志。此外，如果一個(gè)項(xiàng)目完全由你發(fā)起并成功落地，其成果歸因會更加明確；而參與他人主導(dǎo)的項(xiàng)目，即使取得成功，也較難完全歸功于個(gè)人。但需要強(qiáng)調(diào)的是，這仍然是一種“概率游戲”。有些人可能多次嘗試卻未能成功，或者在錯(cuò)誤的時(shí)間提出了正確的想法。創(chuàng)新不僅取決于想法本身，還取決于時(shí)機(jī)是否成熟。

主持人：你在機(jī)器人領(lǐng)域獲得了博士學(xué)位，很多人對是否攻讀博士持不同看法，你怎么看待？

Brendan：這是我最常被問到的問題之一，我通常會用兩個(gè)方面來回答。

首先，有一次我在同一家公司遇到一位大學(xué)本科同學(xué)。他畢業(yè)后進(jìn)入科技行業(yè)創(chuàng)業(yè)，輾轉(zhuǎn)發(fā)展，而我則去攻讀了博士學(xué)位，之后再回到工業(yè)界。最終，我們在同一家公司、同一職級上相遇。我們畢業(yè)于同一年、擁有相同的本科學(xué)歷，職業(yè)發(fā)展路徑不同，結(jié)果卻相似。這從某種程度上說明，是否讀博可能并不會對職業(yè)結(jié)果產(chǎn)生決定性影響。

但從另一個(gè)角度看，我在攻讀機(jī)器人博士期間確實(shí)收獲了很多樂趣，這本身對我來說就很有價(jià)值。同時(shí)，我也學(xué)到了很多在工業(yè)界不容易系統(tǒng)掌握的能力，例如如何清晰地寫作、有效地表達(dá)和展示自己的觀點(diǎn)。這些能力后來對我產(chǎn)生了實(shí)際幫助，比如在我們在花六個(gè)月時(shí)間爭取將某個(gè)項(xiàng)目開源的過程中，我的表達(dá)和論證方面能力發(fā)揮了重要作用，并且這種能力一直持續(xù)影響著我的職業(yè)發(fā)展。

此外，我后來曾擔(dān)任過幾年教授，教授計(jì)算機(jī)導(dǎo)論課程，需要向幾乎沒有計(jì)算機(jī)基礎(chǔ)的學(xué)生講解概念。這段經(jīng)歷讓我學(xué)會如何系統(tǒng)化地組織知識、從零開始解釋復(fù)雜問題。這種能力在我參與 Kubernetes 項(xiàng)目早期階段時(shí)也發(fā)揮了重要作用。當(dāng)時(shí)很多人對容器、編排等概念一無所知，需要大量教學(xué)與引導(dǎo)，而我在教學(xué)中的經(jīng)驗(yàn)幫助我更好地完成了這項(xiàng)工作。

主持人：關(guān)于“最常被問的問題”，排在第一的是什么？

Brendan：另一個(gè)非常常見的問題是：我應(yīng)該學(xué)習(xí)什么？尤其是當(dāng)我與實(shí)習(xí)生或剛?cè)胄幸粌赡甑男氯私涣鲿r(shí)，他們常常會糾結(jié)。比如現(xiàn)在 AI 很熱門，但自己更喜歡系統(tǒng)方向，那么是否應(yīng)該轉(zhuǎn)去學(xué) AI ？

我的回答其實(shí)很簡單：具體學(xué)什么并不重要，重要的是你是否在持續(xù)學(xué)習(xí)。關(guān)鍵在于找到真正讓你感興趣、能夠激發(fā)你投入熱情的方向。只有這樣，你才會主動投入時(shí)間，而不是被動消耗時(shí)間。如果你對 AI 并不感興趣，那么很可能也學(xué)不好，最終只是浪費(fèi)時(shí)間；而如果你對系統(tǒng)領(lǐng)域充滿熱情，就更有可能投入精力并取得成果，而且行業(yè)依然需要系統(tǒng)工程師。

很多人內(nèi)心存在一種對“選錯(cuò)方向”的焦慮。但我一直告訴大家，我的職業(yè)生涯從來沒有一個(gè)明確的長期規(guī)劃，我只是不斷追隨那些我認(rèn)為有價(jià)值、有趣的事情。當(dāng)然，這種方式未必適合所有人，但我希望大家明白，很多當(dāng)初看似錯(cuò)誤或死路的選擇，實(shí)際上都成為了重要的學(xué)習(xí)經(jīng)歷。與其擔(dān)心是否做出了錯(cuò)誤選擇，不如專注于持續(xù)學(xué)習(xí)。只要你在不斷成長，方向通常不會偏得太離譜。

9one more thing：Burns 成長史

Burns 的成長路徑，并不是一條標(biāo)準(zhǔn)意義上的“技術(shù)精英路線”。相反，他興趣廣泛、方向分散，甚至有點(diǎn)“不務(wù)正業(yè)”。

本科時(shí)期，他就讀于位于馬薩諸塞州西部的 Williams College。這所小型文理學(xué)院給了他很大的自由度，讓他可以同時(shí)嘗試多種不同的事情。除了主修課程之外，他還混過校園電臺，也參與過不少別的活動。對 Burns 來說，這段經(jīng)歷最重要的意義，并不只是學(xué)到了什么具體技能，而是讓他更早意識到，自己本來就是一個(gè)對很多事情都好奇的人。

藝術(shù)和計(jì)算機(jī)科學(xué)在在 Burns 身上匯合，因?yàn)樗鼈兌贾赶蛲患拢骸白鰱|西”。他一直很喜歡創(chuàng)造，無論是做雕塑、做實(shí)體創(chuàng)作，還是寫程序、搭系統(tǒng)，本質(zhì)上都是在把一個(gè)想法變成一個(gè)可以被看見、被觸碰、被運(yùn)行的具體存在。也正因如此，藝術(shù)和計(jì)算機(jī)科學(xué)最終都對他產(chǎn)生了持續(xù)的吸引力。藝術(shù)讓他學(xué)會如何塑造和驅(qū)動實(shí)體世界中的對象，計(jì)算機(jī)科學(xué)則讓他能夠在數(shù)字世界里構(gòu)建系統(tǒng)、操控機(jī)器，兩條線后來也慢慢在他的職業(yè)道路上合流。

Burns 算得上是很早就進(jìn)入計(jì)算機(jī)科學(xué)的人。他從 1994 年開始讀本科并選擇這個(gè)專業(yè)，那時(shí)互聯(lián)網(wǎng)才剛剛起步，差不多還是 Mosaic 瀏覽器剛出現(xiàn)不久的年代。等到 1998 年畢業(yè)時(shí)，外界很容易把他的選擇理解為“看準(zhǔn)了時(shí)代趨勢”，好像他早早就預(yù)判到了互聯(lián)網(wǎng)浪潮會席卷一切。但 Burns 自己并不這么看。他更愿意把這件事歸結(jié)為一種樸素的迷戀：從小到大，他一直對這些機(jī)器著迷。和那個(gè)年代的很多年輕人一樣，最初吸引他的，確實(shí)有電腦游戲的成分，但游戲并不是終點(diǎn)，真正讓他留下來的，是想弄明白機(jī)器究竟是怎么工作的。他不滿足于只是使用它，而是想理解它、控制它、擺弄它，想知道系統(tǒng)背后的邏輯到底是什么。

大學(xué)畢業(yè)后，他正好撞上互聯(lián)網(wǎng)泡沫最熱的時(shí)候。那幾年，行業(yè)里的主流敘事幾乎都是：一切都要變成 Web App。那還是動態(tài) Web 應(yīng)用最早的一段時(shí)期，整個(gè)技術(shù)世界都在快速試驗(yàn)、快速生長。Burns 也在那股浪潮中參與了 Web 應(yīng)用開發(fā)。

但與此同時(shí)，他心里一直有另一個(gè)目標(biāo)：當(dāng)教授。于是，在產(chǎn)業(yè)界待了一段時(shí)間后，他又回到學(xué)校繼續(xù)深造。后來他坦言，那段重新回到學(xué)術(shù)環(huán)境的決定，現(xiàn)在看起來像是很有先見之明，因?yàn)樗窃?2000 年進(jìn)入研究生院的，幾乎踩在互聯(lián)網(wǎng)泡沫破裂的前夜。一年之后，當(dāng)他已經(jīng)在招生委員會翻看下一屆申請者材料時(shí)，甚至忍不住感慨：如果讓那時(shí)的自己和這批人一起競爭，恐怕未必還能順利進(jìn)去。因?yàn)榕菽黄疲緵_向產(chǎn)業(yè)界的那批程序員，又有很多回流到了學(xué)校，而他恰恰是在那之前完成了轉(zhuǎn)身。

在研究生階段，Burns 繼續(xù)沿著“實(shí)體世界”和“數(shù)字世界”結(jié)合的方向往下走，最終拿到的是機(jī)器人方向的 PhD，其中又包含了相當(dāng)多 AI 和 robotics 的內(nèi)容。這也成為他成長過程中非常關(guān)鍵的一段：他開始系統(tǒng)地研究，如何把 AI、機(jī)器人、物理系統(tǒng)和計(jì)算機(jī)系統(tǒng)真正接到一起。對他來說，這不是一條抽象的研究路徑，而是一種非常具體的工程興趣。他喜歡思考，也喜歡動手，把控制理論、規(guī)劃、系統(tǒng)設(shè)計(jì)這些原本分散的知識點(diǎn)真正放進(jìn)一個(gè)可運(yùn)行的整體里。很多年后回頭看，他也越來越意識到，那時(shí)候?qū)W過的控制理論、規(guī)劃方法以及“規(guī)劃和控制之間的差別”，并沒有停留在機(jī)器人論文里，而是實(shí)實(shí)在在影響了他后來做系統(tǒng)架構(gòu)的方式。

除了學(xué)術(shù)訓(xùn)練之外，Burns 還在很早的時(shí)候就接觸了開源，這對他的職業(yè)觀念影響極深。互聯(lián)網(wǎng)泡沫時(shí)期，他在做 Web 應(yīng)用開發(fā)時(shí)開始使用 JMeter——一個(gè)用 Java 寫的負(fù)載測試工具。用著用著，他發(fā)現(xiàn)了一些 bug，于是開始往項(xiàng)目的郵件列表里發(fā) patch。那是 1999 年，彼時(shí)沒有 GitHub，甚至連 git 都還沒出現(xiàn)，開源協(xié)作還停留在“靠郵件發(fā) patch”的年代。Burns 后來回頭去翻檔案，發(fā)現(xiàn)自己當(dāng)年真的是一封封郵件在往外發(fā)代碼修改。最開始并沒有人理會這些 patch，直到后來他主動去問，才得到回復(fù)：這個(gè)項(xiàng)目已經(jīng)沒人維護(hù)了，你要不要接手？年輕時(shí)的他，并不知道“當(dāng) maintainer”到底意味著什么，只是覺得聽起來不錯(cuò)，于是就答應(yīng)了。后來，他和另外一個(gè)人一起把這個(gè)項(xiàng)目接了下來，開始負(fù)責(zé)合并補(bǔ)丁、處理問題、維持項(xiàng)目運(yùn)轉(zhuǎn)。這段經(jīng)歷，讓他第一次真正從“使用開源”走向了“維護(hù)開源”。

更有意思的是，這個(gè)項(xiàng)目后來并沒有死掉，反而一路活了下來，甚至最終被整合進(jìn) Azure 的負(fù)載測試服務(wù)里。對 Burns 來說，這件事有點(diǎn)像一種奇妙的時(shí)間回環(huán)：他早年參與維護(hù)的一個(gè)開源工具，很多年后居然以另一種方式重新出現(xiàn)在自己的職業(yè)世界中。更有趣的是，這里面甚至還留著一點(diǎn)他本科時(shí)代“藝術(shù)”那一面的影子。因?yàn)閯偨邮猪?xiàng)目時(shí)，他嫌原來的圖標(biāo)不夠好看，索性自己動手畫了一套帶有濃烈早期 Java 風(fēng)格的圖標(biāo)——有點(diǎn)像 Windows XP，再加一點(diǎn)紫色調(diào)。那套圖標(biāo)后來居然又陪著這個(gè)項(xiàng)目活了十年，直到風(fēng)格徹底過時(shí)。這在 Burns 看來，幾乎就是開源世界里“l(fā)egacy”最生動的樣子：很多東西不是因?yàn)檎l精心設(shè)計(jì)成“歷史遺產(chǎn)”，而只是因?yàn)樗坏┱娴倪M(jìn)入系統(tǒng)，就會比你想象中活得更久。

后來，Burns 還做過幾年教授，也認(rèn)真投入過學(xué)術(shù)工作。但最終，他還是意識到兩件事。第一，他非常想回到西雅圖，那是他長大的地方；第二，比起留在學(xué)術(shù)體系里，他越來越確定，自己真正喜歡的是“做有人在用的軟件”。在那段時(shí)間里，他曾在 Android 還沒有真機(jī)普及、大家主要依賴模擬器的年代，做過一個(gè)可視化的 WYSIWYG 界面編輯器。那時(shí)候做 Android GUI 基本得手寫 XML，而 Burns 覺得這件事太反人類，于是自己寫了一個(gè)拖拽式的 GUI builder。后來開始有用戶真的使用它、反饋它、喜歡它，這件事給他的刺激非常大。對 Burns 來說，一旦親身體驗(yàn)過“有人真的在用你做的東西”，那種吸引力就會變得很難抗拒。

也正是在這種感受推動下，他慢慢意識到，自己最終還是應(yīng)該回到產(chǎn)業(yè)界。后來他進(jìn)入 Google，加入 Web 搜索基礎(chǔ)設(shè)施團(tuán)隊(duì)。現(xiàn)在回頭看，這個(gè)機(jī)會很大程度上來自他在機(jī)器人和系統(tǒng)編程上的積累——尤其是 C 和 C++。在那個(gè)年代，Google 的崗位分配還不是今天這種高度細(xì)分的模式。你申請的是 Google，而不是某一個(gè)具體團(tuán)隊(duì)；真正加入后，公司再根據(jù)你的背景和偏好分配崗位。Burns 選擇了 systems 方向，而他過往在機(jī)器人上的底層編程經(jīng)驗(yàn)，也讓他很自然地被放到了對性能要求極高的搜索基礎(chǔ)設(shè)施團(tuán)隊(duì)。

這段經(jīng)歷讓 Burns 第一次真正體會到，“有人在用”和“幾十億人在用”完全不是一回事。此前他做的 Android 工具已經(jīng)讓他體會到了用戶反饋的快感，但 Google 搜索的量級是另一種世界。對一個(gè)喜歡做系統(tǒng)的人來說，看著自己參與構(gòu)建的東西被數(shù)十億人使用，那種沖擊力和成就感是完全不同的。更重要的是，Google 搜索基礎(chǔ)設(shè)施的經(jīng)歷，讓他真正積累了大規(guī)模分布式系統(tǒng)的經(jīng)驗(yàn)。后來，當(dāng)公司內(nèi)部進(jìn)行重組、他被調(diào)到 cloud 方向時(shí)，他過往在開源社區(qū)里的經(jīng)驗(yàn)，和在搜索基礎(chǔ)設(shè)施里打下的分布式系統(tǒng)能力，第一次真正合到了一起。再往后，這些積累逐漸匯成了 Kubernetes 的雛形。

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

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

聲明：本文為 InfoQ 編譯，不代表平臺觀點(diǎn)，未經(jīng)許可禁止轉(zhuǎn)載。

會議推薦

世界模型的下一個(gè)突破在哪？Agent 從 Demo 到工程化還差什么？安全與可信這道坎怎么過？研發(fā)體系不重構(gòu)，還能撐多久？

AICon 上海站 2026，4 大核心專題等你來：世界模型與多模態(tài)智能突破、Agent 架構(gòu)與工程化實(shí)踐、Agent 安全與可信治理、企業(yè)級研發(fā)體系重構(gòu)。14 個(gè)專題全面開放征稿。

誠摯邀請你登臺分享實(shí)戰(zhàn)經(jīng)驗(yàn)。AICon 2026，期待與你同行。