OpenClaw Health Suite（下）：Rollback、SOP 與故障演練

上一篇 Lv-08 我們把 Detect Layer 搞定了——你的系統終於學會在快死的時候大喊「我不行了」。

但問題來了：喊完之後呢？

你站在半夜三點的螢幕前，alerting 瘋狂響，Slack 炸成一片，你知道系統正在噴火。然後呢？你要怎麼穩穩把它救回來，而不是在 panic 中把火燒更大？

這就是 Lv-09 要解的問題。一整篇只講一件事：怎麼在壓力下安全地把系統拉回來。

---

🏰 Floor 0：Recover Layer 的設計哲學

先講一個反直覺的事：Recover 的目標不是「越快越好」，更不是「越自動越好」。

是「越可控越好」。

想像你是急診室醫生。病人推進來，你不會一看到血就拿刀開刀——你會先問：哪裡受傷？過敏史？吃了什麼藥？這叫 triage，急診分級。rollback 也是一樣的道理：你得先搞清楚現場狀況，再決定怎麼動手。

三條底線：

• 可驗證：每次還原都要能驗證來源跟完整性，不是「我覺得應該對了」
• 可中止：預設先 dry-run，你不會在病人身上直接練刀
• 可重複：流程寫進 SOP，不靠某個英雄半夜的神操作

所以整篇的核心就是兩個檔案：openclaw-rollback.sh 和 openclaw-upgrade-sop.md。

Clawd 忍不住說：

SRE 世界裡最危險的人不是新手，是「自認很熟所以不看 SOP」的老手。這句話聽起來像雞湯對吧？但我在 Lv-05 裡面就看過活生生的例子——|| true 那種「我知道我在幹嘛」的自信，差點把整個 watchdog 報廢 (╯°□°)⁠╯

---

🏰 Floor 1：Rollback 深潛——378 行的緊急手術刀

openclaw-rollback.sh 不是你想的那種「重啟按鈕」。它更像一把有護欄的手術刀——每一步都有確認機制，防止你在 panic 中把健康的器官也切掉。

先記 CLI：

openclaw-rollback.sh --dry-run       # 預設：只看不動
openclaw-rollback.sh --confirm       # 真的動刀
openclaw-rollback.sh --auto-confirm  # 自動模式（給 CI 用的）

注意預設是 --dry-run。這不是客氣，這是用血換來的 safety default。你有沒有過那種手滑按到 Enter 然後整個人冷掉的經驗？就是為了防這個。

Clawd 真心話：

「預設安全」這四個字聽起來很無聊，但它其實是整個 Unix 哲學裡最被低估的設計原則。想想看——rm 沒有預設 --dry-run，所以全世界有多少人因為 rm -rf / 把自己的系統送進太平間？如果 Ken Thompson 當年多一行 confirmation prompt，Stack Overflow 上大概少三分之一的 disaster recovery 問題 ┐(￣ヘ￣)┌

好，那這把手術刀的流程長什麼樣？我用急診室的邏輯幫你走一遍：

先是掛號——找到最新的 rollback package，然後驗 manifest.json 的 SHA256。這一步就像確認病歷是本人的，不是隔壁床的。你拿到的備份沒被動過手腳，才能繼續。

再來是看診——偵測目前的 service mode。這一步是為什麼不能「一鍵還原」的根本原因，等等細講。

然後是手術——pkill -f 清掉所有 gateway process（包含那些陰魂不散的 rogue nohup），還原 config / auth / service / drop-ins，依偵測到的模式重啟。

最後是術後確認——跑 healthcheck 驗證結果。不是「我覺得成功了」，是系統自己告訴你「我活過來了」。

其中最實戰的是看診那步：service mode detection。

事故發生的時候，你的系統可能處於各種詭異狀態：

• user systemd active（正常）
• system systemd active（也正常）
• manual nohup running（有人手動搞的）
• dual mode——兩個同時在跑（最恐怖）

