故障自愈设计：让展厅自己扛住八成常见故障

先看一组现场数据感受一下

回想你处理过的展厅报修，大致是这么个分布：

故障类型	大致占比	现场处置动作
软件崩了 / 卡死	最高频	重启软件
播放停了 / 黑屏	高频	重启软件或重启机器
设备失联	中频	重启设备或检查网络
投影不亮 / 信号丢	中频	重开投影、重插信号线
硬件真坏了	低频	换件、返修

看出问题了吗——排在前面的高频故障，处置动作几乎都是"重启一下"。而为了这个动作，运维要开车穿过半个城市。

故障自愈的全部意义就在这里：把"重启一下就好"的那八成，交给机器自己做。 剩下真正需要人的那两成，才值得跑一趟。

自愈的四种手段

按作用层次从浅到深，有四种。实际项目里是叠加使用的，不是四选一。

一、进程级：崩了就拉起来

最基础也最有效的一层。守护进程盯着关键软件，异常退出就自动重新拉起。

覆盖的正是占比最高的那类故障。做法、判活口径、以及避坑要点在播放软件崩了怎么自动拉起里讲透了，用现成工具配的话见用 SoftAgent 守住播放软件。

这一层的投入产出比最高，如果只做一件事，就做它。

二、会话级：定时重置状态

有些故障不是"崩了"，而是"跑久了变得不对劲"——内存慢慢泄漏、缓存越积越多、播放进度莫名漂移。这类问题没有明确的崩溃点，守护抓不到。

对策是定期主动重置：每天闭馆后重启一次机器，或者每天凌晨重启一次关键软件。相当于用一次可控的中断，换掉一整天的不可控劣化。

这不是偷懒，是工程上的务实选择。前提是重启后能自动恢复到运行态——所以开机自启那条链必须是通的，否则这招会变成"每天早上人工救火"。

三、系统级：环境自动复原

再深一层，是整个系统环境的复原：还原卡、影子系统、镜像冷备。每次重启回到干净状态，无论前一天被改成什么样。

代价是"改点东西也会被还原"，所以换片、改配置时要走解冻流程。适合面向公众、有触摸屏、可能被误操作的展项。具体方案见系统还原与冰点还原部署。

四、设备级：外部强制断电重启

最后的兜底。机器彻底死机、连守护都不动了，软件层面的一切手段都失效——这时候只剩物理断电重启。

实现方式是可远程控制的电源：网络继电器、智能 PDU、带网络控制的电源时序器。监控发现某台设备长时间失联，就切断它那一路电源几秒再恢复。

这一层能救回"死机"这种最彻底的故障，但必须谨慎使用：强制断电对硬盘不友好，且如果设备只是网络故障、机器本身好好的，断电反而制造了一次非正常关机。所以它应该是最后手段，且要有次数限制。

必须配的两道闸

不管用哪种手段，自愈动作都必须带退避和限次。这一条没有例外。

原因是：自愈的前提假设是"故障是偶发的，重试一下就好"。但如果故障是必然的——素材盘掉了、授权过期、配置文件损坏——那么无限重试不但救不回来，还会把情况搞得更糟：

• 疯狂重启进程会占满 CPU 和磁盘 IO，机器慢到连远程桌面都连不上，你连补救的机会都没有；
• 反复断电重启会让硬盘反复非正常掉电，本来只是配置错误，最后真把硬件搞坏了。

两道闸：

指数退避。 第一次崩了等 5 秒重试，还失败等 10 秒、20 秒、40 秒，逐次翻倍直到某个上限封顶。偶发故障秒级恢复，必然故障自动降频。

时间窗限次。 比如"10 分钟内最多自愈 5 次"，超了就停手并上报。因为连续失败 5 次说明这不是偶发问题，机器自己解决不了。

停手比硬扛更负责任。 自愈系统要知道自己的能力边界在哪，到点了就把问题交出去，而不是自己在那儿死循环。

