干货丨一文带你解决保险行业灾备自动化难点

本文转自@TWT社区

【前言】自动化切换方案的难点，首先在于系统本身及强关联系统（CMDB）需要尽量在第三方部署，以避免灾难发生时系统本身的失效。其次，灾备切换各种脚本及服务需要建立开发及维护标准，避免由于脚本或者配置变化，真正切换时出现问题导致切换失败。需要定期检视这些脚本和工具，最好的办法是加大切换演练的频率，在演练中发现问题，解决问题。最后，切换本身的日志记录、展示及切换进展跟踪非常关键，在切换异常需要回退时，需要有办法能快速回切。

为了能更好的解决保险行业同行在灾备自动化切换方案及遇到的难点问题，特意邀请同行以及同创永益专家进行在线交流互动，以下是本次交流活动的精华内容汇编，对保险乃至金融行业用户用参考价值。

1、数据灾备中心同步方式应该如何选择？在数据库进行自动切换时如何防止脑裂问题？

【问题描述】在异地或者同城的数据灾备中心建设中，数据同步是个必须解决的问题，选择何种数据同步方式最稳妥安全？目前比较常用的是存储复制技术和数据库自带或者第三方的逻辑复制方式，不知是否还有其他方式，且哪类技术更成熟，遇到的问题更少？此外，在进行自动数据库切换的时候如何防止脑裂问题，对于灾难的自动判断依据是什么？

@李周华 同创永益灾备咨询服务部总监：

数据复制方式按照不同技术实现层次来说，可分为：

1，存储层，如EMC SRDF、IBM PPRC、HDS Truecopy等

2，SAN管理层，IBM SVC、EMC Vplex以及Netapp都有产品可归于此类

3，操作系统卷管理，如doubletake、Softek TDMF、Veritas VR等，国内部分CDP产品及VMWare vSphere Replication等也可归为此类

4，数据库，如Oracle ADG、DB2 HADR、OGG、Shareplex、DSG等

以上都是传统灾备主流成熟技术与产品。也有用户考虑到业务系统高度标准化且对实时性或系统延时不敏感，将数据复制直接在应用系统上加以实现。

目前客户使用云环境部署业务应用的也越来越多，各云厂商针对自身存储及数据库服务也推出了不同的数据复制工具和服务。

如何选择最稳妥安全的技术，需要从灾备建设的需求和系统现状出发，进行企业关键数据、RTO、RPO的分析来考虑。过去灾备建设多采用存储复制方式，因其对应用系统透明、技术成熟度高；但由于目前客户系统越来越多部署在云的环境，且更多客户有双活需求，因此存储复制的技术受到了一定限制。

数据库本身脑裂问题，与灾备系统脑裂产生原因类似，都是由于生产与灾备中心网络中断无法通信，导致双中心均自立为王。需要加入仲裁节点进行裁判判断。灾备切换的技术手段可以自动化，但因对业务影响较大，建议决策还需人工进行。目前推荐采用在双中心一体化运维模式下，进行运维智能化改造，为人工判断决策提供最快最准确的信息决策辅助。

@cpc1989 某保险公司 存储工程师：

灾备方案的选择这个问题，我的看法是不应该直接来对比技术方案，第一层看业务连续性需求，设计哪些业务应用系统，RTO、RPO的要求；第二层，在一个整体方案需求的前提下，再来看业务系统关联的应用和数据库，设计相应的灾备建设方案，第二层的RTO RPO要求会比第一层要求更高；然后才是第三层，也就是在基础架构组件的灾备方案选择，比如网络大二层打通，存储双活或者复制技术，这一层是纯技术层方案，并不直接实现灾备方案，是配合第二层来实现的，RTO、RPO要求更高 。

