緊急回滾 production rollout

這是什麼 Production 上有一個 rollout 已執行（或執行中）造成事故，需要在最短時間內把資料庫回到變更前狀態。
不該用本頁的情境
Dev / Staging 環境的問題 → 走中止 / 重試 task
Argus 自己（metastore）的問題 → 走二線運維 SOP

觸發條件

[ ] 該 rollout 在 production environment
[ ] 變更已執行至少一個 task（status = running 或 done）
[ ] 已確認業務影響（5xx 上升、延遲飆高、資料異常 …）
[ ] 取得現場最高權限口頭核可（DBA Lead / SRE on-call）

任一不成立 → STOP，先補齊或改走其他 runbook。

風險與不可逆動作

動作	可逆？	影響範圍	需要核可
Cancel 尚未開始的 task	是	單一 rollout	不需要
中止執行中的 task（force-abort）	否	可能留下半完成 DDL / 鎖未釋放	DBA Lead
反向 SQL 回放（drop / revert migration）	否	視 SQL 而定	DBA Lead + SRE
從備份還原	否，但有時間窗	影響期間所有寫入	DBA Lead + SRE + 業務 owner

步驟

⚠️ 每步做完前不要繼續到下一步。

1. 確認觸發條件成立

在 Argus UI：

Projects → <該 project> → Rollouts → <rollout id>
確認 environment = Prod，task 狀態符合觸發條件

驗證指令：

bash

curl -s -H "Authorization: Bearer $TOKEN" \
  "$ARGUS/v1/projects/<proj>/rollouts/<id>" | jq '.state, .environment, .tasks[].state'

預期看到 environment = prod，至少一個 task 狀態為 running 或 done。

2. 公告

在 #ops 頻道貼出公告：

[INCIDENT] Argus production rollout 緊急回滾啟動
- Project: <name>
- Rollout: <id> (link)
- 觸發人: <你的名字>
- 預估影響: <一句話>
- 走 runbook: emergency-rollback

標記值班 DBA + SRE on-call。

3. 凍結後續執行

進入 rollout 頁，按 Pause。確認剩餘 pending task 都不會再被 picker 撿走。

bash

curl -X POST -H "Authorization: Bearer $TOKEN" \
  "$ARGUS/v1/projects/<proj>/rollouts/<id>:pause"

4. 評估回滾策略

依執行進度決定：

進度	策略
全部 pending	直接 cancel rollout，無需回放
部分 done，剩 pending	Cancel pending + 對已 done 的 task 反向回放
全部 done	反向回放所有 task
反向回放成本太高	從備份還原（備份與災備）

5. 執行回滾

WARNING

反向 SQL 由 DBA 親自確認，不要直接信任 Argus 自動產生的 reverse SQL。

於 Argus 開新的 Plan，類型選 Rollback，target 同原 rollout 的 DB，貼上人工確認過的反向 SQL，跑完整 plan check 後執行。

6. 驗證

業務指標恢復（請業務 owner 確認）
資料庫狀態恢復（DBA 確認 schema / 關鍵資料）
Audit log 上有兩筆 entry：原 rollout + 回滾 plan

7. 紀錄與覆盤

在 #ops 公告事件結束
開事件單，附 audit log 區段 URL
安排週會覆盤

演練

上次演練：NaN
頻率：每季一次
演練步驟：在 staging 重現 production 等級的 rollout → 走完整本 runbook → 記錄耗時

緊急回滾 production rollout ​

觸發條件 ​

風險與不可逆動作 ​

步驟 ​

1. 確認觸發條件成立 ​

2. 公告 ​

3. 凍結後續執行 ​

4. 評估回滾策略 ​

5. 執行回滾 ​

6. 驗證 ​

7. 紀錄與覆盤 ​

演練 ​

相關 ​