一、背景与计划1、业务连续性挑战在银行业，业务连续性是一个非常重要的领域。业务系统的大规模中断将导致经济损失，甚至影响公司形象。金融业务事关国计民生，影响公众生活。监管高度重视对银行业务连续性能力的检查，定期开展检查。因此，很多银行都建立了两地三中心的容灾能力。当基础设施层具有容灾能力时，当单个机房发生故障时，通过同城机房的切换实现故障恢复是一种理想的故障处理方式。但是通过与同行的交流发现，当单个机房发生故障时，大家还是倾向于在本地进行故障恢复，很少有通过同城切换实现故障恢复的情况。主要原因如下：架构治理：在架构层面，双活的技术方案和实现没有统一的标准，生产环境的部署配置不一致。预案维护：预案维护在文档系统中进行管理。随着业务的快速发展，预案的新鲜度和准确性都存在问题。演练验证：演练本身的生产风险和实施成本巨大，演练覆盖率低。对预案、应急程序和应急人员操作的有效性缺乏有效验证。所以当容灾的基础能力建立起来之后，离可以随时砍、想砍就砍的实战能力还有一定的距离。2.业务场景切换能力当业务系统或者业务场景发生故障时，通过切换快速实现我们的恢复目标，是我们容灾切换非常重要的能力。我们经常将业务场景切换过程分为以下三个阶段：机房、网络、存储等基础设施的恢复；操作系统、容器平台和信息系统的恢复；恢复业务场景对应的应用程序和数据库。应用场景恢复过程由于其切换对象的数量极高，在整个阶段往往耗时最长。另外，业务场景和应用数据库的关系非常复杂，维护方案的成本非常高。因此，当计划不准确时，故障恢复往往达不到预期的效果，恢复时间就会增加。为了解决以上问题，我们会定期对全行业务进行梳理，找出故障后会造成巨大财务损失的重点业务，然后根据这些重点业务梳理业务相关的业务场景，最后定位到这些业务场景所依赖的业务场景。子系统。3、面向子系统的容灾能力当各个子系统都构建了同城容灾能力后，我们就可以认为我们的业务具备了同城级别的容灾能力。也就是说，当我们的业务场景出现故障时，我们可以通过切换相应的系统来快速恢复故障。IT架构通常分为三个层次：系统、子系统和应用程序。系统由多个实现特定业务功能的子系统组成，每个子系统又由多个实现特定业务逻辑的应用程序组成。我们在建设容灾能力的时候，目前都是选择子系统作为容灾建设的最小单位。原因如下：业务边界清晰：子系统业务功能边界清晰，可变性小，易于与业务场景建立关联关系；功能管理维度：在业务开发、版本控制、运维管理等方面有配套人员和功能支持；维护成本可控：相对于上千个应用，上百个子系统的成本在计划维护上相对可控；架构管理单元：子系统作为架构的管理单元，对架构设计和高可用进行评估；服务流量入口：子系统具有相对独立的服务提供、内部访问关系高、相互访问松耦合等特点。;独立使用数据库：子系统在数据库的使用上相对独立，架构管理成本相对较低。2.预规划一键切换1.双活架构模型上面我们提到了容灾能力是通过子系统来构建的。子系统切换时，实际上是拉掉了故障机房的所有服务，然后将流量和服务切换到同城服务正常的A机房。那么，对于一个完成改造的子系统，其服务分为三层，这三层的部分组件在切换时需要解绑。最上层是互联网流量，比如我们公网的GLSB和HTTPDNS流量，还有一些WAN专线和一些负载均衡服务。当流量进入内网时，我们在内网通过GSLB和负载均衡的切换实现HTTP层的流量调度。对于一些微服务的流量，我们通过拉取一些流量进出注册中心来实现流量切换。除了以上三种，银行还有一种特殊的服务模式——跑批，即晚上复查当天的交易。跑批的结果会直接影响银行第二天能否顺利开门，也会间接影响到我们。服务的可能性。在这个过程中，我们会对在哪里运行作业做一些切换控制。理论上，子系统完成一些结构改造后，我们的项目切换就可以通过这些流量的调度和切换来完成。但实际上也存在一些长尾问题，比如一些子系统的双活改造成本高，或者一些老旧的外包系统。此类系统的比例不高，但非常重要。因此，我们在支持这些子系统的切换时，提供了一些更灵活的切换能力。比如我们支持一些应用配置修改，或者执行自定义脚本，甚至提供一些数据库层面的数据修改能力。目标子系统具有自动快速切换的能力，提高了应急切换的效率。在数据库层面，更多的是Oracle、Mysql或者MongoDB等数据库组件的切换。2.安排原子计划在切换过程中，我们在内部将每一种切换称为一个原子计划，切换工具会安排这些原子计划。在执行之前，我们有一个检查阶段，以确保我们当前处于适合执行之前切换的状态。执行动作完成后，我们还需要通过验证，确保执行目标达到，但具体步骤我们的工具并没有提供，这些能力是由数据库团队或者平台架构团队的变更能力提供的。而我们的平台使用HTTP让他们可以快速安排执行和检查的步骤。这种检查、执行、验证的编排模式，让大家的切换能力更加规范和安全。我们完成切换后，往往需要恢复服务。切换是双活到单活的过渡。当故障恢复或者演练需要切回时，我们也会将单活能力回滚到双活模式，这时候会有回退安排。在回退编排中，编排了一些检查、执行和验证动作。由于每个原子计划都是非常基础的计划，因此风险非常高。所以，当我们的方案要发布的时候，会请各个领域的专家对方案的内容进行评估，甚至做一些测试，确保方案能够达到相应的效果，保证方案本身的安全性。3.子系统应急预案1）故障场景关联当我们具备原子计划能力和清晰的系统切换列表时，我们可以在子系统层面安排子系统计划。计划内容可能包括一些应用、网络和数据库的操作。在做子系统切换时，这些动作需要同步切换。但是，我们可以区分相应的故障场景，尽可能缩小切换范围。2）串并执行安排我们完成双活转换之后，切换对象之间的切换是独立的，所以我们默认使用一些并行切换的方式来提高整体的切换效率。但是因为有一些长尾问题，比如有些子系统需要在切换前关闭一些流量来进行后续的切换动作，所以我们最终提供的是串并结合的编排能力。3）计划版本管理因为架构总是在变化的，当架构发生变化时，工具可以捕捉到这个变化，我们会将变化信息同步给相应的计划维护者，他们可以根据这些提示实时更新计划.更新，以避免价格变化后计划没有及时更新的情况。4)演练状态表示该计划在维护后处于未验证状态。只有在子系统完成一次演练后，我们才认为该计划处于安全有效状态。所以在演练之前我们会提示可以切换方案。存在的风险。以上四项能力是子系统规划过程中的关键能力。当我们的子系统具备了管理计划的能力时，我们对业务场景的安排就会变得更加容易。我们只需要明确业务场景包括哪些子系统，根据故障恢复的优先级设置切换执行的批次即可。4.执行过程可视化在执行过程中，我们会提供计划执行过程的看板，展示当前切换的耗时和执行成功情况，以及每类组件切换的进度和状态。在执行过程中，如果某些步骤或计划执行失败，我们还可以下钻查看具体错误原因。5、每年都有大量的工具可用性演练。我们希望通过自救的方式，让运维、DBA，以及一些演练执行者自己解决一些问题。以上就是如何通过工具系统提高业务系统的可能性。事实上，工具的可用性比业务系统的可能性要高，因为当故障发生时，你希望业务系统能够通过工具恢复。在工具构建的过程中，我们提出了更高的可能性要求。1）多活切换工具及其关键依赖将部署在三个数据中心。这三个数据中心包括我们的同城机房、生产机房和三地机房。我们默认将主服务部署在第三机房。这样，当同城和生产机房出现问题时，工具可以快速接管服务，执行切换动作。切换工具，它们的关键依赖和变化能力是工具的核心能力。这些功能在发生故障时不会造成任何问题。所以，我们会定期对这些强依赖或者关键依赖进行一些容灾切换演练。2）降级、登录等能力是切换工具的弱依赖，切换工具的核心能力是切换。当这些能力失效的时候，我们要尽量避免它对我们的核心切换能力造成影响，所以我们会定期通过故障注入或者主动降级的方式进行一些弱依赖降级演练，保证当弱依赖失效时，核心功能不会受到影响。影响。3）性能我们也会对切换原子计划的执行性能做一些测试。在每个原子计划上线前，我们都会要求计划提供者提供性能测试基准，明确每个原子计划执行的并行度，以及相应并行度下切换的SLA。在这种情况下，工具可以对原子计划的执行进行流控，保证切换过程的稳定性。3、运行的可观察性在切换过程中，切换实施者要实时关注切换服务的运行状态是否有异常，是否达到相应的效果。1.运行监控在突发事件或演练中，我们会有一个切换成功的标准：切换完成后，业务关键指标不会出现明显波动，目标机房必须承载100%的生产流量，并且应用层和基础层相应的一些服务能力满足相应的SLA要求。这就需要我们为演练实施者提供聚合信息的能力，包括业务层、应用层和基础设施层的监控能力。2.架构可观察性除了监控能力，我们还会以列表的形式展示相应组件的状态。异常显示是分层的。只有在出现异常时，我们才会下钻查看实际部署的异常展示。此外，我们还会对反映生产系统异常或对服务节点有相关影响的告警、变更等动作进行标注，及时提示生产变更的潜在风险。3、上面提到的运维数据中心的展示能力，都依赖于运维数据中心的实现。在运维数据中心，我们会把服务之间的调用关系和CMDB的一些部署信息组合成一个拓扑关系网，给每个拓扑节点附加一些配置属性，监控的url地址，变化。丰富每个拓扑节点的数据。一旦拓扑和信息可用，我们就可以快速提供可观察性能力，包括在计划维护期间识别架构变化的能力和一些自动化验证能力。4、线上演练当我们具备一键切换能力和可观察性能力的时候，我们还需要通过演练来验证人员的有效性、计划本身的有效性、流程的有效性。中间过程还有一些问题需要解决。我们的同城子系统切换演练，实际上是子系统层面的中高风险生产变更。在制定变更计划的过程中，尽量避免计划层面的问题造成的影响。1.方案风险控制1）影响范围的评估我们的演练是为了提高生产的稳定性，所以我们在演练过程中会对演练的影响范围进行评估，主要包括以下几个方面：钻子系统，比如是否有共享数据库；识别相关系统相关人员，如开发、运维、DBA等；相关人员应配合识别项目风险并参与演练验证。2）实施风险评估我们也使用工具来评估实施风险，主要包括以下几个方面：数据库防火墙未开启识别；集群部署当前可用容量不对称；软件和框架版本不符合基线；双因素认证异常识别自动检测。有了以上能力，我们就可以在很大程度上规避程序层面的一些风险。2.钻井过程控制第二个风险是过程控制层面的风险。一个完整的过程对于降低钻孔过程的风险非常有帮助。流程的存在也可以提高演练的有效性。对于演练过程中发现的一些问题，我们可以通过问题管理的一些流程进行跟进，重点关注问题的持续解决。但是进程的存在也是有一定代价的。因为流程本身非常复杂，学习培训成本高，在有制度但没有控制的情况下，达不到预期的管理效果。同时，完整的流程实施也会产生巨大的人力成本。所以，我们在把线下的流程改成线上的时候，整理了资料，通过一些强有力的流程控制，对于那些有变更风险或者流程风险的地方，我们设置了检查点，从而规避流程中的一些风险。对于一些本身就比较复杂的流程，我们通过提示和引导的方式大大降低了用户演练的门槛。3.钻孔效率的提升我们在工具层面做了一些信息优化，提升了流程的效率。在使用这些工具之前，单次演习的累计持续时间可能会加起来长达三天，如果考虑到它的开始时间，甚至可能是一个月。当我们把演练上线的时候，我们的工具从四个方面提升了演练的性能，缩短了演练的时间。1）协同在线演练通过演练人员身份识别，实现风险评估、方案制定、演练验证等环节的信息协同录入。这样，我们的演练负责人只需要审核并确认结果就可以完成演练的制定，大大降低了沟通协作的成本。2）流程信息集成在线演练可以集成变更控制、问题管理、审批管理等流程系统，在演练过程中自动完成流程信息的关联和状态反转。3）辅助技术验证在线演练，通过针对不同演练对象建立标准化的技术验证格式和指标，降低验证成本，还可以自动生成验证信息，大大降低了演练中填写验证信息的成本，显着缩短了演练时间时间。4）作业决策分析在线演练可以通过在演练过程中嵌入信息建立数字化过程测量能力，通过多维统计分析建立演练质量的运行分析能力，提高演练过程质量和效率。具备以上能力后，单台钻机的平均投入时间从原来的3天缩短到2小时，效率提高了10倍以上。同时，常态化演练条件已经形成，可以大大提高我们演练的覆盖面。4.演练模拟执行上述内容是通过演练验证切换计划内容本身的有效性。此外，还应验证人员和流程的有效性。这些效果往往是通过培训或桌面沙盘模拟，以及应急演练来实现的，所以我们制定了模拟执行的机制。通过模拟执行，可以提高我们一线团队和一线同事对切换流程的熟悉程度，也可以验证我们流程的有效性。5、演练过程指挥我们在进行大型演练时，会有一些指挥级的要求。比如我们演练的负责人需要关注参与演练的人员信息和设计的业务监控是否正常，还需要关注数据中心在切换过程中的流量变化过程。然后通过我们的指挥大屏，指挥官可以清楚的看到数据中心的运行信息。演练过程中，我们还将在大屏幕上展示各子系统的切换进度。五、上线后的收益1、业务连续性能力提升1）容灾能力提升我们实现了容灾切换平台后，整个切换时间有了很大的提升。目前我们其中一个子系统的端到端切换RTO不到10分钟，缩短到原来的三分之一。对于应用切换，RTO值更小，因为应用切换的成本主要是不同系统之间的运行成本。当我们按照一个计划执行批量执行的时候，基本上可以在几秒内完成。2）业务切换能力因为我们建立了业务场景和子系统的关系，子系统完成了应急预案的闭环管理，所以我们具备了业务场景切换的应急预案维护闭环能力。当业务场景出现故障时，我们可以通过子系统的切换，快速实现业务场景的一键恢复。3）丰富的应急手段事实证明，当我们发现一些故障时，往往会通过传统的重启、扩容、稳定三轴方式来恢复故障。有了切换能力，我们就有了更快捷的方式，通过切换快速恢复业务。同时，倒换方式也得到了验证，因此也是一种比较安全的故障恢复手段。2.变更安全能力的提升除了业务连续性能力的提升，我们还发现了额外的惊喜。1)常规变更我们过去是在技术架构层面做一些变更。应用运维和技术架构方面的同事都非常担心变更可能会导致一些大规模的故障。当我们有了切换能力，然后维护机房的时候，我们会把这些应用的流量，以及一些相关子系统的流量，提前切换到我们的通信机房，保证变更过程中的安全。当我们完成技术架构变更后，我们会批量切回流量，大大提高了安全系数。2）蓝绿发布原来我们行业的发布主要集中在周二和周四。对于一些关键系统，这个时间往往是周二、周四的凌晨两三点，这对运维人员来说是非常不友好的。当我们具备切换能力后，发布过程的安全性就提高了，可发布的时间也延长了。同时发布后的业务异常支持快速回滚。Q&AQ1：是否需要进行以存储为中心的灾备演练，与以应用为中心的灾备演练相比有何不同？A1：我们在做容灾切换的时候，不仅做应用层，还会做数据层。所以我理解这个切换应该是应用和数据库整体的切换，存储部分由技术架构组单独实现。Q2：演练前如何保证双方数据一致？A2：我们目前在应用层有一些检查机制，所以我们会定期做一些检查，切换前也会做一些检查。不能说切换前后一样，但至少生产机房和同城机房是安全的。状态切换，数据库层面通过数据实现切换。Q3：切换后的增量数据能否恢复到原生产机房？A3：演练和应急流程有一些区别。在演练过程中，我们会尽量避免数据丢失，因为演练过程中有切换方式，但是当生产出现紧急情况时，切换方式的时间会比较长。当真正出现生产紧急情况时，我们会使用vivo方式进行切换。这种情况下会丢失一些数据，丢失的数据需要DBA同学来修复。Q4：容灾倒换应急演练一年有几次？A4：我们有一个要求，我们的核心系统要在两年内演练完，所以每年的演练次数基本上是几百次。Q5：只能在同城内转吗？A5：我们在做容灾能力建设的时候，我们既有同城能力，也有容灾能力。但由于大数据是实时复制的，同城机房和生产机房都有流量，切换更安全。当两个同城机房不可用时，我们会做一些容灾切换。两者的使用频率和场景不一样，所以我们也会有灾备机房演练，但是同城演练的频率可能更高。Q6：正常情况下，业务同时运行在两个中心，流量按照1:1的比例分配。如果是应用层面的问题，一般两个center同时出现问题，那么切换就没有意义了吗？A6：我们平时的流量是生产和同城机房1:1部署的。如果某个节点出现问题，或者是物理设备出现问题，或者是单机房的PaaS服务出现问题，那么故障往往是单机房引起的。如果是应用层面的问题，比如容量问题，这种情况是无法通过切换来解决的。因此，容灾切换只适用于部分场景，并不能解决所有问题。