整体方案拆解下来之后，就能真正明确各个技术方案虽然有交叉的点，但是各有侧重。比如基于数据库的数据同步方案是一个第二层的方案，要优于第三层的存储层数据同步方案，逻辑更完整，但是存储同步或复制可以解决存储自身的 RTORPO 需求，能配合实现应用和数据库的灾备方案。

@zhangjunxi570 xjtu 系统分析师：

存储复制技术不用担心脑裂。存储双活需要部署仲裁，在两中心通信中断时决策。可以关注一些存储厂商，为了防止仲裁不可用或者由于网络原因仲裁不可达，增加了多仲裁等方案。

通常情况一个仲裁在第三站点，一个仲裁在主中心。脑裂发生时保生产更重要。

@leodong 系统工程师：

存储复制技术应用时间比较长，相对比较稳定；数据库自带的逻辑复制只能同步数据库变化的部分，如果有一些配置数据文件需要同步，就需要投产变更的时候同步实施；第三方数据复制一般针对表级别的，对于函数，存储过程，sequence等实时同步支持的不是很好。只有同城双活才存在脑裂的情况，需要规划好仲裁方式。

@bbaimm88 银行系统架构师：

数据中心级别的同步是个很庞大工程，涉及业务系统多。个人认为应该先解决灾备建设技术栈的体系规划。数据同步不是人家说好就跟，第三方的，存储级别，数据库原生级。 可能新公司如互金类能完全一统成一种技术，没有历史欠账包袱o(￣︶￣)o。 传统行业技术转型都有剧痛啊。

阁下说数据库切换时如何防止脑裂？有点不解，是Extend RAC嘛，这个玩意是比较复杂。常规主从复制，发生脑裂不影响切换， 切换就是抛弃主，启用备。 若果是存储，你们应该建设第三站点。

灾备切换判断应该是业务使用视角来判断，一定不是技术来定。可以参考业务连续性相关资料。

@guwenkuan 金融行业系统架构师：

之前同创永益的灾备咨询总监回答的已经比较全面，从技术层面上，主流的技术实现方式都很成熟了，主要还是从灾备建设的需求和业务系统现状出发，包括资金投入等，选择适合企业自身的灾备体系。

2、灾备演练结束后回切前需要完成的工作有哪些？

【问题描述】灾备演练完成后需要回切，如何保证各系统的一致性？除了数据要同步，有哪些问题需要注意？请专家指导一下。

@zhangyongjun CMBC 工程师：

单个系统一致性，可以通过数据复制、数据库同步等技术来保证，只要保证灾备端的数据能正常写回主生产环境，或者如果全部是测试数据，可以直接将灾备环境数据抛弃。

系统间最好不要存在一致性问题，否则不好处理。

回切前要对切换到灾备机房的应用系统进行业务验证，根据提前确定的方案和策略，安排各分支机构或者用户对演练的场景进行业务验证或者真实操作。

业务验证之后，确保生产端设备做好准备，待灾备环境停止和数据回写完成之后，启动生产环境。

只有一点需要特别关注：尽量不要在灾备演练的过程中进行主机房设备重启、维修等运维操作，很可能会导致灾备验证完成之后，主环境设备还没有准备好，造成报备的时间内无法恢复主生产，影响正常营业。

@leodong 系统工程师：

对于回切，只要是真实演练回切与切换需要完成的工作应该是一样的。1、检查数据同步情况，保证数据一致。2、检查容灾与生产环境，保证都处于正确的状态。避免存在不应该不应该挂载的文件系统出现挂的问题。3、然后就正常回切，一般和切换的步骤差不多，只是操作的对象不一样。针对是测试演练的，核对数据同步方向，生产数据覆盖掉测试数据。同时切换业务验证终端的配置到生产环境。

@dataprotect 某保险公司 系统运维：

针对真实环境的切换演练，一致性主要体现在数据层面，大部分应用本身可以是无状态的。数据主要包括数据库的数据以及nas类的数据。数据库数据的一致性通过主备同步及日志，对于关系型数据库保持强一致性。nas的数据可以通过类似snapmirror这种日常的镜像来同步数据，切换前把主卷写授权禁用，保证数据强一致。

