建设银行于2010 年明确信息技术“两地三中心” 总体布局策略，确定在北京稻香湖建设新数据中心，在武汉南湖建设异地数据中心，将北京洋桥数据中心作为同城数据中心。同时，建设并部署北京稻香湖和武汉南湖两个总控中心。武汉南湖数据中心已于2014 年11 月正式投产，北京稻香湖数据中心也正在加紧建设中，预计2017 年建成投产。未来北京稻香湖数据中心作为主生产中心，北京洋桥数据中心作为同城中心，武汉南湖数据中心作为异地中心，形成“两地三中心”布局。与之对应的，在北京和武汉分别建设企业控制中心(ECC)， 并形成ECC 间的互备能力，实现同城加异地的多重保护格局。

　　一、灾备体系规划

　　在建设银行的灾备体系规划中，明确了包括董事会、高管层、业务连续性管理委员会、各业务部门、综合管理部门、关键资源部门和审计部门的组织架构及职责分工。全行业务连续性管理工作围绕信息系统、基础设施及关键资源、安全保卫设施等三大关键资源分类开展实施，由信息技术部门、行长办公室(总务)、安全保卫部三大关键资源管理部门牵头负责各类关键资源的业务连续性管理体系建设，各业务部门负责制定和执行本部门或所辖业务条线业务连续性计划，确保重要业务持续正常运营。

　　建设银行根据业务连续性的要求，整体考虑灾备体系的建设和管理，包括灾备模式、人员、系统等。

　　1. 灾备模式

　　在“两地三中心”布局的基础上，建设银行于2011 年启动了新一代核心系统建设工作，以“满足客户任何时候、任何地点、任何方式服务需求”为宗旨，以一套业务模型、一套IT 架构、一套实施工艺、一套管理流程“四个一”为基本特征，实现核心业务系统企业级建模、组件化设计、一体化运维，信息科技全面支持建设银行向“综合化经营、多功能服务、集约化发展、创新型银行和智慧型银行”转型。

　　在灾备模式的选择上，建设银行充分考虑新一代核心系统的特点，结合“两地三中心”的物理距离和当前主流灾备技术特点，制定了多活和主备模式相结合的部署策略。建设银行的新一代核心业务系统建设是一个战略转型项目，系统技术架构是一个面向服务的架构(SOA)，遵循层次化、组件化的原则，采用云计算等核心技术，通过组件拼装和组合为云服务实现资源共享，达到灵活响应和快速创新的目的。架构上分为7 层，自上而下分别是渠道整合层、客户服务整合层、应用集成层、外联集成层、产品服务层、数据集成层和管理分析层。

　　渠道整合层、客户服务整合层、应用集成层和外联集成层采用三活方式部署(A-A-A 模式)，三中心均对外提供服务。多活模式的高可用性最高，灾难发生时能够实现无缝切换，支持快速业务引流，客户体验最好。

　　产品服务层在北京稻香湖、北京洋桥、武汉南湖三中心采用A-Q-S 部署方式。由于存在海量数据，且生产性能要求很高，受限于现有的技术，产品服务层无法实现理想的双活或多活部署，因此以北京稻香湖中心为主生产中心，处理大部分联机交易和批量业务，武汉南湖中心作为异地灾备中心。目前建设银行的业务量非常大，仅核心系统日交易量就已经突破5.24 亿笔，峰值TPM 达到61.47 万笔/ 分钟，IBM 大机的性能已经接近极限，因此在产品服务层引入Q 模式(查询模式)，通过在北京洋桥数据中心同城部署查询和报表处理能力， 降低对主生产中心的压力。

　　数据集成层和管理分析层在武汉南湖、北京稻香湖两中心采用主备部署方式(A-S 模式)。主备模式技术成熟，在满足灾难恢复指标的前提下，可充分保障数据的一致性，降低数据丢失风险。

　　通过上述规划部署，北京稻香湖作为主生产中心， 承担核心业务生产负载以及管理分析类的灾备功能;北京洋桥同城中心提供查询、报表等服务功能，降低主生产中心的压力;武汉南湖异地中心承担管理分析类生产负载，以及总分行、子公司的灾备功能。同时与之对应的，在北京稻香湖中心和武汉南湖中心分别建设企业控制中心(ECC)，并形成ECC 间的互备能力，平时两个ECC 共同承担工作任务，灾难发生时单个ECC 独立承担全部工作任务。在信息系统灾备方面，对不同的系统组件，通过进行业务影响分析，进一步明确信息系统的灾备等级，确定信息系统的恢复时间目标(RTO)和恢复点目标(RPO)。

