Linux 运维流程与工具脱节的改进方法

运维脚本需接入监控告警、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 会导致多进程日志文件被重复处理。