脚本也要版本
巡检脚本一旦在生产目标上执行，它就是代码，必须能回答谁改的、改了什么、哪些目标跑的是哪个版本。没有版本信息时，同一台机器两次巡检结论不同将无法复现，也无法区分环境变化与脚本变化，异常数量的突变会变成无人能解释的数字。
基本信息
| 管理对象 | 巡检脚本、检查项定义、参数阈值、采集模板 |
|---|---|
| 版本标识 | 语义化版本或提交哈希，写入执行记录 |
| 分发方式 | 从版本库或制品库统一拉取，禁止就地改 |
| 发布控制 | 灰度目标验证通过后再推向全量 |
| 回收要求 | 旧版本可回溯，弃用版本需标注替代关系 |
典型使用场景
- 阈值调整：磁盘水位阈值从 85% 调到 80%，需留下变更记录与生效周期
- 环境适配：同一检查项在 RHEL 与 Debian 上命令不同，用分支或分版本脚本承载
- 结果复现：异常复查时按执行记录中的脚本版本重跑，排除脚本变更干扰
- 多团队共用：平台脚本被多个团队引用时冻结版本，而不是让所有人取最新
- 回滚：新版本误判率上升时可快速回退，并知道哪些目标已受影响
版本要素与落地方式
| 要素 | 落地方式 | 缺位后果 |
|---|---|---|
| 版本号 | 语义化版本或提交哈希 | 两次结果差异无法归因 |
| 变更记录 | 提交信息写清检查内容与阈值 | 事后无法解释判定口径 |
| 统一分发 | 从版本库或制品库拉取 | 各目标脚本漂移，结果不可比 |
| 灰度 | 先在小批量目标试用 | 误判一次性铺到全量目标 |
| 弃用标注 | 标明失效版本与替代版本 | 旧脚本长期在线但无人维护 |
执行记录带上版本与指纹
执行记录带上版本与指纹
# 脚本头部声明版本，执行时写入结果文件
SCRIPT_VERSION=2026.10.1
# 记录文件指纹，校验目标上跑的脚本与发布制品是否一致
sha256sum /opt/inspect/disk.sh >> run.log
# 结果同时带上目标与版本，便于复现与横向对比
echo host=www01 version=$SCRIPT_VERSION >> run.log
# 灰度：仅测试组目标启用新版本，验证通过再全量发布
if grep -q www01 /opt/inspect/canary_hosts.txt; then
/opt/inspect/disk.sh.v2 >> run.log
else
/opt/inspect/disk.sh >> run.log
fi巡检结果要与脚本版本绑定存储。只在版本库里记录变更而执行结果不带版本号时，历史结果的判定口径无法还原，趋势分析会把一次脚本升级误读成环境恶化。
直接在目标机上编辑脚本是最常见的失控来源：改动无评审、无备份、无法批量回滚，版本库里的定义与实际执行的代码长期不一致。生产目标上应只允许拉取，禁止就地修改。