如果你不先搞清楚 mode 就直接還原，很容易出現那種「檔案恢復成功了，但服務啟在錯的地方」的假成功。就像醫生開完刀說手術成功，但縫的是右邊，問題在左邊。

Clawd 補個刀：

dual mode 真的是我聽過最恐怖的 production 狀態之一。想像你家有兩個恆溫器同時在控制冷氣——一個說要 18 度，一個說要 28 度——然後冷氣就在那邊瘋狂開關開關直到壓縮機燒掉。這就是 dual mode 下的 service 行為 (◕‿◕) …好吧這個表情用在這裡可能不太對，但我覺得面對恐怖的事情就是要微笑。

---

🏰 Floor 2：Upgrade SOP——人類才是最後一層保險

openclaw-upgrade-sop.md 是一份寫給人類的流程文件，不是腳本。

為什麼需要人類流程？因為 script 再怎麼聰明，總有 edge case 需要人類判斷。就像你不會讓自動駕駛在完全沒學過的路況下全速行駛——某些時候你就是得握住方向盤。

主流程八步。我知道你看到「八步」就想 scroll past，但別急——這八步的設計邏輯其實就是一場手術的標準流程，我一步步帶你看為什麼每一步不能省。

第一步，停掉 watchdog timer。這就像手術前先把心電圖的警報閾值調寬——你馬上要大動干戈了，如果 watchdog 還在正常靈敏度巡邏，升級過程中的任何抖動都會觸發告警，你的 on-call 同事會被炸醒然後衝進來問「怎麼了」，結果你還得分心解釋「沒事沒事我在升級」。先讓保全去喝咖啡。

第二步，跑 pre-update——做 snapshot 加打包 rollback package。這是手術前備血。有些人覺得「我很有信心不會出事」所以跳過這步，然後出事的時候才發現自己連退路都沒有。沒有備份的升級就是在走鋼絲，而且底下沒有安全網。

第三步，升級 OpenClaw 本體。沒什麼好說的，這步最無聊也最直覺。

第四步，檢查 OPENCLAW_NO_RESPAWN=1。我要在這裡停一下，因為這是整個流程裡唯一一個被標成「硬性 gate」的步驟。為什麼？因為 Lv-08 裡我們學到的血淚教訓：self-respawn 放大機制。忘了設這個 flag 就 restart，一旦啟動失敗，watchdog 拼命重啟，每次重啟又失敗，形成 restart storm。你的系統就會像一個溺水的人瘋狂掙扎，越掙扎沉越深。

第五步 daemon-reload 加 restart，第六步 post-update gate 驗收——這兩步是標準術後檢查，確認新版本真的活著而且行為正常。

第七步，恢復 watchdog——保全喝完咖啡回來上班了。

第八步，觀察 quick verify 五分鐘。手術完不是推出手術室就沒事了，你得在恢復室待一下確認沒有內出血。五分鐘不長，但這五分鐘可以幫你抓到那些「啟動成功但三分鐘後默默崩潰」的陰間 bug。

Clawd 吐槽時間：

你知道嗎，我覺得所有寫 SOP 的人都應該被逼去做一次 ikea 家具。那個體驗會讓你深刻理解「步驟順序為什麼重要」——你跳過第 14 步覺得「這個螺絲應該不影響」，結果裝到第 38 步發現整個書櫃歪了，然後你得全拆重來。升級 SOP 也是一樣：你覺得「watchdog 先不關應該沒差」，直到 restart storm 把你的凌晨四點徹底毀掉 (¬‿¬)

---

🏰 Floor 3：Review Drama——一個 || true 差點毀掉整個 safety net

好，接下來這段是我覺得整篇最精彩的地方。不是因為技術多難，而是因為它完美展示了 code review 應該怎麼運作。

故事是這樣的。

第一輪 review 回來，reviewer 列了 14 個點。大部分是小東西，但其中有一個被標成 CRITICAL showstopper。

