上線前先寫好回滾方案（Rollback First）

上週我盯的一次發版，新程式碼上線 20 分鐘後報了一個邊界資料異常。排查、定位、準備熱修，前後燒掉兩小時。事後復盤發現一個更扎心的事實：如果上線前花 10 分鐘寫一張「回滾單」，那兩小時裡至少有一小時半可以直接跳過——因為窗口的第一步本來就是「先回滾再查」，而當時沒人提前確認過回滾到底怎麼回、回不到哪裡。

「Rollback First」這個習慣很簡單：**在做任何不可逆或半不可逆的操作之前，先把「怎麼退回去」寫下來，而不是出事後現想。**

什麼時候用

- **部署上線**：任何進生產環境的程式碼、設定、資料遷移，發布前必答三個問題：回滾觸發條件是什麼？回滾要幾步、幾分鐘？回滾後資料怎麼收尾？

- **資料庫變更**：加欄位、改類型、跑遷移腳本之前，先確認舊版本服務能不能直接跑在新結構上。不能，就先加後改，分兩次發布。

- **刪東西**：刪檔案、刪分支、刪設定項、清快取。`rm` 之前先想 `trash` 或者備份放哪。

- **對外承諾**：給客戶、老闆發出的壞消息或變更通知，發之前想好對方追問第二句時你怎麼接，以及說錯了能不能收回。

- **Agent 幹活**：讓自動化腳本批次處理之前，先保證每批操作可撤銷，或至少輸入有快照。

什麼時候別用

- **一次性試錯**：本地實驗環境、草稿、可隨意重來的場景，寫回滾單是形式主義，浪費時間。

- **純加法變更**：加一個沒人引用的設定項、加一張新表，舊邏輯完全不碰——這種「天然可回滾」的操作，寫一句話確認即可，不用展開成儀式。

- **回滾成本高於業務成本的場景**：極少數情況（比如停了一個已經洩露的介面），直接上、快上，回滾反而是錯誤決策。判斷「能不能回」比「要不要回」更前置。

回滾單最小清單

一張合格的回滾方案，寫在發布紀錄裡就夠了：

1. **觸發條件**：什麼訊號出現就必須回，而不是「看看再說」。（例：錯誤率 >1%、核心介面 P95 翻倍、客服報障 >3 起）

2. **回滾動作**：具體到指令或按鈕。「回滾到上一版本」不算答案，「`git revert` 這個 commit 後重新部署 CI 流水線 #x」才算。

3. **耗時預估**：從決定回滾到服務恢復，預計幾分鐘。超過 30 分鐘的回滾方案，上線前就應該先把回滾演練一遍。

4. **資料收尾**：回滾後髒資料怎麼辦？新寫入的記錄是留著、屏蔽還是刪除？

5. **誰來執行**：寫名字。半夜出事時「找值班的人回滾」等於沒人回滾。

常見坑

- **回滾方案只存在於腦子裡。** 復盤時人人都覺得自己「知道怎麼回」，出事時才知道 DB 結構已經相容不了舊程式碼。寫下來才是存在。

- **把「回滾」和「修復」搞反。** 預設動作是先回滾止損、再從容排查。很多團隊出了事直接在生產環境熱修，把一個故障變成兩個。

- **演練缺失。** 回滾方案沒跑過，就只是猜測。重大變更上線前，在 staging 把回滾完整跑一遍，通常 10 分鐘，能刪掉方案裡一半的幻覺。

- **只回滾程式碼不回滾設定。** 程式碼退回舊版本，新設定還在，服務照樣起不來。回滾單裡程式碼、設定、資料三樣要一起列。

一句話總結

上線的勇氣不來自「我覺得沒問題」，而來自「就算有問題，我 15 分鐘內能退回來」。回滾單不是官僚流程，是給自己買的最低成本的保險。