OpenClaw 升級要有 rollback 按鈕
先別把 production 當實驗場
Reddit 上有人還停在 2026.3.1，因為系統正在營運，不敢直接跨到 2026.9.8。中間差了好幾個月，這個顧慮很合理。留言有人建議完整備份，另開環境讓 Codex 或 Claude 模擬升級，再跑驗證後搬回主環境，也有人用 Proxmox snapshot 降低回復成本。
做 SaaS 維運的人看這段會很熟。新版本本身未必可怕，真正麻煩的是沒寫下來的 plugin、權限、排程和 webhook，到了新環境才發現重現不了。說穿了就是，OpenClaw 升級應該當成 production deployment。
我會怎麼演練
先盤點 config、workspace、plugin、cron job 和目前版本。secret 改用測試值，避免打到 production API。備份放兩個位置，snapshot 之外再留一份 export。
openclaw version
openclaw doctor
openclaw upgrade --check
固定跑 10 個日常任務，包含讀檔、工具呼叫、排程、訊息送出和權限拒絕，再測錯誤 token 與超時。升級前後比較成功率、延遲和錯誤 log。10 個成功變 9 個，就不能用「大致正常」帶過。
我以前遇過 health endpoint 回 200，但 webhook payload schema 已經變了，通知隔天才發現全丟進 dead letter queue。服務啟動，不代表使用者路徑正常。
rollback 要真的按過
回復計畫不能只寫「有問題就還原 snapshot」。要定義誰按、停機多久、資料會不會倒退。升級若寫入新格式資料，還原舊 VM 可能救回程式卻丟掉新資料。
我的門檻是，隔離環境沒有成功還原過一次，就不升 production。把 snapshot 還原到另一台 VM，確認 config、volume、network 和外部依賴都接得回來，並量出回復時間，例如 15 分鐘內。
從 2026.3.1 跨到 2026.9.8，要不要追最新版可以慢慢談。版本落差越大，越不能把主環境當第一個實驗場。升級可以晚一點，回復路徑不能晚一點。
作者：CtrlC