S81：系统失败场景：Timeout、重复消息、数据过期、权限与人工 Backlog

内容类型：预习教材（不代表已完成）
日期：2027-02-11
阶段：P2 · AI Systems Engineering 90
总路线：Day 171
周次节奏：W12 · 周四案例与连接
状态：教材已备；学习未完成

一句话定义

系统工程的失败分析不是为每个异常加 retry，而是分清“状态未知、副作用重复、输入已失效、行动未授权、人工容量不足”的不同处理与证据。

学习目标

1. 从五类失败中选两类，画 trigger→state→detection→handling→residual risk。
2. 区分 retryable、non-retryable、unknown outcome、needs reconciliation 与 requires human decision。
3. 将失败语义映射到 S79/S80 的最小路径，不搭建完整容错平台。

核心知识

Timeout 只说明调用方未在预期时间获得回应，不说明下游未执行。只读检索可能安全重试，但创建工单、发邮件、扣款或广播交易必须使用 idempotency key 与 status query/reconciliation。超时后盲目 fallback 到第二 provider 也可能让两路同时产生副作用。

重复消息 是 at-least-once delivery 中的正常情况，不是意外。去重必须基于业务操作 id，而不只是运输 message id；如果 retry 生成新 message id，运输去重会失效。幂等记录需 retention window，窗口过短可能将迟到重放当成新操作。

数据过期 不是系统 exception，但可能比显式失败更危险。artifact 需 observed_at、valid_until、source version 和 refresh policy。不同数据的新鲜度要求不同：产品规则可按天，余额、nonce、gas 或风险状态可按秒/分。数据 stale 时可 refresh、degrade-to-read-only、escalate 或拒绝，不应默默继续。

权限失败 要区分 unauthenticated、unauthorized、scope/purpose mismatch、approval missing/expired 和 policy unavailable。policy engine 不可用时，高风险动作应 fail closed；但读取公开非敏感数据可按明确策略降级。不可把“重试更多次”当成权限错误的修复。

Human backlog 是一种运行时依赖失效。当 oldest age 接近决策 expiry，可以减少新升级、关闭高自动风险动作、分流给合适技能或向用户明确延迟，不能用自动通过来“清队列”。

机制与推导

对每个 failure 使用五元组：(known_state, side_effect, retry_policy, evidence, human_action)。例如 timeout 可能是 (unknown, possible, reconcile-before-retry, request/idempotency/status trace, investigate)。一个通用退避 delay=min(cap, base×2^attempt)+jitter 只处理短暂资源故障，不处理 invalid input、permission denied 或 stale evidence。

最小练习或观察

1. 在 timeout、duplicate、stale、permission、backlog 中选两个，不全部实现。
2. 对每个画 sequence，标出故障前已知状态、不确定状态与副作用。
3. 填 detection signal、handling、stop condition、safe fallback 与 residual risk。
4. 如果用 toy code，只加一个故障注入点，使用 no-op 外部工具和合成数据。
5. 不运行时将结果留空；设计符合逻辑不等于处理已验证。

常见误区与边界

• 对所有错误使用相同 retry，将权限、过期与永久错误变成风暴。
• timeout 就认为下游未执行，造成重复副作用。
• 用运输 message id 当业务幂等键，无法防止重新发布的同一操作。
• 数据 stale 时保持绿色“正常”界面，让用户无法知道证据时间。
• toy fault 的正确处理不证明分布式故障、恢复与安全已完成。

系统 / 金融 / Web3 连接

支付与工单场景中，超时后必须查业务状态，不能盲目再提交。Web3 交易在签名或广播后超时，需用 tx hash/nonce/chain 查询与对账；旧 simulation 或过期 approval 不应继续使用。AML 工单的 human backlog 还受法定时限影响，不能只用技术队列指标处理。

自检问题

1. timeout 后的系统状态为什么是 unknown 而非 failed？
2. 业务幂等键与运输 message id 有何不同？
3. stale data 应触发哪些不同降级？
4. 哪些 failure 绝不应靠增加 retry 次数处理？

专业课程对齐

• Temporal Documentation：精读 retries、timeouts、workflow/activity 状态、signals 和 durable execution，校准 unknown outcome 与恢复。
• Google SRE Book：精读 handling overload、addressing cascading failures、monitoring 与 incident response，映射 backlog/retry storm。
• OWASP GenAI Security Project：选读 excessive agency、prompt injection 与 sensitive information disclosure，审查权限失败与 tool side effect。

深入学习提示

选 timeout/duplicate 则主读 Temporal，选 backlog 则主读 SRE，选 permission 则主读 OWASP。深挖时不是找“最佳实践”，而是对一个故障说清当时已知/未知状态、可能副作用和恢复证据。

学后填写区

• 选择的两个失败场景：
• state / side effect / retry 语义：
• detection / handling / fallback：
• 实际观察（未运行留空）：
• residual risk：