⚠️ AI 生成标识 · 本文由 AI Agent 协助撰写，人类作者审核发布。
事故：电回来了，服务器却没醒
周二下午，家里电闸跳了。家人很快发现，手动把闸门合了回去——市电只中断了几分钟。但等到晚上我才发现：我的”家庭数据中心”——一台 35W 待机的小主机，跑着 22 个 Docker 容器（DNS、监控、同步、各种 Agent 服务）——已经失联了整整 12 个小时。
时间线是这样的：
| 时刻 | 事件 |
|---|---|
| 11:45 | 家里跳闸，服务器断电，最后一条心跳上报 |
| ~11:56 | 家人手动合闸，市电恢复 ⚡ |
| 11:56 ~ 23:57 | 市电正常，服务器却保持关机，全家静默 |
| 23:57 | 手动按电源键开机，22 个容器全部 Up |
最讽刺的是：电早就回来了，机器却一直不肯自己醒来。
一台服务器要”活着”，需要三件事：有电、能检测、能恢复。这次事故里，这三条链路全断了——但断的方式各不相同，最贵的教训，藏在最小的细节里。
断点一：恢复自动化缺失——一个 BIOS 默认值
这台主机的断电恢复策略出厂是 After Power Loss = Power Off——市电恢复后停在关机状态，不会自动开机。
这个默认值对普通台式机完全合理（防止意外重启、保护数据），对 7×24 运行的服务器却是灾难：厂商为消费者设计的”安全默认”，在服务器场景下成了故障放大器。
最讽刺的还在后面——这个修复免费：进 BIOS（HP 机器是 F10 → Advanced → Power Management Options），把 After Power Loss 改成 Power On，市电恢复瞬间主板自动上电。如果当时开了，这次事故的损失不是 12 小时，而是 11 分钟（市电 ~11:56 恢复 → 自动开机）。
一分钱不花、五分钟能做完的事，因为没人注意，让整个数据中心瘫了半天。
断点二：检测盲区——监控器和业务同生共死
更隐蔽的问题在于：我的监控系统（Uptime Kuma）也跑在这台机器上。断电之后，被监控的机器和监控器同时消失——”监守自盗”式的盲区。
事后第一件事，就是把 Uptime Kuma 从家里迁到云上的宿主机（它本身只是个 SQLite + 心跳表，迁移成本极低）。现在家里断电时，云上的监控器会第一个发出告警，而不是跟着一起沉默。
一句话原则：监控器必须活在被监控系统出事时仍然活着的地方。
断点三：人工依赖——人是最不可靠的组件
这次恢复靠的是”晚上发现 → 手动按电源键”。如果跳闸发生在出差期间、家里没人，失联就不是 12 小时，而是无限期。
每次故障都需要人等，就意味着每次故障都可能失控。设计系统时，应该假设人不在场——不是人不可靠，而是”人在场”本就不该是系统的前置条件。
把断点连起来：无人值守自愈的最小闭环
三个断点对应三条修复动作，按 ROI 排序：
| 优先级 | 修复 | 成本 | 价值 |
|---|---|---|---|
| ① | BIOS After Power Loss = Power On | 0 元，5 分钟 | 市电恢复 → 自动开机 |
| ② | 监控器迁到独立断电域（云/另一台机器） | 0 元 | 出事第一时间有告警 |
| ③ | 容器 restart=always / 进程守护 | 0 元 | 服务崩溃自动拉起 |
| ④ | UPS（可选） | ~200 元 | 闪断无感 + 长断电优雅关机 |
前三项零成本，把”检测独立”和”恢复自动”补上，事故损失就从 12 小时缩到 11 分钟。UPS 是锦上添花：短跳闸（几分钟）直接由电池扛过去，业务零感知；长断电（几小时）时给服务器一个优雅关机的时间窗口，保护数据而不是硬断电。但它不是这个故事的主角——先把 0 元的事做了，收益最大。
一点延伸：设计要假设人不在场
“假设人不在场”也是我做 Agent 系统时反复用到的原则：任何需要人盯着才能正常工作的系统，最终都会失效在没人盯着的那一刻。
服务器如此，自动化任务如此，监控告警也如此。真正健壮的系统，不是”有人维护得好”，而是把恢复动作写进了系统的默认路径——不需要人记得，不需要人执行，出事自己回来。
总结
一次几分钟的跳闸，换来三条铁律：
- 市电恢复 ≠ 服务器恢复——检查你的 BIOS 默认值，它可能是最便宜的故障放大器
- 监控器不能与被监控对象同生共死——检测链要独立于被测对象的供电和网络
- 设计系统时假设人不在场——把恢复写进默认路径，而不是依赖人肉按电源键
下次跳闸，我希望收到的是这样一条通知：家里停电 → 几分钟后”已自动恢复，22 个服务全部在线”。如果装了 UPS，连这条通知都不需要——闪断在电池切换间无感完成，全程无人知晓，也无需人在场。
