1. 灾难恢复与业务连续性导论

在vSphere环境中谈灾难恢复，首先要区分两个经常被混用的概念：灾难恢复（Disaster Recovery，DR）关注的是"IT系统在灾难后如何恢复运行"，而业务连续性（Business Continuity，BC）关注的是"业务在灾难期间和之后如何持续交付价值"。DR是BC的一个子集，BC的范围更广，还包含人员、场地、供应商、流程和沟通机制。理解这一点，是后续所有指标设计和方案选型的前提。

一、四个核心指标：RTO、RPO、MTTR、MTBF

在vSphere灾备项目中，最常被追问的四个数字是RTO、RPO、MTTR和MTBF。它们不是同义词，也不能互相替代。

• RTO（Recovery Time Objective，恢复时间目标）：灾难发生后，业务功能必须恢复到可接受水平的最长允许时间。它回答的是"能停多久"。例如某核心ERP的RTO为2小时，意味着从灾难确认到系统重新对外提供服务，不能超过2小时。
• RPO（Recovery Point Objective，恢复点目标）：灾难发生时，允许丢失的数据时间跨度。它回答的是"能丢多少数据"。RPO=15分钟，意味着最坏情况下丢失最近15分钟内产生的数据。
• MTTR（Mean Time To Repair，平均修复时间）：系统发生故障后，从故障发生到修复完成的平均耗时。它是衡量"恢复能力"的实测统计值，而RTO是"目标值"。MTTR越小，说明团队和架构的恢复效率越高。
• MTBF（Mean Time Between Failures，平均无故障时间）：两次相邻故障之间的平均运行时长，反映系统的可靠性水平。MTBF越大，系统越稳定。

四者的关系可以这样理解：MTBF决定"多久出一次事"，MTTR决定"出事之后多久能修好"，RTO是"业务能容忍的修复上限"，RPO是"业务能容忍的数据丢失上限"。设计灾备方案时，通常先用RTO/RPO倒推技术架构，再用MTTR/MTBF评估现有能力是否达标。

二、业务影响分析（BIA）方法

BIA（Business Impact Analysis）是确定RTO/RPO的正式方法。它的核心逻辑是：先识别关键业务功能，再分析这些功能中断后随时间推移造成的损失，最后据此推导出恢复优先级和时间目标。

一个可落地的BIA流程通常包含以下步骤：

1. 业务功能清单：列出组织全部业务功能，例如"订单受理""库存查询""财务结算""客户门户登录"等。
2. 依赖关系梳理：为每个业务功能标注其依赖的IT系统、数据、接口、人员和外部供应商。在vSphere环境中，这一步要落到具体的虚拟机、数据存储、网络端口组和认证源。
3. 中断影响评估：按时间维度评估损失。常用做法是设定几个时间档（如1小时、4小时、8小时、24小时、72小时），分别估算财务损失、合规风险、客户影响和声誉影响。
4. 确定RTO与RPO：当某个时间档的损失超过可接受阈值时，该时间点就成为RTO的候选值；RPO则由数据变更频率和业务对数据完整性的要求决定。
5. 划分恢复优先级：将业务功能分为P1（最高）、P2、P3等层级，P1功能优先恢复，其对应的虚拟机、存储和网络资源也优先保障。

举例说明：某电商平台的"订单支付"功能，中断1小时预计损失约80万元，中断4小时损失约350万元，且伴随监管投诉风险。业务方确认可接受损失上限为100万元，则RTO应设定在1～2小时之间。该功能每5分钟产生一批交易数据，业务方要求最多丢失10分钟数据，则RPO=10分钟。这两个数字一旦确定，就决定了后端必须采用持续复制或频繁快照，而不是每天一次备份。

三、DR与BC的区别与联系

DR计划回答的是"IT系统怎么恢复"，通常包含备份策略、复制方案、切换步骤、回切流程和演练安排。BC计划回答的是"业务怎么在灾难中继续运转"，除了IT恢复，还包括备用办公场地、人员替代方案、供应商切换、客户沟通话术和危机决策机制。

两者的联系在于：BC是目标，DR是手段。没有DR支撑的BC只是纸面预案；没有BC约束的DR则容易陷入"技术能恢复，但业务已无法承受"的尴尬。在vSphere项目中，DR方案的技术指标（RTO/RPO）必须从BC的BIA结果中推导出来，而不是反过来。

四、从指标到演练：一个可执行的检查清单

指标确定后，必须通过演练验证。以下清单可直接用于vSphere灾备项目的阶段性检查：