前六天，你學到了看見隱形工作、保證瓶頸、用商業風險跟高層對話。但今天早上部署失敗的那一刻，你發現還有一個更根本的問題：Dev 和 Ops 根本不覺得自己在同一條船上。

而公司的 KPI 體系，正在獎勵他們互相傷害。

場景：部署失敗後的指責大會

早上 10 點，Phoenix 專案的一個關鍵功能終於要部署到 Staging 環境。

Dev Lead 在 Slack 上貼了一句：「新版本 Ready，麻煩 Ops 部署。」附上一個 Git Tag。

下午 2 點，Ops Lead 回報：「部署失敗。Database Migration Script 跑不過，Rollback 了。」

Dev Lead 立刻反擊：「我在本地測過，沒問題。是不是你們環境有問題？」

Ops 冷冷回覆：「你們的 Migration Script 硬寫了 localhost 連線字串，Staging DB 的 Host 根本不是那個。還有，這個 Script 需要 SUPERUSER 權限，你們知道 Production 環境不可能給吧？」

Dev：「那你們的環境為什麼跟 Dev 不一樣？我怎麼知道你們那邊什麼設定？」

Ops：「你們的文件在哪？連 Dependency 清單都沒給，我要怎麼準備環境？」

你坐在會議室角落，聽著兩邊爭吵。這不是第一次，也不會是最後一次。

更可怕的是，你發現：這不是個人恩怨，而是系統設計出來的必然。

你看了一眼公司的 KPI：

• Dev 的 KPI：「新功能交付數量」、「Feature Velocity」、「Story Points 完成率」
• Ops 的 KPI：「系統可用性 SLA」、「Incident 數量」、「MTTR（平均修復時間）」

Dev 被獎勵「越快越好」，Ops 被獎勵「越穩越好」，這兩個目標天生衝突。

兩難：劃清責任？還是共同負責？

Phoenix 專案已經延誤兩次。CEO Steve 盯著進度表問你：「能不能讓他們別吵架，好好配合？」

你知道「配合」不是問題的答案。真正的問題是：該怎麼設計這兩個團隊的關係？

如果是你，現在就要做決定。你選哪個？

先別往下看

認真想三十秒。

你會選 A 還是 B？

為什麼？

翻牌：DevOps 的本質不是工具，是 Flow

正確答案是 B。

但我猜你已經猜到了。問題是，為什麼這麼難做到？

因為 「各自最佳化」是人類本能，而「整體最佳化」是反直覺的……

《鳳凰專案》裡，Gene Kim 用 Erik 的工廠隱喻告訴你：當 Dev 專注在「寫出更多 Code」，Ops 專注在「不讓系統掛掉」，兩邊各自最佳化的結果，就是交接處變成了絞肉機。

• Dev 不管部署難度，反正「我的 Code 能跑」，丟過去就不是我的事。
• Ops 不管業務價值，反正「你的 Code 太危險」，擋下來就不是我的錯。

結果：Dev 覺得 Ops 是阻礙創新的官僚，Ops 覺得 Dev 是製造混亂的瘋子。

真正的 DevOps 不是「讓 Dev 學會 Kubernetes」或「讓 Ops 寫 Python Script」。

DevOps 的本質是 Flow（流動）：讓 Dev、Ops、Security、Business 一起對「從需求到 Production 的價值流」負責。

這意味著：

1. Dev 的 KPI 不是「寫了多少 Code」，而是「有多少 Code 成功跑在 Production 並產生價值」。
2. Ops 的 KPI 不是「擋掉多少部署」，而是「Production 的可靠性與部署的頻率能否同時提升」。
3. 兩邊應該攜手為以下端到端價值指標共同負責：
   • ⏱️ 前置時間（Lead Time）：從需求提出到成功上線的耗時。
   • 🚀 部署頻率（Deployment Frequency）：系統發布新版本的頻率。
   • 🩹 平均修復時間（MTTR）：線上系統發生事故後的平均復原速度。

當你把 Dev 和 Ops 的記分板合併，他們才會開始像同一個隊伍。

如果有 AI Agent：打通資訊斷層

問題是，即使你說服兩邊「我們是同一隊」，他們之間的資訊斷層依然存在。

Dev 不知道 Ops 那邊的環境限制、權限設定、監控需求。

Ops 不知道這次改了什麼、哪些地方有風險、出了事該怎麼 Debug。

丟包的本質，是資訊的不對稱。