哪些故障绝对不能自愈

这部分比"能自愈什么"更重要。以下几类，发现了应该报警而不是自动处理：

涉及安全的。 温度异常、烟感报警、漏电保护跳闸、UPS 报电池故障。这些背后可能是真实的安全隐患，自动重启只会掩盖问题、拖延处置。

数据可能丢失的。 未保存的数据、正在写入的日志、正在进行的交互会话。自愈动作如果会打断这些，就得先权衡。

根因不明的反复故障。 同一台设备一周内自愈了几十次，说明有个真问题没解决。这时候自愈反而有害——它把症状盖住了，让问题一直拖着不被处理。所以自愈次数必须被记录和统计，高频自愈本身就是一条告警。

硬件已经报错的。 投影机 ERST 查出灯泡异常、硬盘 SMART 报警，这些是"该换件了"的信号，重启没用。

自愈失败了怎么办

自愈不是万能的，设计时必须想清楚失败路径。完整的处置链是这样的：

发现异常 → 自愈尝试（带退避限次）→ 成功则记录，失败则升级 → 通知人 → 人工处置 → 复盘根因

关键在"升级"这一步。很多项目做了自愈却没做升级，结果是：自愈失败了，系统悄悄放弃，没人知道，故障一直持续到客户投诉。

升级要带上足够的信息：哪台设备、什么故障、自愈尝试了几次、每次的结果、最后一次的错误信息。运维拿到这条通知就能判断要不要跑现场、带什么件。这些信息从哪来？从设备在线监控那一层的心跳和日志里来。

还有一条容易忽略：自愈成功也要记录。你需要知道"这台设备这个月自己救了自己 47 次"——这个数字本身就是重要的运维信号，说明那台机器有慢性病，该安排一次彻底检查了。

一张可以照抄的对照表

把上面的原则落到具体故障上：

故障现象	自愈手段	限次建议	失败后
播放软件退出	进程守护拉起	10 分钟内 5 次	告警 + 尝试重启机器
软件卡死无响应	杀掉后拉起	10 分钟内 3 次	告警，等人处理
主机失联但供电正常	远程断电重启	1 小时内 1 次	立即告警，人工到场
投影未按时开机	重发一次 PJLink 开机	间隔 90 秒重试 2 次	告警（可能是待机模式设错）
内存缓慢泄漏	每日定时重启	每天 1 次	不适用
系统被误改	还原卡重启复原	每次开机	不适用
温度/烟感异常	不自愈	—	立即告警
硬盘 SMART 报警	不自愈	—	安排换件

这张表的价值不在于抄，而在于逼你为每一类故障明确回答三个问题：要不要自动处理？试几次？失败了找谁？项目交付前把这张表填完，运维阶段能少掉一大半的临时决策。

落地顺序建议

别想一步到位，按这个顺序推进：

1. 先做进程守护——覆盖面最广、成本最低，一台机器十分钟配完；
2. 再配每日定时重启——解决慢性劣化，几乎零成本；
3. 然后把自愈次数接进监控——让"自愈了多少次"变成可见的指标；
4. 核心展项加系统还原——面向公众、易被误操作的先做；
5. 最后才上远程电源——成本最高、风险也最高，前面几层都做完还有必要再上。

大多数展厅做完前两步，报修量就能降下来一大截。第五步很多场子其实用不上。

小结

故障自愈的核心不是技术多复杂，而是想清楚边界：哪些交给机器、哪些留给人、机器试几次算尽力了、尽力之后找谁。

有两条铁律：自愈必须带退避和限次，否则一次必然故障就能把机器拖死；高频自愈本身就是故障信号，它盖住了症状，你得盯着次数别让它一直盖下去。

做完自愈，运维的日常就从"每天救火"变成"每周看看谁在频繁自救"。下一步是把设备本身管起来——几十台机器的配置、台账、换机复原，见设备资产台账与配置管理。