打造坚不可摧的防线：容灾策略的实践与探索

在当今这个信息化时代，数据已成为企业最宝贵的财富之一。因此，保护数据免受意外损坏或灾难性事件的影响变得至关重要。这就需要企业建立一个有效的容灾体系，来确保业务连续性和数据安全。

容灾，即灾难恢复（Disaster Recovery），是指在灾难发生后，通过事先制定的方案和措施，快速恢复企业的关键业务和数据。一个有效的容灾体系，不仅能够减少灾难对企业造成的损失，而且能够帮助企业在灾难发生后迅速恢复正常运营。

容灾从大的方面分为两部分。一个是IT系统容灾，一个业务容灾。

IT系统容灾可以使用云桌面，来保证生产力的可持续性。

业务容灾又分为三个方面：数据容灾、应用容灾和网络容灾。

1. 数据容灾（Data Disaster Recovery）: 这部分主要涉及到数据的备份与恢复。企业需要确保在发生灾难时，能够迅速恢复所有关键数据。这通常包括定期将数据备份到安全的位置，例如远程数据中心、云存储或者是其他媒体上。

2. 应用容灾（Application Disaster Recovery）: 这一部分关注的是确保关键应用程序在灾难发生时能够快速恢复并重新上线。这可能涉及到在另一个数据中心或环境中部署应用的副本，并确保这些副本可以在主环境出现问题时接管服务。

3. 网络容灾（Network Disaster Recovery）: 涉及确保网络通信在灾难后能够快速恢复。为了实现这一点，企业可能需要建立冗余网络连接，以确保主要通信线路出现问题时，可以迅速切换到备用系统。

具体企业在基础设施上是怎样实现这些容灾的呢？对于数据容灾和应用容灾，主流方法如下：

1. 离散计划：所部署应用的虚机或者容器不能在同1台物理机、同机柜、同1个leaf交换机上，尽量打散。

2. 机房容灾：有的企业要求N+1容灾，就是N个机房部署，N个机房足以支撑100%的流量，但是会冗余1个机房。可承受1个机房完全故障；业务连续性要求高的企业会三地六中心部署，多点多活，骨干网接入，可承受2个机房同时故障。
   

3. 电力配置容灾：对业务连续性要求高的企业会同时支持市电和备用发电机两种供电方式。

对于网络容灾，一般企业会支持移动、联通和电信三大运营商中的两个，有的企业会三大运营商都支持，即：运营商级别容灾。

在对应真正出现问题时，大体上有两种手段。一种是自动化容灾，一种是应急恢复。

自动化容灾常见的手段有：

1. 定期自动备份：

• 使用自动备份软件，在预定时间自动对关键数据和系统进行备份。这些备份可以是本地的、离线的、热备的或冷备的。

实时数据复制：

• 利用软件工具进行数据的实时复制，如数据库镜像、文件系统同步或存储复制，确保数据的多个副本存储在不同的地理位置。

自动故障转移（Failover）：

• 在主系统出现故障时，通过自动化工具将业务自动迁移到备份系统或灾备站点运行，无需人工干预。

虚拟化技术：

• 利用虚拟化，可以迅速地创建一个或多个虚拟机的副本用于恢复。许多虚拟化平台提供自动化工具来管理和恢复虚拟机。

云服务和灾难恢复即服务（DRaaS）：

• 云计算和灾难恢复即服务（DRaaS）提供了灵活的容灾解决方案，通过在云环境中自动进行数据备份和恢复，确保灾难发生时可快速恢复。

监控和警报系统：

• 使用监控软件自动监控系统健康状况，并在检测到异常时产生警报，有些系统甚至能自动触发灾难恢复流程。

脚本和编排工具：

• 编写脚本来自动化备份、复制、监控和恢复流程。使用编排工具可以自动执行这些脚本以及以特定顺序执行多个任务。

恢复时间和恢复点目标（RTO和RPO）的自动化测试：

• 自动化测试灾难恢复策略，以确保在满足预定的RTO和RPO内恢复服务。其中，恢复点目标（Recovery Point Objective，简称RPO）是在业务连续性规划和灾难恢复领域中的一个关键术语。它用于描述数据丢失的容忍度。具体而言，RPO是在发生故障或灾难时，企业可以接受的最大数据丢失量，通常用时间来度量。

容灾计划的自动审计和更新：

• 使用容灾管理工具定时对容灾计划进行自动审计，确保所有步骤和流程都是最新的，符合当前的业务需求。

这些手段听起来可能会有些务虚，举个具体点的手段。在三地六中心架构下，跨中心进行数据库主从切换要怎样做呢？

• 切断应用对主库的流量

• 主库和备库都设置为只读状态

• 查看备库复制进程状态，确保数据不落后于主库( 确认Slave_SQL_Running状态为YES，Seconds_Behind_Master为0)

• 比对主备两边的全局事务ID是否一致

• 从库停掉复制进程并清空主从信息

• 从库关闭只读开启读写，转为新主库

• 原主库设置执行新主库的复制链路，转为从库，完成主从切换

•  应用流量切向新主库

以上步骤一般是会通过脚本等自动化工具实现，但是脚本的原理机制还是要做了解的。

应急恢复怎样做呢？

尽量实现 SOP/EOP 生产全范围覆盖，来做应急恢复。 应急恢复除了要有预案，但实际中的问题有已知可预测的和未知不可预测的。所以发生问题时也有一些原则作为兜底应急流程来对应突发情况。

原则是一旦出现了问题或者故障，第一要务是恢复现场。先解决问题，控制和降低影响。

如果遇到系统问题，生产环境突然 load 高、线程池被打满……这时候应该马上启动紧急预案。单机器故障则进行故障机器隔离。一个服务的所有机器都有问题，则重启服务或者机器，然后紧急扩容。如果问题发生前有过变更，则立即回滚。如果数据库主库连接池被打满或者其他故障，则要启动主机房切换等预案。

如果遇到业务问题，首先考虑是否有变更，有的话，如果有应急回退切换开关，则立即启用开关；没有则立即回滚；如果是下游通道故障，则考虑是否进行临时关闭通道快速失败；如果是上游问题，则考虑是否调整对应方的限流值或者直接对其做快速失败；如果是中间件故障，则考虑是否降级。比如向 MQ 写数据，MQ 出故障了就先降级不写入。等恢复后再从数据库中拉取数据写入；如果是自身某接口故障，则考虑从服务治理平台上先摘除此接口，尽量减小影响范围。

在发生问题的时候需要有个指挥者负责分派任务和协调人员。现场恢复后再着手调查原因，可以多个人从不同层面来分析问题。比如这次问题主要是一个变更引起的。那么变更的开发人员是问题分析的主力，但是其他人可以同时通过代码 review、监控等数据分析角度帮助一起定位。

原因基本定位之后，如果大家都还没离开。可以以轻松的聊天的方式，让了解问题的人都自然的聚在一起，开一个头脑风暴的茶话会，将问题事前、事中、事后可以优化的都提出来，作为正式复盘前的素材。