运维与升级：日志、健康检查、备份与回滚
“能跑一次”不难，“天天都能跑”才是真本事。
这章给你一套小白也能照做的运维流程：看状态、做体检、留备份、出事能回滚。
本章你将学会什么
Section titled “本章你将学会什么”- 建立统一观测入口（status / logs / doctor / health）。
- 做一次完整的健康自检并读懂结果。
- 用冻结点策略安全升级，不做“盲升”。
- 规划 workspace 与 state 的备份与回滚。
- 快速判断“坏的是模型、配置还是渠道”。
- 你已完成前 6 章基础配置。
- 你可以正常运行：
openclaw gateway statusopenclaw logs --follow7.1 观测入口（日志/指标/事件）
Section titled “7.1 观测入口（日志/指标/事件）”7.1.1 运维第一原则：先看事实，再下结论
Section titled “7.1.1 运维第一原则：先看事实，再下结论”先跑这五条命令，把“现场情况”摸清：
别上来就改配置，先看体征再开药。
openclaw statusopenclaw status --allopenclaw gateway statusopenclaw channels status --probeopenclaw logs --follow7.1.2 日志面分成两类
Section titled “7.1.2 日志面分成两类”官方日志有两层：
- 控制台日志（你终端看到的）；
- 文件日志（JSON 行日志，供长期追踪）。
关键点：--verbose 只影响控制台，不会自动提升文件日志级别。
需要更细粒度落盘时，用 logging.level 配置。
7.1.3 建议的巡检频率
Section titled “7.1.3 建议的巡检频率”- 每天：
status+gateway status； - 每周：
doctor+ 安全检查； - 每次重大配置变更后：
logs --follow至少观察 10 分钟，确认没有持续报错再收工。
7.2 健康检查与自测
Section titled “7.2 健康检查与自测”7.2.1 快速健康检查
Section titled “7.2.1 快速健康检查”openclaw health --json该命令会向运行中的 Gateway 请求健康快照，适合自动化检测与 CI 探活。
你可以把它当成“系统体温计”。
7.2.2 “第一分钟”排查序列
Section titled “7.2.2 “第一分钟”排查序列”当你怀疑系统异常，优先按官方顺序跑（别跳步）：
openclaw statusopenclaw gateway probeopenclaw doctoropenclaw channels status --probeopenclaw logs --follow7.2.3 你应该关注哪些信号
Section titled “7.2.3 你应该关注哪些信号”- Gateway 是否
Runtime: running； - RPC probe 是否
ok； - channel 状态是否
connected/ready； - 日志是否出现持续重复 fatal 错误。
7.3 升级策略（冻结点/变更记录）
Section titled “7.3 升级策略（冻结点/变更记录）”7.3.1 冻结点升级法
Section titled “7.3.1 冻结点升级法”建议按“冻结点”升级，不跟随每日变更漂移。
本书当前冻结点是 v2026.2.17，升级时先在测试环境验证再进生产。
7.3.2 升级前清单
Section titled “7.3.2 升级前清单”- 备份
openclaw.json； - 备份 sessions 与关键 workspace 文件；
- 记录当前版本、关键插件版本、模型路由；
- 先跑：
openclaw doctor --deep7.3.3 升级后验收
Section titled “7.3.3 升级后验收”升级后不要只看“能启动”，至少做三类验证：
只验证启动不验证闭环，后面大概率会补坑。
- 核心对话闭环；
- 一个渠道收发闭环；
- 一个技能执行闭环。
7.4 备份与回滚预案
Section titled “7.4 备份与回滚预案”7.4.1 备份什么，别备份什么
Section titled “7.4.1 备份什么，别备份什么”建议备份：
- workspace（业务文档、技能、项目文件）；
- 配置（
openclaw.json）； - 必要会话数据（按隐私策略脱敏）。
不建议直接外发：
- 明文 credentials；
- 未脱敏日志全集。
7.4.2 回滚要有“最后可用快照”
Section titled “7.4.2 回滚要有“最后可用快照””建议保留最近三份：
T-1（当前前一版）T-7（一周前）T-30（一月前）
出现重大故障时，优先回滚到最近“已验证可用”版本，而不是临场拼修。
先恢复服务，再慢慢复盘，节奏会稳很多。
7.4.3 私有仓库备份 workspace
Section titled “7.4.3 私有仓库备份 workspace”官方建议把 workspace 当私有记忆资产管理。
可以用私有 Git 仓库做版本化，但要明确 .gitignore，防止敏感文件被提交。
7.5 “坏的是模型还是配置”
Section titled “7.5 “坏的是模型还是配置””7.5.1 三步定位法
Section titled “7.5.1 三步定位法”- 先看系统层：
gateway status、doctor、health； - 再看模型层：
models list、鉴权状态、fallback 是否触发； - 最后看渠道层：
channels status --probe、pairing/allowlist。
7.5.2 常见误判
Section titled “7.5.2 常见误判”- 把“渠道权限问题”误判为“模型太笨”；
- 把“配置漂移”误判为“版本 bug”；
- 把“队列积压”误判为“系统卡死”。
7.5.3 一张最短决策表
Section titled “7.5.3 一张最短决策表”| 现象 | 优先怀疑 | 第一动作 |
|---|---|---|
| 所有请求都失败 | Gateway/配置 | openclaw doctor |
| 仅某模型失败 | 模型鉴权/路由 | openclaw models list + 查日志 |
| 仅某渠道不通 | 渠道权限/配对 | openclaw channels status --probe |
| 偶发超时 | 负载/网络/重试 | 看 logs --follow 与重试策略 |
- 观测面要统一，避免“每人一套排障方法”。
- 健康检查和 doctor 是运维基本功，不是“出事才跑”。
- 升级必须有冻结点与回滚点，不能裸奔。
- 先分层定位，再动手修复，效率最高。