看這段 code：

set -euo pipefail
verify_json="$(openclaw-healthcheck.sh verify --quick --json || true)"
rc=$?
# 猜猜 rc 是什麼？

你看出問題了嗎？

set -euo pipefail 說的是「任何指令失敗就立刻中止」。但 || true 說的是「不管前面成不成功，這行的 exit code 都是 0」。

所以 $? 永遠是 0。永遠。

這代表什麼？代表你的 watchdog 永遠覺得系統是健康的。就算 healthcheck 回報「五個 critical check 全部失敗」，watchdog 還是笑嘻嘻地說「一切正常」。你精心設計的 safety net，中間有一個大洞。

Clawd 溫馨提示：

|| true 這東西就像安全帶上的假扣環——看起來扣好了，但真正撞車的時候你會直接飛出去。最可怕的是寫的人通常是故意加的，因為他「不想讓 script 因為 healthcheck 失敗而中斷」。動機很好，執行很致命 ヽ(°〇°)ﾉ

修法其實很直觀——不要迷信 exit code，直接去 parse JSON 內容：

verify_json="$(openclaw-healthcheck.sh verify --quick --json || true)"
failed_critical=$(echo "$verify_json" | jq -r '.failed_critical // 0')

if [[ "$failed_critical" -gt 0 ]]; then
  handle_failure "$verify_json"
fi

但精彩的是下半場。

Codex 對 reviewer 的 14 條意見仔細看過之後，針對其中 3 條提出了反駁。它指出 reviewer 參照的是舊版 spec（v2/v3），不是最終定案的 v4。reviewer 說「這裡沒處理 edge case X」，Codex 回「v4 spec 已經把 X 移到上層處理了，你看的是 v2 的流程」。

後來團隊回去比對 spec，確認 Codex 的 3 條 pushback 全部成立。

這段故事的精髓不是「誰對誰錯」，而是整個協作模式：

Reviewer 抓出了一個差點要命的 || true bug——這是真正的救命。但 reviewer 也不是全對的，因為他參照了過期的文件。Implementer 沒有乖乖照單全收，而是拿出證據反駁——這也是正確的。最後靠的不是誰的官大，而是大家回到同一份最新 spec 上面驗證。

Clawd 吐槽時間：

我最喜歡這段故事的原因是：它同時證明了「不做 code review 很危險」和「盲目接受所有 review 意見也很危險」。健康的協作不是服從，是 evidence-based 的對話。這跟 Lv-03 講的 adversarial collaboration 是同一個道理——你需要有人挑戰你，但挑戰要有根據 (๑•̀ㅂ•́)و✧

---

🏰 Floor 4：Drill——工具不等於能力，演練才是

好，你有了 rollback script，有了 upgrade SOP，有了 healthcheck watchdog。

然後呢？放在那邊積灰塵嗎？

我跟你講一個真實的故事。我認識一個 SRE 團隊（好吧，是我自己的經驗），他們花了三個月寫了一套完美的 disaster recovery playbook。文件漂亮、流程清楚、有圖有表。然後他們放了一年沒動它。等到真的出事的時候，script 跑不起來因為 dependency 版本升了三次、SOP 第三步的路徑已經不存在了、rollback package 放在哪裡只有一個已經離職的人知道。

那份完美的 playbook，在需要它的那一刻，等於廢紙。

這就像家裡的滅火器——你買回來覺得很安心，但它在角落待了五年，等你真的需要的時候才發現壓力表歸零了，拉環拉了沒反應。你的安全感一直是假的。

所以你需要 drill。而且不是那種「大家假裝演一下然後在 spreadsheet 打勾說完成了」的 drill。

怎麼知道你的 drill 有沒有用？很簡單，看數字。我不是要你搞出一個 dashboard 然後每天盯著看——但你至少需要幾個基本指標，讓你知道自己是真的在進步還是在原地踏步。

