状态：在评估 · 未上生产 · 不上比乱上更安全
速读#
watchdog 是整机级兜底，挡的是卡死到 systemd 都没机会拉回来的情况。这篇不是推荐立刻上，而是解释为什么它还在评估：误触发一次硬复位，代价可能比没有它更大；上之前必须先在测试机验通。
守护是分层的#
| 层 | 工具 | 挡什么 | 状态 |
|---|---|---|---|
| 服务级恢复 | systemd | 进程崩了自动拉回 | 在用 |
| 出事通知我 | 哪吒探针 | 挂了 / 负载高了主动告警 | 在用 |
| 整机级复位 | watchdog | 卡死到 systemd 都没机会时，硬复位 | 在评估 |
三层不重叠：前一层失灵，才轮到后一层。systemd 是服务级动作，探针只告警不动作，watchdog 是整机级动作。
它怎么工作#
系统里跑一个定时「喂狗」的程序；硬件看门狗（或内核模块 softdog）等投喂。
- 正常：喂狗不断 → 看门狗不动
- 卡死：喂狗停了 → 超时后硬复位整机
没有硬件看门狗的机器（多数云 VPS）可以用 softdog 顶。但 softdog 的可靠度边界要认清：它本质是内核里的一个定时器，触发复位这个动作本身依赖内核还活着。中断都停摆的硬卡死，它自己也跟着死了——这道坎只有真硬件看门狗跨得过去：计时器在独立芯片上，主机死透了它照样拉电。评估阶段 softdog 反而够用：测试机上就能把「故意卡死 → 超时复位」的演练做完，不用等真硬件。
顺带把两个容易混进来的东西分开，免得高估 watchdog 的必要性：
- 只怕内核 panic 后停机：
kernel.panic = 10一行 sysctl 就能让 panic 十秒后自动重启，不用整套 watchdog。watchdog 针对的是不 panic 的卡死——IO 挂死、内存耗尽后的僵持、活锁。 - systemd 自带的路线：
RuntimeWatchdogSec=让 PID 1 亲自喂狗，配置一行，验证的是「内核和 PID 1 还活着」；独立的 watchdog 守护进程则能加负载、文件更新时间这类更细的判活条件。我评估的顺序是先试 systemd 这条——能用一行配置解决的，别为它多养一个守护进程。
我这几台的主要风险不是「整机卡死」，是单服务挂——systemd 已经覆盖。所以 watchdog 的边际收益，在当前规模没那么高。
「没那么高」≠「永远不需要」。机器再涨、半夜卡死一台没人手动拉，这层就会变成刚需。
为什么在评估，不在用#
推荐栏不全是「在用清单」。有些工具的价值，恰恰是把「为什么还没上」写清楚。
三条叠在一起：
-
配错代价大 误触发会硬复位。生产机误复位一次的损失，往往大于现在不装它。
-
set-and-forget 最怕「装了当没装」 装上就忘，出事才起效；真出事发现没配上——这类系统，纪律要比日常工具严。
-
规模没到 先等真出现过「systemd 拉不回来的整机卡死」，再上。纯预防性地上太早，优先级不排前面。
什么条件下会上#
三个条件同时满足：
- 确认有机器出现过整机卡死
- 测试机 dry-run 验通：故意制造卡死 → 超时复位；正常负载下绝不误复位
- 复位后服务能自己起来（
systemctl enable等开机自启已配齐）
第二条最关键。最怕配成「自己饿死自己」：喂狗脚本卡住，或触发条件太松，正常负载也 reboot 成循环——那不是兜底，是在生产机上装了个定时炸弹。
宁可没有这层兜底，也不要一个会误触发的兜底。
set-and-forget 最怕装了当没装。最后一层兜底：没想明白不上；上了就必须验过——该动才动，不该动绝不动。不验通就是埋雷。