保险行业灾备自动化切换建设方案设计及难点解读

保险行业灾备自动化切换建设方案设计及难点解读

自动化切换方案的难点，首先在于系统本身及强关联系统（CMDB）需要尽量在第三方部署，以避免灾难发生时系统本身的失效。其次，灾备切换各种脚本及服务需要建立开发及维护标准，避免由于脚本或者配置变化，真正切换时出现问题导致切换失败。需要定期检视这些脚本和工具，最好的办法是加大切换演练的频率，在演练中发现问题，解决问题。最后，切换本身的日志记录、展示及切换进展跟踪非常关键，在切换异常需要回退时，需要有办法能快速回切。twt社区为了能更好的解决保险行业同行在灾备自动化切换方案及遇到的难点问题，特意邀请同行以及同创永益专家进行在线交流互动，以下是本次交流活动的精华内容汇编，对保险乃至金融行业用户用参考价值。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的要求；第二层，在一个整体方案需求的前提下，再来看业务系统关联的应用和数据库，设计相应的灾备建设方案，第二层的RTORPO要求会比第一层要求更高；然后才是第三层，也就是在基础架构组件的灾备方案选择，比如网络大二层打通，存储双活或者复制技术，这一层是纯技术层方案，并不直接实现灾备方案，是配合第二层来实现的，RTO、RPO要求更高

。整体方案拆解下来之后，就能真正明确各个技术方案虽然有交叉的点，但是各有侧重。比如基于数据库的数据同步方案是一个第二层的方案，要优于第三层的存储层数据同步方案，逻辑更完整，但是存储同步或复制可以解决存储自身的RTORPO需求，能配合实现应用和数据库的灾备方案。@zhangjunxi570xjtu系统分析师：存储复制技术不用担心脑裂。存储双活需要部署仲裁，在两中心通信中断时决策。可以关注关注一些存储厂商厂商为了防止仲裁不可用不可用或者由于网络原因仲裁不可达，增加了多仲裁等方案。通常情况一个仲裁在第三站点，一个仲裁在主中心。脑裂发生时保生产更重要。@leodong

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

银行系统架构师：数据中心级别的同步是个很庞大工程，涉及业务系统多。个人认为应该先解决灾备建设技术栈的体系规划。数据同步不是人家说好就跟，第三方的，存储级别，数据库原生级。

可能新公司如互金类能完全一统成一种技术，没有历史欠账包袱o(￣︶￣)o。

传统行业技术转型都有剧痛啊。阁下说数据库切换时如何防止脑裂？有点不解，是ExtendRAC嘛，这个玩意是比较复杂。常规主从复制，发生脑裂不影响切换，

切换就是抛弃主，启用备。

若果是存储，你们应该建设第三站点。灾备切换判断应该是业务使用视角来判断，一定不是技术来定。可以参考业务连续性相关资料。@guwenkuan

金融行业系统架构师：之前同创永益的灾备咨询总监回答的已经比较全面，从技术层面上，主流的技术实现方式都很成熟了，主要还是从灾备建设的需求和业务系统现状出发，包括资金投入等，选择适合企业自身的灾备体系。2、灾备演练结束后回切前需要完成的工作有哪些？【问题描述】灾备演练完成后需要回切，如何保证各系统的一致性？除了数据要同步，有哪些问题需要注意？请专家指导一下。@zhangyongjunCMBC工程师：单个系统一致性，可以通过数据复制、数据库同步等技术来保证，只要保证灾备端的数据能正常写回主生产环境，或者如果全部是测试数据，可以直接将灾备环境数据抛弃。系统间最好不要存在一致性问题，否则不好处理。回切前要对切换到灾备机房的应用系统进行业务验证，根据提前确定的方案和策略，安排各分支机构或者用户对演练的场景进行业务验证或者真实操作。业务验证之后，确保生产端设备做好准备，待灾备环境停止和数据回写完成之后，启动生产环境。只有一点需要特别关注：尽量不要在灾备演练的过程中进行主机房设备重启、维修等运维操作，很可能会导致灾备验证完成之后，主环境设备还没有准备好，造成报备的时间内无法恢复主生产，影响正常营业。@leodong

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

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

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