　　2. 灾备资源复用

　　为了降低成本，提高计算资源的利用率，建设银行一直着力研究灾备资源复用的方案。主机平台灾备与测试资源的复用已经实施了多年，计算资源平时主要用于测试环境。除此之外，灾备环境还用于满足审计、模拟演练等需求，资源使用率非常高。

　　新一代业务系统建设大量采用了虚拟化与资源池技术，因此具备资源动态分配与快速供给的技术特性，这为灾备资源的有效利用提供了更方便的条件。目前建设银行正在制定开放平台计算资源的复用方案，综合考虑灾备、准生产和测试环境的资源需求和使用特点，利用虚拟化和云平台技术，实现资源的按需分配和灵活供给。

　　3. 人员能力灾备

　　建设银行从2011 年开始提出大运行的概念，在数据中心内部实施了零线、一线、二线人员分离，实现运维人员专业化分工，满足不同层级的人员灾备要求。

　　零线人员作为7x24 现场监控人员，负责集中监控平台告警的响应，其人员分布在北京和武汉两地，实现全局监控。当发生灾备切换时，某地的ECC 零线人员能够接管全部监控工作。

　　一线人员侧重标准化、常规化运维工作，横向发展， 实现集约化，用最少的人看管最多的系统，并借助于工具平台实现自动化。一线人员以同一个团队的形式分布在两个ECC，灾难发生时作为现场人员执行灾备切换相关动作。

　　二线人员侧重性能分析、容量管理等工作，纵深发展，体现专业性。二线人员通常不需要现场值班，以线下或者远程支持的方式完成二线运维工作。灾难发生时， 二线人员协同进行灾备切换动作，以远程方式对异地中心提供支持。

　　二、灾备体系建设

　　建设银行的灾备体系建设分两个阶段，第一个阶段是2005 年启动的核心业务系统的灾备建设工作，在上海、北京建成了核心系统及海外系统的灾备环境，经过逐步完善，现有灾备环境可以确保在生产中心发生灾难后，主要业务(包括分行柜面渠道、自助渠道和借记卡、贷记卡跨行业务以及海外业务等)能够快速恢复。随着武汉南湖数据中心建成投产，建设银行于2015 年年初完成了从上海、北京将灾备环境迁移至武汉南湖异地灾备中心的工作，彻底解决了灾备机房空间和电力不足的问题。

　　第二个阶段是结合“两地三中心”和新一代核心业务系统建设的整体规划，正在实施的新一代双活和灾备建设方案。该方案计划于2016 年完成北京洋桥、武汉南湖双中心建设，实现渠道双活，并完成全部新一代核心系统已投产产品服务类组件的灾备建设，于2017 年在北京稻香湖数据中心投产后，全面启动三中心灾备建设工作，形成全面、完备的灾备布局。

　　三、灾备体系管理

　　建设银行的新一代核心系统建设是一个IT 战略转型项目，包括灾备在内的IT 运维和管理工作，也都遵循“企业级”运维管理模式，体现新一代 “企业级”的核心思想。在灾备体系的管理上，从灾备管理使用的流程平台、自动化工具，到相关技术标准和规范，都在新一代框架内统筹研发与部署，并与生产、测试等保持一致，都统一遵循新一代核心系统的技术架构和管理标准， 从人员、工具、流程实行生产灾备一体化的运维管理。

　　1. 人员的一体化管理

　　在组织架构层面，一是人员的一体化，不管灾备环境部署在何地，原则上管理某系统生产环境的应用经理， 同时管理该系统的灾备环境，确保同一个系统由同一个小组的人员管理。二是变更的一体化，不管是版本变更， 还是配置参数调整，都要整体考虑生产和灾备的变更方案，从变更的计划开始，到变更的实施和变更的验证， 统筹安排，确保两者一致。

　　2. 流程平台的一体化管理

　　在流程平台方面，灾备相关的运维工作都流转在统一的IT 服务平台上。从底层的配置管理、变更管理， 到高层的事件管理、值班管理，流程平台提供了全方位、多层次的视图。

　　此外，新一代核心系统的灾备资源，全部纳入资源池管理，透过云管理平台及流程平台，以服务目录方式提供菜单式服务。

　　3. 自动化工具的一体化管理

