上線前先寫好回滾方案（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 分鐘內能退回來」。回滾單不是官僚流程，是給自己買的最低成本的保險。