這時候，AI Agent 可以扮演一個角色：共享的脈絡（Context）橋樑。

想像每次 Dev 要部署時，有一個 Agent 自動做這些事：

graph TD
    A[Dev 提交 deployment request] --> B[Agent 分析 changeset]
    B --> C[抓出:改了哪些 API、DB schema、config]
    B --> D[抓出:需要什麼環境變數、權限、dependency]
    B --> E[抓出:過去類似變更的風險點]
    C --> F[生成部署 checklist]
    D --> F
    E --> F
    F --> G[同時推送給 Dev 和 Ops]
    G --> H[Ops 看到風險項,提前準備環境]
    G --> I[Dev 看到遺漏項,補齊資訊]

Agent 做的事其實很單純：

1. 從 Git Diff 抓出這次變更的「風險熱區」（修改了 DB、API，或是加入了新的 Dependency）。
2. 從歷史 Deployment Log 尋找「上次類似改動出過什麼事」（例如：上次修改 DB Schema 時 Migration 超時）。
3. 自動生成一份「這次部署你該知道的事」清單，同時推送給 Dev 和 Ops。
4. 如果缺失關鍵資訊（例如沒寫 Rollback Plan、沒更新環境變數文件），提前發出警報。

這就是 2026 年的做法：不是靠「更多無意義的溝通」，而是靠 Agent 把每次部署該有的資訊自動準備好，推到需要看的人面前。當 Ops 不再問「你們改了什麼」、Dev 不再問「你們環境是怎樣」，丟包的盲區就自然開始縮小。

共享資訊，是共享責任的第一步。

現場推演：三隊各自最佳化的災難

來看一個業界常見的情況（綜合改編，數字為示意）：

想像 2026 年一個 AI 應用專案，三個團隊各司其職：

• Data 團隊：負責建模、特徵工程，用 Snowflake 與 BigQuery 整理資料。
• Platform 團隊：負責 AI 服務的部署、監控、API Gateway，使用 Kubernetes 與 FastAPI。
• AI 團隊：負責調用模型、優化 Prompt、整合業務邏輯，使用 LangChain 與 LLM。

三隊各有自己的 KPI：

• Data 團隊的 KPI：「資料管線穩定性」、「特徵覆蓋率」
• Platform 團隊的 KPI：「API 可用性 SLA」、「容器資源使用率」
• AI 團隊 the KPI：「模型準確率」、「使用者滿意度」

看起來很合理，對吧？

但實際運作時：

🏢 2026 年 AI 專案三團隊各自最佳化的 KPI 災難：

• 📊 Data 團隊：為了「資料管線穩定性」，將特徵更新頻率壓低至每日一次 $\rightarrow$ 導致 AI 模型使用過期資料，業務方抱怨推薦不精準。
• ⚙️ Platform 團隊：為了「可用性 SLA」，拒絕讓 AI 團隊調整 API Timeout $\rightarrow$ 導致長 LLM 請求被攔截截斷，使用者僅能取得部分回應。
• 🧠 AI 團隊：為了「模型準確率」，不斷重建模組與 Prompt 長度 $\rightarrow$ 導致延遲飆高、成本爆表，Platform 團隊對高能耗服務怨聲載道。

三隊都達標了。但整個系統卻是崩潰的。

直到有一天，CTO 受不了了，把三隊的 Lead 找來：「從下個月開始，你們三個一起對『AI 功能的端到端延遲、成本與使用者滿意度』負責。誰的個別 KPI 都不算，只看最終 Outcome。」

三週後，奇蹟發生了：

• Data 團隊主動提出「即時特徵 API」，讓 AI 可以拿到最新資料。
• Platform 團隊跟 AI 團隊一起設計「分級 Timeout 策略」，讓長呼叫走非同步、短呼叫走同步。
• AI 團隊開始關心推理成本，把部分邏輯從 LLM 移轉到規則引擎。

當三隊不再各自最佳化，而是對同一個 Outcome 負責，交接處的坑就開始被填平。

今日金句

「當 Dev 和 Ops 還在計分板兩端，輸的永遠是公司。」

留給你的問題

「你的組織裡，『這不是我的責任』這句話最常出現在哪兩個團隊之間？」

如果你聽過這句話，那你就知道 Silo 在哪了。

明天，我們要面對一個更大的認知挑戰：IT 到底是成本中心，還是工廠？

這個問題的答案，決定了你的團隊能拿到什麼樣的資源，以及你會被當成什麼樣的角色。

Day 8 見。