Rollback Recovery Playbook：回滾之後怎樣把系統安全拉回可用狀態

回滾之後的系統恢復：不只點一個按鈕

一次生產環境的部署變更如果出了問題，最常見的因應就是回滾。但回滾只是把程式碼或設定還原到上一個版本，並不保證系統會自動恢復可用。資料庫遷移帶來的不相容、快取中的髒資料、下游依賴的狀態變更，都可能讓回溯後系統仍處於亞健康或不可用狀態。真正需要的是執行一個完整的 recovery playbook，把系統安全拉回穩定並驗證可用。

最容易失敗的場景：變數未恢復與髒資料殘留

場景：資料庫遷移回滾與資料不一致

假設一個常見的失敗場景：你執行了一次包含資料庫遷移的部署，增加了新表並修改了舊表結構。上線後發現效能下降，於是執行程式碼回滾到舊版。但遷移操作並未回滾，新表仍然存在，舊表結構已被修改。舊程式碼嘗試寫入舊結構時，可能直接報錯或產生不一致。更隱密的是，遷移過程中寫入的新資料與舊業務邏輯衝突，導致使用者可見錯誤。

失敗點： 回溯腳本沒有包含資料遷移的逆操作，或逆操作執行順序錯誤（例如先刪除了新表，但舊表中已有依賴新結構的記錄）。

另一個常見場景：配置中心與回溯不同步

你的配置項目透過配置中心下發，本次部署同時改變了程式碼和設定。程式碼回滾後，設定沒有回滾，導致舊程式碼使用了新配置（例如連接字串指向錯誤叢集）。

回滾復原步驟：從停止到驗證的 7 個關鍵動作

以下是一個經過生產驗證的 recovery playbook 核心步驟。每一步都有明確的判定條件和失敗應對。

1. 立即停止變更擴散：如果變更還在灰階或分批發布中，停止後續流量存取。確認回滾前不要繼續擴大故障面。
2. 執行程式碼/設定回滾：使用 git revert 回滾到上一個發佈 commit，或透過 CI/CD 回退到上一建置。對於配置，請確保配置中心也同步回滾（會依歷史版本回退）。
3. 執行資料遷移逆操作：如果本次變更包含資料庫遷移，執行逆遷移（如使用 Flyway 或 Liquibase 的 undo 腳本）。如果沒有準備逆遷移，需要手動執行 SQL 還原舊結構（此時應優先考慮從備份還原）。
4. 清理快取：回滾後快取中可能殘留舊程式碼寫入的不相容格式資料。清除相關快取層（Redis、Memcached 或 CDN 快取）。注意：如果快取完全清空可能導致雪崩，建議以業務維度逐步淘汰或預熱。
5. 檢查依賴狀態：確認下游服務（API、訊息佇列、資料庫）是否為期望版本。例如，你回滾了 A 服務，但依賴 A 的 B 服務可能已經發送了基於新格式的請求，A 不再能正確處理。此時需要暫停 B 的消費或降級。
6. 逐步放量驗證：恢復流量到一小批用戶（例如 1%），監控錯誤率、延遲和關鍵業務指標。比對回滾前後的基線數據。
7. 持續觀察：至少觀察 30 分鐘（或一個完整業務週期），確認無異常後逐步恢復全量。

容易做錯的一步是第 3 步：很多團隊只專注在程式碼回滾，忽略資料回滾，導致「程式碼舊、資料新」的不一致狀態。必須事先約定所有資料庫變更必須附帶可逆腳本，並在預發布環境驗證。

權限邊界：誰有權執行回溯復原？

回滾恢復是高壓力操作，權限控制不當會引入額外風險。

• 執行回溯決策：通常由 on-call 工程師或值班 SRE 根據 runbook 判斷，但重大變更（如影響全站）需要通知團隊 lead 確認。
• 程式碼回溯：僅 CI/CD 服務或授權管理員可以觸發回溯 pipeline。避免讓每個開發者直接在生產環境 rollback。
• 資料回溯：資料庫回溯腳本應僅由 DBA 或具備備份復原權限的角色執行。自動回滾腳本要加上「dry-run」模式，先輸出將要執行的 SQL，待人工確認。
• 配置回滾：配置中心應該支援變更稽核和快速回退，且回退操作應記入稽核日誌。

邊界情況：當故障嚴重影響到使用者核心操作時，權限策略應設定“緊急 bypass 機制”，允許指定角色跳過某些審批步驟，事後補錄原因。

回滾失敗時的 fallback 路徑：當回滾本身也不可靠時

即使有完善的 recovery playbook，有時回滾也會失敗。例如：

• 回滾後服務無法啟動（舊程式碼依賴了已移除的程式庫或過期憑證）。
• 資料逆遷移執行後導致更多不一致。
• 回滾過程中網路中斷導致部分節點處於混合狀態。

備用方案 1：從快照恢復

從最近的完整備份（全量快照）還原。這通常比回滾更徹底，但恢復時間（RTO）較長。適用於資料層故障且無法透過逆遷移修復的場景。務必定期演練快照復原流程。

備用方案 2：並行切換至備用環境

如果架構支援藍綠部署，回滾失敗時可以直接將流量切至綠環境（舊版）。注意綠色環境是否仍保持最新資料同步。如果沒有，需要先做資料遷移或接受部分資料遺失。

備用方案 3：降級與熔斷

如果無法完全恢復，可以啟用降級特性：關閉非核心功能，確保核心連結可用。例如，臨時關閉推薦演算法，只傳回熱門資料；將寫入操作改為非同步佇列，避免直接失敗。降級後要持續修復根本問題，直到能執行一次成功的恢復。

關鍵決策：回滾失敗後，不要重複嘗試回滾，這可能導致更嚴重的資料損壞。應先評估是否適合切換到備用方案，並通知團隊進入緊急應變流程。

下一步：將復原實踐轉化為自動化與團隊能力

本文提供的 playbook 是基礎框架，每個團隊應根據自身系統特點做客製化。重要的不是記住步驟，而是確保步驟經過演練、內化到部署流程。

如果你希望更有系統地學習如何在 AI 輔助下設計和編寫這類恢復機制，以及如何從普通開發者轉型為具備工程判斷力的 Agent 工程師，可以考慮進一步探索相關課程。