容灾系统

容灾按时间发展维度来看，截止到今天，容灾主要经历了如下了的几个阶段：

• 第一阶段（1980-2000 年）：IT 作为业务支撑系统，容灾以数据为中心，恢复以人工为主，容灾系统作为备用系统
• 第二阶段（2000-2013 年）：IT 作为业务的使能，容灾以业务为中心，双活、AQ 模式使得容灾系统支撑部分业务
• 第三阶段（2013 年-至今）：年容灾即业务，容灾以客户为中心，智能流量分配，多中心部署，容灾系统即业务系统。异地多活目前就是处在第三阶段。

容灾系统的评价指标

容灾系统主要为了在灾难发生时业务不发生中断，那么当灾难发生时，用户最关心的是什么呢？以下是国际通用的容灾系统的评审标准 Share 78，可以作为广大用户衡量和选择容灾解决方案的指标。以下是备份/恢复的范围：

• 灾难恢复计划的状态
• 在应用中心与备份中心之间的距离
• 应用中心与备份中心之间是如何相互连接的
• 数据是怎样在两个中心之间传送的
• 有多少数据被丢失
• 怎样保证更新的数据在备份中心被更新
• 备份中心可以开始备份工作的能力

因此，容灾系统的设计，主要也是围绕这几个用户需求。当然，容灾也不会无限制地投入，我们设计出的系统也只能是在现有的条件下尽量减少故障历时，尽量多的恢复数据，这也是衡量我们所设计出来的容灾系统质量的指标。实际的容灾系统设计过程中，我们重点关注的是 RTO 和 RPO 两个指标。

• RPO（Recovery Point Objective）：即数据恢复点目标，以时间为单位，即在灾难发生时，系统和数据必须恢复的时间点要求。RPO 标志系统能够容忍的最大数据丢失量。系统容忍丢失的数据量越小，RPO 的值越小。

• RTO（Recovery Time Objective）：即恢复时间目标，以时间为单位，即在灾难发生后，信息系统或业务功能从停止到必须恢复的时间要求。RTO 标志系统能够容忍的服务停止的最长时间。系统服务的紧迫性要求越高，RTO 的值越小。

RPO 针对的是数据丢失，而 RTO 针对的是服务丢失，RTO 和 RPO 的确定必须在进行风险分析和业务影响分析后根据不同的业务需求确定。好的容灾系统需要尽量满足用户的需求，但是容灾系统的设计往往受多种条件的制约，如可用的技术、现网状况、用户意志、用户业务等，但到目前为止，起决定性的因素，是容灾建设的成本。以下是容灾中心建设等级示意图。

系统构建

根据对容灾系统建设模型，容灾系统建设过程分为分析、设计和实施三个阶段。

下面分别对各个阶段作出说明：

• 分析阶段：在取得管理层的正式同意后，获得人员和资源的保证。首先收集业务过程的信息、技术基础架构的支撑环境、灾难类型等方面的内容，然后进行业务影响分析和风险分析，确定由于中断和预期灾难可能造成的影响。分析的结果用以确定业务关键级别、业务恢复时间和可承受的数据损失程度。

• 设计阶段：在本阶段，结合以上的分析成果，以及企业对容灾的投入规划，制订企业短期、长期范围内的容灾策略和目标，先定义初步的方案。再进一步结合各种因素进行分析，在候选的方案中剔除不合适的方案，将剩余的可用的方案提交给评估组，评估组经过充分详细的评审，选择最合适的容灾方案。

• 实施阶段：根据选择的容灾方案，整合企业相关资源，确定容灾的体系架构和灾难恢复计划，通过技术手段和服务以达到所要求的容灾目标。任何制订的计划，都必须经过不断的测试和修正，才能满足企业不断发展的需求。同时，通过培训、测试过程，也能够使企业内部人员熟悉自己在容灾流程中所扮演的角色，保证在灾难真正发生的时刻能够有条不紊地执行恢复流程。测试的过程可以分为局部验证和演习两种方式。随着商业需求、新技术的不断升级以及新的内部和外部规则的变化，IT 系统也会随之改变。要确保灾难恢复计划的有效性，必须定期检查和修改计划。