READ · UNDERSTAND · TRANSFER
阅读理解，按需巩固
先沿着原理、问答和迁移案例阅读。需要检查理解时，再切换巩固练习或展开个人记录。
核心知识 · 故障窗口与恢复不变量
先理解核心原理
先备概念：事务提交、幂等操作、状态机
恢复正确性由故障前后的业务事实决定。测试必须切断“提交、回执、状态推进”之间的窗口，证明重放不会突破幂等、权限和预算约束。
500 不是所有故障
服务在提交之前失败与提交成功但回执丢失，对调用方都可能表现为超时。前者可安全重做，后者盲目重做可能产生两次效果。故障注入要控制目标是否提交，不能只有一个总返回失败开关。
用状态替身隔离运行时
固定模型输出工具计划，再使工具替身记录业务键、效果和回执。分别在本地落盘前、外部提交后、收到回执后杀进程，恢复后核对目标记录与本地状态。重复请求可以正常存在，但最终业务效果必须符合约定。
可用性与安全性分开
无法核对结果时停在未知，可能满足“不重复写入”的安全要求，却尚未满足限时完成的服务要求。测试应同时记录这两种结论；不能把安全暂停宣传为所有故障都恢复成功，也不能迫使系统猜成功。下面列出的故障路径是建议，未执行新故障实验。
回到问题：怎样回答？
按持久化、工具提交、响应返回和状态推进的边界注入故障，而不是只让接口返回 500。用可控工具替身模拟已提交但响应丢失、重复消息、权限撤销和 Worker 接管，验证不重复副作用、不越权、预算守恒与最终状态真实。固定模型响应测试运行时逻辑，再用真实模型做端到端行为评测。
实现与取舍
从不变式反推测试
先列出必须始终成立的条件：同一逻辑动作不重复产生效果，取消后不启动新动作，恢复不增加已用预算，撤销权限立即影响执行，成功必须有验收证据。每条不变式映射到可能被破坏的状态边界，不能只检查最终页面是否显示成功。
注入真实的失败窗口
在写意图前、外部提交后、收到响应前、保存结果前分别宕机。再加入租约失效、旧 Worker 继续写、队列重复与乱序，以及恢复过程中配置变化。工具替身记录所有请求、幂等键和实际效果，测试才能区分重复请求与重复业务副作用。
控制模型随机性
运行时可靠性测试使用固定模型响应序列，例如持续重复同一调用、提前声称完成、提出越权参数。这样一次失败能精确定位到调度与策略逻辑。真实模型测试另外运行，观察任务完成与适应能力，两者不可互相替代。测试环境必须隔离真实发信、付款和发布工具。
验收恢复结果
检查操作账本、最终产物、失败分类、回执与审计事件，而不只看函数返回。给每个注入点记录恢复是否成功、耗时和需要人工介入的原因。未知状态并非一定是实现错误；无法安全核对时明确停止，比伪造成功更符合业务不变式。
工程推演
- 场景
- 面试假设：发布工具有幂等键，但恢复逻辑每次生成新键。
- 设计决策
- 工具替身记录 effect，注入响应丢失再恢复。
- 验证目标
- 测试能揭露重复发布，即使单次正常调用都通过。
- 适用边界
- 隔离实验通过不等同于真实供应商的完整一致性保证。
连续追问与解答
沿着问题的前提和约束继续向下读。先理解参考解答，再尝试收起答案，用自己的话解释因果和取舍。
第 1 层重复请求与重复效果有何区别？
恢复常依赖重发，因此先区分网络尝试与真实效果。
参考解答
重复请求是再次尝试同一业务动作，重复效果是目标系统实际做了两次。允许至少一次投递的系统可以多次请求同一键，但接收端需通过唯一业务键、状态检查或幂等机制限制效果；只数 HTTP 调用无法判断幂等是否正确。
沿着这个回答继续深入
第 2 层接收方去重成功，但本地一直未记完成，恢复时该怎么处理？
父问区分重复请求与效果，子问增加本地状态落后的故障窗口。
参考解答
沿同一业务键查询接收方已保存的结果，把核对回执持久化再推进本地状态。若去重接口只说“重复”却不返回结果，仍需独立查询；不能新造业务键绕过去重。测试应断言恢复后本地与目标终态一致。
沿着这个回答继续深入
第 3 层查询也超时，是否可以换一个新键保证最终完成？
父问依赖结果查询，再让查询失败检验未知状态的处理。
参考解答
不可以据此保证安全。新键可能再次执行已完成动作；保存原键与未知状态，按预算继续对账或交人工。只有得到可信的未执行证据、或业务明确允许重复效果，才讨论新动作；网络没有回执不是未执行证据。
第 1 层为什么固定模型响应仍有测试价值？
故障实验需要可重复控制变量，解释替身的价值边界。
参考解答
固定输出让工具选择与参数可控，可稳定复现检查点、超时、取消和权限撤销的运行时错误。它不能说明模型面对真实回执会作出正确下一步，所以之后还需真实模型的行为评估；两层测试回答不同问题，不宜互相替代。
第 1 层无法核对时停在未知算测试失败吗？
缺少目标回执后必须明确测试究竟要求什么。
参考解答
取决于契约。若不可核对时要求安全暂停，停在未知且不继续写是该安全测试通过；若还要求十分钟内完成，则可用性未达标。分别报告安全结果、恢复状态与未完成原因，保留人工对账入口，不把未知改成未执行来重试。
举一反三：条件变了，怎样推导？
先找出改变的条件，再判断原方案中哪些前提仍成立。下面的案例是教学推演，便于将原理迁移到新问题。
只读检索失败
改变的条件：没有写入副作用，但有查询费用和权限变化。
延伸问题：能否直接无限重试？
推导与参考解答
不行。只读可降低重复效果风险，仍需有界退避、成本预算和每次授权检查；记录失败终态。重复检索若使用了新数据版本，应重新核对答案，而不是拿旧证据与新结果混合。
保持不变的原理：恢复仍受事实、权限和资源不变量约束。
多步骤退款与库存补偿
改变的条件：从单工具变成不同服务的多个提交。
延伸问题：只在开头注入一次失败够吗？
推导与参考解答
不够。对每个提交和补偿窗口测试已执行、未执行和未知，检查补偿自身幂等且有真实回执。业务补偿并不抹去原始事实；无法撤销时转人工处理，不宣称跨服务自动原子回滚。
保持不变的原理：故障窗口决定恢复动作，补偿也是受控副作用。
易错点
- 只测试正常路径和 HTTP 500
- 恢复测试真的向外发消息
- 只看返回码不看副作用账本
参考资料
依据公开技术资料设计；参考资料支持技术机制，场景与评分标准为本站设计，不代表某公司面试原题。 新增问答与迁移案例用于原理讲解，来源核查与案例运行验证分别记录。
检查自己理解到哪一步
读完后可以对照这些标准解释原理、边界和取舍。掌握程度由你自评；需要进一步验证时，再完成下方小任务。
- 基础达标
- 能提出超时、重启和重复消息场景。
- 中高级信号
- 精确定位提交窗口并检查业务不变式。
- 资深信号
- 构建可控故障替身、固定模型序列与端到端分层评测。
巩固练习 按需完成 · 建议 15 分钟
为一次发布动作列出四个宕机点，每点写预期恢复行为。
展开验收要求与检查点
- 至少覆盖提交后响应前
- 断言实际效果次数
- 未知状态不会伪装成功
重点检查
- 按提交窗口而非只按状态码测试
- 能记录请求和真实副作用
- 运行时与模型质量分开验证