昨天你剛建好自動監控，讓機器每天告訴你哪裡壞了。今天，你要面對一個更殘酷的問題：如果這個「壞掉」是由你親手按下的那個上線按鈕造成的呢？
時間是週一早上九點。你坐在辦公室裡，盯著螢幕上的 Dashboard 監控面板：
CEO 的郵件早已經躺在收件匣中：「這是怎麼回事？為什麼週末系統掛了這麼久都沒人知道？為什麼我是從客戶那邊聽說這件事的？」
你的胃開始隱隱作痛。
因為這一切災難，都始於你在上週五下午五點三十分做出的那個決定。
場景回到上週五。
你的團隊剛完成了 AI 推薦引擎的重大升級：引入了新的模型架構、更複雜的特徵工程，以及更即時的個人化推薦。這套新系統在測試環境跑了兩週，表現非常完美。產品經理（PM）興奮地說：「這次升級預期能提升轉換率 15%，越早上線越好。」
下午四點，部署 Runbook 準備妥當。Platform Lead 在 Slack 上 @ 你：「要不要趁今天上線？還是等下週一？」
你轉頭看了眼牆上的時鐘：五點。大部分工程師都已經在收拾包包準備下班了。
你想起吃緊的專案排程——如果週五不上，就要等到下週三才有空檔，產品經理肯定會不高興。而且既然測試環境都跑得好好的，應該不會有問題吧。
你在 Slack 上打了一行字：「好，上線吧。記得做冒煙測試（Smoke Test）。」
五點三十分，你按下了 Deploy 按鈕。
部署進度條跑完。HealthCheck 回傳代表健康的綠燈。冒煙測試順利通過。你鬆了一口氣。
接著，你關上電腦，下班回家了。
你不知道的是，部署完成後的最初兩小時，系統看起來一切正常。但在週六晚上十一點四十七分，某個歷史悠久的批次作業（Batch Job）啟動了——它被設計用來清理三個多月前的舊資料。
這個作業在舊系統裡跑了兩年都沒出過任何問題。但新版推薦引擎的 Feature Pipeline 多了一個意料之外的相依關係：它會去讀取那張「即將被清理的表」的歷史資料，用來計算「使用者行為趨勢」。
舊資料被徹底刪除了。新 Pipeline 讀不到歷史資料，拋出異常例外，重試三次後宣告失敗，整個 Pipeline 徹底停擺。
推薦 API 開始向外界回傳 500 伺服器內部錯誤。
但在此時，根本沒有人在盯著系統。
週六深夜，工程師們都在熟睡。監控 Dashboard 雖然亮著刺眼的紅燈，但無人看守。告警郵件也被默默地埋在收件匣裡。
系統在黑暗中崩潰，直到週日凌晨兩點，第一個客戶投訴終於進來：「你們網站的推薦功能壞了。」
客服值班人員不懂技術，只能將其登記為一張 Ticket 工單。
週一早上九點，當你打開電腦，災難已經在週末蔓延了 30 多個小時。
你坐在會議室裡，盯著事後檢討報告。
問題從來不是「程式碼有 Bug」。軟體系統一定會有 Bug。
真正的問題在於：你把部署設計成了一個「大型、高風險、無人守候、回饋反饋最慢」的偶發性事件。
週五下午上線是災難配方，原因在於：
這就是《鳳凰專案》裡 Parts Unlimited 管理層的典型錯誤：將部署當成一次性的「重大冒險」，全憑運氣賭它不會出事。
Bill Palmer 在學會 DevOps 之後，最大的改變就是：把部署從「偶發的大型賭博」變成了「頻繁的小型可控動作」。
Erik Reid 說過：
「好的部署應該無聊到你敢在星期五做。不是因為你膽子大，而是因為你的部署規模小到即使出事，五分鐘之內就能完成回滾。」
現在你面對的選擇，其實在「按下部署按鈕」之前就該做：
| 🔴 選項 A：照計畫週五硬上，賭它沒事 | 🔵 選項 B：改採小批量、可回滾、挑選有人值守時機上線 |
|---|---|
| 短期效益：✓ 勉強趕上產品既定時程，產品經理（PM）感到滿意長期代價：✗ 一旦週末爆發故障，無人值守將使問題擴大 48 小時✗ 造成嚴重營收損耗與客戶流失，團隊信心徹底崩潰結果：✗ 快速但脆弱，將系統穩定度完全寄託於運氣 | 短期代價：✗ 需要花時間建設部署基礎設施（如金絲雀、藍綠部署）✗ 發布時程在初期可能會有些微延遲長期效益：✓ 每次部署規模小、可驗證、可回滾，5 分鐘內即修復✓ 部署演變為日常無聊瑣事，徹底擺脫「上線大冒險」結果：✓ 穩健且快速，讓上線變無聊 |
正確答案當然是選項 B。但這需要你在三個月前就開始著手建設可控部署的基礎設施。
《鳳凰專案》後期，Parts Unlimited 最關鍵的轉變就是部署方式的革新。
從「一個月一次大型部署、每次都像全軍出擊打仗」變成了「一天十次微小改動、每次都無聊到令人打哈欠」。
這是 DevOps 與第二航道（Feedback, 回饋迴路） 的核心實踐：
不要一次發布所有代碼，將大改動拆成多個獨立、微小的步驟：
不要對所有用戶全量更新，先給予 1% 的試驗流量：
[ 100% 外部流量入口 ]
|
| 🔴 | 🔵 選項 B |
| :--- | :--- |
| | |
[ 99% 流量 ] [ 1% 流量 ]
| |
▼ 舊版環境 (Blue) ▼ 新版環境 (Green)
| |
| 🔴 選項 A | 🔵 選項 B |
| :--- | :--- |
| | |
▼
[ 即時驗證核心指標 ]
- 錯誤率 (Error Rate)：0.05\% → 0.06\% (在安全閾值內)
- 延遲 (Latency p99)：120 ms → 125 ms (符合 SLA 規範)
- 業務轉換率 (Conversion)：3.2\% → 3.4\% (指標提升!)
運行機制：若新版在 1% 的流量實驗中表現穩定，在 24 小時內逐步提高放量：1% → 5% → 25% → 100%。若指標異常，則立即自動切斷該 1% 流量，全面保護其他 99% 的用戶。
在生產環境同時保留新舊兩個版本，隨時可以切換：
[ Production 流量入口 ]
|
| 🔴 (流量引流) | 🔵 選項 B |
| :--- | :--- |
| | |
▼ ▼
🟢 Green 環境 🔵 Blue 環境
(新版本運行中) (前一版本就緒中)
如果新版本（Green）在線上出現任何不可預測的故障：
這就是「可控部署」的核心：讓部署不再是退無可退的單向跳崖，而是一條隨時可以安全折返的平坦道路。
問題是，金絲雀部署需要有專人在線上盯著那 1% 流量的技術與業務指標。
週五晚上，誰願意通宵守著？
這時候，AI Agent 可以直接扮演你的金絲雀守衛角色：
graph TD
A[部署新版到 1% 流量] --> B[Agent 即時監控]
B --> C{異常偵測}
C -->|Error rate 暴增| D[自動回滾到舊版]
C -->|Latency 異常| D
C -->|業務指標下降| D
C -->|一切正常| E[逐步放量 5% -> 25%]
D --> F[通知團隊 + 保留現場]
E --> C
Agent 會 24 小時不知疲倦地監控：
一旦偵測到「新版本指標明顯劣於舊版」，Agent 會自動觸發回滾，無需半夜打電話叫醒值班工程師。
你不再是「按了 Deploy 鍵就下班，然後閉眼禱告」，而是「按了之後，有 Agent 忠實替你守著大門」。
我們來看一個業界真實發生的慘烈案例（綜合改編，數字為示意）：
🏢 動態定價引擎上線故障案例：
- 事件背景：團隊強行於週五晚上八點發布全新的動態定價引擎，冒煙測試順利通過後全員下班。
- 故障主因：週六上午十點，該引擎遇到邊界情況（Edge Case）──定價演算法所需的商品歷史銷售數據在週末進行了例行封存。演算法讀取不到資料後，預設將商品定價設為 0 元。
- 災難損耗：客戶發現漏洞後瘋狂下單，訂單系統瞬間過載。週一統計共產生了 618 筆已出貨的「0 元訂單」，直接營收損失達 420 萬美元，且商譽受損無法估量。
事後檢討時，團隊才痛定思痛：
「週五上線」本身並不是罪過。問題在於你將它設計成了一場「大型、不可逆、無人守護」的豪賭。
「好的部署應該無聊到你敢在星期五做。不是因為你膽子大，而是因為你的部署小到即使出事，五分鐘之內就能完成回滾。」
你們團隊上一次上線，是「按了就下班」還是「按了就開始在內心禱告」？
如果線上系統在週末發生故障，你們需要花費多久時間才能察覺？又需要多久才能退回安全版本？
如果答案是「數小時」甚至「必須等禮拜一上班手動處理」，那代表你們的部署流程仍缺乏足夠的控制力。
第二航道（Feedback）的核心在於極力縮短回饋循環。 部署完畢後，你必須在數分鐘內洞察系統是否完好，並有能力隨時安全退回。
明天，我們來聊一個更深層的流程瓶頸：你們的變更流程裡，到底塞了多少道「橡皮圖章」式的簽核？這些層層關卡真的在保護系統，還是在拖慢交付速度？
Day 18 見。
iThome鐵人賽
看影片追技術