DevOps 死了嗎？Kubernetes 傳奇 Kelsey Hightower 的 2025 答案

本文整理自 JetBrains 2024 年 12 月發布的訪談。

DevOps 死了嗎？

這個問題在 2024 年被問了無數次。有人說 DevOps 已經過時，被平台工程取代了。有人說 DevOps 從來沒有真正實現過它的承諾。還有人說 AI 會讓整個討論變得無關緊要。

Kelsey Hightower 的答案比這些都複雜，也比這些都務實。他是 Kubernetes 社群最具影響力的布道者，在 Google Cloud 擔任開發者大使超過八年，也是 KubeCon 的共同創辦人。當他談論 DevOps、平台工程、雲端、AI 時，他不是在販賣願景——他是在分享二十多年的一線經驗。

DevOps 沒死，但很多人只是換了 T-shirt

Hightower 對 DevOps 現況的診斷非常直接：問題不是 DevOps 這個概念，而是很多公司只是假裝在做 DevOps。

「有些公司選擇了簡單的路線，」他說。「『嘿，大家，你們不再是系統管理員了。你們現在是 DevOps 工程師。』就好像，『哇，我有新的 T-shirt 嗎？』然後有些人就只是穿上了 T-shirt，其他什麼都沒改。」

這種現象持續了五年、十年。當這些公司回頭看結果時，他們發現什麼都沒變。Hightower 用了一個更狠的說法來描述這種情況：「有些人有 20 年的一年經驗。」他們重複做同樣的事二十年，從「系統管理員」升到「資深系統管理員」，再變成「DevOps 工程師」。他們處理 on-call 的速度可能變快了，但他們從來沒有把學到的東西轉化成工具、流程、或自動化。

真正的 DevOps 需要持續學習、需要把經驗轉化成可重複使用的知識。DevOps 這個詞本身不包含紀律、不包含永遠學習的承諾、不包含遇到障礙時願意學新技能來解決問題的態度。這些東西必須自己加上去。大多數人選擇不加。

平台工程：從自動化到 API 設計

這帶出了 DevOps 和平台工程的關鍵區別。

Hightower 說，DevOps 時代的典型成就是這樣的：學會 Terraform、教全公司 HCL、把 Terraform 程式碼 check in、建一堆 DevOps pipeline。這樣你就可以在 LinkedIn 上放一個漂亮的 badge，說自己是 DevOps 工程師。

但平台工程要求更多。「在雲端待了八年後，」他說，「你不能停在 HCL。那是一個不足以描述契約的 API。」

然後他講了一個具體的例子。在一場會議上，有個工程師問他怎麼轉型成平台工程師。Hightower 讓他做了一個思想實驗：「如果你必須替整間公司做所有的部署，你會問開發團隊什麼問題？」

那個工程師想了想：「版本號。記憶體和 CPU 需求。可能需要多少磁碟空間。要部署到哪個區域。」

「就這些嗎？」

「應該就這些。」

「那就是你的 API。」

這就是平台工程和 DevOps 的區別。DevOps 工程師專注在活動：學工具、寫自動化、建 pipeline。平台工程師專注在影響：設計 API、建構產品、讓其他團隊能夠自助服務。至於底層用 Kubernetes 還是 Terraform？那是實作細節，外部團隊不需要知道。

那個工程師聽完後恍然大悟：「啊，我需要建構產品。」

Kubernetes：已經無聊六七年了

談到 Kubernetes，Hightower 的回答可能會讓很多人意外。

「如果你有一個無狀態的 web app，」他說，「Kubernetes 已經無聊六七年了。」

這不是在貶低 Kubernetes。在科技領域，「無聊」是最高的讚美。無聊意味著可靠、可預測、不會讓你半夜被 page 起來。Go 語言現在也「無聊」了——它就是能用，不需要思考。這正是基礎設施應該追求的狀態。

讓事情變得「刺激」的，是人們試圖用 Kubernetes 做一些它原本設計之外的事。想用 Kubernetes 管理資料庫？想在上面跑 PostgreSQL 或 MySQL？那你得自己建構那個 control loop。大多數人不知道怎麼做。試過的人偶爾會丟資料。這種「刺激」不是你想要的那種。

Hightower 提供了一個有用的框架：基礎設施只有在你注意到它的時候才會變得刺激。飛機只有在出問題的時候才刺激。正常情況下，你上飛機、睡著、醒來在另一個國家。你不會給機長鼓掌，因為沒什麼好鼓掌的。但如果遇到嚴重的亂流然後安全降落？所有人都在鼓掌。

「當基礎設施擋住你的路時，」他說，「我們通常不會用『刺激』來形容。我們用的是『摩擦』和『挫折』。」

