qa-resilience

QA 韧性

快速参考

症状	从这里开始
依赖项缓慢或卡住	截止时间和超时预算
依赖项暂时性故障	带抖动的有界重试和重试预算
依赖项持续故障	熔断器和回退方案
依赖项遭遇速率限制	遵循 Retry-After，呈现降级行为，并有针对性地测试配额路径
健康节点池中有一个异常主机	异常检测或端点剔除
队列或连接池饱和	隔离舱、并发限制、负载削减
容量变化时静态并发限制持续过时	采用带静态兜底的自适应并发限制；验证有效吞吐量平台期 — load-shedding-backpressure.md
非关键功能中断	优雅降级或功能标志回退
韧性验证	先进行确定性故障注入，再进行混沌测试

何时使用此技能

• 重试、截止时间、对冲、熔断、隔离舱和过载保护
• 降级模式下的用户体验或 API 行为
• 服务网格或网关韧性策略
• 混沌工程、演练日、灾难恢复演练和故障注入
• 根据故障行为而不仅是正常路径负载测试来设置发布门禁

转到其他技能

• 简单的 CRUD 或单进程工具 → 常规错误处理可能就足够
• 仅限前端的故障行为 → software-frontend
• 服务实现细节 → software-backend
• 遥测埋点 → qa-observability
• 更广泛的平台与事件运维模式 → ops-devops-platform

---

工作流

1. 确定关键用户旅程，以及可能导致其故障的依赖项。
2. 为每项依赖定义契约：
   • 超时或截止时间预算
   • 重试责任归属
   • 熔断器或异常检测策略
   • 并发和队列限制
   • 依赖项不可用时的降级行为
3. 确定策略的归属位置：
   • 应用代码
   • 客户端库
   • 服务网格或网关
4. 分阶段测试：
   • 设计审查或检查器输出只能确认策略的一致性
   • 确定性故障注入可验证系统对指定受控故障的响应
   • 在非生产环境中进行分阶段混沌测试，可验证该环境中的行为受限且能够恢复
   • 小范围生产金丝雀或演练日只能验证在指定观察窗口内观测到的目标路径，并须设置防护措施
5. 定义通过或失败信号：
   • 错误预算消耗速率
   • p95 或 p99
   • 回退率
   • 熔断器状态转换
   • 被削减的负载量
   • 恢复时间
6. 记录注入的故障、稳态假设、爆炸半径上限、中止条件、观察窗口、恢复结果，以及模拟而非实际观测到的依赖项。

---

选择性验证与危害分析

• 如果问题是恢复／故障转移协议在并发故障下是否保持不变量，或需要反例，请使用形式化方法。返回属性、初始状态、转换／环境假设、检查界限、结果／轨迹，以及模型与代码之间的局限。有限不变量检查不能证明活性或恢复时间。对于常规超时／重试配置，以及行为可直接观察的指定故障测试，请跳过。
• 如果重试、回滚、故障转移、操作人员或其他正常运行的控制措施可能相互作用，导致明确规定的不可接受损失（例如重复的财务影响或破坏性恢复），请使用安全工程。返回损失 → 危害 → 不安全控制操作及其上下文 → 约束 → 负责人 → 验证证据，并注明尚未解决的问题。对于不涉及有害交互问题的常规可用性或延迟调优，请跳过。正常运行时间和危害图都不能证明安全性。

将弹性策略、故障注入执行、恢复证据和发布建议保留在此技能中；仅在遇到上述明确缺口时使用基础技能。

模式规则

• 重试只发生在一个层级
• 先设置截止时间，再进行重试
• 仅对幂等或可安全取消的读取请求进行对冲
• 过载处理必须尽早卸载负载，而不是等到最后崩溃
• 过载测试应以容量超出后有效吞吐量趋于平稳为通过标准，而不是以“出现了 503”为标准；卸载响应只由负责重试的层级在预算范围内、收到 Retry-After 后重试
• 在受监管的企业中（EU DORA、UK FCA/PRA operational resilience），应针对每项重要业务服务及其影响容忍度进行测试，并将第三方纳入其中；范围界定由法律顾问负责——参见 disaster-recovery-testing.md
• 就绪状态和存活状态检查必须保持有界且浅层
• 弹性行为应纳入有针对性的检查；不要让限流或降级模式覆盖泄漏到无关的正常路径测试套件中
• 生产环境实验必须设置影响范围限制、中止标准、仪表盘和负责人

需要验证的故障模式

