第 10 章 故障演练与 STAR 叙事

监控能发现故障，但发现之后呢？前面九章我们建了 IO 栈心智、存储数学、网络、GPU、推理、调度、监控——这一章把所有这些串成”面对故障的能力”：主动制造故障验证系统（混沌工程）、复盘提炼经验、最后把一次故障讲成面试里最有说服力的故事。这章是全书收尾，也是大概念 B4（故障是常态，可靠系统是”可检测、可隔离、可自愈”）与迁移目标 T3（把真实故障讲成结构化的 STAR 故事）的最终落点。

本章学习目标

读完本章，你应该能：

1. 设计并执行一次故障演练（故障注入 → 观察 → 复盘），产出 MTTD/MTTR 报告。
2. 复盘一次故障，提炼出可复用的 runbook 与告警改进项。
3. 把一个真实（或高度仿真）故障写成结构化的 STAR 面试故事，每环节有量化证据。

10.1 概念讲解

为什么故障要”演练”

“演练过的故障和没演练过的故障是完全不同的故障。”没演练过：故障发生时团队现场救火、反应慢、还可能做出错误决策。演练过：故障发生时按 runbook 走，知道每一步预期结果，MTTR 大幅缩短。大概念 B4 的落地——可靠的系统不是”不出故障”，而是”故障发生时知道怎么做”。

混沌工程：主动制造故障

混沌工程（chaos engineering）是在受控环境下主动注入故障，验证系统韧性。AI 集群常见的注入点：

故障注入	工具	验证什么
GPU 掉线（Xid 79）	物理/模拟	训练能否 checkpoint 恢复
网络延迟/丢包	chaos-mesh NetworkChaos	NCCL 是否降速/重试
存储慢 IO	chaos-mesh IOChaos	数据加载是否卡死
Pod 被杀	chaos-mesh PodChaos	调度能否快速重建
Ceph OSD down	手动 ceph osd down	恢复时间/数据可用性

混沌工程的四个原则（来自 Netflix 混沌工程原理，面试可引）：

1. 先定义”稳态”：在注入前，先明确”系统正常”长什么样（如训练 step 2s、p99 延迟 100ms）——没有基线就无法判断故障影响；
2. 假设会被打破：用实验验证假设（”我们认为 Xid 79 时训练能在 10 分钟恢复”），而不是想当然；
3. 在生产环境做最小实验：先小范围（1 台、1 个 job）注入，验证无大碍再扩大——避免一次搞挂整个集群；
4. 自动化持续运行：把演练做成自动化的（定期跑），而不是想起来才做——故障处理能力需要持续保持。

💡 常见坑：演练不是”搞破坏”。每次演练必须有明确的验证目标（”验证 Xid 79 时训练能在 10 分钟内从 checkpoint 恢复”），演练后必须复盘，否则演练只是给系统添乱。

故障复盘：MTTD/MTTR

复盘的核心指标：

• MTTD（Mean Time To Detect）：从故障发生到被发现的时间——由监控告警质量决定（呼应第 9 章）；
• MTTR（Mean Time To Repair）：从被发现到恢复的时间——由 runbook 与预案决定。

完整公式（把 MTTR 拆解）： \(\text{MTTR} = \text{检测}(MTTD) + \text{定位} + \text{隔离} + \text{重建}\)

• 检测（MTTD）：告警质量决定——for 设多长、覆盖哪些指标（第 9 章）；
• 定位：有没有 runbook——没有 runbook 靠现场摸索，定位可能占 MTTR 一大半；
• 隔离：cordon 节点 / 停 job / 切流量——让故障不再扩散；
• 重建：从 checkpoint 恢复 / 重建 pod——取决于 checkpoint 频率与重调度策略。

复盘的输出：时间线（检测 → 定位 → 隔离 → 恢复 → 复盘）、每个环节耗时、改进项（补告警 / 补 runbook / 改流程）。把 MTTR 拆成四段后，就能逐段优化（见例 10-3）——这是复盘比”看个总时长”更有价值的原因。

STAR 叙事：把故障讲成故事

面试讲故障用 STAR 结构：

• S（Situation）：业务上下文，什么痛点；
• T（Task）：你要解决什么；
• A（Action）：你做了什么技术选择（1-2 个关键决定）；
• R（Result）：量化结果（前后对比）。

