高可用Ansible故障恢复脚本核心是嵌入日常流程的可触发、可判断、可验证机制。需明确定义故障判定标准与恢复成功状态，按服务级、VIP级、数据一致性分层设计恢复逻辑，用wait_for/uri前置检测、assert/fail后置校验，结合delegation和local_action实现跨节点协同，并集成至监控告警与主部署流程中。
编写高可用的 Ansible 故障恢复脚本，核心不是写“一键回滚”，而是让恢复动作可触发、可判断、可验证。它必须嵌入到日常部署流程中，而不是等故障发生后再临时拼凑。
明确恢复目标与触发边界
先定义清楚：什么算“故障”？恢复到什么状态才算成功？避免模糊表述。
- 服务级恢复：如 HAProxy 进程挂了 → 启动服务 + 检查端口 6443 是否监听
- VIP 级恢复：Keepalived 主节点失联 → 在备用节点强制触发 state 切换（用 delegate_to 控制执行位置）
- 数据一致性恢复：MySQL 从库延迟超阈值 → 执行 stop slave; start slave; 并校验 Seconds_Behind_Master ≤ 5
- 不恢复硬件故障或磁盘损坏这类底层问题，Ansible 不负责物理层修复
用 Playbook 封装带条件判断的恢复逻辑
把恢复动作写成独立的 playbook（如 recover-haproxy.yml），关键在于加入前置检查和失败中断：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 用 wait_for 模块检测服务是否已不可达（例如连接超时、端口无响应），作为启动恢复的依据
- 用 uri 模块调用健康接口（如
/healthz返回非 200）触发后续步骤 - 每个恢复任务后接 assert 或 fail，确保恢复后状态达标，否则整个 play 中断
- 避免用
command: systemctl restart xxx这类无判断操作；改用systemd: name=xxx state=restarted并设ignore_errors: no
利用 delegation 和 local_action 实现跨节点协同
高可用场景下，恢复常需在特定节点执行，或由控制机协调：
- 主节点宕机后，在备节点运行
keepalived --force-reload：用 delegate_to: "{{ groups['lb_backup'][0] }}" - 生成恢复报告或发送告警：用 local_action 在控制节点执行脚本或调用 webhook
- 批量检查所有节点服务状态并汇总：加 run_once: true + delegate_to: localhost，再用
set_fact收集结果
集成到日常运维链路中
恢复脚本不能孤立存在，要能被监控系统或人工快速调用：
- 配合 Zabbix/Prometheus 告警，用 webhook 触发
ansible-playbook recover-xxx.yml -i inventory/prod/ -e "target=node1" - 在主部署 playbook 结尾加上 include_tasks: check-health.yml，自动校验并跳转到恢复流程
- 敏感操作（如强制 VIP 漂移）加 pause 模块，等待人工确认再继续
- 所有变量通过 group_vars 统一管理，不同环境（prod/staging）复用同一套恢复逻辑
