你回頭看這五年走過的路。從 Day 4 你發現 Brent 是系統的單點故障、到 Day 13 你學會保護瓶頸讓他「閒下來」——這些管理招數在過去確實都奏效了。
然而，今天早上的站會，卻讓你發現了一個更為殘酷的真相。
即使做了這麼多，新的 Brent 還是一直在組織中冒出來。
她是你兩年前招募進來的資深 SRE，對 Kubernetes 以及整套可觀測性技術棧（Observability Stack）瞭若指掌。如今，她變成了團隊中新的「什麼問題都找她」。
你打開了上個月的 Slack analytics 數據統計：
這個場景讓你感到似曾相識。
五年前，技術主管 Bill Palmer 面對的是 Brent——那個全公司唯一懂部署、懂資料庫、懂一切的英雄。Bill 後來學會了保護 Brent，把他從低價值救火中解放出來，讓他能專注在關鍵任務上。
但 Bill 沒有從根本上解決問題：為什麼系統每次都需要一個英雄？
你看著 Maya 的行事曆，她今天依然要處理：
你深深意識到：這不是 Maya 的問題，這是系統設計的結構性缺陷。
只要「開測試環境」、「修改權限」、「Debug 基礎設施」這些事情依然需要找人手動處理，就一定會源源不斷地產生下一個瓶頸。
這場打地鼠遊戲永遠沒有結束的一天。真正的根本解法是：讓這些事情不再需要「找人」解決。
你盯著白板，畫出兩條截然不同的路：
| 🔴 選項 A：招募第二位 Maya，分擔當前的工作負載 | 🔵 選項 B：建置內部開發平台（IDP），將需求轉為自助服務 |
|---|---|
| 短期效益：✓ Maya 的請求量由 97 次降低至約 50 次，能暫時喘口氣長期代價：✗ 半年後兩人都會成為新的瓶頸，因為依賴人的本質沒變✗ 團隊規模擴張時，需等比例招募更多英雄，成本暴增結果：✗ 陷入永無止境的「打地鼠」與尋找救火英雄的惡性循環 | 短期代價：✗ 前期需要投入研發資源建置平台，短期內可能看不見產出✗ 需要承受管理層質疑「為何不直接多招人」的政治壓力長期效益：✓ 常見需求全部變成平台自助按鈕，完全釋放專家產能✓ Maya 被打斷次數由 97 次鋪平至 12 次（只解難題）結果：✓ 建立自動化規模化路徑，讓系統不再依賴個體英雄而存在 |
如果是你，此時 CEO 在等待你的答案：「要不要幫你再批准一個 SRE 的人力預算？」
你敢不敢堅決地說：「我現在不要招人，我要花六個月建置一個內部開發平台。」？
正確答案是 選項 B。
這就是**平台工程（Platform Engineering）**的核心洞見：
組織的成長瓶頸，從來不是因為缺少能人，而是因為能人的知識無法被規模化複製。
內部開發平台（Internal Developer Platform, IDP）的真正任務，是將「重複解決的技術問題」轉化為「自助式的產品服務」。
Bill Palmer 在《鳳凰專案》裡學會了保護 Brent，讓他專注於高價值工作。但如果 Bill 活在 2026 年，他會發現一個更深層次的道理：
一味地「保護 Brent」只是治標，真正的治本是「讓大部分找 Brent 的常態事務不再需要 Brent 出面」。
這正是平台工程要解決的痛點。
將開發者每次都需要 SRE / DBA / SecOps 協助的日常任務，做成「權限邊界內的自助服務」：
這絕不是為了「讓 Maya 失去價值」，而是「讓 Maya 不需要反覆回答同樣的問題 97 次」。
她終於能有完整的專注時間去研究更核心的挑戰：優化系統架構的可觀測性、設計更具韌性的容災方案、並處理只有 SRE 專家大腦才能解開的複雜線上事件。
這才是 Day 4 Brent 瓶頸問題的終極解答路徑：
英雄的個人知識，終於在平台工程的沉澱下，轉化成了組織共有的能力。
你可能會質疑：「平台會不會淪為另一種官僚流程？開發者想開個環境還要被平台流程卡住，不是反而更慢了？」
這就牽涉到 鋪平道路（Paved Road） 或 黃金路徑（Golden Path） 的設計思維：
平台的任務絕不是為了限制工程師的自由，而是在「大多數人在大多數時候需要的事情」上，提供一條最快速且最安全的綠色通道。
需要臨時測試環境？走 Golden Path 黃金通道，三分鐘快速建置，內部已自動配好合規安全政策、自動備份與基礎監控。
想要做一些平台尚未覆蓋的極限技術實驗？完全可以，但你必須自行負責該環境的安全與維運，或者向平台團隊提出新模板的擴充申請。
問題在於，平台建置得再好，「學習如何使用平台」本身對開發者而言依然是一道門檻。
開發者必須記住「去哪個 Portal、點擊哪個按鈕、填寫哪些 YAML 模板」，這依然是一種認知負荷。
這時候，AI Agent 可以作為平台的自然語言介面，把「學會用平台」變成簡單的「人機對話」：
graph TB
A[開發者需求] --> B[AI Platform Agent]
B -->|1.「幫我開個有 GPU 的測試環境」| C[理解意圖:<br/>Spark? K8s? GPU type?]
C --> D[檢查 policy:<br/>此人有權限嗎?]
D -->|在權限內| E[自動執行:<br/>調用平台 API]
D -->|超出權限| F[升級給 Maya<br/>附完整 context]
E --> G[回報結果:<br/>環境 URL + 存活時間]
B -->|2.「為什麼我的 pod CrashLoopBackOff」| H[診斷工具:<br/>image/resource/log]
H -->|常見問題| I[給解法+文件]
H -->|新問題| F
B -->|3.「給我上週的 cost breakdown」| J[查詢平台 metrics]
J --> K[生成報告+視覺化]
透過 AI Platform Agent，開發者不需要去記憶繁瑣的平台 UI：
開發者：@PlatformAgent 幫我開一個環境測試新的 Feature Flag 邏輯。
Agent ：收到！已為您準備，開通前請協助確認以下資訊：
- 執行環境：(Python 3.11 / Node 20 / Go 1.21)
- 連接資料庫：(Dev / Staging)
- 預計使用期限：(2h / 1d / 1w，時間到期將由系統自動回收)
開發者：Python 3.11，連 dev 資料庫，用一天就好。
Agent ：✅ 環境已成功建立！
URL: https://dev-env-a3f2.internal/
該環境將於 2026/07/28 14:00 自動回收銷毀。
詳細連線憑證已發送至您的私密頻道。
💡 小提示：下次您可以直接對我說「開一個 Python dev 環境一天」即可。
在安全策略之內的事務，Agent 全部自動搞定。一旦超出權限邊界，則自動 Escalation 升級交給 Maya 處理——同時附上詳盡的脈絡資料（誰、需要什麼、為什麼、安全策略檢查報告），Maya 再也不需要從頭問起。
如此一來，Maya 原先面臨的 97 次線上打斷，有 80 次直接被 AI 搭配內部開發平台給自動化消化掉，她只需處理剩下 17 次真正棘手的技術難題。
我們來看一個 2026 年大型團隊的平台化實踐案例：
想像一個擁有 120 人的產品研發組織，僅配置了 6 名 SRE 負責管理整體的基礎設施。每個 SRE 每天平均被開發者臨時打斷 8 次，換算下來，每位專家每週會白白損失 12 個小時在重複性、低價值的髒活累活上。
他們隨後堅定地執行了以下三步轉型：
六個月後的效能數據比對：
SRE Lead 在季末的分享會上感慨地說：「以前我們就像是系統的『消防隊』，每天疲於奔命。現在我們終於轉變成了『築路隊』，有時間去把路鋪好，不讓火燒起來。」
這就是從「英雄爆肝支撐系統」，走向「由平台系統服務團隊」的根本轉變。
「英雄只能拯救團隊一時，而良好的內部開發平台卻能保障組織一世。將英雄的個人知識平台化，系統的瓶頸才會真正消逝。」
在你們團隊目前最依賴、每天被問倒最多次的那個「技術英雄」身上，他每天重複被問到的問題裡，有多少其實能被做成平台上的「自助按鈕」？
如果你的答案是「絕大部分都可以」，那麼，你就已經知道平台工程的第一步該往哪裡踏出去了。
明天，我們要去挑戰一個更加具有毀滅性的管理難題：如果這位在團隊中舉足輕重的關鍵人物明天突然宣布離職，他腦袋裡的那些避坑經驗，有辦法被系統性地留存下來嗎？
我們將聊聊如何透過 RAG + MCP + 知識庫，將 Brent 的大腦轉化為組織隨時可檢索的數字資產。
Day 25 見。
iThome鐵人賽
看影片追技術