近年来随着银监会《商业银行数据中心监管指引》和《商业银行业务连续性监管指引》等规范的陆续出台，监管部门对商业银行信息系统业务连续性管理提出了很高的要求，特别是要求定期开展灾备切换演练，而随着业务系统架构多样性及复杂性的不断提高，整个切换流程将变得越来越复杂，同时演练中对于流程控制的要求也变得越来越高。
民生银行在灾备建设中采用的是大同城小异地的两地三中心灾备方案，同城两个机房采用了网络大二层打通的技术，主要目的是实现同城应用双活和系统在任意机房运行，在灾备技术方面，由于行内新核心刚刚上线不久，因此没有采用对应用有改造需求的应用端双活技术，而数据库日志传输技术可能会导致数据丢失，灾难时无法保证RPO=0，因此我们在现有技术栈基础上，采用了改造和影响最少的存储复制技术，虽然在切换过程中需要激活灾备端的各种资源，会导致RTO时间较长，但是可以尽力保证RPO=0。
存储复制技术带来的灾备切换问题主要有：流程复杂，切换步骤多，逐层操作的IT模块多，切换时间长。因为银行业务特点和技术栈的原因，我行业务系统数量非常多，而且使用了各种IT技术，存储方面有EMC SRDF/SWAP/STAR以及华为HyperReplication，数据库方面有DB2、ORACLE、MySQL、DB2 HADR、ORACLE RAC、MySQL MHA以及DB2 PureSacle GDPC、Oracle extend RAC等，操作系统方面包括Suse Linux、IBM AIX、HP Unix、Oracle Solaris以及相应的集群技术，中间件包括Weblogic、Tomcat、Apache、Nginx、ActiveMQ、IBM MQ等。日常灾备切换演练和真实灾备切换时间压力比较大。
灾备切换面临的主要问题除保证RPO的前提下尽量减小RTO外，还包括跨部门指挥协调问题、切换流程进度监控问题、以及众多流程的维护问题。灾备切换时要考虑如何解决这些问题，实现安全有序的灾备切换，这样就需要一款能自动化执行、对所有系统的切换流程可以指挥调度的平台。
我们从2015年开始进行灾备指挥平台的建设，项目初期我们曾尝试通过某IT公司咨询来解决我们的问题，但是后来发现洋洋洒洒几百页无法落地的ppt并不能解决上述问题，为此我们也曾了解过业内几个灾备切换产品，这些产品大多需要深度定制，而且大多无法实现自动化操作，或者在流程编排方面只能采用一个系统一个场景对应一个流程的方式编排，缺乏灵活性，当系统和场景复杂时对流程的维护是一个大问题。
基于以上背景，我们决定自行架构开发一套符合我行使用需求的灾备自动化调度指挥平台。
银行的数据中心一般采用两地三中心架构，分为同城生产和灾备中心，异地灾备中心，可能采用大同城架构，也可能大异地架构，甚至采用异地双活。目前因技术和财务限制，大多数银行业务没有采用双活架构，而是按照业务系统重要性在同城或者异地搭建容灾环境。常见的可能面对的灾难场景有整个站点故障、网络问题导致整个网络区域服务不可用、主机或者存储故障导致部分服务不可用，等等。那么平台不仅要支持单一系统的切换，还要支持多系统的站点的切换，针对网络区域故障、存储故障的切换。
考虑到场景复杂，灾备系统数量多，在确保RTO基础上，既要做到灾备切换过程可控，满足多种容灾场景，还要提高跨部门沟通效率，我们对平台需求做了如下分析：
1）架构分层，逐层解耦
为加快灾备建设进度，保护行内已有投入，灾备指挥平台需要采用松耦合分层架构，实现通用性和弹性，层与层之间没有强依赖，使用API接口调用，每一层都可以使用市面上符合要求的开源或商用产品。主要分层包括：展示层、数据层、调度指挥引擎、流程引擎、消息中间件层、自动化层。
2）将流程步骤与具体系统分开定义
业界部分产品平台采用一套系统一个场景对应一个流程的设计，最大的问题是无法灵活应对各类场景，无法充分复用标准化流程。我们希望架构一个平台，使用一套带有分支的标准通用流程，满足所有系统的各种切换场景。
3）依据切换的系统和选择的场景实时生成灾备切换流程
在模块化组件基础上建立一套通用流程，以及由此组合派生的与多种场景对应的切换流程，如何进一步实现具体应用系统的灾备切换呢？为更加弹性和通用性，就需要将流程本身与业务系统具体配置进行解耦。配置解耦就是将流程、系统、脚本解耦，将流程参数化，分别维护。在充分解耦的基础上，对通用流程进行定制，系统信息作为参数，把通用流程实例化成各个应用的各种场景流程。
为实现一个通用弹性满足我行灾备自动化切换要求的平台，我们建立了一个数据模型，用户前台确定需要切换的系统，选择相应的切换场景或方式，经数据处理引擎处理后，能自动生成针对该场景的流程步骤。弹性通用流程体系使用三层体系架构实现：模型化的通用组件、能反映灾备切换周期特点的灾备步骤、根据灾备特点由一个或多个灾备步骤组合而成的流程。通过系统名称再去关联系统配置信息，生成相关具体步骤和启停脚本使用的参数。生成应用系统对应的流程就是将该场景关联的通用流程实例化的过程，通用流程作为一个超集，应用只需实现自身需要的步骤，将应用配置信息作为参数传递给流程和脚本。数据处理引擎就是数据驱动的，能动态的将用户选择转换成可以用于调度指挥、自动化执行的流程的实现逻辑，如此平台就不必维护数百个流程。
3、灾备自动化调度指挥平台技术架构设计
我们同城中心网络是大二层，存储采用商用存储的复制技术，主机主要有小型机和x86服务器，灾备使用的技术种类繁多，如何在平台使用最少的组件、最少的流程来实现更多的可能，这是平台优先考虑的问题。
1）操作原子化
在现实生活中，乐高积木自由拼接、分层次搭建无疑是最典型的一种实现。一套通用积木块可以搭建成多种机器人，控制程序用于驱动机器人的可控积木块，让机器人动起来。各种机器人就相当于各种场景下的标准流程，控制程序相当于自动化实现的各个应用系统具体场景下的切换流程。对应于灾备自动化调度指挥平台，先构建模块化组件，搭建成通用的流程，再组合成各种场景流程，将组件绑定脚本实现自动化，再为每个应用系统实现定制化的流程。
我们将使用的IT产品标准化，匹配启停、检查等动作类型进一步模块化、原子化，再搭配通用脚本实现自动化。模块化组件是弹性流程的基础，简化了复杂的异构问题。针对我行使用的40多种IT产品，我们构造了60个自动化实现的模块化组件，编写了60个通用脚本，实现了所有产品的启停和状态检查。以此为基础，组合成一个具有500多个原子步骤的具有多个分支的通用切换流程。为多套应用系统实现了4700多个流程步骤，组成应对各种场景的600余套流程。
2）原子步骤的标准化操作分组
两个2*4大小的同色积木模块，它们有多少种搭建可能呢？——17种！
与之类似，两个IT组件，集群和应用，都具有相应的启停操作，可以构成4个原子化操作，再按照灾备周期划分，可以包含启/停主生产集群/应用、启/停灾备端集群/应用共8个原子步骤，这些步骤属于一个简化的标准灾备切换流程的4个灾备周期步骤：停止生产-启动灾备-停止灾备-启动生产。不同的场景需要的周期步骤不同，只要提前定义每个场景对应的步骤列表，就可以依据场景的选择和设定生成针对该场景的具体的流程。
灾备周期步骤的自由组合搭配就如同积木搭建一样丰富多彩，一套通用流程就可以成就无限可能。示例中组合构建了5个流程对应相应的场景，实际上，我们就是这样实现的应对各种灾难场景的切换流程。
3）通用切换流程的实例化
现在有了在模块化组件基础上建立的一套通用流程，以及由此组合派生的与多种场景对应的切换流程。标准模板流程有了，怎么实现具体应用系统的灾备切换呢？
根据需求分析的考虑，我们使用配置解耦，将流程、系统、脚本解耦，将流程参数化，系统信息作为参数，这样就可以把通用流程实例化成各个应用的各种场景流程。生成具体系统的切换流程就是通用流程的实例化。
在实现过程中我们梳理通用切换流程，梳理成通用流程表；将灾备相关配置数据分别写入主机表、应用表、集群表、网络表、存储表等。这样当业务系统接入灾备环境，只需要填写配置信息表就可以由灾备自动化调度指挥平台生成切换步骤并下发到自动化模块执行。
4）灵活切换
在切换技术上，灾备自动化调度指挥平台有四项功能值得特别提一下：动态展示、分层切换、串并行执行、桌面演练。
（1）动态展示
在流程设计时，我们将灾备切换流程的展示分为4个层次：大的流程阶段、阶段内步骤组合、原子步骤、实例化的具体原子操作，基于动态页面技术，自动生成各系统的流程展示。
（2）分层切换
每套灾备系统包含的主机和应用可能很多，因此我们将应用系统进行分层，分为DB、APP、WEB、辅助、前置等。我行使用的同城大二层网络打通的技����,��Ҫ术，可以使每层独立切换，整个系统多个分层可以运行在不同机房，或者构建应用系统特定分层的双活。除了分层之外，网络上对不同功能进行了分区，如业务后台区、互联网区、外联区等。一套系统的一个应用分层属于一个网络分区，而一个网络分区可能包含多个应用分层。灾备自动化调度指挥平台实现了应用的灵活分层切换，以及在分层基础上的网络分区切换和存储故障切换。系统在切换时可以选择只切换受影响的分层，也可以切换整个系统所有分层（即所有主机上的应用）。
（3）串并行执行
灾备切换自动化要优先考虑RTO，要确保流程高效运转和自动化执行的可靠性，传统上的单纯串行严重影响效率，单纯并行则会导致有顺序依赖的应用启停失败，为此我们使用了分层次串并行组合的自动化运行机制。
第一层，多个系统切换流程可以并行执行；
第二层，一个系统流程内的大步骤串行执行；
第三层，在大操作步骤内，根据启停依赖性要求，在尽可能提升执行效率的情况下使用了串行和并行混合操作。
（4）桌面演练
正式切换时一个系统的灾备流程能否正常流转、能否按照预期自动执行，相信没人可以打包票，那么就需要提供一种机制在切换前确保流程将会按照我们设计时的预期逐步执行。我们使用桌面演练功能解决这个问题。每个脚本都需要支持check选项，并在脚本中提供其实现，以支持和区分是真实切换还是桌面演练。通过在前台选择参与切换的系统、切换类型、特定场景以及是真实切换还是桌面演练来产生具体流程步骤，关联应用系统配置信息，生成命令和参数，登陆到主机和网络设备验证连通性，之后利用脚本中的check=true的分支将真实切换时待执行的具体命令及参数以 --debug: {待执行命令及参数}的形式打印出来，在此过程中与真实切换操作唯一的不同就是只是生成命令而不执行。
4、灾备自动化调度指挥平台使用情况
灾备自动化调度指挥平台上线后解决了：
（1）流程定制维护问题，使用统一的通用流程，无需系统负责人自己定义和维护流程，简化了难度，降低了工作量；
（2）灾备切换自动签到和公告发布功能，可以清晰了解到灾备切换人员参与情况和重大通知进度情况；
（3）问题工单，当自动化步骤失败时根据每个步骤的负责人设置派发工单，流程暂停，问题解决后流程继续自动化流转；
（4）进度监控和回看，支持ECC大屏和桌面台式机监控界面，支持进行中和已完成的流程回看已完成步骤的详细情况；
（5）切换历史和报告，方便地统计每个周期内的系统切换情况，并按照监管和运维要求导出html或word格式切换报告和应急手册。
平台在异常应对方面做了充分考量：从决策支持、场景选择、健康和性能检查、桌面演练、全自动操作、高并发执行都做了有益探索，尤其是应对异常方面，支持自动步骤失败后派发人工处理和重试、替换预定的步骤、跳过特定步骤、整个流程转换为人工执行、流程紧急终止以及全调用路径日志等功能。如果灾备自动化调度指挥平台本身出现故障，可以切换到两地三中心其他备用平台进行操作，支持流程断点继续。所有站点的灾备平台或者自动化基础设施都有问题时，还可以使用灾备自动化指挥调度平台生成的离线灾备切换预案进行人工切换。
另外，业内的大多数类似产品只用于灾备切换，我们对灾备自动化调度指挥平台进行了扩展，可以作为监控和应急启停使用：支持实时查看两地三中心灾备系统运行状况，也可以对故障的应用独立地启停。启停过程中可以实时监控执行日志，直到执行成功。
在推广应用过程中，灾备自动化调度指挥平台实现了RTO保证，从原来人工操作的数小时多人参与降为无人值守数分钟就可以完成灾备切换：
（1） 全自动操作减少了对人的依赖，有效规避操作风险；
（2）平台覆盖了十余个行内定义的切换演练和灾难场景；
（3）一键切换，紧急情况下一人即可完成系统灾备切换；
（4）组件化模块、充分解耦，大大加快了应用验证测试和投产实施进度，更加安全、可靠、高效，一年内实现了数十套系统的切换测试和上线，包含数百台主机、上千个应用，每年支持百余次/套灾备切换演练和千余次桌面演练。
总体上来说，灾备自动化调度指挥平台实现了灾备系统切换流程的灵活编排，提高了业务系统接入的效率，实现了RTO目标，提高了参与切换人员整体满意度。
5、创新点
综上所述，在灾备自动化调度指挥平台方面我们主要做了如下尝试：
1）积木式拼接，分层次搭建
2）设计了一套数据处理引擎，使用数据驱动流程
3）在此基础上，我们在流程构建、切换技术、运维支持上按照我们的实际需求进行了一些创新：
首先，在流程构建上的创新，包括：
（1） 组件模块化用来解决异构问题；
（2） 通用流程以应对各种切换场景和切换方式；
（3） 充分解耦，按需定制可以灵活地定义应用系统灾备切换流程；
（4） 依据应用配置信息自动化建立应用系统的逻辑模型，并模拟切换。
其次，在切换技术上的创新，包括：
（1） 大二层打通基础上灵活的应用系统分层跨机房切换；
（2） 兼顾效率和可靠性的串并行执行。
另外，在运维支持上的创新，包括：
（1） 平台可以应对各种异常状况，保证实战性；
（2） 可以对两地三中心灾备系统进行监控以及对单个应用进行应急启停；
（3） 有效应对流程、应用变更，确保两地三中心一致性。
6、后记
以上是我们在建设和使用灾备自动化调度指挥平台的需求分析、技术架构、使用过程和遇到问题，由于各个公司灾备架构不同，使用的技术栈各异，汝之蜜糖，彼之砒霜，再加上该平台在2015年8月份即投入使用，如今技术和背景已经大不同，肯定不可能拿来即用，只是希望我们的技术思路、经验教训能给大家提供些微帮助，在建设过程中少走些弯路，期待市场上出现更加成熟稳定、通用可靠的灾备自动化调度指挥类产品。