关键：R 必须有数字——”MTTR 从 2 小时降到 30 分钟”“故障停摆 2 小时，后续 2 次同类问题都 30 分钟内处理”。没有数字的故事没有说服力（大概念 B5：不能量化的无法被验证）。

10.2 示范例题

例 10-1：设计一次故障演练【Bloom：创造】

题目：为一个 100 卡训练集群设计一次”GPU 掉线恢复”演练，包含目标、步骤、观察点、验收标准。

解：

目标：验证单个 worker 的 GPU 掉线（Xid 79）时，训练能在 15 分钟内从最近 checkpoint 恢复。

步骤：

1. 准备：确认训练已启用周期性 checkpoint（每 30 分钟），记录当前 checkpoint 时间；
2. 注入：模拟 GPU 掉线（如 nvidia-smi -r 或拔卡/断 PCIe）；
3. 观察：记录从注入到告警触发的时间（MTTD）；
4. 恢复：确认调度器重调度该 worker、从 checkpoint 续训；
5. 复盘：记录从告警到训练恢复的时间（MTTR），比对验收标准。

观察点：告警是否触发（哪个规则）、worker 是否被杀、job 是否重排队、续训是否成功、是否有数据丢失。

验收标准：MTTD ≤ 2 分钟、MTTR ≤ 15 分钟、训练从最近 checkpoint 恢复且无数据丢失。

回顾：这道题用到了”目标 → 注入 → 观察 → 验收”的演练设计闭环。

验证：✅ 已验证（核对来源：混沌工程实践方法（Netflix chaos engineering 理念）与训练 checkpoint 容错机制；此为设计题）

例 10-2：写一个 STAR 故事骨架【Bloom：创造】

题目：把”NCCL hang 导致训练停摆”写成 STAR 骨架，每环节给出需要填的量化项。

解：

• S：公司训练 70B 模型，32 卡集群，某晚训练卡住，所有 GPU 利用率归零；
• T：作为 oncall，需要在 2 小时内恢复训练并找出根因；
• A：按”先网络后软件”排查——NCCL_DEBUG=INFO 定位 rank，ibstat 发现某节点 IB 卡 link 为 Polling 而非 Active，机房查实是一根光纤被碰松；重插后恢复；事后加 IB link 告警；
• R：首次故障 2 小时恢复；加告警后，后续 2 次同类问题都在 30 分钟内处理；MTTR 从 2h → 30min。

要点：每个环节都要有可验证的数字（卡数、时长、次数），并把”技术动作 + 量化结果”绑在一起——这就是有说服力的 STAR。

回顾：这道题用到了 STAR 结构 + 量化——R 必须有前后对比数字。

验证：✅ 已验证（核对来源：STAR 面试叙事方法；故障案例为典型 NCCL hang 场景，技术细节已在第 5 章验证；此为叙事框架题）

10.3 引导练习

例 10-3：复盘的输出【Bloom：分析】（引导练习）

题目：一次 Ceph OSD down 故障，从发生到恢复耗时 3 小时。复盘发现：告警在 30 分钟后才触发（MTTD=30min），定位 OSD 花了 1 小时，恢复 backfill 花了 1.5 小时。分析三个环节各能优化什么。

提示 1（方向）

把 3 小时拆成 MTTD（检测）+ 定位 + 重建三段，逐段看优化空间。

提示 2（关键步骤）

MTTD 长 → 改告警；定位长 → 补 runbook；重建长 → 看能否提速 backfill。

完整解答

1. **MTTD = 30 分钟**（检测时延）：太长——OSD down 应立即告警（`for: 1m` 而非默认阈值）。优化：加 OSD down 告警规则，目标 MTTD ≤ 2 分钟； 2. **定位 = 1 小时**（决策时延）：没有现成 runbook，现场摸索。优化：补"Ceph OSD down 定位 runbook"（ceph health detail → 找 PG stuck → 查 OSD 状态），目标定位 ≤ 10 分钟； 3. **重建 = 1.5 小时**（重建时延）：backfill 受并发限制。优化：评估提高 `osd_max_backfills`（权衡对线上性能影响），或扩容分散 PG。 **结论**：总 MTTR 从 3h 拆解后可分别优化三段，目标压到 30 分钟内——这就是复盘的价值：把"3 小时"拆成可优化的环节。 **验证**：✅ 已验证（核对来源：Ceph OSD down 排查标准流程与 backfill 参数（docs.ceph.com osd-config-ref）；MTTD/MTTR 定义为运维通用概念；此为复盘分析题）

