前言

跑到這裡，我們的 CI/CD 已經相當豪華了：

• 有 自動部署，讓程式一 push 就能跑到伺服器。
• 有 藍綠切換，避免上線就是賭命。
• 還有 金絲雀發布，小心翼翼地放出新版本，觀察風向。

聽起來很穩吧？
但還是有一個殘酷的現實：新版本總有一天會炸掉。

想像一下：凌晨三點，你剛睡著，手機狂震，因為 production 爆了。
這時候你是要半夢半醒地 ssh 進伺服器找 log，還是希望 pipeline 自動幫你退回去？

今天，我們就來聊聊 自動回滾（Auto Rollback）：
讓系統在察覺異常時，自動撤退到上一個穩定版本，像 RPG 裡的「回城捲軸」，不管團滅多慘，至少能瞬間拉回安全點。

為什麼需要自動回滾？

1. 降低 MTTR (平均修復時間)
   從「半夜被吵醒 + 10 分鐘手動修復」，變成「30 秒內 pipeline 自己救回來」。

2. 避免人工失誤
   緊急狀況下人容易手滑。
   例如服務炸了 → 工程師慌亂地 docker stop，結果多打一個 -a，整個伺服器都熄火。

3. 支撐高可用性
   使用者不會因為你 debug 而等半天，
   只會短暫遇到「新版本失敗 → 系統自己閃回舊版」。

常見的回滾方式

1. Tag 雙保險
   這在之前的文章就有實作過，每次發版時同時推兩個 tag：

• latest → 永遠指向最新版本。
• commit SHA → 精準對應某一次 build。

如果新版本炸掉，只要拉回上一個 SHA 就能快速復原。
這比重新 build 一次還快，因為 image 已經在 registry 裡備好。

2. 健康檢查失敗 → 自動觸發
   在 CD pipeline 裡加一個步驟：

- name: Health check
  run: |
    for i in {1..10}; do
      curl -fsS http://localhost/healthz && exit 0
      sleep 3
    done
    exit 1

• 如果 /healthz 在 30 秒內沒回應 200 → job 直接 fail。
• job fail 後，觸發「回滾動作」，把舊版再起一次。

這就像副本開打前，團長喊「全部報血量！」，沒喊出聲的直接踢回城。

3. 藍綠/金絲雀的天然支援

其實前面講過的藍綠和金絲雀，本質上就能支援快速回滾：

• 藍綠：只要把流量切回舊環境（Blue），新環境（Green）直接棄用。
• 金絲雀：觀察 10% 流量炸掉 → 立刻把流量全數導回舊版。

這種切換通常比「重啟容器」更快，因為兩個版本是並行存在的。

實作範例

部署流程可以這樣設計：

1. 發版 → 新版容器啟動，標籤為 latest。
2. 健康檢查 → /healthz 檢查 10 次都成功才算過。
3. 失敗時回滾 → pipeline 自動執行：

docker compose down
docker compose -f docker-compose.prev.yml up -d

或者更簡單：直接切回上一個 SHA image

docker run -d ghcr.io/<user>/<repo>:<previous_sha>

4. 通知 → Slack / Email：「最新部署失敗，已自動回滾到 previous_sha」。

這樣就完成了「自動衝 → 自動檢查 → 自動撤退」的流程。

結論

自動回滾它是半夜保命的解藥。
因為服務炸掉的時候，你最想做的不是 ssh，而是繼續睡XD

而這也是讓整個 pipeline 具備真正韌性的最後拼圖。