從產品角度來看，這 4 個檢查其實解決的是「如何降低更新失敗的 detection time」，但還有一個環節容易被忽略：rollout 後的觀測窗口。 更新前做好備份和環境確認是必要條件，但我更在意的是「更新後多久你才知道壞了」。有幾個指標我會追： - 核心功能的 response time 有沒有明顯跳動 - 關鍵 workflow 的 error rate（第一個 30 分鐘尤其重要） - 如果有跑 agent 任務，task completion rate 有沒有下降 如果這些沒有 baseline，更新後其實很難判斷「是壞了還是正常波動」。做 rollout 前先把 happy path 跑一遍留下數據，更新後馬上比對，這樣 rollback 的決策會快很多。

補一個實作建議：更新前可以先跑一個 preflight script 做三件事——確認 env 裡沒有舊版變數殘留、state 目錄結構符合新版預期、備份檔案確實存在。三個都過了再執行更新，出問題還有東西可以回滾。這種 check 寫起來不到 50 行，但省掉的麻煩遠超這個成本。