1. 课程导入与业务连续性框架
在数据中心里，服务器宕机从来不是"会不会发生"的问题，而是"什么时候发生、影响多大、多久能恢复"的问题。业务连续性（Business Continuity, BC）讨论的正是这套应对逻辑：当硬件故障、断电、网络中断、软件缺陷甚至人为误操作发生时，业务如何以可接受的速度和代价继续对外服务。故障切换（Failover）则是业务连续性在技术层面的核心手段——把原本运行在故障节点上的工作负载，转移到仍然健康的节点上继续运行。
理解这两个概念，需要先区分"高可用"与"容灾"两个常被混用的词。高可用（HA）关注的是本地范围内的快速恢复，目标通常是让服务在秒级到分钟级内重新可用，典型手段是集群、心跳检测、自动重启与主备切换。容灾（DR）关注的是更大范围的灾难，比如整个机房失效，目标是在异地重建服务能力，恢复时间通常以小时计。业务连续性框架把两者都纳入进来，并向上对齐业务部门对"可接受中断"的要求。AMD EPYC 平台的价值，正是在这个框架的底层提供算力与可靠性基础：更多的核心、更大的内存带宽、更完善的 RAS（Reliability, Availability, Serviceability）特性，使得单节点能承载更多业务、故障检测更及时、切换代价更低。
RTO 与 RPO：把"可接受"变成可度量的数字
业务连续性不能停留在"尽快恢复"这种模糊表述上，必须落到两个关键指标：
- RTO（Recovery Time Objective，恢复时间目标）：从故障发生到业务恢复可用的最长时间。它衡量的是"停多久"。例如 RTO = 5 分钟，意味着故障后 5 分钟内必须让服务重新对外可用。
- RPO（Recovery Point Objective，恢复点目标）：业务恢复时允许丢失的数据时间跨度。它衡量的是"丢多少"。例如 RPO = 0，意味着不允许丢失任何已确认的数据；RPO = 15 分钟，意味着最多可以回退到 15 分钟前的数据状态。
这两个指标直接决定技术方案的选择。RTO 越小，越需要自动检测与自动切换；RPO 越小，越需要同步复制或强一致写入。它们也直接决定成本：RTO 从 30 分钟压缩到 30 秒，往往意味着从冷备升级到热备甚至双活，投入可能翻倍。因此业务连续性设计的第一步，不是买设备，而是和业务方一起把 RTO/RPO 谈清楚。
故障切换的基本过程
一次典型的故障切换包含四个阶段：检测、决策、转移、确认。检测依赖心跳、健康探针或硬件告警；决策判断故障是否真实、是否需要切换，避免"脑裂"导致双写；转移把 VIP、存储映射、会话状态或容器调度迁移到健康节点；确认则验证业务真的可用，而不是"进程起来了但服务不通"。
下面这张图把业务连续性框架、RTO/RPO 与故障切换过程放在同一张关系图里，帮助建立整体认知：
AMD EPYC 在业务连续性中的定位
把 EPYC 放进这个框架，它的作用不是"替代"集群软件或容灾方案，而是从底层改变切换的代价与可靠性上限。具体体现在几个方面：
第一，核心密度。单颗 EPYC 可提供数十甚至上百个核心，意味着原本需要多台服务器承载的业务可以收敛到更少的物理节点上。节点数量减少，心跳链路、仲裁配置、数据复制路径都会简化，切换时的状态同步量也随之下降。但要注意，收敛也意味着单节点故障的影响面变大，因此必须配合更严格的冗余设计。
第二，内存带宽与容量。数据库、缓存、虚拟化等业务对内存敏感。EPYC 支持多通道内存与较大容量，使得单节点能容纳更大的工作集，减少因内存不足导致的换页抖动。在故障切换瞬间，健康节点需要承接故障节点的负载，如果内存余量不足，切换后性能会急剧下降，RTO 名义达标但业务实际不可用。
第三，RAS 能力。EPYC 平台支持内存巡检、缓存纠错、PCIe 错误上报等机制，能够在故障演变为宕机之前发出告警。这相当于把"检测"阶段前移，让运维团队有机会在业务受影响前介入，把被动切换变成主动迁移。
第四，安全与隔离。SEV（Secure Encrypted Virtualization）等特性让虚拟机内存加密，在多租户或混合负载场景下，故障切换时不必担心数据在迁移路径上被窥探，这对金融、医疗等合规要求高的业务尤为重要。
一个可参考的指标设定示例
假设某在线订单系统部署在双节点 EPYC 服务器上，业务方给出的要求是"工作日高峰期中断不超过 3 分钟，订单数据不能丢"。据此可以设定：
| 业务模块 | RTO 目标 | RPO 目标 | 对应技术手段 |
|---|---|---|---|
| 订单写入服务 | ≤ 2 分钟 | 0（同步复制） | 数据库同步复制 + 自动主备切换 |
| 订单查询服务 | ≤ 3 分钟 | ≤ 5 分钟 | 只读副本 + 负载均衡摘除故障节点 |
| 报表与对账 | ≤ 4 小时 | ≤ 1 小时 | 异步复制 + 定时备份 |
这张表说明一个关键点：RTO/RPO 不是全局统一值，而是按业务模块分别设定。订单写入最严格，报表可以宽松，这样既满足业务要求，又避免为低价值模块过度投入。表中数值为示例设定，实际项目需结合业务方确认与演练结果调整。
本节要点
- 业务连续性关注"中断可接受程度"，故障切换是其技术实现手段。
- RTO 衡量停多久，RPO 衡量丢多少，两者共同决定架构复杂度与成本。
- 故障切换包含检测、决策、转移、确认四个阶段，缺一不可。
- AMD EPYC 通过核心密度、内存带宽、RAS 与安全特性，从底层降低切换代价、提升可靠性上限。
- 指标应按业务模块分别设定，并通过演练验证，而非停留在纸面。