1. 业务连续性与故障切换导论

在数据中心里，“系统没坏”并不等于“业务没断”。业务连续性（Business Continuity, BC）关注的是业务功能能否持续对外提供服务；故障切换（Failover）关注的是当某个组件、链路、节点甚至站点失效时，工作负载如何被转移到仍然健康的资源上继续运行。Lenovo ThinkSystem 服务器、存储与网络设备构成的基础设施，是承载这两件事的物理与逻辑底座。本课程围绕 ThinkSystem 场景，讨论如何定义高可用目标、如何用 RTO/RPO 量化容忍度、如何划分故障域，并据此设计可验证的故障切换方案。

一、高可用目标：从“设备可用”到“业务可用”

高可用（High Availability, HA）常被简化为“冗余”，但冗余只是手段。真正的高可用目标应表述为：在约定的故障场景下，业务功能在可接受的时间内恢复，且数据损失不超过可接受范围。对 ThinkSystem 环境而言，这意味着要同时考虑计算节点（如 SR650/SR630）、存储（如 DE 系列磁盘柜、SAN 交换机）、网络（冗余上行、堆叠/MLAG）、电源与制冷，以及虚拟化层（如 VMware vSphere、Lenovo XClarity 管理）的协同。

可用性通常用“几个 9”表达。99.9% 对应全年约 8.76 小时不可用；99.99% 约 52.6 分钟；99.999% 约 5.26 分钟。这些数字不是口号，而是设计约束：它决定了你是否需要双机热备、是否需要跨机箱/跨机架甚至跨站点部署，以及是否必须引入自动故障检测与切换。需要强调的是，可用性目标必须与业务影响分析（BIA）对齐——不是所有业务都需要 99.999%，把关键业务与非关键业务分级，才能把预算和复杂度花在刀刃上。

二、RTO 与 RPO：把“能忍多久”变成可测量指标

RTO（Recovery Time Objective，恢复时间目标）回答的是“业务中断后，多久必须恢复”。它从故障发生时刻算起，到业务重新可用为止，包含检测、决策、切换、验证等全部时间。RPO（Recovery Point Objective，恢复点目标）回答的是“最多能丢多少数据”，通常以时间衡量，表示恢复后数据回退到过去某个时间点。例如 RPO=15 分钟，意味着最多丢失最近 15 分钟的数据。

两者必须分开看：RTO 约束的是“停机时长”，RPO 约束的是“数据损失”。同步复制通常可实现 RPO≈0，但会引入写延迟，且受链路距离限制；异步复制可放宽距离，但 RPO 取决于复制周期与链路带宽。下面这张图把 RTO/RPO 与故障时间轴、复制方式放在一起，便于建立直观关系。

在 ThinkSystem 场景中，RPO 的实现往往落在存储层：例如通过 SAN 存储的同步/异步远程复制、或虚拟化层的复制能力。RTO 则更多取决于检测机制与切换编排：XClarity 可提供硬件告警，vSphere HA/DRS 可自动重启虚拟机，应用层负载均衡可摘除故障节点。设计时要避免“RPO 达标但 RTO 失控”——数据没丢，但业务两小时才恢复，同样不可接受。

三、故障域划分：冗余必须跨域才有意义

故障域（Fault Domain）是指一个故障能够同时影响到的资源集合。同一台服务器内的双电源、双网卡属于同一机箱故障域；同一机架内的多台服务器共享配电与顶部交换机，属于同一机架故障域；同一机房内的所有设备共享制冷与市电，属于同一站点故障域。冗余设计的关键原则是：副本与切换目标必须位于不同故障域。如果主备虚拟机在同一台主机上，主机宕机时两者一起失效，冗余形同虚设。

常见的故障域层级可归纳为：组件级（电源、风扇、磁盘、网卡）→ 节点级（单台服务器）→ 机架级（配电、TOR 交换机）→ 机房级（电力、制冷、网络出口）→ 站点级（城市级灾难）。ThinkSystem 的冗余电源、RAID、双上行、堆叠交换机分别对应前几层；跨机房双活或主备则对应站点级。划分故障域后，应逐一回答：该域失效时，哪些业务受影响？RTO/RPO 是多少？切换目标在哪个域？

四、课程整体路线图

本课程后续将按“概念—设计—实现—验证—运维”的脉络展开：先建立业务连续性与故障切换的基本模型，再深入 ThinkSystem 硬件冗余与 XClarity 管理；随后进入虚拟化层 HA、存储复制与网络冗余的具体配置；最后通过故障注入演练验证 RTO/RPO 是否达标，并讨论演练复盘与持续改进。学习时建议始终带着三个问题：这个组件的故障域是什么？它的失效会触发什么切换？切换后如何验证业务与数据一致？

最后给出一个可直接用于梳理的故障域与目标对照示例（参数为教学假设，需按实际业务替换）：