运维脚本需接入监控告警、ansible需执行后验证、logrotate与elk策略需协同、一键部署须做环境自检；缺一即埋隐患。
运维脚本没接入监控告警，等于裸奔
很多团队写的 bash 脚本能跑通，但一出错就没人知道——因为没和 Zabbix、Prometheus 或 Alertmanager 对接。不是工具不行，是脚本里缺了状态出口和日志标记。
- 所有关键步骤后加
echo "[INFO] backup completed"或logger -t "backup-job" "success"，确保日志可被采集 - 脚本末尾用
exit $?保持原始返回码；别写成exit 0掩盖失败 - 在
crontab里调用时加2>&1 | logger -t "cron-backup"，避免 stderr 丢失 -
Prometheus场景下，优先改用exporter模式（如textfile_collector），比轮询脚本更稳定
Ansible Playbook 和线上配置实际不一致
常见现象：Playbook 声称“已统一 NTP 配置”，但某台机器的 /etc/chrony.conf 还是旧内容。根本原因是没做「执行后验证」，只信 changed=1。
- 每个
copy或template任务后，紧跟一个command任务校验：比如grep -q "pool ntp.aliyun.com" /etc/chrony.conf - 用
assert模块强制失败：当result.stdout == "old_value"就fail，不让流程继续 - 避免在 Playbook 中硬编码路径，改用
vars_files分环境加载vars/prod.yml，否则测试环境改了，生产还在用旧路径 - Ansible 2.12+ 支持
diff: true，但默认不输出；需配stdout_callback = yaml才能在日志里看到真实变更
日志轮转策略和 ELK 索引生命周期冲突
运维按惯例设 logrotate 每天切一次、保留 30 天，但 Logstash 把日志推到 Elasticsearch 后，索引按月创建，冷数据清理却依赖 ILM 策略——结果磁盘爆了，因为 logrotate 没删，ILM 又没生效。
- 确认
logrotate的postrotate是否触发了systemctl kill -SIGUSR1 logstash（部分版本需手动 reload） - ELK 侧检查
ilm_policy是否绑定到索引模板，运行GET /_ilm/policy/log-retention看phases.hot.min_age是否小于logrotate的保留周期 - 不要同时开
logrotate的compress和Logstash的gzip输入插件，会解压失败报invalid gzip header - 用
find /var/log -name "*.log.*.gz" -mtime +30 -delete做兜底清理，别全指望单一机制
交接文档里写的“一键部署”根本跑不通
所谓一键，常指一个 deploy.sh，但里面藏着三处致命假设：当前用户有 sudo 权限、/opt/app 目录存在、python3.9 已全局安装——而新来的同事连 which python3 都返回空。
- 脚本开头加环境自检：比如
command -v python3.9 >/dev/null || { echo "python3.9 missing"; exit 1; } - 路径全部用变量定义：
APP_HOME="${APP_HOME:-/opt/app}"，允许外部传参覆盖 - 权限检查写进
pre_tasks：Ansible 里用stat模块查/opt/app是否可写，而不是靠mkdir -p硬扛 - 把
deploy.sh的每一步拆成独立.sh文件（如01-check-env.sh、02-install-deps.sh），方便单步调试
工具链越长，各环节的隐式依赖就越难暴露。真正卡住人的，往往不是不会写 Ansible，而是不知道 logrotate 的 sharedscripts 会导致多进程日志文件被重复处理。