例 10-4：演练 vs 真故障【Bloom：评价】（引导练习）

题目：某团队演练记录：网络断演练中 MTTR 45 分钟；但一次真实网络故障却花了 3 小时。分析演练与真实的差距来源，并说明如何缩小。

提示 1（方向）

演练是"知道要发生什么"，真实故障伴随未知（告警噪声、其他系统连锁反应）。

提示 2（关键步骤）

差距来自：演练没覆盖的未知、告警没覆盖的指标、跨团队沟通。

完整解答

差距来源： 1. **演练是"定向"的**：预先知道注入什么、看什么，真实故障是未知的（可能是多条故障叠加）； 2. **告警覆盖不全**：演练验证的路径有告警，真实故障可能触发的是没演练过的指标； 3. **连锁反应**：真实故障常引发二次故障（如网络断了存储也受影响），演练没覆盖； 4. **跨团队沟通**：真实故障要协调多团队，沟通成本在演练中没体现。 缩小差距的方法：1) 演练覆盖更多故障组合（不只单点）；2) 用"故障注入 + 告警触发验证"把监控盲区补上；3) 演练纳入跨团队协作；4) 演练后更新 runbook 覆盖真实场景。 **验证**：✅ 已验证（核对来源：混沌工程实践（演练与真实故障差距的普遍认知，Netflix 混沌工程文献）；此为评价推理题）

10.4 独立习题

习题 10-1【Bloom：评价】

题目：一次 GPU 掉线故障 MTTR 为 4 小时。复盘发现：告警 10 分钟后触发（MTTD=10min），但没人会处理 Xid 79、等了 2 小时才找到有经验的人，重建 job 花了 1.5 小时。分别指出三个环节的优化空间，并给出目标 MTTR。

习题 10-2【Bloom：创造】

题目：为一个 AI 集群设计一次”网络延迟注入”演练（验证 NCCL 在延迟下的表现），包含目标、注入工具、观察点、验收标准。

习题 10-3【Bloom：创造】

题目：把第 5 章的 NCCL hang 排查（例 5-4）改写成一段 STAR 面试叙事骨架：给出 Situation / Task / Action / Result 各一段，Action 里包含至少一个技术决定，Result 里包含前后对比的数字。

习题 10-4【Bloom：创造】

题目：结合全书所学，为一个”新入职 AI Infra 工程师”写一份”第一周学习路线”（不超过 8 条），每条对应本书一章的关键能力，并说明为什么要先学那条。

本章小结

核心结论：

1. 演练过的故障和没演练过的完全不同——可靠系统靠”预案 + 演练”，不是靠运气。
2. 混沌工程在受控环境注入故障，必须有明确目标与复盘，不是搞破坏。
3. 复盘拆解 MTTR = MTTD（检测）+ 定位 + 重建三段，逐段优化。
4. STAR 叙事：S/T/A/R 四段，R 必须有前后对比的量化数字。
5. 全书主线回顾：IO 栈 → 存储 → 网络 → GPU → 推理 → 调度 → 监控 → 故障，从”数据怎么走”到”故障怎么办”。

与持久理解的呼应：本章推进了「学生将理解：一切性能与可靠性承诺都必须能量化验证」——用 MTTD/MTTR 量化演练结果、用 STAR+数字量化面试叙事，把”量化验证”这条贯穿全书的主线收束。

自检：回到章首学习目标，逐条问自己做到了没有——

• 设计并执行一次故障演练并产出 MTTD/MTTR 报告 → 拿不准就重读 10.1，自测：习题 10-2
• 复盘故障提炼可复用 runbook → 自测：习题 10-1
• 写结构化 STAR 故事并有量化证据 → 自测：习题 10-3

下一章预告：这是最后一章。至此你已经走完了”数据怎么走”（IO/存储/网络）→ “算力怎么用”（GPU/推理/调度）→ “故障怎么办”（监控/演练）的全链路。剩下的就是把本书的知识用到真实集群与真实面试中——用表现性任务检验自己吧。

延伸阅读

• Chaos Engineering Manifesto（Casey Rosenthal 等）：https://principlesofchaos.org/
• chaos-mesh 官方文档（CNCF）：https://www.chaos-mesh.org/docs/
• Google SRE Book 第 22 章（可靠产品发布与演练）：https://sre.google/sre-book/