3.2.2 容灾演练及冬奥实践

容灾是一个系统化、体系化工程，通常会覆盖分析、规划、设计、实施及管理5大部分。这里只讨论实施阶段中的容灾演练部分。容灾建设是否成功、是否达到设计目标，需要多种手段进行衡量，而通过演练来验证容灾建设方案是最直接最有效的手段。全面、有序、高效的容灾演练可以提升信息系统服务在突发中断后应急响应和灾难恢复的效率，以最大限度减少业务中断时间并降低风险，对提升赛时信息系统整体可用性非常重要。

在容灾领域，有两个最重要的概念，即所谓RTP和RPO。

所谓 RTO，Recovery Time Objective，它是指灾难发生后，从 系统宕机导致业务停顿之时开始，到IT系统恢复至可以支持各部门运作、恢复运营之时，此两点之间的时间段称为 RTO。

所谓 RPO，Recovery Point Objective，是指从系统和应用数据而言，要实现能够恢复至可以支持各部门业务运作，系统及生产数据应恢复到怎样的更新程度。这种更新程度可以是上一周的备份数据，也可以是上一次交易的实时数据。

在系统设计时就需要明确RTO和RPO，通常来讲，我们的目标是追求更短的RTO和RPO。当然，这和成本有关：设计两地三中心类型的容灾系统，可以保证RTO为0，但成本要double或者trible；设计极高的数据备份频率，可以保证RPO非常小，但成本也会比较高。成本、RTO、RPO总是一个不可能三角的模型。

容灾演练规划大体可分成三个环节：

规划演练方案：规划好要验证系统的哪些功能、设计演练的具体场景、落实操作具体流程为演练脚本。

实施演练过程：按照顺序逐步实施演练脚本，并观察业务运转是否符合预期，观察系统稳定性指标。

解决演练问题：针对演练过程中出现的问题进行定位并逐一解决。

在北京冬奥，我们一共做了两次系统容灾演练(DDR，Discovery Disaster Rehearsal)。

考虑到云数据中心承载着公共服务，无法模拟真实的灾难场景，且与赛时保障密切相关的信息系统均采用了双活架构，因而演练主要从云产品实例层面进行触发，通过手工切换的方式，来考察上层应用的容灾能力，识别潜在风险。整个容灾演练涉及SLB、ECS、RDS、Redis和OSS的灾难切换和恢复操作，涵盖了应用、存储和数据层面的灾难模拟和恢复。两次容灾演练共计15个关键信息系统参与。项目团队针对各产品的特性，制定了详细的演练计划和执行脚本，在云基础设施和应用层面均识别出了不同类型的问题和风险，为赛时重保打下了坚实的基础。

下面介绍下第二次容灾演练DDR2，在DDR2，我们针对8个核心信息系统(交通、火炬手、餐饮、数据、抵离、Info1AV，健康监测，收费卡)进行演练，涉及SLB/ECS/RDS/Redis/OSS等核心云资源在政务云AC可用区之间切换，覆盖资源数量占整体资源的15%以上。在此期间，我们和各系统的开发商密切配合，按照演练脚本逐一测试了核心功能。

《云上大型赛事保障白皮书》——第三章 压测调优与技术演练——3.2 云上大型赛事技术演练——3.2.2 容灾演练及冬奥实践（下）： https://developer.aliyun.com/article/1226501?groupCode=supportservice