@bbaimm88 银行 系统架构师：

演练按常理说，原环境应该没有变化，回切应该首要检查环境（软、硬）正常可用，其次确认回切环境的依赖关系顺序，回切失败是否存在此类隐患，该类要坚决排除。

3、目前保险行业的业务连续性管理现状如何？

@冯军 同创永益高级咨询顾问：

目前保险行业的业务连续性管理成熟度较低，无体系化管理。重点大部分在灾备建设阶段，保障信息系统的稳定运行；对于业务方面（非 IT ）的连续性有待加强。类似于 10 年前的银行业，无监管明确要求，未引入成熟的业务连续性管理方法论。但考虑到银监会与保监会的合并，保险行业的监管要求会逐步向银行业靠拢，也因新冠疫情的重大业务影响，急需引入一套成熟的管理体系来维持企业的业务连续性，部分头部企业已着手搭建业务连续性管理体系，强化自身业务连续性管理能力，增强企业竞争力。

@lsx 大唐控股 信息技术经理：

保险行业内保险公司可分为原保险、再保险，中介分为专业代理、兼业代理、经纪，还有公估……这么多业态，不能一概而论。即便是业务连续性做的比较好的原保险公司，在RTO/RPO的指标上也有差距。但是从大的趋势来说，随着业务的内在需求推动和监管的外在因素拉动， 业务连续性要求必然是逐渐提高的。

4、灾备系统自动化演练需要生产中心配置变更规范化，配置变更需要更新同步至灾备中心，如何进行同步状态验证？

【问题描述】1、生产中心包含应用配置、数据库配置、网络配置、全局DNS配置，生产环境一但变更如何保证所有的配置变更均已同步至灾备中心？2、中小型金融机构若要实现灾备中心自动化演练如何进行投入产出比计算？

@zhangyongjun CMBC 工程师：

两地三中心配置同步是一个建设难点，最主要的是灾备端经常处于standby或者停止状态，难以验证当前的配置是否完全一致。

我们依据灾备管理系统、应用、数据库、中间件、OS的配置和CMDB，尝试建设了一个两地三中心一致性比对工具，确定关键配置，逐个建立检查和比对机制，随时进行比对并生成报表，尤其是生产环境变更之后和灾备演练前，及时进行检查。目前已经建立近百个比对项。

另外，应用发布和基础软硬件变更工单中依据CMDB自动关联灾备环境，确保灾备端完成变更，不至于遗漏。

最重要的多演练，把碰到的问题积累起来，经过解决之后再进行推广，一般的灾备演练系统经过每套系统五六次的演练之后，一致性的问题基本上能解决七七八八。

@zhangjunxi570 xjtu 系统分析师：

CMDB对数据中心内各环节的配置项进行全生命周期的管理。有CMDB至少可以保证有一份最新最准确的配置信息。

有一些不涉及不涉及应用的例如操作系统参数的修改是可以在灾备环境同步操作的。

但是真实情况很多配置修改不能在灾备中心实施，比如应用的发版如果灾备是备用的环境通常不能在生产发版的同时在灾备的环境里同步作修改；再比如网络的一些变更涉及复杂的路由路由和防火墙策略也不一定能让灾备和生产同时变更。这样启用灾备时灾备的灾备的环境和生产会存在一些差异。

因此灾备切换平台应具备这样的能力或者考虑到这些工作：即从CMDB甚至是手工维护的信息里去比对灾备没有添加上的配置，在切换前消除差异。这项工作比调度切换更繁琐也是真正见识灾切平台交付能力的地方。

@leodong 系统工程师：

