故障切换测试 Skill：验证服务切换与业务状态一致性

故障切换测试要判断：按已批准的主备路径切换后，请求是否到达可用节点，写入权是否仍然唯一，业务状态是否可追溯。路由发生变化本身不能证明写入安全，也不能证明用户能完成受影响的流程。

先定义切换合同

根据已有架构和业务要求，记录主备节点、自动或人工触发条件、健康检测方式、各阶段的写入权，以及“业务就绪”的判定方法。

阶段	要对照的证据
检测与决策	健康信号、触发规则、选主或人工决定
隔离与写入权	新节点接收提交前，旧主是否已被 fencing
路由与重连	请求实际去向、过期路由、连接池恢复情况
就绪与切回	业务路径健康度、复制积压、对账和切回门槛

业务恢复时间目标或可接受的数据丢失边界没有来源时，应保留为待确认项，不推断零丢失，也不自行设阈值。

沿一条业务记录追踪切换

使用已有请求或账本记录，串起切换前、切换中和切换后的证据。对照请求 ID、提交记录、重试、Webhook 投递和最终业务状态，查找仍可写入的旧主、到达旧主的过期路由、重复处理，以及因确认丢失而无法确定的提交结果。

可用性和单写一致性要分别判断。流量到了备节点时，两个节点仍可能都接受提交。初次路由切换成功，也不能代替恢复后的对账证据或安全切回判据。

示例：按时间线判读写入权

以下是说明性示例。假设请求 ID req-example-01 在切换前发往主节点，调用方超时后又向备节点重试。复核时至少要关联原请求、超时记录、旧主隔离事件、新主提交记录和最终业务账本。

证据组合	可以支持的判断	仍需补充
只有新主路由记录，没有旧主隔离证据	请求可能已到达备节点，单写权尚未证明	旧主隔离（fencing）事件、时间戳和提交日志
两个节点都接受同一业务意图的写入	该时间窗存在双写风险，应记录为范围内的差异	对账结果、受影响记录和责任人决定
旧主已隔离，重试只产生一条可对账记录	支持该请求在所提供证据范围内保持单写	更广场景仍需按批准的验证计划检查

区分故障切换与灾备恢复

故障切换关注在线主备转换、路由、写入权和服务恢复；灾备还要覆盖灾难范围、恢复目标、备份证据及恢复业务链路所需的依赖。故障切换可以是灾备方案中的一步，但不能证明备份能够恢复。

记录 FOV-## 发现

记录受影响对象和规则、来源、触发条件或适用范围、预期关注点、证据状态、影响与优先级、责任角色、关闭条件及验证方法。事实、推断、候选检查和人工决策要分开。时间线应标出各阶段的节点、请求路由和写入权。

准备有边界的验证

用已有架构图、要求、日志和账本材料做静态复核。提出最小、获授权、隔离且可回滚的验证建议和停止条件；不要注入故障、访问线上依赖，也不要把候选检查写成已经执行的测试。

安装与调用

安装这个 Skill：

npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh --skill failover-testing

调用 failover-testing 时，提供架构、主备角色、已批准的触发规则、业务就绪条件以及现有路由或账本证据：

请用 failover-testing 复核这段脱敏的主备切换时间线。
架构与规则：[主备节点、触发/选主规则、写入权、业务就绪和切回门槛]
记录：[请求 ID、路由、旧主隔离、重试、提交记录、账本对账]
请区分可用性和单写一致性，列出 FOV-## 候选发现、缺失证据和最小隔离验证步骤。不要把路由切换成功写成无数据丢失或业务已恢复。

常见问题

请求已经到达备节点，就能证明切换安全了吗？ 不能。还要确认旧主已被隔离，并对账新旧节点的提交和最终业务状态。

故障切换和灾备恢复是一回事吗？ 不是。切换关注在线主备路径；灾备还要证明备份、恢复数据点和业务依赖可以支撑完整恢复。

源文件

阅读故障切换测试 Prompt: https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/failover-testing/prompts/failover-testing.md。其中定义 FOV-## 发现合同，并要求记录节点、路由和写入权时间线。