故障演练、项目接管与能力沉淀
一句话收获：项目交付完成于系统、材料、权限和人员能力同时可接管。
这个场景在解决什么问题
目标（goal）是证明新接管者能独立诊断、停止、恢复和回滚——也就是证明"换个人来，不看原开发者，也能把系统管起来"。
观察方式（observation）是：原开发者退出即时指导，接管者只使用正式材料。原开发者不站在旁边手把手教，接管者只能靠正式的文档、看板、故障库这些材料自己干。
这个场景值得单独学，是因为"交付完成"最容易被误判成"我把代码和文档交给你了，就算完事"。但实际上，项目真正交付完成的标志，是系统、材料、权限、人员能力这四样同时能接管。少了任何一样，都只是"看起来交出去了"。
先理清这条判断链（文字版）
这条链是"用一场真实故障，逼出新接管者的独立能力，再把经验留下来"：
- 先安全故障注入：在授权环境里，故意制造模型不可用、权限拒绝、知识冲突、结果未知这类故障，先定义好预期行为和停止条件；
- 再让接管者定位：新人员只靠运行看板、Trace、健康检查、故障库自己定位问题，原开发者不即时指导；
- 然后停止、恢复或回滚：接管者自己选正确的处理机制并执行，再验证残留副作用、重新跑关键验收；
- 最后沉淀组织能力：把部署手册、测试集、故障库、Skill、责任矩阵按正确的载体更新，让一次经验变成可复用的能力。
一句话：注入安全故障 → 新人独立定位 → 新人独立处置 → 沉淀成可复用能力。全程原开发者"闭嘴"，用真实演练验证接管。
逐层详解
第 1 步：安全故障注入
原文：在授权环境制造模型不可用、权限拒绝、知识冲突或结果未知。
白话：在事先授权、影响受控的环境里，人为制造几类典型故障：模型服务不可用、权限被拒绝、知识检索结果冲突、任务结果未知。这是"演习"，不是去搞坏生产。
类比：像消防演习——不是真放火烧楼，而是在安全、受控的场景里模拟火情，训练大家怎么应对，而且提前说好什么时候停止、怎么恢复。
举例：在测试环境里，故意把模型推理服务的路由指到一个不存在的端口（模拟模型不可用），或者临时收窄一个账号的权限（模拟权限拒绝），看接管者能不能发现并处理。注入前先写清楚：预期行为是什么、影响范围控制在哪、停止条件是什么、恢复步骤是什么。
为什么重要：故障演练验证异常路径而不是破坏生产。它的目的不是搞破坏，而是在不碰生产的前提下，验证异常路径下系统和人能不能扛住。
怎么验证（证据点）：
- 影响范围受控：故障只影响授权的测试范围；
- 停止条件：预先定义好什么时候停止演练；
- 恢复步骤：有清晰的恢复步骤能退出演练。
别踩的坑（边界）：只演示正常路径不能证明现场韧性。只在"一切正常"的情况下演示一遍，证明不了真出故障时系统和人能扛住。
落地检查：每次注入先定义预期行为。每次注入故障前，先写清楚"注入后系统应该表现出什么行为"，否则演练完也不知道结果对不对。
第 2 步：接管者定位
原文：新人员使用运行看板、Trace、健康检查和故障库定位问题。
白话：让新接管者靠自己，用运行看板（dashboard）、Trace（调用链追踪）、健康检查、故障库（记录过的历史故障）这些工具和材料，自己找出问题在哪。原开发者不许在旁边提示答案。
类比：像换了个新机修工，只给他维修手册、仪表盘和故障记录本，让他自己判断车哪儿坏了——而不是老师傅直接告诉他"就是那个火花塞坏了"。
举例：接管者发现某个 Agent 请求超时，自己打开运行看板看指标、翻 Trace 定位到"模型服务调用失败"这一环、跑健康检查确认模型服务挂了、再去故障库里查"模型不可用"这条历史记录对应的定位方法。全程原开发者不插手。
为什么重要：接管能力依赖可观察系统和可执行材料。新人能不能接手，取决于系统有没有可观察性（看板、Trace、健康检查）和材料可不可执行（故障库、手册），而不是靠某个老员工脑子里的经验。
怎么验证（证据点）：
- 故障位置：接管者能定位到故障具体在哪；
- 证据依据：定位有证据支撑（不是猜的）；
- 合法选项：给出的处理选项是合法、可执行的。
别踩的坑（边界）：口头告诉答案不构成接管测试。如果原开发者在旁边口头提示"问题就在 XX"，那这次定位不算数，因为接管者的真实能力没被验证。
落地检查：原开发者不即时指导。演练时原开发者要退出即时指导，只提供正式材料，才能真正测出接管能力。
第 3 步：停止、恢复或回滚
原文：接管者选择正确机制并验证残留副作用。
白话：定位完之后，接管者要自己判断该用哪种处理方式——是停止、恢复、还是回滚——并亲手执行，执行完还要检查有没有残留副作用（比如脏数据、没清理的状态）。
类比：像医生诊断完要自己开方动手——不是只说出"你发烧了"，还要决定是吃药、打针还是观察，并跟踪疗效和副作用。
举例：接管者判断"模型服务不可用"应该回滚到上一版模型路由，于是自己执行回滚，然后检查有没有残留副作用（比如半截任务、脏数据），再重新跑一遍关键验收确认业务恢复。
为什么重要：真正接管包含决定权和执行能力。光会定位问题不算接管，敢拍板选方案、能亲手执行、会检查副作用，才是真正的接管。
怎么验证（证据点）：
- 停止确认：停止操作被确认生效；
- 恢复证据：有证据证明业务已恢复；
- 业务影响清单：列出这次故障对业务的影响范围。
别踩的坑（边界）：命令执行成功不证明业务已经恢复。回滚命令跑成功，只是"动作做了"，不代表业务真的恢复了，必须重新验证业务结果。
落地检查：重新运行关键验收。处理完之后，重新跑关键验收任务，用结果证明业务恢复，而不是只看命令成功。
第 4 步：沉淀组织能力
原文：部署手册、测试集、故障库、Skill 和责任矩阵按正确载体更新。
白话：把这次演练踩到的坑、学到的经验，回写到正确的地方：部署手册、测试集、故障库、Skill（可复用的技能/流程）、责任矩阵。注意"正确载体"——不是随便写一篇长文档，而是更新到对应的、能被下次复用和追踪的地方。
类比：像厨师做完新菜要把配方写进菜谱本——不是随手记在纸巾上，而是更新到分类清楚、下次能照着做的正式菜谱里，这样别人才能照着复现。
举例：这次发现"模型不可用"这个故障的定位和回滚方法很有价值，就把它更新进故障库；把漏掉的部署步骤补进部署手册；把回滚流程固化成一条 Skill；在责任矩阵里明确谁负责模型路由。下次再有新人，直接照着这些材料就能干。
为什么重要：一次项目经验需要经过复用才能成为能力。经验本身不自动等于能力，只有被整理进正确载体、能被下一次复用，才沉淀成组织的能力。
怎么验证（证据点）：
- 材料与现状一致：手册、测试集、故障库和当前系统现状对得上；
- 版本可追踪：这些材料的版本能追溯；
- 第二环境可复用：拿到第二套环境也能照着复用。
别踩的坑（边界）：把所有经验写成长文档不会自动形成能力。堆一篇超长文档，没人看、没人维护、找不到，那不叫能力沉淀，反而可能变成"废文档"。
落地检查：以可重复交付和独立接管收束课程。整个课程要收在"能重复交付 + 能独立接管"这个结果上，而不是收在一堆文档上。
落地可行性小结
这个场景涉及的技术栈和真实落地要点：
- 安全故障注入：用 Chaos Engineering（混沌工程）工具或手动注入（改路由、收权限、造脏数据）模拟故障，务必在授权测试环境进行，先定义预期行为、影响范围、停止条件、恢复步骤。
- 可观察性：运行看板（如 Grafana）、Trace（如 OpenTelemetry / Langfuse）、健康检查、故障库，是接管者独立定位问题的基础设施。
- 处置能力：停止、恢复、回滚要能被接管者独立执行，验证残留副作用后再跑关键验收。
- 能力沉淀：部署手册、测试集、故障库、Skill、责任矩阵按正确载体更新，做到"与现状一致、版本可追踪、第二环境可复用"。
- 常见坑：只演示正常路径、口头提示答案、命令成功就当作业务恢复、把经验堆成没人看的长文档。
- 落地动作：故障演练全程原开发者退出即时指导；接管者用正式材料独立定位、处置；事后把经验回写到对应载体，而非另写一篇长文档。
回顾
- 项目交付完成于系统、材料、权限、人员能力四样同时可接管，缺一不可。
- 故障演练要在授权环境做，先定义预期行为和停止条件，只演示正常路径证明不了韧性。
- 接管者定位必须"原开发者不即时指导"，口头给答案不算接管测试。
- 处置后命令成功≠业务恢复，要重新跑关键验收；经验要沉淀进正确载体（手册/测试集/故障库/Skill/责任矩阵）才能成为可复用能力。