雲端回遷：不是雲不好，是你沒改變操作模式

關於企業離開雲端回到自建機房的趨勢，Hightower 有一個非常清醒的觀察。

他以 37signals（Ruby on Rails 背後的公司）為例。這是一個非常強的工程團隊，強到能夠把他們建構 web 應用的方式編碼成一個框架，讓十五、二十年前的無數人用來建構三層架構。這個團隊試過了每一個主要的雲端供應商：GCP、AWS、Azure。最後他們決定回到自建機房。

但 Hightower 指出，大多數公司不是 37signals。他們選擇離開雲端的原因，不是因為他們太厲害了不需要雲端，而是因為他們從來沒有真正利用雲端的好處。

「很多人掙扎的原因，」他說，「是他們相信可以『把雲塗在你的混亂上』，然後事情就會變好。」

這些公司做的是：把所有東西原封不動搬上雲端（lift and shift）、繼續開著太大的機器（因為沒人有工具或技能做真正的效能分析）、繼續用舊的操作模式。問題是，雲端有 2-3 倍的價格溢價。如果你不改變操作模式，你等於在為舊行為付出巨額罰款。

五年後，這些公司抓著頭說：「我們不願意改變操作模式，我們也付不起這個稅。」所以他們回去了。

但好消息是，硬體變快了、變便宜了，而且雲端也演進了。我們從 EC2 和 S3 這種專有系統，演進到 Kubernetes 和 Prometheus 這種開放服務。這意味著你終於可以在自建機房獲得類似雲端的 API 體驗。所以回遷也不是完全沒道理——只要你知道自己在做什麼。

Serverless：一個好概念被濫用了

Hightower 對 Serverless 的評價非常微妙。

他說，Serverless 剛出現時的想法是對的：能不能把機器抽象掉，讓它看起來不存在？你只需要實作一個 handler，不用管底層的伺服器。這個願景很美好。

問題是很多人太興奮了，開始「Serverless for everything」。他們把根本不適合 Serverless 的東西硬塞進去。而且，那個看起來很簡潔的 function signature，一旦你開始 import 資料庫、import 各種依賴，那個 HTTP handler 就變成了 function main，和其他任何東西一樣大。

Hightower 把 Serverless 類比成 Ruby on Rails：它是一個 framework。如果你買單這個 framework 的假設，你可以從中獲得很多好處。但如果你需要跳出來，你就卡住了。

最後他給出了一個務實的結論：容器 image 贏了。你把東西放進容器裡，如果你想要 Lambda 的契約，你用 Lambda shim；如果你想要 Linux kernel 的契約，你就綁定一個 port 等待流量。這個 image 讓你可以從 Heroku 跳到 VM 跳到 Kubernetes，在它們之間自由移動。這是一個好的中間地帶——平台獨立，選擇最適合你的。

AI：意圖導向 API 的潛力，但別忘了工程師的基本功

Hightower 對 AI 的態度非常務實。

他觀察到一個根本性的張力：軟體工程師這個職業，本質上就是在把不確定的東西變成可預測的東西。當系統不可預測時，我們叫它 bug；當它做了預期之外的事，我們叫它安全漏洞。然後 AI 來了，它的核心特性恰恰是不可預測性。

「為什麼要預測？明明可以確定。」他這樣問。

但他也看到了 AI 的真正價值：意圖導向的 API。現在的工具鏈太碎片化了——HCL、Kubernetes API、Helm charts、SQL、各種配置檔。如果 LLM 能讓人用自然語言表達意圖，然後由某個中間層處理底層的複雜性，那是有價值的。

只是他也提醒：底層的東西一樣都沒變。你還是要呼叫雲端供應商的 API，你的應用還是跑在同樣的 kernel 上。「除非這些都改變了，」他說，「否則我們真正談論的，只是一個新的 API 來做我們過去三十年一直在做的事。」

回歸 Unix 哲學

訪談的最後，Hightower 被問到未來會是什麼樣子。他的回答回到了一個古老但歷久彌新的原則：Unix 哲學。

「做一件事，把它做好。」

Kubernetes 之所以成功，部分原因是它沒有試圖解決所有問題。它提供了一個可擴展的系統，讓其他人可以在上面建構自己的解決方案。資料模型對了，介面對了，剩下的讓社群去做。這和 Unix 的精神是一致的。

Hightower 說，在這波 AI 淘金熱中，很多人在重新發明輪子，重新發明 MCP 這樣的東西。但如果你理解基礎和根本，你就會發現這些原則從來沒有改變過。

DevOps 沒死。它只是需要回歸本質：持續學習、把經驗轉化成工具、設計好的 API、做一件事並把它做好。這些聽起來不新，但能做到的人一直都很少。

而這，可能才是最該解決的問題。