如果配置了完成CMDB,并且实际中已经很好的应用了，可以依靠CMDB管理容灾环境的配置，前期不具备，首先对于管理上，对于有容灾的业务系统，投产变更就必须是同步投产的，为了避免有遗漏，可以设计检查点，监控配置检查项。比如生产环境配置文件与容灾环境配置文件时间相差较大等。通过监控对比生产与容灾环境的配置，但是这些监控只能根据投产经验逐渐完善。

5、灾备自动化切换过程涉及较多专业软硬件产品（网络、安全、负载、各类数据库等），一般哪些不建议做自动化切换？

@zhangjunxi570 xjtu 系统分析师：

1.部分网络环境。城商行在建设同城灾备时一个主流的方案是大二层网络，拉通的二层一般将网关布在生产站点，自动切换要将二层的网关在同城站点启用涉及复杂路由及安全策略的配置，除非提前经过演练验证并将日常的维护做好记录梳理。如果两个站点是三层对接复杂度会降低。

2.数据库的切换。目前Oracle Db2都有数据库容灾方案，启用备库可以设置成自动化的。但是出于数据一致性的考虑，一般启用备库人工干预的。

3.存储。存储情况比较复杂。如果搭建了同城双活的存储，配合仲裁，存储在两端可以自行管理。基于复制的存储容灾拉起备用存储可以配制成编排好的切换操作，通常不会自动切换。

@zhangyongjun CMBC 工程师：

个人觉得这个问题要考虑对这些操作的把控程度，基本上没有操作不能自动化实现。

我们采用的是同城网络大二层打通，存储复制技术（SWAP和STAR模式）实现的大同城小异地的灾备方案， 要进行网络设备、操作系统、数据库、中间件、监控、应用、存储等操作。

无论是主备机房同一个服务IP的方式（要增删服务IP和重新apply集群），还是DNS方案（流程中需要更改DNS服务器中的指向），以及外联只允许一个IP通过防火墙的特殊情况等等，都实现了自动化操作。

建设初期，我们就实现了除同城演练存储SWAP回写步骤之外的所有自动化，只是担心存储回写步骤出现问题导致在同城灾备端通过各种渠道写入的真实业务数据被抹掉而采用了人工操作，经过数次演练验证之后，现在也实现了全自动化操作。

目前，整个灾备演练流程，只有切换流程第一步“确定能否演练切换”和中间的“业务验证”，是人工操作，其他全部自动化操作。

@leodong 系统工程师：

无论是任何一种产品都可以配置成自动切换，主要是根据风险程度去决定是否进行自动化配置。但是可以逐渐去实现自动切换，而且不是开始就是自动化切换，对于应用、中间件、数据库等启动都可以自动化，但是涉及存储的虽然有可以自动化，为了安全可以前期先手工切换。制定了完备检查方案后，再纳入到自动切换中。

6、紧耦合系统的灾备自动化切换如何演练？

【问题描述】紧耦合系统的灾备自动化切换如何演练？测试环境如何准备，毕竟搭建一套生产灾备环境就很耗资源。

@zhangyongjun CMBC 工程师：

同城演练时，对于紧耦合的系统，如果同城网络大二层打通状态，可以分别切换，无需考虑耦合；如果主备机房网络隔离，则必须将紧耦合的系统放在一起进行切换演练，逻辑上作为一个系统。

我们没有对每一套系统分别建设灾备演练的测试环境，过于浪费！只是针对灾备系统使用的技术搭建了AIX集群、HP集群、Linux集群、分别使用SWAP、STAR存储技术以及Oracle、DB2、MySQL等数据库，F5应用集群、使用DNS的服务IP，大约不超过20台物理机+虚拟机完全能覆盖所有灾备技术。这些IT组件的自动化脚本是通用和参数化的，由参数驱动，参数的来源是灾备平台。灾备流程将每套系统每个IT组件和应用的参数从灾备平台中取出来，传递给自动化脚本，下发到目标主机去执行。无论多少套灾备系统，脚本都是同一套，所以无需搭建每一套灾备系统的测试环境。