金融行业系统架构师：灾备回切时保证数据一致性，绝大程度取决于灾备体系的的技术整体架构，与数据的灾备实现方式有很大关系。一类通过存储层实现灾备保护，通过存储层面实现的数据保护的体系，各业务系统一致性实现起来比较容易，存储厂家对数据一致性绝大多数通过LUN数据一致性组来实现，这种实现方式比较可靠。通过存储实现的灾备分为存储双活、存储同步复制、存储异步复制。存储双活架构，优势比较明显，不存在数据一致性问题，两个同城数据中心的两套存储对等，两套存储实时对外服务，数据实时双写到两个存储，存储层无需任何操作，只需要进行上层数据库、应用的切换即可。存储同步和异步架构，切换时需要将上层业务关闭，存储层角色提升，系统一致性组断开才能保证数据一致性。一类通过数据库层面、主机层面技术、第三方软件等实现灾备架构，这种情况实现数据一致性是对单个库级别实现，无法保证多个系统数据一致性。回切期间，数据库方面，一定要正常关闭数据库、正常关闭应用等技术操作，防止存储层切回后数据库数据不一致，数据库无法打开的情况。3、目前保险行业的业务连续性管理现状如何？@冯军

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

信息技术经理：保险行业内保险公司可分为原保险、再保险，中介分为专业代理、兼业代理、经纪，还有公估……这么多业态，不能一概而论。即便是业务连续性做的比较好的原保险公司，在RTO/RPO的指标上也有差距。但是从大的趋势来说，随着业务的内在需求推动和监管的外在因素拉动，业务连续性要求必然是逐渐提高的。4、灾备系统自动化演练需要生产中心配置变更规范化，配置变更需要更新同步至灾备中心，如何进行同步状态验证？【问题描述】1、生产中心包含应用配置、数据库配置、网络配置、全局DNS配置，生产环境一但变更如何保证所有的配置变更均已同步至灾备中心？2、中小型金融机构若要实现灾备中心自动化演练如何进行投入产出比计算？@zhangyongjunCMBC工程师：两地三中心配置同步是一个建设难点，最主要的是灾备端经常处于standby或者停止状态，难以验证当前的配置是否完全一致。我们依据灾备管理系统、应用、数据库、中间件、OS的配置和CMDB，尝试建设了一个两地三中心一致性比对工具，确定关键配置，逐个建立检查和比对机制，随时进行比对并生成报表，尤其是生产环境变更之后和灾备演练前，及时进行检查。目前已经建立近百个比对项。另外，应用发布和基础软硬件变更工单中依据CMDB自动关联灾备环境，确保灾备端完成变更，不至于遗漏。最重要的多演练，把碰到的问题积累起来，经过解决之后再进行推广，一般的灾备演练系统经过每套系统五六次的演练之后，一致性的问题基本上能解决七七八八。@zhangjunxi570xjtu系统分析师：CMDB对数据中心内各环节的配置项进行全生命周期的管理。有CMDB至少可以保证有一份最新最准确的配置信息。有一些不涉及不涉及应用的例如操作系统参数的修改是可以在灾备环境同步操作的。但是真实情况很多配置修改不能在灾备中心实施，比如应用的发版如果灾备是备用的环境通常不能在生产发版的同时在灾备的环境里同步作修改；再比如网络的一些变更涉及复杂的路由路由和防火墙策略也不一定能让灾备和生产同时变更。这样启用灾备时灾备的灾备的环境和生产会存在一些差异。因此灾备切换平台应具备这样的能力或者考虑到这些工作：即从CMDB甚至是手工维护的信息里去比对灾备没有添加上的配置，在切换前消除差异。这项工作比调度切换更繁琐也是真正见识灾切平台交付能力的地方。@leodong

系统工程师：如果配置了完成CMDB,并且实际中已经很好的应用了，可以依靠CMDB管理容灾环境的配置，前期不具备，首先对于管理上，对于有容灾的业务系统，投产变更就必须是同步投产的，为了避免有遗漏，可以设计检查点，监控配置检查项。比如生产环境配置文件与容灾环境配置文件时间相差较大等。通过监控对比生产与容灾环境的配置，但是这些监控只能根据投产经验逐渐完善。5、灾备自动化切换过程涉及较多专业软硬件产品（网络、安全、负载、各类数据库等），一般哪些不建议做自动化切换？@zhangjunxi570

xjtu