　　建设银行通过自主开发并实施的云管理平台，提高了运维效率，控制了操作风险，进一步提升了数据中心运维的标准化、自动化和集约化水平。

　　(1)基础设施统一纳管。新一代核心业务灾备系统的全部开放系统资源，都纳入资源池管理，通过云管理平台和流程平台，以服务目录方式提供菜单式管理服务。云管理平台支持多类型基础设施统一纳管。随着新一代核心业务系统的投产实施，以及两地三中心运维格局的推进，越来越多的基础设施资源统一纳入云管理平台。截至目前，云管理平台已经纳管1500 台小型机，4200 台x86 服务器，5000 台x86 VM，520 台PowerVM，以及配套的网络和存储设备。

　　(2)资源动态分配与快速部署。云管理平台在对基础设施进行统一管理的基础上，实现IT 资源和服务快速交付、动态调整、弹性伸缩，提高资源利用率。目前新一代核心业务系统中开放系统的资源基本由云供给，实现了IT 资源的动态分配与快速部署。以新一代核心系统2.2 期投产为例，在IAAS 层，共安装1200 台虚拟机和物理机，传统手工安装需要1200 人时，通过自动化安装只用了70 人时。在PAAS 层， 共安装了30 套RAC 数据库(其中包含存储分配)， 传统手工安装需要150 人时，通过自动化安装只需15 人时，供给效率提高了10 倍。资源供给效率显著提升。

　　(3)运维标准化与自动化。通过运维自动化工具平台，实现了运维操作的标准化与自动化，极大地减少了运维工作量，降低了运维操作风险。仅以2015 年9 月25、26 日的版本发布为例，云平台完成了涉及133 套系统的397 次版本发布，共计执行5700 多个任务， 如人工发布需要1000 人时，自动化发布只用30 人时， 应用发布效率提高了30 倍。

　　(4)生产事件智能响应。通过建立事件统一分析平台和故障自动识别处置流程，不断提高应急处置的智能化水平，有效控制运行风险。首先，实现生产事件的关联分析与智能识别。在出现事件告警后，通过业务影响分析，确定影响范围和根源，通过知识库关联查询相关知识及应急处理方法。以目前的新一代核心系统交易告警为例，应用监控平台能够通过该故障的全局跟踪号， 合并重复告警和关联告警，自动挖掘和展现该笔交易的全路径，提供同比、环比、甚至自定义时段的交易信息对比，帮助处置人员定位和分析问题原因。其次，结合自动化工具，调用自动化处理模块，隔离或恢复故障。结合应急预案，将场景明确、简单的故障纳入自动处置范畴，将复杂、未知的故障，提供封装好的一键式处置手段，加快处置过程。最后，通过大数据分析平台生成事件分析报告，提出优化建议。

　　4. 灾备演练

　　为满足境内外监管机构对业务连续性管理的要求， 根据灾备的演练规划，在灾备的运维演练与灾备切换方面，业务与IT 紧密配合，按照方案进行协同实施。由信息技术部组织业务部门、数据中心和开发中心共同讨论制定演练计划(每年至少一次)，数据中心制定和实施ITCP 切换演练流程，业务部门和参演分行配合进行业务验证，开发中心进行技术支持，检验重要IT 系统灾备环境和应急切换流程的有效性。

　　演练的范围主要包括大机平台所有应用系统及海外分行的应用系统，基本做到每年一次演练，包括对私核心、信用卡、个人贷款、海外核心、新一代客户信息和对公存贷业务等主机系统及包括海外分行操作型数据管理系统(ODAS)、海外贸易融资系统(OTFS)、海外清算系统(GMPS)、SWIFT 报文处理系统(SWIFT) 等的海外系统。

　　演练的实施是从IT 角度模拟生产中心发生灾难而导致生产系统对外服务中断的场景，按照ITCP 进行灾备数据的复制，完成灾备系统的启动和对外服务的恢复， 通过生产系统和灾备系统的业务执行结果比对来验证灾备数据的完整性和业务服务的连续性。

　　从近年来每年一次的演练结果看，建设银行灾备体系基本能够满足海内外监管部门对灾备切换演练的要求，主机平台的RPO 和RTO 成功控制在≤ 2 分钟和≤ 2 小时的监管要求和建设目标内，验证了建设银行系统平台灾备方案的可行性。通过灾备演练，一方面帮助系统管理员和业务人员熟悉灾备切换及验证的步骤;另一方面不断改进切换演练中发现的各种问题，进而推动灾备切换步骤更加标准化、自动化。