分类： 运维工具脚本

滚动发布或批量重启之后，很多团队会用一个 sleep 任务加一次 curl 探测来「确认服务起来了」。这种写法在测试环境勉强能用，到了生产环境就会暴露三个问题：探测太早，服务还在初始化，任务直接失败；探测太晚，流水线白白空转几十秒；服务确实挂了却没有明确的重试策略，失败点分散在多个 task 里，很难定位到底是谁把服务拖垮的。Ansible 的 uri 模块

rsync 增量备份本身很可靠，但一旦被 cron 或 systemd timer 调度起来，就会遇到两个非常现实的问题：第一，上一次备份还没跑完（源端文件多、网络慢、磁盘抖动），下一次调度又启动了，两个 rsync 进程同时写同一个目标目录，轻则重复传输浪费带宽，重则 rsync: mkstemp "/backup/.../.file.XXXXXX" fa

容器突然消失，docker ps -a 里状态显示 Exited (137)，运维第一反应往往是「被 OOM 杀了」。但这个判断在多数情况下是错的：退出码 137 只说明进程收到了 SIGKILL（信号 9，128+9=137），而 SIGKILL 的来源至少有四种——cgroup 内存超限被内核 OOM killer 选中、docker stop 超时后

线上常遇到一类故障：某个服务因为配置写错、依赖模块缺失或端口被占用而一启动就退出，而它的 unit 文件里写着 Restart=always。systemd 会立刻重新拉起它，进程又秒退，于是形成每秒数次、甚至每秒十几次的重启风暴。日志被刷满、监控被打爆、CPU 被 fork 和 exec 吃掉，真正的根因被淹没在 Started ... 与 Stopped

Ansible 默认的执行模型是「遇错即停」：playbook 里任何一个 task 在目标机上返回非零退出码，host 就会被标记为 failed，后续所有任务直接跳过。这对一次性脚本够用，对滚动部署、数据库迁移、服务重启这类「失败后需要原地收拾残局」的场景就非常别扭——你真正想要的是「这一步可能失败，失败了先回滚/降级/重试，收拾干净再决定整体成败」。b

写运维备份脚本的人大多踩过同一个坑：参数一多，$1、$2、$# 手工 case 判断就开始失控。./backup.sh -s /data -d /backup -k 7 /etc/nginx 里既有选项又有位置参数，一旦用户把 -k 7 写到源目录后面，脚本要么把 -k 当成目录名，要么把 7 当成了第二个源路径，备份跑完才发现备错了东西。更糟的是它在 -k