upgrade drill 跑完應該在 5 分鐘以內。聽起來很緊？其實不會——如果你的 SOP 真的寫得夠清楚、你真的演練過超過三次，5 分鐘是很寬裕的。超過 5 分鐘代表你的流程有瓶頸，找出來，修掉它。

rollback drill 要更快，3 分鐘以內。為什麼比 upgrade 短？因為 rollback 不需要思考「要不要做」——事情已經炸了，你唯一要做的就是還原。猶豫的成本比行動的成本高得多。

alert latency 5 分鐘內通知到人。你的告警響了之後，如果 5 分鐘還沒有人類知道，那你的告警跟森林裡倒下的樹沒有兩樣——有聲音但沒人聽見。

restart storm 在 72 小時觀察期內必須是 0 次。這個不用解釋了吧？如果演練完還出現 restart storm，代表你的 NO_RESPAWN gate 根本沒發揮作用。

Clawd 畫重點：

我發現很多團隊對 drill 的態度就是「我們有做」然後指著半年前的一份文件。拜託，drill 的價值不在於你做過，在於你做了之後有沒有變快。如果你每次 drill 的 MTTR 都差不多，你不是在練習，你是在表演。就像我每天說要減肥但體重從來沒變——那叫許願，不叫執行 (╯°□°)⁠╯

好，那最小 drill 套餐長什麼樣？五個動作，我帶你想一遍為什麼每個都不能省。

先故意搞壞一個配置——注意，是「可回復的壞」，不是「把 production 炸了然後在 postmortem 說『我在演練』」。你要模擬的是真實故障，但在有退路的前提下。這就像消防演習要真的放煙，但不是真的放火燒辦公室。

然後你等。等 watchdog 在 SLA 時間內發出告警。如果它沒響？恭喜，你的 Detect Layer 有問題，回去看 Lv-08。如果它響了，進入 Recover 流程。

跑 rollback——先 --dry-run 確認還原計畫看起來正確，再 --confirm 真的執行。這個順序永遠不能反過來，就像你不會先跳下去再看水有多深。

跑 post-rollback healthcheck，確認系統真的回來了。不是「它重啟了所以應該沒事」，是系統自己告訴你「我的 critical checks 全部 pass」。

最後——這步最重要——記錄這次的 MTTR，跟上次比。快了還是慢了？快了是哪裡快了？慢了是卡在哪？這些紀錄才是 drill 真正的產出。不是「我們演練了」那個打勾的動作，是「我們知道自己下次可以更快」那個認知。

延伸閱讀

• Lv-08: OpenClaw Health Suite（上）：從 36 小時故障到自動健檢
• SP-77: OpenClaw 騷操作：另起一隻 AI 專門修壞掉的 AI
• Lv-04: OpenClaw Gateway 核心：你的 AI 管家長什麼樣

Clawd 認真說：

「故意搞壞系統」聽起來很瘋對吧？但這在 SRE 界有個正經名字叫 Chaos Engineering，Netflix 的 Chaos Monkey 是始祖——它會隨機在 production 殺 instance，逼團隊在真實環境下練恢復能力。我們的規模用不到猴子，但精神是一樣的：你不去找問題，問題會來找你，而且它一定挑你最忙、最累、最沒準備的時候來。跟期末考前一天才發現教授改了考試範圍一樣 ╰(°▽°)⁠╯

---

🏰 Floor 5：收尾

Lv-08 和 Lv-09 是一組的。

Lv-08 教你偵測——系統在喊救命的時候你聽得到。Lv-09 教你行動——聽到之後你知道怎麼穩穩地把它拉回來，而不是在半夜三點 panic 亂按。

如果你只記一件事，記這個：rollback 不是一顆按鈕，它是一整條有 triage、有護欄、有驗證的手術流程。而 SOP 不是寫了就好，要演練到你閉著眼睛都能走完那個流程。

下一篇 Lv-10 見。