交付清单是干什么的
新装系统从『能开机』到『可交付』之间有一串固定动作：身份与时间、网络与解析、软件源、远程管理、防火墙与安全基线、日志与磁盘。逐项核对的意义在于把问题挡在交付之前——时间不同步、DNS 没配、自启服务过多这类问题，登录测试看不出来，却会在上业务后集中爆发。
基本信息
| 身份项 | 主机名、时区、时间同步、系统版本 |
|---|---|
| 网络项 | IP/掩码/网关、DNS、路由、对外连通性 |
| 安全项 | SSH 策略、防火墙状态、账户与口令策略、SELinux 状态 |
| 运维项 | 软件源可用性、日志服务、磁盘余量与挂载、失败服务 |
| 留痕方式 | 脚本采集输出并随交付文档归档 |
| 原则 | 先只读采集，确认无误再做变更 |
典型使用场景
- 批量装机后逐台核对，形成交付记录
- 割接前最后一次体检，确认系统状态与设计一致
- 接手他人维护的系统时快速摸清底数
- 等保与内审前的自查，把证据准备好
- 出现故障时用同一套命令对比『正常时』与『现在』的差异
一条命令快照
一条命令快照
hostnamectl; timedatectl; ip -br a; ip route | head -3
# 上面依次输出：主机名与系统版本、时区与同步状态、接口地址、默认路由
df -h / /var 2>/dev/null; systemctl --failed
# 再输出：关键分区余量、启动失败的服务单元
getenforce 2>/dev/null; firewall-cmd --state 2>/dev/null || ufw status 2>/dev/null
# 最后输出：SELinux 状态、防火墙是否在运行（两种工具自动择一）一次性例行检查
一次性例行检查
timedatectl status # 看 NTP 是否已同步，避免日志时间错乱
chronyc tracking | head -3 # 时间源与偏移量
ssh -V # 版本留档，便于漏洞影响面比对
systemctl is-enabled sshd chronyd 2>/dev/null # 关键服务是否开机自启
lsblk -f # 分区与文件系统一览
uptime; free -h # 负载与内存基线检查项与判定
| 检查项 | 命令 | 判定标准 |
|---|---|---|
| 主机名 | hostnamectl | 符合命名规范且与资产台账一致 |
| 时间同步 | timedatectl / chronyc tracking | System clock synchronized: yes |
| 网络与解析 | ip -br a、ping -c1 DNS 名 | 地址与网关符合设计，解析正常 |
| 软件源 | dnf repolist / apt update | 无报错且包数量正常 |
| 失败服务 | systemctl --failed | 无 failed 单元，或已登记原因 |
| 安全状态 | getenforce、firewall-cmd --state | 与基线一致，例外需有变更单 |
把清单固化成脚本并保留每次执行输出：批量交付时逐台留痕，后续出现问题时可以直接对比『交付时』与『故障时』的差异。
检查脚本第一版应只读采集，不要混入修改动作：先看清现状再决定改什么，避免脚本顺手把生产配置改掉。