前言：
自动化切换计划的难点，首先在于零碎自身及强关联系统（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，灾备零碎是依据业务连续性需要进行开发，因而每个客户灾备切换策略和技术架构细节均会有所不同；而且每个客户对灾备切换平台的定位不尽相同，灾备切换平台与监控运维平台、各业务零碎的相互协作形式也会不同，因而为了更好的应用灾备切换平台，须要进行肯定的定制革新工作。
如果您抉择的灾备切换平台胜利案例比拟丰盛，实用宽泛的行业、客户、利用零碎、灾备场景，那么定制革新的工作量就会比拟少，零碎上线工夫会更短，灾备理论切换和治理成果就会更好。
如果您有任何其余问题，也欢迎您与咱们分割，咱们会第一工夫响应您的需要。也欢迎您关注咱们~
微信、微博、知乎：@同创永益
官网：https://www.hatech.com.cn/