至于说一起切换时的启停顺序和依赖问题，我在另一个问题中刚刚做了答复，转帖过来：

业务的依赖性，不建议在灾备流程中实现，建议在应用设计中考虑，最好不要深度耦合，尽量采用重试机制来进行探测和重连。

举个简单例子吧，安保系统，对银行其他系统来说非常重要，大多需要依赖，尤其是渠道类如柜面、手机银行、网银等系统。

如果同时进行切换，可能渠道类系统先进入到应用启动的步骤，这时就需要应用端进行探测和等待，直到安保系统完成启动之后，渠道类探测到操作完成，连接到可用的安保平台。

在灾备自动化流程中实现前置和关联检查会造成流程复杂度大大增加，不利于今后的变更和灾备演练。灾备自动化最多依据安保提供的连通性判断脚本或者RESTful接口进行判断，一待完成判断后，立即继续执行渠道类系统的后续操作。

与之相类似，更简单的一种场景就是NFS，当server如果来自另一个系统，尚未完成启动，则nfs client会处于重试状态，NFS server not responding, still trying，会一直重试，直到server和NFS文件系统准备好，之后client端完成NFS挂载，继续执行后续步骤。这应该就是各强关联和强依赖业务系统必须改造，改造后要达到的效果。

@leodong 系统工程师：

对于紧耦合的业务系统一般切换的时候都是按照一个整体一起切换的，尤其是有大量业务数据交互、延迟敏感的业务系统，即使是二层通延时也会成倍增加。不可能针对每一个业务系统都搭建一个测试环境。为了测试容灾切换平台，可以建立一个标准的测试环境，一般就是启动、停止、检查等标准的任务或命令，可以完成一些基本的测试。

7、灾备自动化切换具备的条件有哪些？应该如何规划？

【问题描述】保险企业如何实现业务由生产中心自动切换到灾备系统？自动化切换的条件有哪些？如何规划？

@潘延晟 系统工程师：

本身灾备的架构就是比较复杂的一套架构。在规划灾备时首先要考虑的就是所有的业务，包括业务类型，业务特点，数据量，重要程度等等，根据实际的情况制定出生产中心的系统架构，主备数据中心之间的距离。数据通信方式及带宽，首先要先保证主备数据中心的业务，数据能够准确的同步运行，通过仲裁判断满足某些条件，比如主数据中心管网络故障，设备宕机等情况后决定切换到灾备系统，但每个公司的实际情况都不同。所以切换条件也要根据实际运行中逐渐摸索改进。另外最主要的是要定期进行切换演练。

@leodong 系统工程师：

第一个问题讨论过，起码要有以下工具才可以实现1、监控平台：监控工具需要能够准确 发现、定位故障，并且能够推送到容灾管理平台。2、容灾管理平台：容灾管理平台需要准确的展示业务系统在生产与容灾数据中心的整体架构，并且清楚内部与外部的访问关系以及依赖关系。才能准确的下发自动切换任务。3、自动化任务平台：能够准确定义切换流程，并且反馈切换过程中的详细信息，能将切换状态反馈给容灾管理平台，完成切换任务工作。针对于如何规划：越是双活越是容易自动切换，同时对于技术的要求也越高，现在一般都可以做到应用双活，数据库双活需要根据本身的技术能力以及业务系统特点决定。

8、在双活数据中心架构下，自动化切换的工具平台有哪些选择？自动化切换的前提条件大致有哪些?

@cpc1989 某保险公司 存储工程师：

个人理解是，自动化切换的工具平台需要与数据中心灾备管理工作深度集成，并不是简单使用一套工具就能实现的。灾备自动化切换的工具平台大致需要满足三大的功能点：1.自动化能力，包括集成现有类似Ansible这种的自动化工具，在不同运行环境执行切换命令和脚本 2.流程编排能力，灾备切换演练流程能按需编排，需要设立一些检查确认点， 子流程之间流程关联等 3.与CMDB的集成，切换脚本的配置维护，切换前后的配置比对和检查，展示切换过程中的业务数据流的变化等等

