我最近在 staging 做了一次 OpenClaw 升級演練，真正讓我放心的不是更新成功，而是故意把更新後檢查弄失敗，確認它能不能把服務帶回可控狀態。這是我把東西放進 production 前一定會做的測試。

我目前的環境是 Ubuntu 24.04，gateway 由 systemd 管理，設定檔和 secrets reference 都不跟 npm 套件放在同一個目錄。升級前先做兩件事：保存目前設定與服務狀態，再把 systemd unit、Node 執行路徑和 plugin 清單記下來。不要只備份一份整包目錄，因為 rollback 時最怕把新產生的狀態一起蓋掉，反而丟掉原本可用的 reference。

這次演練我特別注意 post-update Doctor 的處理。以前更新指令回傳成功，我就以為服務沒問題；但實際上套件換完、plugin 還沒 ready，gateway 可能已經進入半殘狀態。現在的流程比較像維運 runbook：Doctor 失敗時，先回退 npm candidate，保留既有設定和 secrets reference，再交給內建的 triage agent 判斷問題，等 plugin ready 之後才重啟 gateway。這個順序很重要，因為 systemd 的 Restart=on-failure 只能處理程序退出，不能保證依賴尚未就緒的服務重啟後真的健康。

我在 staging 驗證時會看三層結果：

1. systemctl is-active 是否回到 active，並檢查 journal 裡有沒有連續 restart 或 permission denied。
2. gateway 是否能在既有設定下啟動，plugin 的 ready 狀態是否完成，而不是只看到程序存在。
3. 更新前後的設定 diff，確認沒有因為 migration 或 rollback 把 secrets reference 展開、改寫或遺失。

另外幾個細節也很實用。大 agent roster 或高負載時，startup recovery 要能撐住，不然一台 server 開機後可能卡在「服務有起來但接不了工作」。舊 cron row 如果格式不相容，隔離 quarantine 比直接讓整個 gateway 拒絕開機安全得多；migration warning 也應該降級處理，讓我先登入修復，而不是把維運窗口變成整台機器不可用。沒有 service manager 的環境不該因此拒絕更新，但那代表操作者必須自己補上 health check、鎖定程序和回復步驟。

我也會把 cron.skipMissedJobs、SSRF blockedHostnames 和 config set 的嚴格驗證列入升級後檢查。前者避免停機期間的排程一次補跑造成尖峰；中間那個是出站安全邊界，不能只靠 firewall；後者則能在設定寫入時早點攔住拼錯的 key。

實測結果是，升級的風險不在「新版本有沒有 bug」這句空話，而在失敗時誰負責收拾、收拾到哪個狀態。我的 production 原則很簡單：先在 staging 讓 Doctor 失敗一次，確認 rollback、設定保留、plugin readiness 和 systemd recovery 都有明確證據，再安排正式更新。能夠安全失敗，才算真的能上線。