本文根据凌霄老师在〖deeplus直播：平安银行容灾切换平台建设的探索与实践〗线上分享演讲内容整理而成。

凌霄

平安银行科技运营中心

运维开发架构师

专注于数据化与智能化的能力在运维场景中落地，曾就职于新浪及智能运维产品厂商。年加入平安银行，致力于平安银行运维数据化体系与业务连续性领域工具体系的建设。

背景与方案

预案一键切换

运行可观测性

演练线上化

上线后的收益

一、背景与方案

1、业务连续性挑战

在银行业，业务连续性是一个非常重要的领域。

业务系统发生大规模中断会产生资金损失甚至影响公司形象。

金融业务关系国计民生，影响大众生活。

监管对银行业务连续性能力的检视非常重视，会定期开展巡检。

因此，很多银行都建立了两地三中心的容灾能力。当基础架构层面具有容灾能力后，出现单机房故障时，通过同城机房的切换实现故障恢复是一种非常理想的故障处理方式。

但通过与同行交流发现，在出现单机房故障时，大家还是倾向于在本地进行故障恢复，通过同城切换来实现故障恢复的案例少之又少。主要原因如下：

架构治理：架构层面对双活的技术方案和实现未制定统一的标准，生产环境部署和配置存在不一致的情况。

预案维护：预案维护于文档系统中管理，随着业务的快速发展预案的新鲜度和准确性存在问题。

演练验证：演练本身的生产风险和实施成本巨大，演练覆盖率较低。预案有效性、应急流程和应急人员操作缺乏有效的验证。

所以当有了容灾的基础能力后，距离随时能切，想切就切的实战能力还有一定距离。

2、业务场景切换能力

当业务系统或业务场景出现故障后，快速通过切换实现我们的恢复目标，是我们容灾切换非常重要的能力。

我们往往将业务场景切换过程分为以下三个阶段：

机房、网络、存储等基础架构恢复；

操作系统、容器平台、信息系统恢复；

业务场景对应的应用与数据库恢复。

应用场景恢复过程往往在整个阶段中耗时最久，因为它的切换对象数量极多。另外，业务场景与应用数据库之间的关系非常复杂，维护预案的成本很高，所以当出现预案不准确的情况时，往往会导致故障恢复不能达到预期效果，增加故障恢复时长。

为了解决以上问题，我们会定期对全行业务进行梳理，找出产生故障后会导致巨大资金损失的关键业务，之后根据这些关键业务梳理出业务相关的业务场景，最后定位到这些业务场景所依赖的子系统。

3、面向子系统的容灾能力

当每一个子系统都建成同城容灾的能力后，我们就可以认为我们的业务具备了同城级别的容灾能力。换言之，当我们的业务场景出现故障时，我们可以通过切换对应的系统快速恢复故障。

IT架构往往分成系统、子系统以及应用三个层次，系统由多个实现特定业务功能的子系统组成，每一个子系统又由多个实现特定业务逻辑的应用组成。

我们在建设容灾能力时，目前选择子系统作为容灾建设的最小单位，原因有以下几点：

业务边界明确：子系统有明确的业务功能边界，变动性小，易于建立与业务场景的关联关系；

职能管理维度：在业务开发、版本控制、运维管理有配套的人员和职能支持；

维护成本可控：相比数千级别的应用数量，数百个子系统在预案维护上成本相对可控；

架构管理单元：子系统作为架构的管理单元，会对架构设计、高可用等进行评估；

服务流量入口：子系统间有提供服务相对独立，内部访问关系高内聚，彼此访问松耦合等特点；

数据库独立使用：子系统在数据库使用上相对独立，架构治理成本相对较低。

二、预案一键切换

1、双活架构模型

上文中我们讲到通过子系统建设容灾能力，子系统在切换时，其实是将故障机房的一些服务全部拉出，然后把流量和服务切换到服务正常的同城机房。

那么对于一个完成改造的子系统而言，它的服务分成三层，切换时需要对这三层的一些组件做解绑动作。最上面的一层是互联网的流量，例如我们公网的GLSB和HTTPDNS等流量，也有一些广域网的专线，还有一些负载均衡的服务。当流量进入内网后，我们通过内网的GSLB与负载均衡的切换实现HTTP层的流量调度。对于一些微服务的流量，我们通过注册中心的一些流量拉入拉出实现流量的切换。

除了以上三种，银行中还有一个比较特殊的服务模式——跑批，即晚上对当天的交易进行复核，跑批的结果会直接影响第二天银行能否顺利开门，也会间接影响我们服务的可能性。在这个过程中，我们会对作业在哪个地方去跑等做一些切换控制。