@zhangyongjun CMBC 工程师：

双活数据中心的运行方式，通常有两种，网络大二层打通的方式和隔离的方式。网络大二层打通的方式，可以采用负载均衡的方式，通过软件或者F5实现随机派发，写入同一套双活数据库中（如DB2 PureScale或者Oracle CRS等）。如果是网络隔离的方式，主机房和灾备机房实际上是分开的，数据库是两套，应用也不是负载均衡的方式，在应用端必须实现双写。

在切换时，网络大二层打通的方式按照流程定义的步骤直接停止再启动灾备端应用和数据库以及生产端应用和数据库，来验证单独生产端、单独灾备端能否承载业务；网络隔离方式灾备验证第一步要控制双写的应用的流量，进行流量切换，只写一端，即实现了灾备切换，之后再对应用和数据库进行启停操作，最后进行流量恢复。

更重要的是设计方案，自动化平台可以采用任意的平台，如商用BMC、MicroFocus、开源ansible等都可以作为自动化引擎，但是需要自行设计流程，如cpc1989所讨论。

@潘延晟 系统工程师：

现在信息化的架构越来越复杂。虽说是双活。但是落实到每一个实际的环境中都不一样。从服务器硬件，存储和网络到上层虚拟化和实际应用都不一样。一般来说很难有那种自动化平台可以实现广泛应用。所以基本都涉及到针对实际业务的二次开发，另外，不同的公司环境也不同，信息化的投入。数据中心之间的线路，业务的实际情况，技术人员储备这些都决定双活切换是否成功。

基于以上的原则我觉得双活数据中心更应该注重的是一整套体系流程。而不能只关注双活数据中心架构的技术，因为信息化架构的问题可能是千差万别，自动化切换只能是一个美好的目标，实际环境中可能会因为各种各样的遗漏导致自动化切换失败，所以从整体的架构设计业务流程，故障流程，切换条件以及定期的应急演练。缺一不可。没有最好的自动化切换平台。只有最适合的。

@赵海 技术经理：

在双活数据中心架构下，自动化切换的工具平台有哪些选择？

这个问题首先得确定那一层的自动化切换工具平台？网络、应用、数据库、存储，每一层都有每一层的不同架构，不同的架构又决定了不同的自动化切换方法。例如数据库层，如果是RAC模式，那么靠RAC自身的浮动IP切换机制实现，如果是ADG,理论上可以靠ADG的自动化切换机制实现；例如存储层，如果是虚拟化网关的架构，那么可以靠虚拟化网关自身的切换机制实现…

自动化切换的前提条件大致有哪些?

自动化切换的前提条件包括三个主要方面：首先，对故障场景的探测机制，例如网络心跳、磁盘心跳之类的探测机制，主要用来判断点的健康存活状况；其次，需要有第三方的参照机制，也就是通常所说的仲裁物，例如数据库的仲裁盘、存储的仲裁服务器等等。再有，数据上的同步情况以及应用会话的同步情况，必须保障切换之后应用会话及数据的延续性。

9、灾备切换自动化编排过程中，如何去设计关联业务层的前置性或关联性的检查？

【问题描述】考虑到有些应用的深度耦合，会产生前后串联管理，对业务的启停有严格前置条件。灾备切换自动化编排过程中，如何去设计关联业务层的前置性或关联性的检查。

@zhangyongjun CMBC 工程师：

业务的依赖性，不建议在灾备流程中实现，建议在应用设计中考虑，最好不要深度耦合，尽量采用重试机制来进行探测和重连。

举个简单例子吧，安保系统，对银行其他系统来说非常重要，大多需要依赖，尤其是渠道类如柜面、手机银行、网银等系统。

