故障转移自动化需将人工判断、状态检查、资源迁移、服务验证等步骤固化为可重复、可调度、可监控的执行流，核心是翻译人脑逻辑为机器指令，并设安全边界与人工干预入口；须明确触发条件（如主节点心跳超时、服务进程异常、集群失联、数据同步滞后），分步封装操作链路（暂停原主、提升备节点、更新路由、验证可用性），优先调用集群原生接口（pvesh/kubectl/powershell/pcs），并强制人工确认、维护窗口校验与失败告警。
故障转移自动化不是靠“一键切换”实现的，而是把人工判断、状态检查、资源迁移、服务验证这些步骤，用脚本固化成可重复、可调度、可监控的执行流。核心在于把“人脑逻辑”翻译成“机器可执行命令”，同时留出安全边界和人工干预入口。
明确触发条件与检查项
脚本不能盲目执行，必须先确认是否真该切换。常见检查项包括：
- 主节点心跳超时（如 ping 失败 + SSH 连通性验证）
- 关键服务进程不存在（如
systemctl is-active postgresql返回 inactive） - 集群健康状态异常（如
pvecm status显示 quorum lost，或kubectl get nodes中节点为 NotReady） - 数据同步滞后（如 MySQL 的
Seconds_Behind_Master> 60，或 etcd 成员状态不一致）
建议每个检查都带超时和重试，避免因瞬时网络抖动误判。
封装标准操作链路
一次完整故障转移通常包含多个原子动作，脚本应分步封装并支持失败回滚：
- 暂停原主节点资源（如
pvecm expected 2或pcs resource disable） - 提升备节点角色（如
mysql -e "STOP SLAVE; RESET SLAVE ALL;"后CHANGE MASTER TO ...） - 更新路由或配置（如修改 Keepalived VIP 绑定、刷新 ProxySQL 后端列表、推送新 kubeconfig）
- 验证服务可用性（如 curl 检查 API 健康端点、执行简单 SQL 查询、等待 Pod Ready 状态）
每步执行后建议记录时间戳和返回码，便于事后审计和定位卡点。
Codex Sub Agents 1
下载
使用 OpenAI Codex CLI 处理编码任务。触发词：codex、code review、fix CI、refactor code、implement feature、coding agent、gpt-5-codex。Clawdbot 可将编码工作委托给 Codex CLI 作为子代理或直接工具。
接入集群管理接口
避免直接操作底层命令，优先调用集群原生管理工具的 CLI 或 API：
- Proxmox：用
pvesh调用 REST API，比 rawpct/qm更安全 - Kubernetes：用
kubectl patch或curl -X PATCH更新 Deployment/StatefulSet，而非重启 Pod - Windows 故障转移群集：用
Move-ClusterGroup和Suspend-ClusterNodePowerShell cmdlet - Pacemaker/Corosync：用
pcs resource move和pcs cluster standby，而非手动 kill 进程
这样既能保证语义正确，又能被集群状态机识别，避免出现“脚本认为已切，但集群仍认为旧主在线”的不一致。
加入安全防护与人工闸门
自动化不等于无人值守。关键操作前必须强制确认：
- 脚本启动时检查当前是否处于维护窗口（读取环境变量或配置文件中的
MAINTENANCE_WINDOW） - 执行提升主库前输出拟变更清单（如“将把 node-2 设为 PostgreSQL 主节点，原主 node-1 将降级为只读从库”），并要求输入
YES确认 - 设置最大并发切换数（如一次只允许一个资源组迁移），防止雪崩式切换压垮备用节点
- 失败时自动告警（发邮件/钉钉/企业微信），并保留现场快照（如
journalctl -u pacemaker --since "1 hour ago"）供人工介入
不复杂但容易忽略
