1. 课程导入与灾备可靠性全景

企业网络承载着办公、生产、交易、视频会议等关键业务，一旦核心链路或关键设备失效，损失往往以分钟甚至秒来计算。灾备与可靠性验证的目标，不是让故障永不发生，而是让故障发生后业务能尽快恢复、数据尽量不丢、切换过程可预期、可验证。本课程围绕 H3C Comware 平台，从可靠性度量、灾备架构、协议机制到验证方法，逐步建立一套可落地、可复现的灾备可靠性验证能力。

灾备的核心目标：RTO 与 RPO

讨论灾备，首先要区分两个最关键的指标：RTO（Recovery Time Objective，恢复时间目标）和RPO（Recovery Point Objective，恢复点目标）。RTO 描述的是“业务中断后，多长时间内必须恢复”，它约束的是恢复速度；RPO 描述的是“最多允许丢失多长时间的数据”，它约束的是数据丢失窗口。举例来说，某企业要求核心交易系统 RTO ≤ 30 秒、RPO = 0，这意味着故障切换必须在 30 秒内完成，且不允许丢失任何已确认的交易数据。这两个指标直接决定了灾备方案的技术选型：RPO=0 通常需要同步复制或状态热备，RTO 很小则要求快速检测与自动切换。

需要特别注意的是，RTO 和 RPO 是业务指标，不是设备指标。设备侧的切换时间、收敛时间、备份周期，都是为达成业务 RTO/RPO 服务的手段。验证工作的核心，就是把设备与协议层面的行为，映射回这两个业务指标，判断是否达标。

可靠性度量：MTBF 与 MTTR

衡量网络可靠性的两个基础参数是 MTBF（Mean Time Between Failures，平均无故障时间）和 MTTR（Mean Time To Repair，平均修复时间）。MTBF 反映系统平均能连续正常运行多久，MTTR 反映故障后平均需要多久修复。二者共同决定稳态可用度：

可用度 A = MTBF / (MTBF + MTTR)

示例（假设值，仅用于说明计算关系）：
MTBF = 8760 小时（约 1 年）
MTTR = 4 小时
A = 8760 / (8760 + 4) ≈ 99.954%

从公式可以看出，提升可用度有两条路径：一是提高 MTBF，即选用更可靠的设备、做冗余设计、减少单点故障；二是降低 MTTR，即加快故障检测、简化切换流程、提升可运维性。灾备体系中的冗余链路、BFD 快速检测、VRRP 主备切换、IRF 堆叠等机制，本质上都是在压缩 MTTR。而 MTBF 的提升，则更多依赖设备质量、电源冗余、风扇冗余、链路冗余等硬件与架构层面的设计。

Comware 在灾备体系中的定位

Comware 是 H3C 网络设备的统一操作系统平台，覆盖交换机、路由器、防火墙等产品。在灾备体系中，Comware 处于“控制与执行”的核心位置：它负责运行各类高可用协议，执行链路与设备的切换决策，并提供验证所需的日志、告警、状态查询与调试命令。可以说，灾备方案的设计最终都要落到 Comware 的配置与运行行为上。

Comware 提供的灾备相关能力大致可分为几类：链路级冗余（如链路聚合、BFD 联动）、网关级冗余（如 VRRP、VRRP 与 Track 联动）、设备级冗余（如 IRF 堆叠、双机热备）、路由级冗余（如 OSPF/BGP 快速收敛、路由备份）、以及安全与控制平面冗余（如防火墙双机、主控板冗余）。这些机制不是孤立存在的，实际灾备方案往往是多种机制的组合，需要验证它们在故障场景下的协同行为。

课程任务地图

本课程共 30 章，整体上分为四个阶段。第一阶段建立概念基础，包括灾备目标、可靠性指标、Comware 定位与验证方法论；第二阶段深入各类高可用机制，逐一分析 VRRP、BFD、IRF、链路聚合、路由快速收敛等技术的原理与配置要点；第三阶段进入验证实操，围绕故障注入、切换观测、日志分析、结果判定展开；第四阶段聚焦综合场景与复盘，把单点机制组合成完整灾备方案，并形成可复用的验证报告与改进建议。

学习本课程时，建议始终带着三个问题：这个机制解决的是 RTO 还是 RPO？它的故障检测时间与切换时间是多少？我如何用可观测的手段证明它真的生效了？这三个问题贯穿全课程，也是灾备可靠性验证的基本思维框架。