系统分析师：1.部分网络环境。城商行在建设同城灾备时一个主流的方案是大二层网络，拉通的二层一般将网关布在生产站点，自动切换要将二层的网关在同城站点启用涉及复杂路由及安全策略的配置，除非提前经过演练验证并将日常的维护做好记录梳理。如果两个站点是三层对接复杂度会降低。2.数据库的切换。目前OracleDb2都有数据库容灾方案，启用备库可以设置成自动化的。但是出于数据一致性的考虑，一般启用备库人工干预的。3.存储。存储情况比较复杂。如果搭建了同城双活的存储，配合仲裁，存储在两端可以自行管理。基于复制的存储容灾拉起备用存储可以配制成编排好的切换操作，通常不会自动切换。@zhangyongjunCMBC工程师：个人觉得这个问题要考虑对这些操作的把控程度，基本上没有操作不能自动化实现。我们采用的是同城网络大二层打通，存储复制技术（SWAP和STAR模式）实现的大同城小异地的灾备方案，要进行网络设备、操作系统、数据库、中间件、监控、应用、存储等操作。无论是主备机房同一个服务IP的方式（要增删服务IP和重新apply集群），还是DNS方案（流程中需要更改DNS服务器中的指向），以及外联只允许一个IP通过防火墙的特殊情况等等，都实现了自动化操作。建设初期，我们就实现了除同城演练存储SWAP回写步骤之外的所有自动化，只是担心存储回写步骤出现问题导致在同城灾备端通过各种渠道写入的真实业务数据被抹掉而采用了人工操作，经过数次演练验证之后，现在也实现了全自动化操作。目前，整个灾备演练流程，只有切换流程第一步“确定能否演练切换”和中间的“业务验证”，是人工操作，其他全部自动化操作。@leodong

系统工程师：无论是任何一种产品都可以配置成自动切换，主要是根据风险程度去决定是否进行自动化配置。但是可以逐渐去实现自动切换，而且不是开始就是自动化切换，对于应用、中间件、数据库等启动都可以自动化，但是涉及存储的虽然有可以自动化，为了安全可以前期先手工切换。制定了完备检查方案后，再纳入到自动切换中。6、紧耦合系统的灾备自动化切换如何演练？【问题描述】紧耦合系统的灾备自动化切换如何演练？测试环境如何准备，毕竟搭建一套生产灾备环境就很耗资源。@zhangyongjunCMBC工程师：同城演练时，对于紧耦合的系统，如果同城网络大二层打通状态，可以分别切换，无需考虑耦合；如果主备机房网络隔离，则必须将紧耦合的系统放在一起进行切换演练，逻辑上作为一个系统。我们没有对每一套系统分别建设灾备演练的测试环境，过于浪费！只是针对灾备系统使用的技术搭建了AIX集群、HP集群、Linux集群、分别使用SWAP、STAR存储技术以及Oracle、DB2、MySQL等数据库，F5应用集群、使用DNS的服务IP，大约不超过20台物理机+虚拟机完全能覆盖所有灾备技术。这些IT组件的自动化脚本是通用和参数化的，由参数驱动，参数的来源是灾备平台。灾备流程将每套系统每个IT组件和应用的参数从灾备平台中取出来，传递给自动化脚本，下发到目标主机去执行。无论多少套灾备系统，脚本都是同一套，所以无需搭建每一套灾备系统的测试环境。至于说一起切换时的启停顺序和依赖问题，我在另一个问题中刚刚做了答复，转帖过来：业务的依赖性，不建议在灾备流程中实现，建议在应用设计中考虑，最好不要深度耦合，尽量采用重试机制来进行探测和重连。举个简单例子吧，安保系统，对银行其他系统来说非常重要，大多需要依赖，尤其是渠道类如柜面、手机银行、网银等系统。如果同时进行切换，可能渠道类系统先进入到应用启动的步骤，这时就需要应用端进行探测和等待，直到安保系统完成启动之后，渠道类探测到操作完成，连接到可用的安保平台。在灾备自动化流程中实现前置和关联检查会造成流程复杂度大大增加，不利于今后的变更和灾备演练。灾备自动化最多依据安保提供的连通性判断脚本或者RESTful接口进行判断，一待完成判断后，立即继续执行渠道类系统的后续操作。与之相类似，更简单的一种场景就是NFS，当server如果来自另一个系统，尚未完成启动，则nfsclient会处于重试状态，NFSservernotresponding,stilltrying，会一直重试，直到server和NFS文件系统准备好，之后client端完成NFS挂载，继续执行后续步骤。这应该就是各强关联和强依赖业务系统必须改造，改造后要达到的效果。@leodong