理论上，当子系统完成了一些架构改造后，通过这些流量的调度切换，就可以完成我们的工程切换。但实际上，也有一些长尾问题，比如有些子系统做一些双活的改造成本很高，或它是一些比较老的外购系统，这样的系统比例不高，但很重要。所以我们支持这些子系统切换的时候，提供了一些更加灵活的切换能力，比如我们支持做一些应用配置的修改，或者执行自定义的脚本，甚至会提供一些数据库层面的数据修改能力，让那些非标的子系统具备自动化、快速切换的能力，提高应急切换效率。在数据库层面，更多的是像Oracle、Mysql或MongoDB等数据库组件的切换。

2、原子预案编排

在切换过程中，每一个类型的切换，我们内部都称之为一个原子的预案，切换工具会对这些原子预案进行预案编排。在执行前，我们有一个检查阶段，来确保目前处于适合切换的状态，才能执行。

当完成执行动作后，我们还需要通过验证来确保执行目标的达成，但具体步骤不是由我们的工具提供，这些能力是由数据库团队或平台架构团队的变更能力提供。而我们的平台是通过HTTP的方式，让他们对执行、检查的步骤进行快速编排。这种检查、执行、验证的编排模式，让大家的切换能力变得更加标准化，也更加安全。

当我们完成切换后，往往还需要对服务进行恢复，切换是从双活变到单活的过渡，当故障恢复后或演练要回切时，我们也会把单活的能力回退到双活的模式，这时候会有一个回退的编排。在回退编排中要做一些检查、执行和验证动作的编排。

由于每一个原子预案都是很基础的预案，风险非常大。所以当我们的预案要发布时，会请每个领域的专家对预案的内容进行评估，甚至做一些测试来保证预案能达到相应效果，保证预案本身的安全性。

3、子系统应急预案

1）故障场景关联

当我们有了原子预案能力以及明确的系统切换清单后，我们就可以在子系统层面编排子系统的预案，这个预案内容可能会包含一些应用、网络以及数据库的操作。当做子系统切换时，这些动作需要同步切换。但是我们可以将对应的故障场景进行区分，尽可能降低切换范围。

2）串并执行编排

我们完成双活改造后，切换对象之间的切换都是独立的，所以我们默认通过一些并行切换的方式提升整体切换效率。

但是因为有一些长尾问题，例如有些子系统在切换之前需要先关闭一些流量才能执行后面的切换动作，所以我们最终提供的是串并行结合的编排能力。

3）预案版本管理

因为架构一直在发生变化，当架构发生变化之后，工具能够捕获到这种变化，我们会将这些变化信息同步给对应的预案维护人，他们可以通过这些提示信息对预案进行实时更新，以免发生价格变化后预案更新不及时的情况。

4）演练状态标识

预案维护后是未验证的状态，只有当子系统完成一次演练后，我们才会认为这个预案处于安全有效的状态，所以我们会在预案没有演练前，提示其切换过程中可能存在的风险。

以上4个能力是子系统预案编排过程中比较关键的能力。当我们的子系统具备了预案管理能力后，我们再去做业务场景的编排会更容易。我们只需要明确业务场景中包含了哪些子系统，并按照故障恢复的优先顺序设定切换执行的批次即可。

4、执行过程可视化

在执行过程中我们会提供预案执行过程的看板，展示目前切换的耗时与执行成功与否，以及每一类组件切换的进度和状态。在执行过程中，如果说有一些步骤或一些预案执行失败，我们也可以通过一些下钻查看具体的报错原因。

5、工具可用性

每年的演练非常多，我们希望通过自助的方式，让运维、DBA以及一些演练执行人能够自助解决一些问题。

上文讲的是如何通过工具体系提高业务系统的可能性，其实工具的可用性相比业务系统的可能性要求更高，因为发生故障时，你期望通过工具对业务系统进行恢复。我们在工具建设过程中，提出了更高的可能性要求。

1）多活

切换工具及其关键依赖，我们会在三个数据中心进行部署。这三个数据中心包含我们的同城机房，生产机房，还有第三地机房。我们会默认把主服务部署在第三地机房。这样当同城和生产机房出现问题时，工具可以快速接管服务，实施切换动作。

切换工具，其关键依赖，以及变更能力是工具的核心能力，发生故障时这些能力不能出现任何问题，所以我们会定期对这些强依赖或关键依赖做一些容灾切换演练。

2）降级

登录等能力是切换工具的弱依赖，切换工具的核心能力是切换。当这些能力出现故障时，我们要尽量避免它对我们核心切换能力产生影响，所以我们会定期通过故障注入或者主动降级来做一些弱依赖的降级演练，确保弱依赖发生故障时，核心功能不受影响。

3）性能

我们也会对切换原子预案的执行性能做一些测试。我们在每一个原子预案上线前，会要求预案提供方提供性能测试的基准，明确指出每一个原子预案执行的并行度是多少，以及在对应并行度下切换的SLA是多少。这种情况下，工具可以对原子预案的执行做流控，保证切换过程的稳定性。

三、运行可观测性

在执行切换过程中，切换的实施人要实时

转载请注明:http://www.aideyishus.com/lkgx/3590.html