凌晨3点被报警叫醒？他把六成告警删了，反而睡了四个月好觉

凌晨3点17分，手机震了一下。他眯着眼解锁，屏幕上写着：ZFS存储池降级，3号盘校验错误持续增加，建议执行scrub。

他看了四秒，把手机放下，继续睡。第二天喝完咖啡才跑了一遍scrub，池子没事，那块盘进了每周观察名单。

这个故事之所以无聊，之所以他能接着睡，是因为系统本来就是被设计成"无聊"的。一年前不是这样——那时候他得等存储池进入严重的降级状态才会知道出了问题，而那种通知在凌晨3点收到，完全是另一回事。

大多数监控失效，其实是校准失效

系统什么都盯，什么都报，结果什么都报就等于什么都没报。人开始忽略告警，然后错过真正重要的那一条。

他用来校准的问题只有一个：如果我忽略这条告警8小时，最坏会怎样？

这一个问题，几乎能把所有告警分进三个桶里。

• L1——立刻叫醒我。数据丢失风险，比如多块盘故障导致存储池降级；安全入侵迹象，比如异常外联、陌生IP的认证失败；有真实外部暴露的服务，比如定时自动化流水线停摆。这类走高优先级推送，会把他叫醒。全部加起来大概五条。
• L2——醒着的时候告诉我。降级但稳定，比如单块盘校验错误升高、单个容器崩溃后自动重启；错误率上升但还没影响服务；磁盘健康趋势走坏。这类走普通优先级推送，不叫醒人，配咖啡看。
• L3——只记日志，不告警。其余全部：备份完成、定时任务结果、健康检查成功、例行scrub结果。这些进日志，永远不进推送。

第一次套用这套框架时，他删掉了大约60%的存量告警。响应质量上去了，告警疲劳下来了，睡眠质量跟着改善。

整套监控栈，运行成本为零

服务可用性用Uptime Kuma，按计划巡检每个服务，宕机告警里带足够上下文，不用登录就能判断严重程度。系统指标用Netdata，CPU、内存、ZFS池健康、网络吞吐实时看。磁盘健康用Scrutiny，把SMART数据聚合起来做趋势，故障之前就能看到退化。推送用ntfy，通知里带告警级别、受影响服务、一行建议动作。

整套东西跑在自建基础设施上，没有云依赖，没有SaaS费用。

他的判断很直接：没有校准过的告警系统，比没有告警还糟。

自愈脚本：先解决八成

真正改变一切的思路转换是：别再问"坏了之后我怎么修"，改问"我怎么让它坏了之后自己修"。第二个问题的答案，几乎总是一个二十行的bash脚本——检查一个条件，执行一个动作。写一次，挂在定时任务上跑到天荒地老。

每个自愈脚本都遵循同一套结构：检查一个条件，只执行一个动作，记录结果，失败时通知。关键约束是"只执行一个动作"——想耍聪明走多条恢复路径的脚本会变得不可预测。一次检查，一个动作，没解决就升级。

他的NAS上实际跑着这些：

• ZFS健康检查，每6小时一次。从zpool status读校验错误计数，超过阈值立刻触发scrub并发L2通知；scrub结束后记日志并跟进——错误清掉就记录，错误持续就升级到L1。他已经好几个月没手动发起过scrub。
• 容器健康检查，每5分钟一次。检查每个Docker容器是否处于unhealthy或exited状态，命中就按指数退避重启：等1分钟，再等5分钟，再等15分钟。连续第三次失败升级到L1并停止重试。这样瞬时崩溃循环不会叫醒他，真正的故障还是能抓到。
• Ollama推理检查，每10分钟一次。向推理端点发一个最小测试提示，连续三次失败触发容器重启，重启后还要验证端点健康才算恢复。Ollama现在是他一半自动化栈的承重墙，静默失败不可接受。
• n8n工作流队列检查，每10分钟一次。队列深度超过阈值持续10分钟以上，就重启n8n worker并记录触发事件。没人注意的工作流积压，就是自动化流水线悄悄烂掉的方式。

他最庆幸存在的一个脚本是个小看门狗，每5分钟跑一次，检查面板的node进程是否活着、健康端点是否在响应。不在就做依赖检查、重启进程、记录恢复。上线以来，这个脚本已经静默把面板从崩溃里拉回来11次。这11次他一次都没实时察觉，服务就那么一直在线。他说，只有这个数字才重要。

核心管理守护进程是另一类脚本。它每分钟检查一次NAS的核心管理进程，关键区别是：这个进程不能自动恢复——重启它造成的问题比原来的故障更糟，这是他踩过坑才学会的。所以脚本不去修它，只负责发现故障并立刻发L1告警。对于一个不能安全自动恢复的进程，快速发现就是全部的自愈策略。目标是从故障到告警两分钟，实际稳定在90秒以内。

大多数家庭实验室监控指南漏掉的东西

它们教你怎么装Prometheus和Grafana，却不告诉你最难的部分不是埋点，是校准。校准这件事，是花一周时间留意自己到底会处理哪些告警、哪些看都不看就划掉。这份功夫比更好的仪表盘值钱得多。

他衡量自己运维质量的指标只有一个：这个月有几次为它下床。现在是零，而且已经连续四个月是零，包括开头那次ZFS校验错误事件。每一次非零都是一个数据点，指向系统哪里断了：要么一条L2被错分成了L1，要么某个自愈脚本没触发，要么那确实是一条真L1，本该在白天就被自动化掉。

先建自动化，再调校准。没有告警的自动化是瞎的，没有自动化的告警只是一个寻呼机——把你叫醒来做一件bash脚本本来就能做的事。