1. 灾备与可靠性验证导论

企业网络灾备的核心目标，不是“设备坏了能换一台”，而是在可接受的时间内，把业务恢复到可接受的数据状态。对 Cisco Nexus 数据中心网络而言，灾备体系要同时回答三个问题：故障发生时业务会损失多少数据、业务要停多久、恢复后如何证明网络真的回到了设计状态。可靠性验证则是把这三个问题从“口头承诺”变成“可测量、可演练、可审计”的工程活动。

先看两个最基础的可靠性度量。MTBF（Mean Time Between Failures，平均无故障时间）描述系统两次故障之间的平均运行时长，反映“多久坏一次”；MTTR（Mean Time To Repair，平均修复时间）描述从故障发生到恢复可用状态的平均耗时，反映“坏了多久能修好”。二者共同决定稳态可用性：

可用性 A ≈ MTBF / (MTBF + MTTR)

示例（假设值，用于说明计算关系）：
MTBF = 8760 h（约一年），MTTR = 4 h
A ≈ 8760 / (8760 + 4) ≈ 99.954%
年停机时间 ≈ 8760 × (1 − 0.99954) ≈ 4 h

这个公式揭示了一个常被忽略的事实：把 MTTR 从 4 小时压到 1 小时，可用性提升幅度往往比单纯追求更高 MTBF 更明显。Nexus 平台上的 ISSU（In-Service Software Upgrade）、快速重启、BFD 快速检测、vPC 双活、FabricPath/EVPN 多路径等能力，本质上都在压缩 MTTR，而不是改变硬件本身的 MTBF。

灾备语境下更常用的是 RTO 与 RPO。RTO（Recovery Time Objective，恢复时间目标）是业务可容忍的最长中断时间，回答“多久必须恢复”；RPO（Recovery Point Objective，恢复点目标）是业务可容忍的最大数据丢失量，回答“最多能丢多少数据”。RTO 与 MTTR 的关系是：MTTR 是实际修复耗时，RTO 是目标上限，验证工作就是确认 MTTR ≤ RTO。RPO 则取决于数据复制方式与复制周期，例如同步复制 RPO 趋近于 0，异步复制 RPO 等于复制间隔或复制延迟。

下面这张图把四个指标放在同一条时间轴上，并标出 Nexus 灾备体系中各层能力的作用位置。图中“故障发生”为时间轴原点，向左为故障前，向右为故障后；RPO 是故障点向前回溯的数据丢失窗口，RTO 是从故障点到业务恢复的时间窗口。

从图中可以看出，RTO 窗口内部并不是一个黑盒，它由“故障检测、路径切换、路由收敛、业务确认”四段组成。Nexus 平台在每一段都有对应的技术手段：BFD 把检测时间从秒级压到毫秒级；vPC 与 EVPN 多路径让流量在成员链路或 Leaf 之间快速切换；ISSU 让软件升级不中断转发；而 RPO 则主要由存储复制、数据库日志传送或应用层双写策略决定，网络侧能做的是保证复制流量有稳定、低时延的路径与足够的带宽。

Nexus 在灾备体系中的定位，可以概括为“承上启下的可靠传输与快速收敛层”。向上，它承载服务器、存储、数据库之间的复制流量和业务流量；向下，它依赖物理链路、光模块、电源与冷却等基础设施。灾备验证如果只测“链路通不通”，就会漏掉真正决定 RTO 的收敛时间、表项规模、控制面恢复速度和业务侧会话保持能力。因此，验证对象应至少覆盖：控制面协议收敛、数据面转发恢复、管理面可操作性、以及跨站点复制路径的稳定性。

举一个可操作的示例。假设某企业双活数据中心要求核心业务 RTO ≤ 30 s、RPO ≤ 5 s。网络侧采用 Nexus 9000 系列组成 EVPN/VXLAN Fabric，站点间通过 DCI 互联，存储异步复制周期为 5 s。验证时可以设计如下故障注入用例：

这些用例的价值在于把抽象的 RTO/RPO 拆成可观测的计数器与时间戳。例如用 show bfd neighbors 看检测时间，用 show ip route vrf ... summary 看路由收敛，用抓包或流量镜像看复制流量的中断时长。只有把“目标—注入—观测—判定”串起来，灾备验证才具备可重复性和审计价值。