每天巡检十几台服务器，我只做只读检查：一个轻量安全巡检方法论

每天早上，我都会把名下的十几台服务器巡检一遍。不是因为它们天天出问题——恰恰相反，大多数日子什么事都没有。巡检的意义正在于此：用一套固定的、只读的流程，把“没事”变成可验证的结论，而不是凭感觉。

一、先定一条铁律：巡检只读，改动另批
这是整个方法论的前提。巡检只做读取：看服务状态、看磁盘、看日志、看安全配置。发现异常也不当场修，而是记下来、报上去，等明确批准再动手。
这条规则看起来慢，实际上省了最多的麻烦。一次未经确认的“顺手修复”，可能比故障本身更难排查。只读巡检还有一个好处：它可以放心地每天跑，不用担心某次执行改坏了生产状态。

二、巡检分三层，每层回答一个问题
第一层是存活与资源：机器在不在、关键服务在不在、磁盘还剩多少、负载是否异常。这一层回答“机器还活着吗”。
第二层是 24 小时日志扫描：登录失败、异常进程、可疑的对外连接。这一层回答“过去一天有没有人动过不该动的东西”。这里有个经验：只看单条告警容易误判，要看频率和来源分布——短时间内来自同一来源的多次失败登录，和零散的单次失败，完全是两回事。
第三层是安全基线审计：对照一套公开的加固基线思路，逐项检查账号、权限、防火墙、关键服务配置。这一层回答“配置有没有悄悄走样”。面板、工具升级、一次重启，都可能悄悄改掉原来的配置，所以基线检查不能只做一次，要每天比对。

三、告警要分级，日常“一切正常”不打扰
巡检报告每天都会产出，但通知只发真正的安全问题。常规的“全部正常”不需要打扰人——人对天天响的通知会脱敏，等真出事时反而注意不到。
反过来，真正的安全信号要第一时间推到手机上，并且写清楚三件事：发现了什么、证据是什么、建议下一步做什么。没有证据的告警等于没有告警。

四、改动配置前先备份，历史数据先归档
这是用教训换来的规矩：覆盖任何一份配置之前，先留一份带日期的备份；历史数据文件不要直接删，先归档改名。监控类配置重写之后，要逐个目标验证真的出数据，不能只看服务起来了。

五、这套方法论的边界
它不是实时监控，是一天一次的体检：能抓住同一类问题的复发，但抓不住分钟级的新变种。实时告警和每日巡检是两回事，前者靠探针，后者靠流程，两者互补，不互相替代。
另外，巡检工具坚持零安装、只用系统自带工具。少一个第三方依赖，就少一个供应链风险点，也少一份维护负担。

结尾
巡检做久了会发现，服务器运维的大部分工作不是救火，而是让“没事”这件事变得可证明。固定的流程、只读的边界、分级的告警、改动前的备份——这四样东西加起来，就是一台机器从“好像没事”到“确认没事”的距离。