如果同时进行切换，可能渠道类系统先进入到应用启动的步骤，这时就需要应用端进行探测和等待，直到安保系统完成启动之后，渠道类探测到操作完成，连接到可用的安保平台。

在灾备自动化流程中实现前置和关联检查会造成流程复杂度大大增加，不利于今后的变更和灾备演练。灾备自动化最多依据安保提供的连通性判断脚本或者RESTful接口进行判断，一待完成判断后，立即继续执行渠道类系统的后续操作。

与之相类似，更简单的一种场景就是NFS，当server如果来自另一个系统，尚未完成启动，则nfs client会处于重试状态，NFS server not responding, still trying，会一直重试，直到server和NFS文件系统准备好，之后client端完成NFS挂载，继续执行后续步骤。这应该就是各强关联和强依赖业务系统必须改造，改造后要达到的效果。

@leodong 系统工程师：

对于容灾切换管理平台一定是在设计阶段制定好关联关系的，在切换的过程并行的任务可以同时执行，对于串行的任务一定是串行并且提供检查方式的，一般任务分为执行任务+检查任务。对于强关联深度耦合的系统容灾切换的时候建议是最为一个整体去切换的。而且在设计阶段尽量设计为各个业务系统之间是松耦合的，避免一个业务系统与多个业务系统之间都相互关联。

10、相比于手工切换来说，灾备自动化切换更需要关注哪些灾备管理方面？

【问题描述】相比于手工切换来说，灾备自动化切换更加便捷，但必然需要增加更多的日常管理工作，主要体现在哪些方面？

@leodong 系统工程师：

容灾自动切换平台的管理：1、监控的管理：对于生产环境与灾备环境要配置准确、详细的监控策略，控制切换触发条件。2、容灾管理平台：容灾管理平台的管理，容灾管理平台要能准确体现业务系统物理以及逻辑架构、业务数据流、系统关联关系。3、自动任务工具：自动任务工具能准确的配置切换流程，同时对于切换流程有严格的控制，执行任务+检查任务都可以准备执行以及反馈。4、变更管理：针对于投产变更，如果有相关变更，要同步变更监控策略、容灾管理平台的架构以及业务切换流程以及相关的任务命令等。保证容灾自动切换平台始终与生产环境一致是重中之重。

@zhangyongjun CMBC 工程师：

注意自动化带来的风险泛滥，一定要实现脚本的幂等性，可以多次执行。

最重要的是一定要保证变更的同步。

千万不要把灾备切换平台作为一个独立的平台，要和CMDB、变更操作紧耦合，任何基础软硬件、应用的重要变更和版本升级、扩缩容操作一定要派发任务单，保证灾备平台的同步。

除被动响应之外，还要有主动性的检查机制。两地三中心一致性比对工具的建设对保证灾备切换的成功率很重要。

桌面演练功能，会生成具体的操作步骤、执行顺序、调用的脚本、执行的参数，这么说吧，除了脚本没有真正去执行，其他与真实切换完全一样，因为每个脚本都实现了是否桌面演练还是真实切换换的分支。桌面演练的报告发送应用负责人和基础硬软件、网络、存储等相关技术模块支持人员进行切换前的人工复核。

—— 要发挥主观能动性要靠赏，而事急宜罚，确定流程中每个步骤的负责人，写入灾备流程中，并自动生成在报告上，演练后进行总结，确定自动化步骤失败的责任人，只需要每个步骤罚款就行了，连续几次之后，自动化的成功率绝对能达到99.9%以上！：-）

@dataprotect 某保险公司 系统运维：

除切换操作外，还需要维护容灾通讯录以及自动呼叫信息，以实现灾难自动呼叫通知。这块可以和公司的ad以及ps系统等对接，容灾管理员主要关注容灾角色与人员的关联，容灾话术的维护等。当然，随着即时通讯产品的发展及功能的完善，直接拉一个大群统一播报可能更加直接、高效。

