课程导入：学习目标、课程大纲与核心概念
数据中心GPU集群承载着大模型训练、科学计算和实时推理等关键业务，其规模从单机八卡扩展到万卡互联。随着集群规模增长，故障从"偶发事件"变为"常态事件"——一个万卡集群每天可能经历数次部件故障、网络抖动或软件异常。如果不能有效应对，轻则训练任务中断，重则数据损坏、集群长时间不可用。本课程围绕"故障自愈"与"容灾恢复"两大主题，系统讲解如何在GPU集群中构建从故障发现、诊断、隔离到恢复的完整闭环。
1.1 学习目标
完成本课程后，学习者应能够：
- 理解故障自愈与容灾恢复的本质区别：自愈强调"不中断"或"短暂中断后自动恢复"，容灾强调"灾难发生后快速重建服务"，两者在目标、手段和代价上均有不同。
- 掌握GPU集群故障的典型分类与特征：包括硬件故障（GPU HBM错误、PCIe链路退化、NVLink故障）、网络故障（RoCE丢包、拥塞风暴）、软件故障（驱动异常、CUDA错误、框架挂起）以及环境故障（温度、供电）。
- 熟悉故障检测、诊断、隔离与恢复的完整方法论：能够根据故障特征选择合适的检测手段（如健康检查、遥测监控、日志分析），并设计合理的自愈策略。
- 了解容灾恢复的关键设计模式：包括检查点与恢复、多副本冗余、跨可用区容灾、数据一致性保障等。
- 具备构建故障自愈系统的工程能力：能够结合具体集群架构，设计自愈流程、定义SLA指标、评估自愈效果。
1.2 课程大纲概览
本课程共30章，分为五个模块，各模块之间层层递进：
| 模块 | 章节范围 | 核心主题 |
|---|---|---|
| 基础与框架 | 第1-5章 | 故障自愈与容灾概念、GPU集群架构、故障分类体系、监控与遥测基础 |
| 故障检测与诊断 | 第6-12章 | 硬件故障检测（GPU/内存/网络）、日志分析、AI异常检测、根因定位 |
| 自愈机制设计 | 第13-20章 | 故障隔离策略、任务迁移、弹性调度、自动重启与回滚、自愈编排 |
| 容灾与恢复 | 第21-26章 | 检查点技术、数据备份、跨数据中心容灾、恢复演练、数据一致性 |
| 工程实践与案例 | 第27-30章 | 大规模集群自愈系统设计、故障复盘方法论、SLA度量、综合案例实战 |
课程内容从基础概念出发，逐步深入到具体技术实现，最后通过工程案例将知识串联为可落地的系统能力。
1.3 核心概念：故障自愈与容灾恢复
在进入具体技术之前，必须先厘清两个核心概念的定义与边界。
故障自愈（Fault Self-Healing）是指系统在检测到故障后，无需人工干预，自动执行预设的恢复策略，使服务恢复到正常状态的能力。自愈的关键特征包括：
- 自动检测：通过健康检查、指标阈值、日志异常等方式实时感知故障。
- 自动决策：根据故障类型和当前系统状态，选择最优恢复策略。
- 自动执行：执行隔离、重启、迁移、降级等操作，整个过程无需人工介入。
- 自愈闭环：恢复后验证效果，并更新故障知识库，持续优化自愈策略。
容灾恢复（Disaster Recovery）则关注在重大灾难（如机房断电、网络分区、大规模硬件损坏）发生后，如何尽快恢复业务可用性。容灾的核心指标是恢复时间目标（RTO）和恢复点目标（RPO）：
- RTO：从灾难发生到业务恢复所允许的最大时间。
- RPO：灾难发生时，允许丢失的最大数据量（通常以时间度量）。
两者的关系可以这样理解：自愈是"小病自治"，容灾是"大病重建"。自愈处理单点故障、瞬时故障，追求的是高可用性；容灾处理区域性、系统性灾难，追求的是可恢复性。一个完整的GPU集群韧性体系，必须同时具备这两种能力。
1.4 整体框架：从故障发生到业务恢复
本课程的整体技术框架可以概括为一条完整的故障处理链路，这也是后续所有章节展开的主线：
故障发生 → 故障检测 → 故障诊断 → 故障隔离 → 恢复执行 → 验证与复盘
↑ |
└──────────────── 知识沉淀与策略优化 ←──────────────────────┘各环节的核心任务如下：
- 故障检测：回答"系统出问题了吗"。依赖硬件健康状态监控（如NVML、ROCm SMI）、网络质量探测、应用日志异常检测等手段。
- 故障诊断：回答"哪里出了问题、为什么出问题"。需要结合多源数据（指标、日志、追踪）进行根因分析，区分硬件故障、网络故障、软件缺陷或配置错误。
- 故障隔离：回答"如何防止影响扩散"。通过将故障节点从集群中摘除、屏蔽异常路径、降级非核心服务等方式，保护整体系统稳定性。
- 恢复执行：回答"如何让业务继续跑"。包括任务重新调度、容器重启、检查点回滚、流量切换等具体操作。
- 验证与复盘：回答"恢复是否成功、下次如何更快"。通过自动化验证确认业务健康，通过复盘更新故障库和自愈策略。
下面用一张示意图展示GPU集群中故障自愈与容灾恢复的整体架构关系：
从图中可以看出，自愈与容灾并非两条孤立的路径，而是共享检测与诊断能力，在恢复策略上根据故障严重程度进行分级处理。自愈处理不了的故障，会升级为容灾事件，触发更重量级的恢复手段。
1.5 典型场景与误区
典型场景：某万卡GPU集群在训练大语言模型时，节点A的GPU 2出现ECC可纠正错误（单比特翻转）。自愈系统检测到错误率超过阈值后，自动将该GPU从训练任务中隔离，触发任务迁移到备用节点，整个过程耗时约90秒，训练任务仅中断一次并自动恢复。如果该GPU错误升级为不可纠正错误（多比特翻转），系统则判定为硬件故障，触发节点下线流程，同时从检查点恢复训练数据，RPO控制在5分钟以内。
- 误区一：自愈等于"所有故障都自动处理"。实际上，过度自愈可能导致系统在错误的状态下反复重启，反而延长故障时间。合理的做法是设置自愈尝试次数上限，超过后自动升级为人工介入。
- 误区二：容灾就是"多备份"。备份只是容灾的一部分，更重要的是恢复流程的自动化程度和演练验证。没有经过演练的容灾方案，在真实灾难面前往往无法执行。
- 误区三：只关注GPU本身，忽略网络和存储。在GPU集群中，网络故障（如RoCE丢包）和存储故障（如检查点写入失败）同样会导致训练中断，且排查难度往往高于GPU硬件故障。