灾备自动化带来的是灾备切换效率的提升，业务RTO减少，人为误操作可能性降低等诸多优势，但是，灾备切换由于可能会涉及到较多的业务系统，业务数据一致性和可用性的要求高，尤其是银行类业务系统，业务类型多，关联关系复杂，实现灾备自动化相对复杂度较高，需要通过业务梳理，权重判定，业务依...

按照系统进行分析, 切换条件和切换业务涉及的应用和内容网络连接部分按照应用完成切换操作步骤存储切换按照应用切换顺序进行规划,完全需要安装切换应用的过程进行每个业务应用切换,前验证切换条件,后验证切换是否成功自动切换条件一般 为网络故障,应用无法连接, 存储故...

1、脑裂主要一般说的是一些部件高可用协议层面，两个节点同时认为自己为主节点。在双活架构下，一般数据中心级别切换一般需要人工介入，全部自动化触发同城切换的案例我还没有见到（一方面监控主要、切换工具自身可能存在故障或者误判，并且概率较发生数据中心故障更高。第二，切换...

高端存储都有存储同步复制技术 可采用其他业务可做分布式写入oracle rac 可以用备库技术看你的业务对数据丢失的抗风险能力, 如果数据完全不可丢失, 必须使用同步复制技术. 如果可小部分丢失(30秒以内)可考虑异步,延迟问题需要同多方面进行io优化, 最简单的还是数据压缩...

定义好切换流程,人力资源配合能自动化的全部自动化化操作, 手工操作的只能是点击按钮切换速度一定会很快, 但很多部门不配合你做这个, 就没办法了

新华三，华青融天等公司都有灾备管理平台，但是大部分的商用产品在具体应用都会出现水土不服，大多需要进行二次开发。

1、结合个人的经验，在灾备系统数量较多的情况，应该以业界连续行管理理论作为指导，首先从业务角度进行分级管理，高等级应用优先保证回复，例如达到几十分钟级别，低等级应用可以容忍恢复时间，在几天内完成2、对于灾容场景复杂，场景较多的情况，如果每个都制定预案，预案多，演练多，成本高。...

由于我们的灾备架构设计，我们的首要目标是保障切换成功条件下尽量缩短切换时间，所以我们把灾备步骤最大程度的自动化，部分必要的业务验证等步骤是人工步骤，其余涉及网络，存储，中间件，操作系统，数据库，应用的动作都是自动化步骤。您提到的误判和误操作，我的理解可能出现在平台本身，数...

灾备自动化设计基本是在运维中心完成的应用部门对切换前后的业务状态进行检查设计好的应用在开发阶段解决数据复制技术应该是最好的方式目前金融开发 还不能和互联网模式相比随着分布式业务的开发模式 相对成熟, 日后 分布式数据库, 分布式业务系统上线灾备切换相对容易...

针对目前网络隔离的现状，实现双活比较平滑的过度，网络可以建设一个出口，双活中心二层打通，这样好处是不用改变原来的ip,平滑过度。