系统工程师：对于紧耦合的业务系统一般切换的时候都是按照一个整体一起切换的，尤其是有大量业务数据交互、延迟敏感的业务系统，即使是二层通延时也会成倍增加。不可能针对每一个业务系统都搭建一个测试环境。为了测试容灾切换平台，可以建立一个标准的测试环境，一般就是启动、停止、检查等标准的任务或命令，可以完成一些基本的测试。7、灾备自动化切换具备的条件有哪些？应该如何规划？【问题描述】保险企业如何实现业务由生产中心自动切换到灾备系统？自动化切换的条件有哪些？如何规划？@潘延晟

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

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

存储工程师：个人理解是，自动化切换的工具平台需要与数据中心灾备管理工作深度集成，并不是简单使用一套工具就能实现的。灾备自动化切换的工具平台大致需要满足三大的功能点：1.自动化能力，包括集成现有类似Ansible这种的自动化工具，在不同运行环境执行切换命令和脚本

2.流程编排能力，灾备切换演练流程能按需编排，需要设立一些检查确认点，子流程之间流程关联等

3.与CMDB的集成，切换脚本的配置维护，切换前后的配置比对和检查，展示切换过程中的业务数据流的变化等等@zhangyongjunCMBC工程师：双活数据中心的运行方式，通常有两种，网络大二层打通的方式和隔离的方式。网络大二层打通的方式，可以采用负载均衡的方式，通过软件或者F5实现随机派发，写入同一套双活数据库中（如DB2PureScale或者OracleCRS等）。如果是网络隔离的方式，主机房和灾备机房实际上是分开的，数据库是两套，应用也不是负载均衡的方式，在应用端必须实现双写。在切换时，网络大二层打通的方式按照流程定义的步骤直接停止再启动灾备端应用和数据库以及生产端应用和数据库，来验证单独生产端、单独灾备端能否承载业务；网络隔离方式灾备验证第一步要控制双写的应用的流量，进行流量切换，只写一端，即实现了灾备切换，之后再对应用和数据库进行启停操作，最后进行流量恢复。更重要的是设计方案，自动化平台可以采用任意的平台，如商用BMC、MicroFocus、开源ansible等都可以作为自动化引擎，但是需要自行设计流程，如cpc1989所讨论。@zhangjunxi570

xjtu

系统分析师：双活数据中心背景下，业务都改造成在两个数据中心同时对外服务，需要在两个在两个数据中心之间合理分担调度请求端（各种渠道）来的业务请求，因此通常会部署GTM全局负载均衡设备负载流量，同时一个数据中心不能对外服务后调度调度原来分发到该数据中心的请求切换到存活的站点。因此双活站点自动化切换首先要能够很好的对接GTM。要明确一个数据中心故障检测的的标志，一定要准确并且配置一定超时时间。第三，通常不可能将不可能将所有业务改造成双活模式，双活站点也有主备之分，切换要不要自动化是值得商榷的，需要公司各级领导商讨出一个共同认可的做法的做法。通常切灾备不是自动的不是自动的。@潘延晟

系统工程师：现在信息化的架构越来越复杂。虽说是双活。但是落实到每一个实际的环境中都不一样。从服务器硬件，存储和网络到上层虚拟化和实际应用都不一样。一般来说很难有那种自动化平台可以实现广泛应用。所以基本都涉及到针对实际业务的二次开发，另外，不同的公司环境也不同，信息化的投入。数据中心之间的线路，业务的实际情况，技术人员储备这些都决定双活切换是否成功。基于以上的原则我觉得双活数据中心更应该注重的是一整套体系流程。而不能只关注双活数据中心架构的技术，因为信息化架构的问题可能是千差万别，自动化切换只能是一个美好的目标，实际环境中可能会因为各种各样的遗漏导致自动化切换失败，所以从整体的架构设计业务流程，故障流程，切换条件以及定期的应急演练。缺一不可。没有最好的自动化切换平台。只有最适合的。@leodong

