应急预案里面明确写出，哪些场景应对哪些流程？什么样的故障启动什么级别的汇报
由于我们的灾备架构设计，我们的首要目标是保障切换成功条件下尽量缩短切换时间，所以我们把灾备步骤最大程度的自动化，部分必要的业务验证等步骤是人工步骤，其余涉及网络，存储，中间件，操作系统，数据库，应用的动作都是自动化步骤。您提到的误判和误操作，我的理解可能出现在平台本身，数...
做好业务和虚拟机已经 虚拟化的物理机监控,在监控触发业务故障情况下,进行故障分析, 需要一个elk平台和, 故障分析平台再次通过监控分析结果触发容灾级别的故障切换, 自动化平台承接底层切换过程, 包括网络和负载均衡设备的配置.前提示你有业务监控分析和故障分析平台...
针对目前网络隔离的现状，实现双活比较平滑的过度，网络可以建设一个出口，双活中心二层打通，这样好处是不用改变原来的ip,平滑过度。
应用的灾备切换，这个还是要提前做好应用标准化，比如我行所有系统目前都支持在指定的标准目录使用标准命名脚本实现分步骤或者一键式启停，在实现应用标准化后也能方便接入运维自动化系统方便进行统一的管理...
我理解您说的应用是具体的业务系统，业务系统按照重要程度，灾备级别可能是2:1,2:2或者是双活，目前灾备指挥平台支持上诉场景的灾备切换。在业务系统灾备上线时，我们会联系负责人梳理参与切换的应用模块范围，尽量保证一个灾备业务系统的闭包，使得应用内部的模块切换不依赖其他应...
同城的灾备切换是每半年一次，我行是所有系统统一进行切换，如果是负载均衡系统需要进行停单边一周进行业务检验。异地灾备切换目前是重要信息系统进行切换，每季度进行一次连通性测试。...
建立完善的配置库, 所有变更信息 灾备平台上进行更新和重新部署所有相关变更影响到 切换的信息都应 在灾备切换流程中有重配置
1、结合个人的经验，在灾备系统数量较多的情况，应该以业界连续行管理理论作为指导，首先从业务角度进行分级管理，高等级应用优先保证回复，例如达到几十分钟级别，低等级应用可以容忍恢复时间，在几天内完成2、对于灾容场景复杂，场景较多的情况，如果每个都制定预案，预案多，演练多，成本高。...
