误操作多数不是手滑
自动化造成的事故里，纯粹「手滑」占比不高，更多是机制导致的：目标范围用模式匹配写得太宽，一次执行覆盖了远超预期的主机；变量未定义导致空值进入命令，作用对象变成根目录；预演与实做之间环境不同，验证通过但执行结果不同。这些都有共同特征——在执行前就有迹可循。事前防护的思路正是把检查点前移，让错误在产生破坏之前就暴露出来。
基本信息
| 适用对象 | 批量执行、配置变更、发布与清理类任务 |
|---|---|
| 误操作来源 | 目标范围过宽、变量空值、环境混用、缺少预演 |
| 防护时机 | 执行前，而非执行中或事后 |
| 关键手段 | 预演、范围确认、差异预览、串行推进、变更窗口 |
| 权限要求 | 目标选择与审批权限应分离，避免同一人独立完成全流程 |
事前防护手段
- 默认预演：把只检查不修改设为默认，实际执行需要显式开启
- 范围二次确认：执行前打印将要影响的主机清单与数量，人工比对
- 差异预览：先展示会改动哪些地方，再决定是否继续
- 小步推进：先单机、再小批量、最后全量，每步都设观察点
- 限速与串行：避免全部目标同时变化导致影响面不可控
- 变更窗口与冻结：避开业务高峰与冻结期，并提前告知相关方
防护性执行流程
防护性执行流程
ansible -i inventory --list-hosts 'prod:&web' | wc -l # 执行前先看目标数量
ansible-playbook -i inventory site.yml --limit 'prod-web01' --check --diff # 单机预演并查看差异
ansible-playbook -i inventory site.yml --limit 'prod-web[01:03]' --step # 分批推进，逐批确认
ansible-playbook -i inventory site.yml 2>&1 | tee run-$(date +%F-%H%M).log # 全程留档
case "${TARGET_ENV:-}" in prod) ;; *) echo '未显式指定环境，已中止' >&2; exit 1;; esac # 环境必须显式声明误操作类型与防护
| 误操作类型 | 典型成因 | 事前防护 |
|---|---|---|
| 范围过宽 | 模式匹配写错或过松 | 执行前打印目标清单与数量 |
| 作用对象为空 | 变量未定义或取到空值 | 对关键变量做非空校验 |
| 环境混用 | 凭据或配置指向错误环境 | 环境必须显式声明，缺省即中止 |
| 并发冲突 | 多任务同时改同一资源 | 加锁或串行化，明确变更顺序 |
| 时间不当 | 打到业务高峰或冻结期 | 变更窗口与冻结期校验 |
缺省值的设计方向决定事故形态：缺省指向测试环境时，误操作最多影响测试；缺省指向生产时，一次漏填参数就可能直达生产。把「默认安全」作为硬性要求，比反复强调小心更有效。
不要为了跑完而打开「忽略错误继续执行」：在部分失败的状态下继续推进后续破坏性步骤，是批量事故里最常见的放大机制。失败即中止并保留现场，代价远小于扩大影响。