• 超时和截止时间传播
• 重试风暴和重复副作用
• 依赖项部分中断
• 下游缓慢和长尾延迟
• 队列积压和连接池耗尽
• 池中的单个故障主机行为
• 降级模式响应和过期数据回退
• 限流处理、Retry-After 和客户端退避预期
• 恢复或后端重置后可见状态的收敛
• 故障转移和故障恢复行为
• 亚稳态故障：一种自我维持的反馈循环（重试放大、缓存未命中导致的请求风暴、队列积压、连接池反复抖动），即使原始触发因素消失，也不会自行恢复——参见 references/cascading-failure-prevention.md

---

测试阶梯

优先进行确定性测试

• 在受控测试中注入延迟、错误、超时、格式错误的负载和不可用端点
• 验证预期的控制措施会启动，且错误的控制措施不会启动

其次进行混沌测试

• 从非生产环境开始
• 控制影响范围并设定固定的时间窗口
• 一旦错误预算或客户影响超标，立即停止

最后进行灾难恢复和演练

• 明确验证 RTO 和 RPO 声明
• 演练恢复职责，而不只是技术故障转移

---

运营护栏

• 每项实验都需要明确的假设和稳态指标
• 每次运行都应记录时间戳、目标、影响范围和仪表盘链接
• 重试、断路器状态转换、对冲、卸载和回退的遥测字段都属于弹性契约的一部分
• 发布应以可靠性行为作为门槛，而不应只看资源使用情况

反模式

• 没有超时
• 每一跳都重试
• 固定间隔重试或无限重试
• 每次调用的重试次数固定，且没有全系统重试预算（错误率上升时不会收紧）
• 重试操作不具备幂等性
• 对不安全的写入进行对冲
• 没有舱壁隔离或队列上限
• 深度就绪或存活检查
• 静默降级模式
• 未经测试的故障转移计划
• 仅进行正常路径负载测试

---

脚本

脚本	用途
scripts/resilience_checker.py	对声明的模式覆盖情况进行评分并报告缺口；拒绝格式错误的声明

典型用法：

python scripts/resilience_checker.py assess --input data/sample-service-profile.json
python scripts/resilience_checker.py gaps --input data/sample-service-profile.json
python scripts/resilience_checker.py report --input data/sample-service-profile.json --output resilience-report.md

请提供实际的 JSON 布尔值，并明确说明对冲不适用的理由。启发式评分描述的是声明的覆盖情况；它不能证明故障行为或恢复能力。有关输入格式和评分逻辑，请参阅 scripts/README.md。

ASCII 流程图

Resilience request
  -> Identify failure mode: slow, transient, sustained, overloaded, or degraded
  -> Set deadlines, retry budgets, isolation, and fallback ownership
  -> Add telemetry for saturation, errors, latency, and degraded behavior
  -> Validate with deterministic fault injection before chaos experiments
  -> Gate release on recovery evidence, SLO impact, and rollback path
  -> Document runbook actions and residual risk

导航

应用基础方案

• references/reliability-theory-applied.md
• references/distributed-systems-applied.md

核心参考资料

• references/circuit-breaker-patterns.md
• references/retry-patterns.md
• references/timeout-policies.md
• references/deadlines-hedging.md
• references/bulkhead-isolation.md
• references/load-shedding-backpressure.md
• references/gateway-mesh-resilience.md
• references/graceful-degradation.md
• references/health-check-patterns.md
• references/cascading-failure-prevention.md
• references/disaster-recovery-testing.md

运维资源

• references/resilience-checklists.md
• references/chaos-engineering-guide.md
• references/chaos-tooling-recipes.md
• references/idempotency-key-design.md
• references/resilience-telemetry.md
• references/slo-as-code.md
• references/ai-llm-resilience-failure-modes.md
• assets/runbooks/resilience-runbook-template.md
• assets/testing/fault-injection-playbook.md
• assets/testing/template-resilience-test-plan.md
• data/sample-service-profile.json

相关技能

• ops-devops-platform
• software-backend
• software-architecture-design
• qa-observability
• qa-debugging
• software-security-appsec
• data-sql-optimization
• dev-api-design

经验总结循环

如果以往的决策或陷阱与当前情况相关，请在 learnings.consolidated.md 存在时查阅；仅在需要了解历史或其为可用替代项时使用 learnings.md。否则跳过两者。

应用后，如果遇到值得记住的模式、值得避免的错误，或令你意外的领域事实，请通过 agents-skills-feedback-loop/scripts/append_learning.py 向 learnings.md 追加一条带日期的项目。不要修改 SKILL.md 本身。