巡检的价值不在"今天又转了一圈"，而在于留下一条可以对比的历史曲线。同一台服务器，单次的数据看不出问题，三十天的曲线却能提前三周告诉你：磁盘要满、RAID 要掉盘、内存要爆。所以巡检表的第一原则不是"全"，而是"可对比"。
一、先把表定死：三类状态、一页纸
巡检表最常见的失败方式是"太长"。十几页的表单，第一次认真填，第二次开始抄上次的，第三次就只剩签字了。我们的做法是先压缩到一页纸，只保留能改变决策的项目。
- 三类状态：正常 / 预警 / 异常——没有中间地带，避免"看起来还行"
- 每一项都必须有明确的预警线，否则填表人只能凭感觉
- 记录格式固定：项目、实测值、预警线、状态、备注，方便逐月对比
一条经验
巡检表不要超过一页。需要放到第二页的项目，通常说明它更适合交给监控系统，而不是交给巡检的人。
二、硬件层：先看不会撒谎的部分
硬件状态是客观的，优先从这里开始，能最快排除物理隐患。这一层不需要复杂工具，多数设备的带外管理界面就能看全。
| 检查项 | 看什么 | 预警线 |
|---|---|---|
| 电源与冗余 | 双电源是否都在位、有无告警灯 | 任一电源异常即预警 |
| 风扇与温度 | 进风口温度、CPU 温度、风扇转速 | 较基线上升 10℃ 以上 |
| 磁盘健康 | RAID 状态、SMART 重映射扇区数 | RAID 降级、重映射数持续增长 |
| 网卡与链路 | 协商速率、错包与丢包计数 | 速率下降、错包计数增长 |
| 机柜环境 | 温湿度、UPS 负载与电池状态 | 温度 > 27℃、UPS 电池超期 |
三、系统层：日志、水位、负载
这一层的核心是趋势。服务器不会突然满，只会慢慢涨。所以看的是"比上次多了多少"，而不是"现在是多少"。
- 分区水位：系统、数据、日志分开看，日志分区往往最先告急
- inode 使用率：小文件多的场景，inode 比容量更早撑不住
- 内存与 swap 使用情况，以及系统日志里的 OOM 记录
- CPU 负载的三个值（1 / 5 / 15 分钟）——看趋势，不看瞬时
- 关键服务进程与监听端口是否都在
- 时间同步是否正常（时间漂移会污染日志，也会让证书校验失败）
如果时间有限，优先级建议是：磁盘水位 > RAID 状态 > 服务进程 > 其它。这三项覆盖了运维现场最常见的故障来源。
四、业务层：能被客户感知的部分
前两层回答的是"机器还好不好"，这一层回答的是"业务还能不能用"。巡检表上必须有业务视角，否则容易变成纯硬件巡检。
- 服务健康检查接口是否正常，响应时间是否在基线范围内
- 数据库连接数、慢查询数量的变化
- 昨天的备份任务是否成功，最近一次恢复演练是什么时候
- 证书与域名到期时间——提前 30 天就应该出现在巡检表上
别把"备份成功"当"可以恢复"
巡检表上建议并排两列：备份成功率、最近一次恢复演练日期。只有第二列有日期，第一列的数字才有意义。
五、让巡检真正生效的三个前提
- 模板固定：项目一旦定下来就不再改来改去，否则历史数据无法对比
- 阈值写死：把判断标准提前写进表里，不依赖填表人的经验
- 问题闭环：每次巡检先看上一轮问题的处理结果，谁在什么时候改了什么
最后补一句：巡检是"发现趋势"，监控是"发现当下"，两者不能互相替代。清单里那些需要实时、高频监测的项目，应该交给监控系统；巡检表只保留需要人判断、需要历史对比的部分。这样巡检才不会沦为一项填表任务。
#服务器巡检#IT 运维#运维台账#主动治理