系统工程师：容灾的自动化切换是需要各种工具相互配合才能实现的。1、监控平台：监控工具需要能够准确

发现、定位故障，并且能够推送到容灾管理平台。2、容灾管理平台：容灾管理平台需要准确的展示业务系统在生产与容灾数据中心的整体架构，并且清楚内部与外部的访问关系以及依赖关系。才能准确的下发自动切换任务。3、自动化任务平台：能够准确定义切换流程，并且反馈切换过程中的详细信息，能将切换状态反馈给容灾管理平台，完成切换任务工作。@赵海

技术经理：在双活数据中心架构下，自动化切换的工具平台有哪些选择？这个问题首先得确定那一层的自动化切换工具平台？网络、应用、数据库、存储，每一层都有每一层的不同架构，不同的架构又决定了不同的自动化切换方法。例如数据库层，如果是RAC模式，那么靠RAC自身的浮动IP切换机制实现，如果是ADG,理论上可以靠ADG的自动化切换机制实现；例如存储层，如果是虚拟化网关的架构，那么可以靠虚拟化网关自身的切换机制实现...自动化切换的前提条件大致有哪些?自动化切换的前提条件包括三个主要方面：首先，对故障场景的探测机制，例如网络心跳、磁盘心跳之类的探测机制，主要用来判断点的健康存活状况；其次，需要有第三方的参照机制，也就是通常所说的仲裁物，例如数据库的仲裁盘、存储的仲裁服务器等等。再有，数据上的同步情况以及应用会话的同步情况，必须保障切换之后应用会话及数据的延续性。9、灾备切换自动化编排过程中，如何去设计关联业务层的前置性或关联性的检查？【问题描述】考虑到有些应用的深度耦合，会产生前后串联管理，对业务的启停有严格前置条件。灾备切换自动化编排过程中，如何去设计关联业务层的前置性或关联性的检查。@zhangjunxi570

xjtu

系统分析师：关联系统启动时有先后顺序，切换工具依据前置任务的返回结果，即检查前一个业务启动后进程端口的状态，或者或者向前一个系统发探测包系统发探测包收到期望的结果后，确认前一个系统完全启动，再执行下一个任务。也可以和监控系统配合，每一项任务执行完成后主动去监控系统采集当前任务状态。@zhangyongjunCMBC工程师：业务的依赖性，不建议在灾备流程中实现，建议在应用设计中考虑，最好不要深度耦合，尽量采用重试机制来进行探测和重连。举个简单例子吧，安保系统，对银行其他系统来说非常重要，大多需要依赖，尤其是渠道类如柜面、手机银行、网银等系统。如果同时进行切换，可能渠道类系统先进入到应用启动的步骤，这时就需要应用端进行探测和等待，直到安保系统完成启动之后，渠道类探测到操作完成，连接到可用的安保平台。在灾备自动化流程中实现前置和关联检查会造成流程复杂度大大增加，不利于今后的变更和灾备演练。灾备自动化最多依据安保提供的连通性判断脚本或者RESTful接口进行判断，一待完成判断后，立即继续执行渠道类系统的后续操作。与之相类似，更简单的一种场景就是NFS，当server如果来自另一个系统，尚未完成启动，则nfsclient会处于重试状态，NFSservernotresponding,stilltrying，会一直重试，直到server和NFS文件系统准备好，之后client端完成NFS挂载，继续执行后续步骤。这应该就是各强关联和强依赖业务系统必须改造，改造后要达到的效果。@leodong

系统工程师：对于容灾切换管理平台一定是在设计阶段制定好关联关系的，在切换的过程并行的任务可以同时执行，对于串行的任务一定是串行并且提供检查方式的，一般任务分为执行任务+检查任务。对于强关联深度耦合的系统容灾切换的时候建议是最为一个整体去切换的。而且在设计阶段尽量设计为各个业务系统之间是松耦合的，避免一个业务系统与多个业务系统之间都相互关联。10、相比于手工切换来说，灾备自动化切换更需要关注哪些灾备管理方面？【问题描述】相比于手工切换来说，灾备自动化切换更加便捷，但必然需要增加更多的日常管理工作，主要体现在哪些方面？@leodong

