新机器交付前，我会先跑这 20 项检查

做交付多了以后，我养成一个习惯：新机器到我手里，不装业务、不建用户，先花二十分钟跑一遍检查。二十分钟能挡掉后面两周的扯皮。这篇把那份清单摊开，每一项都写清楚「为什么查」和「不合格怎么处理」，脚本也一并放出来。

一、最费时间的从来不是装系统

装一台 Linux 机器，真正花时间的步骤只有三分钟。剩下的时间全花在「这台机器到底干不干净」上。

去年验收一批机器，同一批镜像、同一个脚本装完，逐台巡检的时候翻出来的问题五花八门：有一台 /etc/resolv.conf 是上家客户留下的内网 DNS；有一台时间戳差了 40 分钟，装软件直接报证书错误；还有一台 SELinux 是关闭的，说明装机的人图省事顺手关了。这类问题不上线永远发现不了，一上线就是线上事故。

所以我的判断标准很简单：能被脚本查到的问题，就不该靠眼睛看。

二、清单分成三档

我把检查项按「错了会不会出事」分成三档，不分档就没法决定检查的深度。

A 档是必须过项，任何一项不过这台机器就不能进下一步。硬件状态、分区使用率、时区与时间同步、SELinux 与防火墙状态、远程登录策略、审计服务——这些错了是要出事的，要么影响业务稳定，要么影响合规。

B 档是规范项，不影响上线但影响后续维护。默认 shell、登录提示语、日志保留周期、软件源配置、hostname 规范——这些现在不改，以后就是「历史遗留问题」。

C 档是记录项，只采集不拦截。装了哪些补丁、内核版本、网卡速率、内存条大小。这类的数据在出故障时是唯一的线索。

分档的意义在于：全量脚本跑一遍，把结果按档位分成三种颜色，一眼就知道卡在哪。

三、A 档里最常翻车的是这几项

时间同步。这一项我从来不放进自动化，就手工核。原因是自动化的 chronyc sources 输出经常看着正常，实际偏差几百毫秒，而证书校验、数据库时间戳、日志对齐对时间敏感的场景，偏差几百毫秒就能出诡异问题。我的做法是同时对两路 NTP 源，并且要求 offset 和 delay 都在 1ms 以内。

SELinux 和防火墙。很多装机模板为了省事把 SELinux 关了，理由是「应用跑不起来」。我的处理方式是反过来：先在 enforcing 模式下跑一遍应用日志，把确实需要的策略补上，而不是把服务关掉。真关掉的话，交付文档里得写清楚原因，否则后面没人知道这机器的安全模型是什么。

SSH 配置。要求密钥登录、禁 root 直连、禁密码爆破。这三项直接改 /etc/ssh/sshd_config，改完一定用 sshd -t 验语法再 reload——直接 restart 遇上语法错误会把人锁在外面，这是个老坑。

审计服务。等保测评里几乎必查。auditd 开着、规则文件里至少有文件变更和用户权限变更两类、审计日志写到独立分区——这三条不过，测评直接挂。

四、脚本怎么写

不用什么框架，bash 就够。我把它写成一个函数库加一个主脚本，主脚本读配置、跑检查、输出报告，报告是 Markdown 的，方便直接贴进交付文档。

脚本跑完输出一张表，A 档有 FAIL 就直接退出码 1，交付流程里把这步做成硬卡点。B 档只提示，C 档只记录。

五、检查完了还要留一份快照

巡检通过不等于完事。我还会在交付前把机器的当前状态打包存一份：已装包列表、内核版本、关键配置项、服务启用状态。这份快照不出问题的时候没人看，出问题的时候是唯一能对比的基准——「上次还好好的，这次内核从 5.14 升到了 6.1」这种信息，比事后翻聊天记录快得多。

打包就是几条命令：

归档编号跟机器编号一致，跟着交付文档一起走。下次再上这台机器，先解一份快照对比，能省掉一半的排查时间。

六、把这套东西沉淀成规范

单台机器的二十分钟，最后会变成一套东西——巡检脚本、清单文档、异常处理 SOP，都放在团队的知识库里共享。新人上手照着跑一遍就能干活，不用等老同事带。

我个人的建议是：清单不要追求一次到位，先写最容易出问题的十几项，跑三次再补。像「内核参数有没有按业务调过」这种需要结合具体应用的检查项，放在通用清单里没意义，应该单独出一份按业务分类的附加清单。

这套东西跑了半年多，最实在的变化是——交付会上争论「这台机器到底有没有问题」的时候，翻报告就行，不用靠记性。