目标

只读巡检如果写重了，就会变成另一种变更脚本。我的做法很简单：只保留三件事：

• 采集
• 汇总
• 报告

不做修复，不做重启，不动数据。

最小执行模型

每台机器只跑一组只读命令，命令尽量短。

#!/usr/bin/env bash
set -euo pipefail

host="$1"
ssh -o BatchMode=yes -o ConnectTimeout=5 "$host" '
  echo "hostname: $(hostname)"
  echo "kernel: $(uname -r)"
  echo "uptime: $(uptime -p)"
  echo "disk: $(df -h / | tail -1)"
  systemctl is-system-running || true
'

关键不是命令多，而是每台主机的输出字段一致。

报告怎么做

我更倾向于把报告拆成两层：

1. 汇总表

只看状态和异常数。

| 主机 | 内核 | 在线 | 异常数 |
| --- | --- | --- | --- |
| node-01 | 5.14.0 | yes | 0 |
| node-02 | 5.15.0 | yes | 2 |

2. 异常清单

只展开需要处理的项。

## 异常
- node-02: 磁盘使用率过高
- node-03: systemd 状态非 running

怎么避免脚本越写越重

我现在会把巡检项做成插件式，但插件也只允许读：

checks/
  system.sh
  disk.sh
  network.sh
  service.sh

每个检查只输出一行状态，不往里面塞修复动作。

定时作业怎么接

定时巡检只做两件事：

1. 保存当天结果
2. 生成当天报告

base="/var/log/readonly-check/$(date +%F)"
mkdir -p "$base"
./readonly-check.sh hosts.txt > "$base/raw.log"
python3 render_report.py "$base/raw.log" > "$base/report.md"

这篇文章真正该讲什么

不是“只读很重要”这种结论，而是：

• 命令如何限制为只读
• 输出如何固定成表格字段
• 报告如何拆分成汇总和异常
• 定时任务如何不污染系统

结论

只读巡检的价值在于，它能持续跑，而且不会把系统再改坏。如果要写成博客，就应该写成一套能直接落地的采集和报表流程。