系统工程师：容灾自动切换平台的管理：1、监控的管理：对于生产环境与灾备环境要配置准确、详细的监控策略，控制切换触发条件。2、容灾管理平台：容灾管理平台的管理，容灾管理平台要能准确体现业务系统物理以及逻辑架构、业务数据流、系统关联关系。3、自动任务工具：自动任务工具能准确的配置切换流程，同时对于切换流程有严格的控制，执行任务+检查任务都可以准备执行以及反馈。4、变更管理：针对于投产变更，如果有相关变更，要同步变更监控策略、容灾管理平台的架构以及业务切换流程以及相关的任务命令等。保证容灾自动切换平台始终与生产环境一致是重中之重。@zhangyongjunCMBC工程师：注意自动化带来的风险泛滥，一定要实现脚本的幂等性，可以多次执行。最重要的是一定要保证变更的同步。千万不要把灾备切换平台作为一个独立的平台，要和CMDB、变更操作紧耦合，任何基础软硬件、应用的重要变更和版本升级、扩缩容操作一定要派发任务单，保证灾备平台的同步。除被动响应之外，还要有主动性的检查机制。两地三中心一致性比对工具的建设对保证灾备切换的成功率很重要。桌面演练功能，会生成具体的操作步骤、执行顺序、调用的脚本、执行的参数，这么说吧，除了脚本没有真正去执行，其他与真实切换完全一样，因为每个脚本都实现了是否桌面演练还是真实切换换的分支。桌面演练的报告发送应用负责人和基础硬软件、网络、存储等相关技术模块支持人员进行切换前的人工复核。——要发挥主观能动性要靠赏，而事急宜罚，确定流程中每个步骤的负责人，写入灾备流程中，并自动生成在报告上，演练后进行总结，确定自动化步骤失败的责任人，只需要每个步骤罚款就行了，连续几次之后，自动化的成功率绝对能达到99.9%以上！：-）《智囊》有个故事可以参考

：鲁人烧积泽，天北风，火南倚，恐烧国。哀公自将众趋救火者，左右无人，尽逐兽，而火不救。乃召问仲尼，仲尼曰：“夫逐兽乐而无罚，救火者苦而无赏，此火之所以不救也。”哀公曰：“善。”仲尼曰：“事急，不及以赏救火者；尽赏之，则国不足以赏于人。请徒行罚。”乃下令曰：“不救火者，比降北之罪；逐兽者，比入禁之罪。”令下未遍，而火已救矣。贾似道为相，临安失火，贾时方在葛岭，相距二十里，报者络绎，贾殊不顾，曰：“至太庙则报。”俄而报者曰：“火且至太庙。”贾从小肩舆，四力士以椎剑护，里许即易人，倏忽即至，下令肃然，不过曰：“焚太庙者斩殿帅。”于是帅率勇士一时救熄。贾虽权奸，而威令必行，其才亦自有快人处。@dataprotect某保险公司

系统运维：除切换操作外，还需要维护容灾通讯录以及自动呼叫信息，以实现灾难自动呼叫通知。这块可以和公司的ad以及ps系统等对接，容灾管理员主要关注容灾角色与人员的关联，容灾话术的维护等。当然，随着即时通讯产品的发展及功能的完善，直接拉一个大群统一播报可能更加直接、高效。11、灾备自动化切换的流程应该如何制定和维护？如何体现工具在其中的作用？@zhangyongjunCMBC工程师：流程一定要通用，尽量实现场景驱动，一定不要一套系统一个场景对应一个流程，否则难以维护，无法应对千变万化的场景，无法应对日渐增加的灾备系统梳理，更无法应对灾备系统的变更。比如，典型非双活灾备方案中最简单的流程可以定义为六步：1.

停止主生产2.

启动灾备3.

业务验证4.

停止灾备5.

启动主生产6.

业务验证每一个大的步骤再按需要进行细分，进一步实现标准化、通用化、自动化、参数化。工具实现数据维护、操作界面、流程监控、大屏展示、多部门沟通、演练报告和报表等灾备演练相关功能，以及自动化引擎等功能。工具实现了场景驱动，将每套系统的配置数据与流程步骤数据分开，实现参数化驱动，进一步将流程步骤与脚本分开，实现自动化驱动。

@leodong

系统工程师：灾备自动化切换流程主要根据业务的系统的架构来制定：主备中心、双活中心、与其他业务系统关联性、是否有专线外联等。切换的流程每个执行单元或者任务需