用途
当目标不是验证数据系统“一切正常时能跑通”，而是证明它在故障下能够安全恢复时，使用本技能。它帮助智能体为数据平台设计受控的韧性演练，覆盖重试、重启、依赖中断、状态恢复、重复数据防护、积压追赶和发布保护等场景。
何时使用
- 在广泛上线前对生产管道进行加固
- 测试故障转移、重启、重放或检查点恢复行为
- 验证重试不会导致数据重复或损坏
- 为编排器、作业、流处理或数仓发布证明恢复目标
- 将过去的事故转化为可重复的韧性演练
注意：韧性测试不是随机破坏。重点是在明确的安全边界和证据下验证恢复行为。
工作流程
-
定义重要的故障模式。优先考虑：源中断或上游延迟交付；工作进程或任务重启；编排器重试与超时行为；重复事件或重复文件交付；检查点或增量状态恢复；凭证、密钥或网络依赖故障；部分发布或下游不可用。
-
定义韧性目标。包括：可接受的数据丢失行为；恢复时间目标；重放或积压追赶预期；重复数据防护要求；发布阻断或隔离行为；告警与升级预期。
-
选择最安全的演练环境。优先使用：预发或隔离的非生产环境；金丝雀数据集或分区；合成或脱敏测试数据；有界窗口且可回滚的测试范围。
-
一次只注入一种故障模式。使用受控演练，例如：杀死任务或工作进程；暂停上游依赖；延迟输入到达；重放重复输入；在安全环境中强制使用过期密钥或拒绝权限；模拟部分输出并验证发布关闭。
-
验证恢复路径。检查：系统是恢复还是安全失败；告警是否携带有用上下文触发；重复数据是否被阻止；积压追赶是否保持有界；发布是否在验证通过前保持阻断。
-
记录护栏并自动化最高价值的演练。最好的韧性测试是团队在变更后可以重新运行的测试，而不是一次被遗忘的练习。
按故障模式加载配套技能
- 重放或回填演练：safe-backfill-and-replay-orchestration
- Kafka 延迟、死信队列或模式漂移：kafka-resilience-and-schema-evolution
- 无服务器 Spark 检查点恢复：spark-serverless-reliability-and-state-management
- 演练前的实时诊断：mcp-data-observability-integration
- 演练模式：references/data-resiliency-testing-patterns.md
常见合理化借口
- “如果作业会重试，我们就足够有韧性了。”——仅靠重试并不能证明重放安全、重复数据防护或发布保护。
- “我们可以在真实事故中测试恢复。”——真实事故是最不适合发现恢复路径不清晰或不安全的时机。
- “对数据系统做故障注入太冒险。”——不受控的故障比在安全环境中进行有界、可审查的演练风险更大。
- “调度器健康页面已经证明了韧性。”——调度器状态不能证明数据正确性、积压追赶或下游安全。
危险信号
- 不存在按优先级排列的故障模式清单
- 启用了重试但没有幂等性证明
- 韧性演练没有回滚或爆炸半径限制
- 检查点或增量状态恢复从未被测试过
- 告警触发了但恢复责任人不明确
- 过去的事故没有对应的回归演练
验证清单
- 高影响故障模式已被命名并排定优先级
- 恢复目标和可接受的失败行为已明确
- 演练范围有界且可安全运行
- 恢复证据覆盖告警、重放安全、重复数据防护和发布保护
- 至少一个源自事故的故障模式已转化为可重复演练