「我喜歡穀倉」——Kelsey Hightower 的反直覺團隊協作論
Kubernetes 共同創辦人 Kelsey Hightower 說「我喜歡穀倉」時，所有人都愣住了。但他的論述非常務實：專業分工加上好的 API，比讓每個人都懂一切更有效。這是對 DevOps 原教旨主義的一次務實修正。
本文整理自 JetBrains 2024 年 12 月發布的訪談。
「我喜歡穀倉。」
當 Kelsey Hightower 說出這句話時，訪談者明顯愣了一下。這是 Kubernetes 社群最具影響力的布道者、前 Google Cloud 開發者大使、KubeCon 共同創辦人——一個 DevOps 運動的標誌性人物——公開挑戰「打破穀倉」這個行業共識。在過去十五年裡，「穀倉」（silos）一直是軟體產業的髒話，代表著官僚、低效、各自為政。每一本談 DevOps 的書、每一場談敏捷的演講，都在告訴你：穀倉是敵人，必須摧毀。
然後 Hightower 說：不，你們搞錯了。
機場比喻：我不需要知道怎麼開飛機
Hightower 用了一個精妙的比喻來解釋他的立場。
「當我去機場時，」他說，「我不知道怎麼開飛機。我不知道怎麼經營一家航空公司。我買我的機票——這是一個非常棒的 API。我購買機票，我出現在機場，我坐到指定的座位上，我閉上眼睛，醒來時我已經在另一個國家了，然後我離開。」
他停頓了一下。「我可能會跟機長說聲謝謝。但除此之外，我不需要任何其他的互動就能完成一件像飛到另一個地方這樣平常的事。」
這個比喻揭示了一個被忽略的事實：我們每天都在享受專業分工的好處，卻在軟體產業裡試圖否定它。沒有人期望乘客學會飛行，也沒有人期望機長去理解訂票系統的實作細節。他們透過一個清晰的介面——機票和座位——進行協作。這種協作不需要他們坐在一起開會，不需要他們互相理解對方的專業知識，更不需要他們每個人都懂一切。
這就是 Hightower 說的「好的穀倉」：清晰的邊界，加上定義良好的 API。
DevOps 的問題：很多公司只是換了 T-shirt
要理解 Hightower 為什麼這樣說，需要先理解 DevOps 運動出了什麼問題。
DevOps 的原始願景很美好：開發和運維應該緊密協作，打破傳統的組織壁壘，讓軟體能夠更快、更可靠地交付。這個願景吸引了無數公司投入轉型，但 Hightower 觀察到一個殘酷的現實：很多公司只是走了捷徑。
「有些公司選擇了簡單的路線，」他說。「『嘿，大家，你們不再是系統管理員了。你們現在是 DevOps 工程師。』就好像，『哇，我有新的 T-shirt 嗎？』然後有些人就只是穿上了 T-shirt，其他什麼都沒改。」
這種現象持續了五年。然後當這些公司回頭看結果時，他們發現 DevOps 這個詞本身什麼都不代表。沒有新的技能，沒有新的實踐，沒有新的工具——只有一個新的職稱。Hightower 用了一個更狠的說法：「有些人有 20 年的一年經驗。」他們做了二十年同樣的事，只是職稱從「系統管理員」變成「資深系統管理員」，再變成「DevOps 工程師」。他們處理 on-call 的速度可能變快了，但他們從來沒有把學到的東西轉化成工具、流程、或自動化。
真正的 DevOps 不是換 T-shirt。它是要求人們永遠學習，把經驗轉化成可重複使用的知識。這很難。大多數人選擇不這麼做。
平台工程的真正意義：設計 API，不是教全公司 Terraform
這帶出了 Hightower 對平台工程的看法，也是他「喜歡穀倉」論述的核心。
他說，很多自稱平台工程師的人，把工作定義成「教全公司 Kubernetes、Prometheus、Docker、Terraform」。他們覺得目標是讓每個人都會用這些工具。Hightower 直接說：「那你就錯了。」
然後他給了一個具體的思考方式：「如果你必須替整間公司做所有的部署，你會問開發團隊什麼問題？」
答案通常很簡單：版本號、記憶體和 CPU 需求、可能還有需要多少磁碟空間、要部署到哪個區域。就這些。
「那就是你的 API，」Hightower 說。「你把它變成一個 API。它可以是 repository 裡的一個簡單 YAML 檔案，也可以是一個用 curl 呼叫的 API 端點。但這就是公司要你做的事。他們要你把你繼承的任何平台——VMware、雲端供應商、什麼都好——和我們剛才談的那個 API 之間的膠水程式碼做出來。」
這才是平台工程師的工作。你用 Kubernetes 還是 Terraform？那是實作細節。外部的團隊不需要知道。他們只需要知道怎麼呼叫你的 API。
當 Hightower 這樣解釋時，那位工程師恍然大悟：「啊，我需要建構產品。」
專業分工 + 好的 API = 真正的協作
這就是「我喜歡穀倉」的真正含義。
Hightower 不是在說團隊不應該溝通。他是在說，溝通應該發生在必要的時候——當需要新功能、當 API 需要演進、當需要協作才能達到正確的目標時。但一旦 API 建立好了，就不需要為了第一千次的軟體部署而再次協作。
這和雲端供應商的運作方式一樣。大多數人從來沒有見過 S3 或各種負載平衡服務背後的工程師，但不知道怎麼地，我們就是能夠使用這些東西，而不需要每天和他們互動。這不是因為缺乏協作，而是因為有一個設計良好的介面。
「如果我要負責基礎設施，」Hightower 說，「我想成為那種說『軟體開發本身就已經夠難了』的隊友。我們需要什麼樣的契約，來確保你建構的任何東西都能以最有效的方式送到客戶面前？我會成為這個領域的專家，你成為你那個領域的專家，我們在中間相遇——不是透過坐在一起，而是透過一個文件完善的 API。」
這是對 DevOps 原教旨主義的一次務實修正。不是每個人都需要懂一切。專業分工存在是有原因的。關鍵在於，穀倉之間的介面要設計好。
機場就是這樣運作的。航空公司、機場、空管、海關——這些都是穀倉。但因為介面定義得很清楚（機票、登機證、護照），整個系統就能運作。沒有人會說「我們應該讓乘客學會飛行，這樣協作才會更好」。
軟體產業不知道為什麼，就是特別喜歡否定這個常識。Hightower 只是把它說出來了。