第 17 周：让依赖故障进入安全降级路径

直接答案： 第 17 周不是再增加一种 AI 能力，而是让故障成为系统的正常状态。模型超时、索引过期或 MCP 不可用时，用户必须得到明确、权限安全、可以继续人工处理的结果；系统不能返回一段貌似正常的答案，也不能盲目重试写操作。

为什么“报错”不等于安全失败

服务器返回错误，只说明某个技术步骤没有正常完成。FDE 还要回答四个更接近一线工作的问题：

用户正在完成的任务现在是什么状态？
系统有没有给出未经验证的答案或产生未授权效果？
用户下一步能做什么，谁负责接手？
依赖恢复后，怎样证明业务任务真的恢复，而不只是进程重新启动？

本周使用的最小模型是：

依赖故障
  → 分类：瞬时 / 确定性 / 权限拒绝 / 结果不明确
  → 选择：重试 / 降级 / 停止 / 对账
  → 写入用户可见任务状态
  → 恢复后重跑任务并核对真实结果

先看完成品：北辰系统的三类故障

以下任务、版本和运行结果都是固定教学模拟。

故障	系统终态	一线员工看到什么	系统绝不能做什么
模型超时	partial / search_only	已经过权限过滤的来源列表和人工升级入口	生成未经验证的答案或调用写工具
索引过期	abstained	“当前资料无法确认”，以及知识所有者入口	使用陈旧缓存装作正常回答
MCP 不可用	action_preview	保留工单预览，并说明尚未创建	宣称创建成功或无限重试

MCP 故障的完整结果示例：

task_run_id: northstar-w17-0042
task_state: action_preview
reason_code: mcp_unavailable
answer_state: abstained
allowed_next_actions:
  - copy_preview
  - submit_manually
  - retry_later
external_effect_count: 0

这个结果是合格的，因为它没有隐藏失败，也没有扩大权限。HTTP 200 加一段“工单已经创建”的文字，即使界面更顺滑，也是失败结果。

第一步：写故障行为合同

复制下面的结构，为三类依赖各填一行：

# 故障行为合同 v1

| 依赖 / 故障 | 影响的用户任务 | 可重试？ | 安全终态 | 用户下一步 | 关闭开关 | 恢复验证 |
| --- | --- | --- | --- | --- | --- | --- |
| MCP 不可用 | 创建主管复核单 | 否，先保留预览 | action_preview | 手工提交或稍后再试 | MCP_OFF | 重跑预览与一次获批创建 |

决策规则

瞬时只读失败可以进行有次数和时限的重试；
确定性错误先修正输入，不自动重试；
权限拒绝保持拒绝，不能切换成宽松备用路径；
写入结果不明确先进入 reconciling，查询实际状态；
任何降级路径继续执行原有 ACL、审批和审计。

第二步：独立实现一种降级

本周只要求你独立实现一种。推荐选择 MCP 不可用，因为它同时训练用户提示、关闭开关和“没有外部效果”的核验。

你的实现必须产生以下可观察结果：

输入：已生成、但尚未执行的工单预览
注入：MCP Server 不可达
预期：
  - 任务停在 action_preview
  - 不调用写入重试
  - external_effect_count = 0
  - 用户能复制预览或回到人工流程
  - trace 中记录 mcp_unavailable

模型和索引故障使用完成示例进行观察与固定演练；不要在同一周独立重写三套恢复机制。

第三步：用任务结果验证恢复

恢复依赖后，依次检查：

原来的关闭开关已按批准方式复位；
正常任务能再次完成；
受限任务仍然拒绝；
原故障任务没有重复效果；
同一个任务运行标识或关联记录能还原故障、降级和复验；
普通日志没有提示全文、政策正文、凭据或审批载荷。

只检查进程、端口或健康接口，不算完成恢复。

五天安排

学习日	建议时间	当天动作	离开前必须有的结果
第 1 天	1–2 小时	比较三类故障，完成行为合同	每类故障都有安全终态和禁止行为
第 2 天	2 小时	独立实现 MCP 超时、预览降级和关闭开关	有一个可以注入的故障路径
第 3 天	1–2 小时	运行模型与索引的固定演练	保存三类任务终态
第 4 天	2 小时	用运行标识核对权限、日志、效果和恢复	有故障前后对账记录
第 5 天	1–2 小时	编写一份 runbook，完成迁移和三层说明	非作者能按步骤复现你的故障

本周验收

学习者独立实现了一种安全降级；
三类故障都进入预定义终态，没有无限重试；
权限拒绝、确定性错误和结果不明确采用不同动作；
降级路径没有绕过 ACL、审批或审计；
写入结果不明确时先查询或对账；
任务运行标识可以还原故障、降级、恢复和最终状态；
恢复后重跑了用户任务，而不只检查服务；
普通日志没有秘密或敏感正文；
所有结果明确标为教学或授权环境证据。

常见失败与修复

失败	诊断信号	修复动作
所有错误都重试	权限拒绝也反复调用	先按四类错误重新分类
备用搜索绕过权限	fallback 能看见更多来源	使用同一个 ACL 查询层
仪表盘变绿就结束	没有重跑用户任务	重新执行正常、拒绝和升级路径
MCP 故障仍显示成功	用户看到工单编号，但外部系统没有记录	保留预览，改为未执行状态
runbook 从未演练	步骤看似完整，但缺 trace 与结果	实际注入一次并保存复验证据

独立迁移：供应商 API 结果不明确

供应链系统向供应商提交了加急请求，随后连接中断。请写出：

为什么不能立即重新提交；
系统应进入什么任务状态；
用什么业务键查询供应商状态；
哪些结果允许标记完成，哪些必须人工接管；
如何证明没有重复采购效果。

如果你的答案只有“重试三次”，说明还没有区分瞬时失败和结果不明确。

用同一份证据向三类人解释

老板版： 哪些故障仍允许有限服务，哪些必须停止；人工兜底增加多少负担目前是事实、假设还是未知。
一线版： 故障时能做什么、不能做什么、怎样核验、复制预览或升级。
工程版： 故障如何注入、分类、追踪、降级、对账和恢复。

下一步

通过后进入第 18 周：把服务交给别人运行。下一周不会重新设计故障机制，而是让非作者使用你已经演练过的关闭开关和 runbook。

来源与事实边界

Google SRE — Monitoring Distributed Systems：以用户症状和服务行为观察系统，而不是只看内部组件。
MCP Security Best Practices：授权、会话、令牌和远程服务器风险参考。
OpenTelemetry — Generative AI semantic conventions：生成式 AI 追踪字段参考；实现时需要核对字段稳定级别。

核验日期：2026-08-25。 本周故障场景、状态名、时间安排和验收门是课程教学设计，不是生产 SLO 或行业统一标准。北辰公司、任务和运行结果均为合成材料。