ansible 是将故障应对逻辑提前编码进 playbook 的自动化工具。它通过内置模块快速定位问题，用 block/rescue/always 实现自动恢复，结合 check_mode、灰度执行和断言确保安全，并持续将故障经验固化为可复用的自动化能力。
Ansible 不是“故障发生后再响应”的工具，而是把故障应对逻辑提前编码进 Playbook，让系统具备自动识别、隔离、恢复的能力。关键不在事后补救，而在把经验固化为可重复执行的自动化流程。
快速定位：用模块代替人工排查
突发故障的第一分钟，时间就是服务。别登录每台机器敲命令，用 Ansible 内置模块批量采集关键状态：
- stat 检查关键文件是否存在、权限是否正确、大小是否异常（比如日志轮转失败导致磁盘满）
-
uri 批量探测服务端口或健康接口（如
/healthz），5 秒内确认哪些节点已失联 -
command + failed_when 组合判断业务指标，例如：
curl -s http://localhost:8080/metrics | grep 'up{job="app"} 1'，不匹配即标记为异常 - debug 配合 register 把结果汇总输出，一眼看清故障范围
自动恢复：基于条件触发修复动作
定位之后不能等人工介入。用 block/rescue/always 结构构建弹性恢复链：
- block 中执行主恢复动作，比如重启服务、切换备用配置、清空缓存目录
- rescue 处理主动作失败的兜底方案，例如主服务起不来就启动降级模式、拉取上一个备份版本
- always 记录操作日志、发送告警通知、重置监控状态，确保闭环
配合 until + retries，还能应对临时性问题——比如等待数据库连接池重建、等待 Kubernetes Pod 就绪，避免“一击不中就放弃”。
降低误操作风险：安全执行与灰度控制
自动化修复的前提是“不会让情况更糟”。必须加几道保险：
- 所有变更类任务启用 check_mode: yes 先做模拟运行，确认影响范围再真实执行
- 用 -l 参数限制首次执行只在 1~2 台机器上，验证逻辑无误后再全量 rollout
- 敏感操作（如重启核心服务、修改防火墙规则）加上 vars_prompt 或依赖外部确认信号（如 Redis 键存在才继续）
- Playbook 开头加入 assert 模块校验前提条件，例如磁盘剩余空间 >10%、当前时间不在维护窗口外
持续加固：把每次故障变成自动化能力
每次真实故障处理完，不是写个报告就结束，而是立刻反向提炼成 Ansible 能力：
- 把人工执行的排查命令，封装成可复用的 role，比如
check-disk-full、verify-db-connection - 把临时修复脚本，改造成带 when 条件的 task，下次同类现象自动触发
- 把故障特征（如特定日志关键词、CPU 突增模式）写进 failed_when 或 until 判断里，让 Ansible “学会识别”
- 所有 Playbook 纳入 Git 版本管理，每次提交附带故障编号和根因说明，形成组织级故障知识库
