1. 灾备与故障演练导论
企业网络早已从“支撑系统”演变为“生产系统本身”。当订单、支付、视频会议、远程办公、物联网采集都跑在同一张园区与广域网上时，网络中断不再只是IT部门的内部事件，而是直接对应营收损失、合规风险与客户信任流失。灾备（Disaster Recovery，DR）与故障演练（Failure Drill）正是为这种连续性挑战而生的工程实践：前者回答“坏了怎么快速恢复”，后者回答“我们真的能恢复吗、恢复得多快”。本章作为全课程导论，先建立企业网络连续性的问题框架，再概览Cisco Catalyst平台的高可用能力，最后给出灾备与演练的目标与衡量指标，为后续章节的具体设计、配置与验证打下共同语言。
一、企业网络连续性面临的三类挑战
企业网络的“断”并非单一原因，按影响范围与恢复难度，可归纳为三类挑战。
第一类是设备与链路级故障。交换机电源模块失效、上行光纤被施工挖断、光模块老化导致误码率升高，都属于这一类。它们的共同特征是影响面相对局部，但发生频率最高。以一台接入交换机双上行链路为例，若两条链路物理路径完全重合（同管道、同ODF架），那么“双上行”只是逻辑冗余，一次外力破坏即可同时中断，这就是典型的“伪冗余”。
第二类是协议与控制平面故障。生成树震荡、路由协议邻居反复建立与断开、ARP表项异常、DHCP地址池耗尽、VLAN间路由环路等，往往不会让设备“死机”，却会让转发行为变得不可预测。这类故障的隐蔽性最强，因为接口状态灯可能一切正常，而业务已经时断时续。Catalyst平台上的STP根桥漂移、HSRP/VRRP主备频繁切换，都属于需要重点演练的场景。
第三类是站点级与区域性灾难。机房断电、空调故障导致设备过热、楼宇火灾、运营商骨干中断，甚至勒索软件同时加密主备数据中心。这类事件概率低但后果重，考验的是异地灾备中心、数据复制链路与切换流程是否真正可用。
二、Catalyst平台的高可用特性概览
Cisco Catalyst系列交换机在企业园区与中小型数据中心中承担核心角色，其高可用能力可以从“硬件、链路、协议、系统、管理”五个层面理解。
硬件层面，Catalyst 9000系列支持可插拔电源与风扇模块、双电源冗余供电，部分型号支持StackWise-480或StackWise-1T堆叠，将多台物理交换机虚拟为一台逻辑设备，实现跨设备的链路聚合与统一管理。链路层面，EtherChannel（LACP）提供链路级冗余与带宽叠加，配合跨堆叠的MEC（Multichassis EtherChannel）可避免单台设备故障导致整组链路失效。协议层面，STP/RSTP/MSTP负责二层环路防护与收敛，OSPF/EIGRP/BGP负责三层可达性，HSRP/VRRP/GLBP提供网关冗余。系统层面，SSO（Stateful Switchover）与NSF（Nonstop Forwarding）让主控切换时转发不中断、路由邻居不重建立。管理层面，NETCONF/RESTCONF、Telemetry与DNA Center提供配置备份、状态流式采集与自动化恢复能力。
需要强调的是，这些特性是“能力”，不是“结果”。堆叠线缆接错、EtherChannel成员口速率不一致、HSRP优先级与抢占未规划、SSO未启用，都会让高可用设计在真实故障面前失效。这正是故障演练存在的意义。
三、灾备与演练的核心目标与衡量指标
灾备不是“买一套备用设备”，而是用可度量的目标约束设计。业界最常用的两个指标是RTO与RPO。RTO（Recovery Time Objective）指业务从中断到恢复可接受的最长时间，例如核心交易系统RTO为15分钟；RPO（Recovery Point Objective）指可接受的数据丢失时间窗口，例如RPO为5分钟意味着最多允许丢失最近5分钟的数据。二者共同决定了技术选型：RTO短、RPO小，就需要热备、实时复制与自动切换；RTO长、RPO大，则可采用冷备与定期备份。
另一个关键指标是可用性。若某网络设备MTBF（平均无故障间隔）为87600小时（约10年），MTTR（平均修复时间）为4小时，则可用性约为87600/(87600+4)≈99.9954%，对应年停机约24分钟。若MTTR因缺乏备件或预案而升至24小时，可用性降至约99.9726%，年停机约144分钟。可见，缩短MTTR对可用性的贡献往往比单纯提高MTBF更显著，而演练正是压缩MTTR的核心手段。
演练本身也需要指标。建议至少记录四项：切换成功率（成功切换次数/演练总次数）、业务中断时长（从注入故障到业务恢复的实测秒数）、丢包率与协议收敛时间（如OSPF邻居重建耗时、STP收敛耗时）、预案执行偏差（实际步骤与预案步骤的差异项数量）。这些数据应形成基线，每次演练后对比，才能判断体系是在进步还是在退化。
四、一个可落地的演练记录示例
以下是一份可直接使用的演练记录表结构，字段围绕网络连续性设计，避免引入无关管理字段。
| 字段 | 示例值 | 说明 |
|---|---|---|
| 演练编号 | DR-2024-001 | 唯一标识，便于追溯 |
| 演练对象 | 核心交换机C9500堆叠主控 | 具体设备与角色 |
| 故障注入方式 | 手动切换主控（redundancy force-switchover） | 真实操作命令 |
| 预期RTO | ≤30秒 | 设计目标 |
| 实测中断时长 | 8秒 | 业务侧ping丢包统计 |
| 丢包数 | 3个（间隔1秒） | 连续ping 100个包 |
| 协议收敛 | OSPF邻居未重建（NSF生效） | show ip ospf neighbor |
| 预案偏差 | 0项 | 步骤与预案一致 |
| 结论 | 达标，SSO/NSF配置有效 | 是否需优化 |
这份记录的价值在于：它把“演练做完了”变成“演练结果可比较”。下一次演练若实测中断时长变为25秒，即使仍在RTO内，也说明系统在退化，需要排查堆叠线缆、SSO状态或协议定时器。
五、从导论到实践：本课程的学习路径
后续章节将沿着“设计—配置—演练—度量—优化”的路径展开。你会看到具体的Catalyst配置片段，例如启用SSO与NSF、规划HSRP优先级与抢占、配置StackWise与MEC、使用EEM或Python脚本实现故障自动响应；也会看到演练脚本如何注入故障、如何用show命令与Telemetry数据判断恢复是否真正完成。请记住本章建立的核心判断：高可用特性只是能力，只有经过演练验证并达到RTO/RPO目标的体系，才称得上灾备就绪。