灾备恢复演练的三点注意事项
第一，领导绝对要从第一次就开始重视
在国企，银行领导要是不重视，你很多东西别想玩起来。这种重视是要在一开始建设数据中心的时候就要提醒领导重视起来，而不是在灾备恢复演练的时候重视，将很多问题和需求都在第一次的时候和领导讲清楚，讲明白，强调灾备的重要性，以及一些惨痛的教训，比你以后再提再改IT 结构要省事的多，这是我的亲身体会。用华为的价值观来说就是第一次把事情做对。很多银行在一开始建设数据中心的生产中心的时候，同城灾备和异地灾备中心就同步建设，并物理同构，系统同构，使用不同的运营商的网络以及不同的电力支援系统。
成功的灾备恢复对成本要求的非常之大，以前也有人也提到过，灾备中心98%的时间都是闲置的，但是2%的时间出现问题，基本就会造成毁灭性的打击。现在银行领导已经不会不重视了，因为银监会，地方的银监局都会督促的。但是我们IT 的兄弟们一定要在第一次就将问题讲足，讲透，让领导明白我们的roadmap 规划。
当然，区域银行在财力上有所不及，就只能考虑能力范围内的灾备恢复，比如重点数据，重点系统等。同构建设，异地建设就要量力而行。
第二，制定完善的规章制度和详尽具体的指导手册
什么是规章制度，就是要所有人都知道你办事有据可查可依，而不是随意办事，就是要所有人都知道各自的角色和任务。规章制度绝对是非常有用的（我之前很轻视的，后来工作让我知道是非常重要）。中国人民银行和银监会对银行的灾备恢复有明确的政策文件，也有国家标准，但是不同企业也要根据各自的实际情况，具体需求，制定各自的规章制度，这就是企业标准（比行标具有更强的约束）。
规章制度制定总体的灾备恢复要求，以及预案的启动，以及负责人，以及流程。比如我们要明确成员：灾备恢复领导小组（行长级别的），管理小组（信息科技，保卫，业务等方面的中层），执行小组（以IT 为主，其他为辅）。我们还要明确每小组的职责，和每个人的任务。成员的名单要根据组织的变动不断刷新，比如北京、上海的数据中心的负责人，比如中间件、网络、业务的负责人，比如对外联络EMC、GDS、IBM 等公司的联络人，和运营商，电力公司的联系人等，都要及时刷新保持最新。经常遇到在演练的时候，找到一个，不好意思，我调走了，或者离职了，这是不可接受的。还有相关权限的获取，流程审批的指导等。
规章制度还要定义明白，业务要恢复到什么程度，多长时间能恢复，RPO,RTO 大家都很明白了，无需多言，总之要有明确的量化指标，不可随意更改。
指导手册要有灾备恢复的具体技术指导。这个一般不能第一次就能确定最优的操作，要多次演练，或者参考别的银行或者公司的经验，厂商一般有一些原厂材料或者案例推荐（比如EMC、万国数据、飞康等），值得学习。指导手册一个重要的信息，就是现有系统的信息，以及灾备系统的信息。比如生产中心的拓扑，数据库的列表，主机的操作系统和软件配置等，IP 地址列表，硬件信息，软件所在位置槽位等。现有系统的信息一定要准确和分门别类，比如按网络、操作系统、数据库、应用、动力等分类，也可以按业务进行分类，比如资金清算、信贷、信用卡等业务进行业务分类。现有系统的信息要有专人维护，并定期巡检。信息的变更要走流程，并报信息科技主管备案。当然灾备中心或者目标库的信息也一定要维护和刷新，根据不同公司的灾备恢复模式而变。
指导手册的灾备恢复的技术指导就不用说了，要指明相关脚本位置，图形界面的操作方式，或者命令行的命令的指导等。相关的脚本位置，软件版本要严格指明，对于关键的动态参数，要有解释。现在一些厂家的灾备恢复做的已经足够简化了。但是如果是一个系统的完整搬迁，涉及不同的厂家和不同层面的系统。还要指明目标系统、网络的开启和重建，SAN 的挂载，应用系统的重配等需要更复杂的工作，还要有营业系统的测试用例等。
对于电信运营商，要选择话务的峰谷时间段，比如凌晨1 点到3 点。银行，业务一直是繁忙的，要选择一个相对事务较少的时刻。最开始可以先尝试的实验数据较少的生产库，之后，再整体切换上百个数据库的系统。演练或者真实恢复，一定要做好网页或者重点客户的通知，防止对重要业务的干扰，造成不必要的损失。我曾经了解过，某运营商，机场选择在业务繁忙时间恢复演练的时候失败，导致整片区域都瘫痪的事件。灾备管理部门要结合业务部门预测好业务高峰期，以及突发时间等，更新容灾恢复的时间窗。
还有对外宣传的指导详细流程，比如不成功会怎么样，成功会怎么样，都要有预案。
第三，容灾演练一定要各种场合都要考虑到
我们要有预案分类。比如网络断了怎么办，动力断了怎么办，数据库宕了怎么办，都要有完善的预案措施，平时技术团队没事的时候多研究，出事的时候就少花时间恢复。这个我国要向美国学习，7000 多种预案，不是盖得。当然我们也没必要搞那么复杂。
具体来说，数据损坏了怎么办，从备份硬盘恢复。主机系统损坏怎么办，HACMP,BCV?一般来说，同城容灾和异地容灾我们都应该演练一下。比如北京同城150 公里，比如上次北京暴雨发大水，导致电力传输系统损坏，导致生产中心断掉。我们可以利用关闭掉光纤通路，或者关闭掉生产中心和灾备中心的连接来模拟。我们可以利用SRDF 来恢复。观察清算系统的运转，恢复花了多少时间等。还有异地灾备恢复等。要考虑异地灾备中心负责人对北京数据中心的了解情况。谈到这里，各种规章制度和技术指导手册最好要分角色来撰写，要充分考虑到负责人员得技术和系统的领悟能力，不要假设他什么都知道。
从系统故障来看，我们应该测试和演练网络故障，主机故障，磁盘阵列故障，应用系统故障等（比如操作人员误操作），SAN 网络故障等。我们要结合规章制度，以及现有情况，决定恢复的时间点和系统等，优先要保证最高优先级的系统的恢复。容灾恢复演练从来都不是仅仅是数据库的事情，而是全套系统的事情，而且涉及到很多操作系统和硬件平台。
其实容灾演练的功夫在平时做好是最省事的。比如我们在架构设计的时候，为生产中心和同城容灾中心准备充足的带宽，比如FCoIP，带宽可以达到数百兆的速率，对于连接的交换机和存储系统主机最好采用双机冗余，互为备份。让生产中心和容灾中心之间的数据尽量做好同步，对于远距离的系统，采取存储层面的磁盘镜像比较合适，异步镜像就可以了。
而且注意采取可以无需主机处理的交换机和存储技术，让平时的数据同步可以较少的占用系统的资源。在容灾系统上，SAN 是当之无愧的选择。
本文作者 DB2 中国社区 sunyangnj