11、灾备自动化切换的流程应该如何制定和维护？如何体现工具在其中的作用？

@leodong 系统工程师：

灾备自动化切换流程主要根据业务的系统的架构来制定：主备中心、双活中心、与其他业务系统关联性、是否有专线外联等。切换的流程每个执行单元或者任务需要能够检查，可以配置执行任务+检查任务，同时可以展示；有详细的输出，可定位诊断。流程的维护就需要与平时投产变更相关联，保证切换流程与实际情况一直保持一直。同时做的好的话，可以与CMDB相结合，同步关联，保证与生产环境的一致性，而不是每次真实演练都需多次的模拟演练测试流程。对于工具监控工具检查生产容灾运行情况，是否可切换，以及定位故障，将故障发给容灾管理工具，容灾管理工具根据容灾架构下发给自动任务工具 下午自动切换流程。同时容灾管理工具要能对整体切换流程可展示。

12、自动化切换如何修改中间件至数据库的数据源配置？

@leodong 系统工程师：

不只是中间件，应用程序连接数据库更改为容灾数据库连接可以有以下几种办法：1、二层通的业务系统，可以直接切换数据库对于应用的服务IP地址即可。2、三层的业务系统，可以使用DNS域名访问，应用程序无需变动。3、如果不适用DNS，可以在应用系统里面配置hosts文件替换任务，将数据库的IP地址替换为同城容灾环境。应用程序也不需要改动，可能需要应用程序重新连接。4、架构上配置为生产连接生产的数据库，同城连接同城的数据库，整体切换同城就无需更改连接数据源。此架构应用程序是冷备，可能存在投产包不一致的问题，就需要控制投产的过程中严格控制。

@zhangyongjun CMBC 工程师：

灾备切换无需修改数据源中的数据库地址。

一般数据库IP使用如下两种方式进行切换：

1、数据库一般都要配置高可用，也就是要有服务IP，在切换的时候，服务IP可以随着切换到到灾备端，通过向灾备端集群增加服务IP、重新apply灾备集群的方式将服务IP配置到灾备环境集群中。

2、使用DNS，主备机房集群使用不同的服务IP。这时jdbc连接串只需要使用域名即可，切换到灾备端之后，需要更改DNS服务器中域名的指向，指向到灾备端的IP地址。

综上，任何一种方式，都不需要更改JDBC连接串中的数据库地址。

@潘延晟 系统工程师：

简单的环境里。你可以通过域名来做数据源。所有中间件都指定到统一的域名数据源上，，这样以后无论是更换中间层，还是变更数据库都只要修改DNS映射就可以了。可以避免大量的修改中间件配置的工作。

13、灾备自动化切换工具该如何选型？

【问题描述】关于灾备切换，有以下两个问题希望看看专家的意见和建议，谢谢！1、如何选择自研的灾备切换平台还是商业版的切换平台？主要基于哪些考虑？2、切换过程中难免会有业务影响，如果要做定期切换演练，需要和哪些关联方进行沟通以及如何沟通以确保切换演练高效进行？

@李周华 同创永益 灾备咨询服务部总监：

灾备切换平台建议在商业版的切换平台上进行部分定制改造，两点考虑：

1，商业版的切换平台进行了充分技术测试，并且适用于比较广泛的场景，大大避免了底层琐碎的技术难点。

2，灾备系统是根据业务连续性需求进行开发，因此每个客户灾备切换策略和技术架构细节均会有所不同；而且每个客户对灾备切换平台的定位不尽相同，灾备切换平台与监控运维平台、各业务系统的相互协作方式也会不同，因此为了更好的使用灾备切换平台，需要进行一定的定制改造工作。

如果您选择的灾备切换平台成功案例比较丰富，适用广泛的行业、客户、应用系统、灾备场景，那么定制改造的工作量就会比较少，系统上线时间会更短，灾备实际切换和管理效果就会更好。