寿IT战略规划项目灾备中心高端设计报告

中国人寿IT战略规划项目灾备中心高端设计报告版本号 V3.0起草人:中国人寿IT规划项目组北京市朝阳区建国路112号中国惠普大厦（100022）电话：010-65643888传真：010-65668278版权说明本文件中出现的任何文字叙述、文档格式、插图、照片、方法、过程等内容，除另有特别注明，版权均属中国惠普有限公司咨询与集成事业部和中国人寿共同所有，受到有关产权及版权法保护。任何个人、机构未经中国惠普有限公司咨询与集成事业部和中国人寿共同的书面授权许可，不得复制或引用本文件的任何片断，无论通过电子形式或非电子形式。文档信息项目名称：中国人寿信息化战略规划文档版本号：3.0文档作者：中国人寿信息化战略规划项目组生成日期：2003-12-2文档审核者：中国人寿信息化战略规划项目组审核日期：2004-3-8目 录1概述72灾备中心建设的策略72.1业务连续的几个层次102.1.1 高可用性102.1.2 灾备中心112.1.3 业务永续运行112.2业务影响分析132.3业务永续运行计划142.4结论213灾备中心建设的建议223.1灾备中心的建设方案223.2灾备中心建设要求233.3灾备中心的建设与数据中心的关系233.4灾难恢复基本模式243.5省市灾备中心建设253.6机房建设264灾备中心的功能要求264.1灾备环境264.2开发测试环境264.3预生产环境274.4演习环境274.5灾备中心功能示意图285灾备中心设备、网络性能要求295.1灾备中心的容量295.2恢复时间的要求305.3体系架构315.3.1 灾备中心的主机、存储布局395.4灾备中心的网络425.4.1 灾备中心与生产中心之间的网络425.4.2 灾备中心的广域网架构445.5灾备中心的安全体系456灾备中心的管理体系456.1业务永续管理与中国人寿其他管理流程的关系466.2业务永续管理流程476.3计划的测试、培训和演习476.4业务永续运行计划的维护496.5恢复组组织结构图526.5.1 角色和职责537缩略语59图表目录图 21停机因素8图 22中国人寿IT高可用性环境建设线路图9图 23业务连续的层次10图 24中国人寿业务永续运行环境实施方法12图 25中国人寿业务影响分析方法14图 26中国人寿开发业务永续运行计划的方法15图 41容灾中心的功能28图 51校园集群体系架构33图 52城间集群体系架构34图 53广域集群体系架构35图 54中国人寿灾备中心假设方案38图 55 灾备中心主机、存储布局39图 56 灾备中心与生产中心的数据链路43图 57灾备中心广域网逻辑架构示意图44图 61业务永续管理与ITSM其他流程的关系46图 62中国人寿永续运行管理流程概览47图 63中国人寿业务永续运行计划的维护流程50图 64灾备中心永续运行管理组构成53表 51技术手段与RPO、RTO的对应关系36表 52业务类型的服务级别分类36表 53中国人寿关键应用RTO与RPO要求（来源：中国人寿IT规划项目组）401 概述 根据项目第一阶段的调查和在在中国人寿IT战略的要求，我们认为中国人寿有必要建立一个灾备中心和相应的业务永续运行计划。本文是中国人寿IT战略规划项目的高端设计之一灾备中心高端设计。其中涉及到如下问题： 灾备中心建设的策略提出了业务永续运行的概念，并建议中国人寿的灾备中心具有保证关键业务永续运行的能力 灾备中心建设的建议介绍了灾备中心建设应该考虑的问题，例如灾备中心地点的选择，技术的选择，关于省市级数据中心的灾备中心建设的考虑等 灾备中心的功能要求 灾备中心设备、网络性能要求，以及灾备中心的安全体系 灾备中心的管理体系介绍灾备中心的组织架构以及管理流程，质量控制等2 灾备中心建设的策略 在信息时代，数据是企业创造商业价值的生产资料，数据的丢失将为企业带来毁灭性的灾难。 据Gartner Group的调查数据表明：在经历过大型灾难或长时间系统停运的公司中，有2/5的公司再也未恢复运行，而在其余的公司中，有1/3的公司在两年内破产。面对各种未可预知的灾难，越来越多的企业将容灾作为企业安全的保障。 根据Gartner Group在2003年9月分表的报告，由于硬件故障而导致的系统停机只占非计划停机的21。因此，减少系统的停机时间不能仅仅靠加大硬件的投入，还有兼顾其他因素，例如加强员工的教育，强化管理流程，成立专门的机构应对突发事件等。通过我们第一阶段的调研，也发现中国人寿从自身的发展出发，有建立灾备中心的需求。建议中国人寿的灾备中心建设成一个能构保证关键业务能够永续运行的数据中心。图 21停机因素惠普公司在总结了大量经验的基础上提出了建设高可用性环境的5个步骤。这5个步骤将伴随建设的全过程，是一个不断循环往复的过程。这5个步骤分别是：分析，设计，建设，管理，提高。图 22中国人寿IT高可用性环境建设线路图高可用性只有通过技术，服务和最佳管理实践三者的完美结合才能达到。2.1 业务连续的几个层次 图 23业务连续的层次如图2-3所示，根据受保护对象的不同，保证业务连续运行所使用的技术不尽相同，当然，实现的成本也有较大的差异。2.1.1 高可用性 可用性并不是一个模糊概念，实际上它能用数学方法来精确地表示。简单地讲，一个高可用性系统就是一个用户能随时使用的系统，例如当用户需要在早上8点到下午5点启用该系统时，该系统就应该在这段时间内保证良好的可用状态，其余的时间可以用来进行定期维修保养。可用性常被定义为实际的服务时间和要求的服务时间的比值，常用百分比表示。许多现代化系统需要一天24小时、一年365天连续不间断运转(有时也称为724或36524)。一个可用性为99.9%的36524系统一年的平均故障时间为8.76小时(525分钟)，而要想让系统的中断时间在一年中只有3分钟的话，系统必须有99.999%的可用性。我们将图2-3中对应于数据，应用/数据库，系统和网络的解决方案称为高可用性解决方案。我们这里所说的高可用性解决方案是指利用冗余设备在本地（机房内部）完成的，一般恢复时间在几分钟之内。在使用高可用性方案进行系统恢复时，一般只需要IT部门参与，而与业务部门无关。2.1.2 灾备中心 当遇到大规模的自然或人为灾害，例如火灾，地震等，办公场所/机房也许会遭到破坏。灾备中心就是为了应对这种情况而诞生的。灾备中心位于与生产中心不同的建筑物中，距离因容灾目的而不同。灾备中心强调的是灾难恢复功能，重点在灾难发生后。而要保证关键业务在灾难发生到灾备中心开始工作期间不中断运行，仅仅靠IT部门的力量是远远不够的，还需要各个业务部门的积极参与，利用技术，服务和管理的手段才能做到。2.1.3 业务永续运行 所谓业务永续，是指在遇到严重灾害事件时（物理场所的灾难，人为破坏，自然灾害等），仍能够提供保证业务运行的环境。它包括一个持续不断的评估，计划，实现和支持流程，还要求利用必要的技术和服务来为基础架构提供支持。业务永续不是专门的技术，产品或服务。也不是高可用性，灾难恢复或者容灾的实现。业务永续运行应该包括风险评估，中断影响分析，以及避免中断策略，必须将这些因素充分考虑进综合性业务持续性计划即要根据关键性业务程序而不是技术来进行调整。然而，无论在高可用性、冗余、容错、群集和镜像策略等方面考虑得多么全面，仍然没有哪个业务持续性计划能保证业务万无一失。业务永续的关键，在于了解什么业务程序在业务中事关重大，并确定影响该程序的所有因素。综合性风险分析，有助于企业做出有关应对，迁移或转移风险的业务决策。根据中国人寿的具体情况，我们建议中国人寿灾备中心的建设分4个阶段进行：图 24中国人寿业务永续运行环境实施方法2.2 业务影响分析执行业务永续运行项目的第一步就是做业务影响分析(Business Impact Analysis)。以后的基础架构设计和业务永续运行计划都是根据业务影响分析的结果。业务影响分析是确定不同业务流程对企业的影响程度。优先级的制订主要根据分析有形的和无形的影响，对停止业务时间长短的接受情况和为使影响降至最低的最低需求。这些数据可以用来做制订恢复和业务永续运行策略的基础。BIA的目标： 识别和量化每个业务单元或者资源对整个企业在财务和运行方面的影响 识别潜在的失效场景和评估潜在的威胁 帮助定义针对不同的可用性/灾难恢复要求所需要的不同级别的投资情况 规定恢复策略 建立灾难恢复时的恢复流程优先级我们认为，中国人寿应该按照如下步骤进行业务影响分析：图 25中国人寿业务影响分析方法2.3 业务永续运行计划业务永续运行计划是关于一些流程的正式文件，这些流程是制订企业面对不利的意外事件时的策略和行动计划的。使用这些策略和行动计划可以使企业在预先定义的时间段内恢复关键业务的运行，从而使灾难的影响降至最小，使受影响的业务尽快的恢复。业务永续运行计划是灾备中心最重要的文件之一。我们根据中国人寿的情况制订了如下开发业务永续运行计划的方法：图 26中国人寿开发业务永续运行计划的方法根据中国人寿的具体情况，我们认为中国人寿在制订和执行业务永续运行计划时应参考如下原则：原则 1: 董事会和管理层应该对其企业的业务永续运行计划准备情况负责。1. 企业的业务永续运行计划是董事会和管理层的责任。管理层应该通过对业务永续运行计划准备情况的定期验证来表明其对于风险及其消减措施的充分了解和重视。2. 验证的内容应该明确包括： 企业的准备情况 企业考虑到其业务活动水平、风险管理策略和在保护保险体系系统稳定性方面所扮演的角色这些因素的情况下，选择遵循本文中原则的程度 3. 这些验证应该提交给董事会。企业业务优先情况的变化可能影响到其业务永续运行计划准备的效率。所以验证应该定期进行更新。4. 越来越多的客户和合作伙伴也在寻求为其提供金融服务的企业在业务永续运行计划准备方面的保证。所以，如果适当，应该将这些验证与客户、合作伙伴以及其它有关方面共享。原则 2：企业应该将业务永续运行计划融入到日常的业务活动中使之成为良好的工作习惯。1. 业务永续运行计划是面向风险和事先反应的方法，它包括对业务分枝的全面理解、事件响应、危机管理和对外联络。它通过制定恢复业务功能以履行业务职责的方法和规程来处理风险。2. 业务永续运行计划应该是可信的，包含清晰的策略和职责，具有可操作性，随着业务变化得到更新并经过切实的测试。依据企业业务规模和范围的不同，良好的工作措施可包括： 明确业务永续运行计划政策和策略 明确业务永续运行计划项目中的角色和责任 进行业务影响分析 制定、部署、测试和维护业务永续运行计划 不断对员工进行相关的意识培养和技能培训 应急响应和操作规程 对外联络和危机管理协调规程 对外协调规程（包括管理当局和相互依赖的团体等） 3. 一旦建立了业务永续运行计划，就应该定期对其进行检查、维护和测试以确保其具有及时性、高效性和可操作性。企业应该努力将面向风险的业务永续运行计划融入到日常运行和管理中并使之成为企业文化的一部分。原则 3：企业应该定期、全面和切实地测试其业务永续运行计划。1. 需要通过测试来确定业务永续运行计划的有效性。技术、业务方法以及员工角色和责任的变化将影响和降低业务永续运行计划的效率并最终影响到企业的准备状态。因此，通过对业务永续运行计划的测试来测量其可用性和有效性是很重要的。测试还将使员工熟悉恢复站点的位置以及中断期间所需的恢复规程。测试的目标是确保企业在启动业务永续运行计划后能够按照计划可靠、及时和有效地恢复运行。2. 定期：企业对其业务永续运行计划一年至少要测试一次。经常性的测试对于保证业务永续运行计划的效率是至关重要的。一些企业发现，每月或每季度进行测试能够有效帮助其进行中断处理的准备。管理层应该参与到测试中并熟悉其在计划启动时的角色和责任。3. 全面和切实：业务方法的所有部分都应该得到切实的测试（比如从前台到支持和处理部分），其中包括测试恢复站点所提供基础设施的连接性、功能性和负载能力。企业应该能够证明其测试项目充分涵盖了定性和定量等各方面的问题。所有的策略和计划的假设都应该定期地被检讨以确保其适当性，在业务范围和方向发生变化时尤其应该如此。全面性还包括测试人员的意识和准备情况以及对外协调情况。相互依赖性，特别是对企业控制范围之外的外部团体的依赖性应该被全面测试。这包括在新加坡以外工作的企业官员、分枝或服务提供商。4. 其它可能的测试包括： 整个系统的桌面排演测试 员工呼叫测试（人员调动和无调动情况下） 备份站点到备份站点的测试（包括与外部服务提供商） 共享服务替代测试 备份磁带还原测试以及 关键记录恢复（数字的或书面的） 应该准备好正式的测试文档和列有经验教训以及风险消减措施的测后分析报告供管理层签署。原则 4：企业应该制定恢复策略和关键业务功能的恢复时间目标。1. 建立恢复策略可以使企业以有序和事先定义的方式执行业务永续运行计划以减少中断时间和经济损失。它是定义关键业务功能的恢复时间目标 的基础。没有这些清晰的定义，有限的资源就有可能被不恰当的用于次要的活动。这样就可能对企业的信誉和生存能力造成负面的影响。关键业务功能2. 在危机中，全部恢复所有的业务功能可能是不实际的。所以，企业应该确定其关键的业务功能以及这些操作中断情况下的潜在损失（经济或非经济方面）。获取这些信息的常用方法是进行业务影响分析 。这种方法也用来凸现各种关键功能之间的相对优先顺序并帮助企业确定其恢复策略和恢复时间目标。3. 由于不同企业的业务导向和顾客预期不同，所以其关键业务功能也有所不同。但是，与完成大额支付业务、清算和结算事务、履行每日资金和担保职责、管理客户风险以及维护客户、投资者或公众信心有关的功能通常被视作关键的。恢复时间目标4. 不同企业的恢复时间目标可能不同，范围从中断后的一天之内到数分钟之内，非常重要的企业功能比其它企业要求有更快的恢复能力。原则 5：企业应该了解和适当地消减关键业务功能互相依赖的风险。1. 企业具有将风险和过程分散和分布在本地、区域内和全球范围的倾向。这使其增加了对其它团体（内部或外部的）的依赖。任何对互相依赖风险的不当管理都可能造成风险叠加而降低运行或系统效率，从而有可能损害企业的运行。2. 在制定关键业务功能的应急计划时，企业应该考虑到这些功能的相互依赖性及其相互依赖的程度。企业也应该了解支持这些关键功能的相关业务方法，尤其是业务永续运行计划准备和恢复优先顺序方面的。这些依赖性的例子有： 企业中的 企业之间（如银保通） 对供应商（如灾难恢复服务供应商） 对基础设施提供者（如电信） 业务永续运行计划应该将复杂的依赖关系考虑进去并且尽可能地消减这些风险。这些依赖关系应该在制定恢复策略和恢复时间目标时做为考虑因素。3. 虽然有些依赖性风险不在企业的控制范围内而无法彻底消减（如无法使用电信网络），但是这并不能降低其客户和合作伙伴对企业服务和履行职责的期望。最终，依赖性风险将会落在企业身上而无法回避。所以，企业应采取合理的步骤消减这些风险（如同电信供应商讨论确保通信线路通过不同的交换局进行路由的问题）。4. 在与任何外部供应商签订合同之前，企业都应该确信外来风险在当前风险策略可接受的范围内，并且不会破坏自己的业务永续运行计划。它们应该确定其服务供应商也有相应的应急计划，即使这些计划没有自己的业务永续运行计划准备的那么充分。企业还应该事先向其服务供应商寻求其业务永续运行计划得到定期测试的保证。5. 在外部供应商异常终止或破产的事件中，企业寻找其它合适的供应商并进行安置和部署可能要花费数月的时间，这样的过渡期风险是无法接受的。企业应该采取合理步骤以保持适当的控制水平并保留采取适当措施继续其关键业务运行和维护其业务永续运行计划不容破坏的权力。原则 6：企业应该为大范围中断情况制定计划。1. 911事件表明，企业应该为大范围中断情况制定计划。范围被定义为同一中断所影响的可能区域 。企业考虑的因素还应该包括什么情况下关键人员可能会遭受严重损失或无法使用，什么情况下诸如电信这样的关键服务会大面积中断。企业应该在业务永续运行计划中考虑到多个区域中断的情况，考虑到各关键业务活动的水平、风险承受能力和风险管理策略。另外，它们还应该考虑到长期中断情况下对业务永续运行计划的范围进行扩大和深化的问题。2. 大范围中断可能会增加依赖性风险。同一区域的关键功能和服务提供者的相互依赖性应该得到适当消减。对于企业与客户、合作伙伴和服务供应商的主站点在同一区域的情况，其恢复站点之间应该安排有电信链接。这些链接应该得到测试。原则 7：企业应该采用分离策略来消减集中风险。1. 关键人员和信息是难以快速替代的重要资产。当业务运行及其支持技术（IT设备和人员）被安排在同一区域时，企业应该评估其集中风险。例如，当今的许多企业设想将主站点的同一批人员用于在恢复站点对其关键业务功能进行恢复的工作。这在中断造成人员无法使用的情况下通常是行不通的。2. 所以说，既要消减集中风险和提高人员安全性，又不能损失业务处理和关键人员集中带来的高效率，这两者之间作出平衡是很重要的。在应对大范围中断的准备中，企业应该尽量采用以下三种关键业务功能的分离策略：第一：主站点和恢复站点分离。关键业务功能的主站点和恢复站点应在不同的区域内。第二：事务操作和IT操作分离。关键的事务操作和支持事务操作的IT操作应该在不同的区域。例如，结算操作人员与其IT操作（包括IT设备和人员）应该在不同的区域。第三：功能内分离。部署在另外区域的一批工作人员用于接管关键业务功能。解决方案可能包括处于两个分离的操作地点的人员和得到交叉培训的另一个地点的人员。企业应该确定和设计减少集中风险的最适当的消减措施组合。2.4 结论综上所述，结合中国人寿IT战略规划和中国人寿IT架构的要求，我们认为中国人寿灾备中心的建设应按照如下策略进行： 灾备中心的建设需要得到高层领导的支持灾备中心的建设和运维需要大量人力、物力的配合，涉及到许多部门。没有企业高层领导的支持是不行的。 灾备中心的建设要满足业务的需求灾备中心的建设资金投入、功能、处理能力、管理方式等必须满足目前的业务需求，同时还要兼顾未来发展的要求。 灾备中心需要建立高可用性的架构灾备中心启用后，就开始做为生产中心提供服务。因此灾备中心也应该与生产中心一样，对关键业务应用采用高可用性架构，以防止由于单点故障而引起宕机 灾备中心应该可以提供演习环境演习是保证业务永续运行计划有效性的重要手段，每年至少应该举行一次。演习环境是为了保证在演习是正常的业务处理仍能继续而建立的。 灾备中心的设备应该得到充分利用灾备中心的建设不仅要考率到紧急情况下的使用情况，还要考虑日常如何利用。例如，为了在平时提供灾备中心设备的利用率，可以利用灾备中心的设备进行应用的开发和测试。 灾备中心的建设以用先进、成熟的方法论做为指导，分阶段进行先进、成熟的方法论为灾备中心建设的成功提供了保障。 灾备中心与生产中心使用结构相同的IT基础架构和管理流程这样可以大大降低管理与运行维护的复杂度。灾备中心的处理能力可以与生产中心不同，但是要满足业务需要。3 灾备中心建设的建议 根据中国人寿的未来IT架构，我们建议中国人寿建设一个灾备中心，以保证中国人寿因重大灾难事件而使一级数据中心无法继续提供服务时，继续为关键企业应用提供运行平台。我们的设计基于如下假设：由于连续性灾难（即主数据中心发生灾难尚未恢复正常运行时，灾备中心又因发生重大灾难而停止运行）发生的概率极小，我们在设计中不考率对于连续性灾难的恢复问题。3.1 灾备中心的建设方案灾备中心的建设方案由两种：1. 建立一个独立的灾备中心2. 建立两个数据中心，两个中心之间互为备份但是，如果建立两个数据中心，管理流程会变得复杂，人员配备会增加，运行成本也会提高（例如，为了进行双向数据同步，要租用多条通信线路）。所以，我们建议采用第一种方案。 容灾备份系统建设内容 在灾备中心建设中，不仅要考虑数据中心端的容错，还要考虑对重要关键业务系统进行异地容灾备份和对重要数据的定时和实时备份。 灾备中心建设的内容包括： 1. 面向数据中心提供网络通讯设备、通讯线路、存储网络设备的全面容错和异地容灾。 2. 面向数据中心提供部分关键业务系统的容错和异地容灾。 3. 提供数据中心和容灾中心本地数据备份。 3.2 灾备中心建设要求 灾备中心的建设须满足以下要求： 1. 备份中心与数据中心在地理位置上保持较远的距离(例如1000公里)，使得当数据中心遭受灾害破坏时，不会影响到备份中心。 2. 交通便捷3. 主要电信服务商可以提供语音及专用数据网络服务4. 机房环境要求与主中心相同5. 可以容纳足够的工作人员办公6. 备份中心的所有应用系统必须经过严格的测试，确保业务系统能够正常运行 7. 备份中心与数据中心间网络带宽应能保证两地间数据的可靠同步。 8. 备份中心计算机系统有足够的处理能力来接管数据中心的业务；同时应具有不低于数据中心的安全防护能力9. 重大灾难发生时，灾备中心和数据中心可以通过手工操作的方式切换10. 数据中心或灾备中心发生小范围事故时，系统在数据中心或灾备中心内部可以自动切换3.3 灾备中心的建设与数据中心的关系灾备中心机房建设的前提条件是 完成BIA分析和灾备中心IT基础架构设计 生产数据中心开始运行理由如下：1. 没有BIA的分析结果，无法明确灾备中心到底针对何种灾害设计，即无法决定灾备中心的物理地点2. 没有BIA的分析结果，无法决定中国人寿对灾备中心的投资规模3. 没有BIA的分析结果，无法确定灾备中心运行的核心应用种类及其对恢复时间和数据丢失量的要求；无法确定核心业务流程之间的依赖关系，也就是说无法明确核心业务应用之间的数据传递关系及对数据完整性的要求，所以无法进行IT基础架构设计。4. 没有BIA的分析结果，无法确定中国人寿在发生灾难后所希望达到的服务标准，即是否关闭一些保险业务，是否关闭一些分支机构（如区县级机构），是否限制使用系统的用户数量，是否改变正常的业务处理流程等。这些都决定者与灾备中心相连的广域网布局如何设计。5. 没有IT基础架构设计，无法明确灾备中心需要的设备类型和数量，所以无法进行设备选购，无法得出对机房配电，空调，地板承重以及布线的具体要求6. 如果数据中心的应用部署没有最终完成，无法得到详细的应用之间的数据依赖关系，无法得到应用正常运行需要何种质量的数据，无法取得应用正常启动和异常启动需要的时间，这些都是决定采用何种恢复技术的关键因素，也是衡量灾备中心的设计是否能够达到要求的恢复时间的重要依据。3.4 灾难恢复基本模式 1. 本地容错 本地故障、错误可以分为几种类型：网络设备宕机、服务器宕机、数据库宕机、存储设备宕机、线路中断、操作系统故障、应用系统故障、硬件设备故障、磁盘故障。本地设备和软件发生故障时，本地冗余和备份的设备和软件可以帮助恢复故障。 2. 异地容灾 大灾难包括：自然灾难（地震、台风、洪水等）、突发事件（业务系统中断、通讯中断、计算机病毒、计算机网络犯罪、火灾影响、恐怖活动）等。大灾难使得本地的网络、服务器、存储设备宕机，技术支持人员不能及时到现场恢复，业务系统中断，从而造成重大损失和灾难。 异地容灾是在本地发生大灾难时由异地设备提供业务容灾恢复。高端异地容灾由本地运行中心和异地备份中心组成，异地备份中心具有本地运行中心的相同业务系统，两个中心的数据是同步的。在无大灾难时，本地运行中心正常运行。在有大灾难时，关键业务的客户端的请求自动被送往异地备份中心的服务器，而异地备份中心的数据库提供已同步的数据响应客户端的请求，从而保证数据的完整性和一致性，保证业务7天24小时不间断运行。中端异地容灾与高端异地容灾大部分相同，所不同的是对重要业务采用中端容灾硬件和软件，有数据丢失，业务短暂间断，投资成本较低。低端异地容灾可以对一般业务采用远端磁带库和磁盘进行定期备份，业务恢复时间长，数据丢失多，投资成本最低。 3.5 省市灾备中心建设 由于未来中国人寿的核心业务系统和关键数据都集中在一级数据中心，省市级数据中心的数据量较少，主要是办公自动化数据，所以建议在省市级数据中心不建立灾备中心。影像系统虽然在二级数据中心，但是在一级数据中心保存有影像数据，所以二级数据中心发生故障时，用户可以使用一级数据中心的影像数据。地市系统先通过公司内部专用网络连接到二级数据中心，然后再连接到一级数据中心。当二级数据中心发生灾难无法工作时，地市用户可以通过因特网上的VPN直接与一级数据中心通信。3.6 机房建设请参照数据中心高端设计的相应章节。4 灾备中心的功能要求如果灾备中心平时处于冷备份状态，那么为了更有效地利用灾备中心的设备，灾备中心除了担负灾难发生时的应急处理中心的任务外，在平时还可以做为应用开发中心使用。这要求用于应用开发的主机配有2套系统启动硬盘。灾备中心在平时做为开发测试中心基于如下假设：灾备中心在需要启动时，所有服务器冷启动就可以满足“恢复时间”的要求。4.1 灾备环境 平时，灾备系统的主机用于应用开发机，但应用数据必须保持与生产系统同步，这就要求应用数据要保存在基于硬件同步的磁盘阵列中。灾难发生时，用灾备系统的启动硬盘启动，系统进入灾备系统状态工作。4.2 开发测试环境 由于开发测试不稳定，经常会进行修改或者重新启动系统，所以要求开发测试环境的数据与灾备环境的数据分开存储存储在不同的物理设备上或同一设备的不同分区上。开发测试环境还可以用作业务永续运行计划的演习环境。4.3 预生产环境 预生产环境主要用于系统正式投产前的验收测试。主要进行的是压力测试，系统联调等。其技术实现方面的要求与开发测试环境相同，即也需要独立的存储环境支持。4.4 演习环境为了更好的对实际情况进行模拟，建议演习环境与灾备环境使用统一运行平台。环境的相互切换通过使用不同的系统启动硬盘实现。演习环境应该有不同于灾备环境的磁盘空间存储演习用数据。例如，可以在演习前停止测试环境，并对测试环境的数据进行全备份。演习时使用原来测试环境使用的磁盘阵列。演习除了包含主机系统的切换外，还应该包括广域网的切换，所以在演习前还应该通知相应的电信运营商做好配合。4.5 灾备中心功能示意图图 41容灾中心的功能如图4-1所示，一级数据中心内部有生产环境，运行维护环境，IT 服务管理环境和响应中心。响应中心的人员可以访问生产环境，IT服务人员 可以访问运行维护系统。二级数据中心有生产环境，运行维护环境和响应中心。二级数据中心的响应中心主要解决本地的故障，当遇到故障无法解决时，将问题转给位于一级数据中心的响应中心处理。灾备中心有开发组，应用支持组，开发环境，测试环境和预生产环境。当一级数据中心的响应中心有关于应用的问题无法解决时，将问题传递给位于灾备中心的应用支持组。应用支持组也无法解决时，再将问题交给开发组。当有灾难发生时，停止开发环境，测试环境和预生产环境的运行，启动备份生产环境。同时响应中心，IT服务管理环境和运行维护环境也切换到灾备中心。5 灾备中心设备、网络性能要求 5.1 灾备中心的容量灾备中心的处理能力受到几方面的制约： 运行与灾备中心的关键应用系统的数量 灾备中心运行时的联机系统用户的数量 灾备中心运行时能够提供的应用系统响应速度所以灾备中心的容量必须等到业务影响分析完成后才能明确。容灾中心的设备要与数据中心的设备兼容，具体配置通过下述述手段获得：1. 根据对处理性能的要求并参照数据中心的配置给出初步建议2. 搭建测试环境进行测试（兼容性测试和压力测试）3. 对初步建议进行调整，给出最终建议现假设灾备中心只有保险核心应用、财务系统、销售支持系统、客户服务系统和电子商务系统，且灾备中心这些应用系统的处理能力与生产系统相同。5.2 恢复时间的要求RPO（Recovery Point Objective）：即数据恢复点目标，主要指的是业务系统所能容忍的数据丢失量。 RTO（Recovery Time Objective）：即恢复时间目标，主要指的是所能容忍的业务停止服务的最长时间，也就是从灾难发生到业务系统恢复服务功能所需要的最短时间周期。 RPO针对的是数据丢失，而RTO针对的是服务丢失，二者没有必然的关联性。RTO和RPO的确定必须在进行风险分析和业务影响分析后根据不同的业务需求确定。对于不同企业的同一种业务，RTO和RPO的需求也会有所不同。RPO和RTO是业务影响分析的结论之一。恢复时间是指从确认生产中心切换至灾难中心到灾难中心接替生产中心工作的时间。 而RTO的实现以以下两个主要方面为前提条件： 第一，实现灾难恢复的主要步骤及操作模式。包括：由灾难中心主管确认灾难的确发生；在灾难中心主机作断点分析，查明交易情况；完成网络物理切换（手工或自动）；启动灾难中心主机应用系统（手工或自动）；主机系统重新与分支机构连线，完成灾难中心切换任务。 第二，灾难恢复有关制度及运作模式的建立。包括灾难恢复的运作完全采用实时自动方式，及灾难恢复的运作采用人工干预与部分自动相结合的方式。可见，RTO不仅受到技术的影响，还跟管理流程和具体的业务操作密不可分。所以，目前我们尚无法估计出符合中国人寿实际情况的RTO指标。5.3 体系架构容灾的体系架构不仅要能处理单点故障，还要能处理多点故障，甚至能处理数据中心、整个企业甚至某一区域性的灾害。能够抵御多点故障甚至区域故障的集群结构是一种特殊的集群结构，称为容灾体系架构。这种架构可以提供灾难发生后的自动切换或者手工切换功能。一般来说，只有当整个数据中心都失效时，才启动切换功能。在地理位置上分离的容灾体系架构可以对非计划的停机提供保护，因为一个地点的故障影响不到另一点。为了能评估不同的容灾方案需要知道： 灾难的风险。需要针对台风，洪水还是地震设计容灾方案。要应对什么样的灾难，决定了选择什么样的容灾方案。例如，如果所在地易发生地震，那么另一处容灾站点就不应选择在相同的城市，因为地震会影响相当大的区域。另外，灾难发生的频率也影响是否选择一个快速的恢复方案。例如，可能会针对每个季节都发生的飓风设计一个快速恢复方案，而不会针对100年都没有喷发的火山设计方案。 业务的弱点。业务到底能承受多长时间的宕机？一些业务也许可以承受1或2天的恢复时间，而另一些业务可能需要在几分钟内恢复。一些应用可能只需要提供本地保护，另一些应用可能既需要本地保护，又需要具有远程容灾功能。重要的是要考虑容灾中心担任的业务角色。例如，生产线生产可能需要非常快的恢复速度。但是，如果最容易发生的灾难是地震，生产线和为生产线服务的计算机会在灾难中同时损坏，在这种情况下，容灾就没有什么必要了。而实现本地切换会更有意义。又如，订单处理中心是完全依靠计算机工作的，为避免灾害对这些设备造成损害而造成业务停顿而建立灾备中心是有意义的。决定采用什么容灾方案需要权衡灾难风险和在灾难发生时的业务弱点。针对不同的需求有不同的方案，但是无论什么容灾方案都会遵循一些基本原则： 通过地理位置上的分离保护节点 通过复制保护数据 使用冗余电源 建立高可用性网络这些指导原则还要加上标准的高可用性原则，例如采用冗余的物理访问通道（主机到磁盘阵列的连接）、网卡、电源和硬盘。容灾中心的数据复制方式的选择与应用的RPO密切相关。 对于RPO要求低的应用（例如，一天以上），可以采用磁带备份的方法进行数据复制。这种应用对于生产中心与灾备中心之间的网络连接无要求。 对于RPO要求较高的应用（例如，几个小时），可以采用异步数据同步的方式 对于RPO要求高的应用（例如，几分钟），可以采用同步数据同步的方式针对数据同步方式（同步或者异步），有两类方案1. 采用基于主机上运行的软件进行要求生产中心与灾备中心之间有高速IP网络2. 采用磁盘阵列进行要求生产中心与灾备中心之间有高速存储网络容灾的体系架构可以分成以下三种： 校园容灾 包含多个建筑物 可以自动切换的单一集群结构 不同站点间的磁盘镜像图 51校园集群体系架构 城市间容灾 本地网络和磁盘保护优先 可以自动切换的单一集群结构 站点间使用物理数据复制图 52城间集群体系架构 广域容灾 租用的高速交换网络 (用于数据链路) 多集群架构 站点间可以采用物理数据复制或逻辑数据复制 物理数据复制是指利用硬/软件进行的磁盘裸设备复制 逻辑数据复制指利用文件系统或数据库进行数据复制图 53广域集群体系架构数据同步技术及相关指标：技术手段RPORTO磁带备份几小时几星期硬盘间在线复制映像（快照）几分钟一天异步复制几秒钟几分钟同步复制0几秒钟基于广域网的集群几分钟一天磁带恢复几天几星期表 51技术手段与RPO、RTO的对应关系不同业务类型的服务级别：Gartner根据业务类型的不同，提出了如下的RTO和RPO要求（参见Best Practices and Trends in Business Continuity Planning2002年版）。级别业务服务级别一级 直接面对客户或者合作伙伴 对企业收入和正常生产有严重影响 提供24X7服务 可用性达到99.9%(停机时间45分钟/月) RTO=2小时；RPO=0小时二级 供应链 对企业收入和生产有一定的影响 可用性达到99.5%(停机时间3.5小时/月) RTO=8-24小时；RPO=4小时三级 企业后端应用 可用性达到99%(停机时间5.5小时/月) RTO=72小时；RPO=24小时四级 部门级应用 可用性达到98%(停机时间13.5小时/月) RTO=120小时；RPO=24小时表 52业务类型的服务级别分类我们建议中国人寿也按照这种方法，将所有应用分成四级。体系架构建议：中国人寿是全国性的大企业，数据中心是为全国各省服务的，为了最大限度的降低灾害的影响，我们建议灾备中心最好远离生产数据中心，所以我们建议中国人寿采用“广域集群体系架构”。中国人寿可以采取先建立同城的灾备中心，然后在建立远程灾备中心的策略。基于同城的灾备中心可以采用同步数据传输的方式，保证数据不丢失。而远程灾备中心采用数据异步传输的方式，保证系统的响应速度。通过同步与异步的结合，既保证了不丢失数据，又保证了系统的响应速度。如图5-4所示：开始，可以建立如图中最上部分所示的采用同步传输的灾备中心。其中P-VOL是在数据中心（站点A）的存储，而S-VOL是位于灾备中心的存储。如果条件成熟后，可以选择比较远的地方建立远地灾备中心（站点C），而将同城的灾备中心做为中间站点（站点B）（参见图中最下端的部分）。中间站点只需要配备存储设备，而不需要服务器设备。在建立了远程灾备中心后，应用的切换是在数据中心和远的数据中心之间进行的。数据中心（站点A）与中间站点（站点B）之间采用同步数据传输，中间站与灾备中心（站点C）之间采用异步数据传输。当站点A因故停止运行后，站点C要等待站点B的数据完全传输到站点C后才能重新运行。图 54中国人寿灾备中心假设方案5.3.1 灾备中心的主机、存储布局图 55 灾备中心主机、存储布局图示： 细线是网络线 绿色代表Active 红色代表Standby 粗线是存储网络线（SAN） 黑色代表Active 红色代表Standby 黄色背景的主机属于组 其他主机属于总部灾备中心包含了数据中心的所有应用，根据应用的RPO和RTO的要求不同，推荐采用不的技术进行数据复制。应用系统APP业务区域名称APP NAME灾难发生时的容灾要求可容忍的数据丢失时间（RPO）可容忍的业务中断时间（RTO）核心保险应用-Core24小时8小时销售支持和管理-SFA24小时8小时财务系统-Financial24小时8小时管理信息系统-MIS5天24小时电子商务-eBiz24小时8小时CRM24小时8小时精算和风险管理-Acturial 5天24小时人力资源管理-HR5天24小时表 53中国人寿关键应用RTO与RPO要求（来源：中国人寿IT规划项目组）根据表5-3中的数据，我们推荐采用磁带备份恢复和基于磁盘阵列的数据复制两种方式。 磁带备份恢复： 管理信息系统 精算和风险管理 人力资源管理 磁盘阵列复制： 核心保险应用 销售支持和管理 财务系统 电子商务 CRM另外还有一些系统，表5-3中虽然没有提到，例如目录服务器、企业门户网站、OA系统、EAI服务器、ETL服务器、Service Desk系统和产品开发。我们认为还是应该在灾备的考虑范围之内，原因有两条：1. 有些系统没有会影响其他系统的工作，例如EAI和ETL服务器、目录服务器2. 有些系统是平时进行正常的服务所必须的，例如OA系统、Service Desk、企业门户网站和产品开发。对于这些系统，我们也建议了如下恢复方案： 磁带备份恢复： Sevice Desk （提供IT服务，优先级不高） 产品开发（数据量小且变更频率低） EAI（数据量小且变更频率低） ETL（数据量小且变更频率低） 目录服务器（数据量小且变更频率低） 磁盘阵列复制： OA系统 企业门户网站根据表格5-1的要求，采用磁带备份恢复的系统每周备份二次增量备份和一次全备份（例如周六一次全备份，周二和周四各一次增量备份），将磁带快递到灾备中心后每周恢复三次。采用磁盘阵列复制方式的系统可以使用异步同步方式将数据从生产中心复制到灾备中心。采用磁带备份恢复的主要目的是节省网络通信的费用。实际上我们设计的体系架构（图5-4）可以支持所有数据通过磁盘阵列复制。5.4 灾备中心的网络5.4.1 灾备中心与生产中心之间的网络灾备中心与生产中心之间应该有容一条专用的网络链路（包括一条冗余链路）保证数据同步（参见图5-7中的链路D1和D2）。链路D1是与数据中心同步传输的链路，其带宽必须大于数据中心的峰值数据变化量。由于中间站点与数据中心是同城的，所以建议租用裸光纤，每对光纤的数据传输值可达80Gb/s（32波系统，2.5G/）。链路D2的带宽可以这样估算： 假设保险核心系统的每日数据更新量与其他系统（财务系统、销售支持系统、客户服务系统和电子商务系统）每日更新量的总和相同。 假设每日数据更新量与每日数据增长量相当 保险核心系统起用新系统时的初始数据量大约是是12TB，5年后是60TB。则平均每年增长9.6TB， 即每秒钟需要传送(60-12)/5)*1024*1024*8/360/24/36002.6Mb（注：这里假设使用异步传输，每日的数据平均在24小时内传输完毕，即RPO=24小时。如果考虑同步传输，则带宽应该大于等于最大的峰值数据变化量）如果加上其他业务的每日数据增长量，网络利用率为70，则要求带宽为2.6*2/0.7=7.42Mb图 56 灾备中心与生产中心的数据链路图示： 细线是网络线 绿色代表Active 红色代表Standby 粗线是存储网络线（SAN）中间站点与灾备中心之间采用FCIP技术进行异步数据同步。FCIP(Fibre Channel over IP)是在TCP/IP上用管道技术来实现Fibre Channel的受推荐标准。它采用封装技术将Fibre Channel协议封装在IP包中，以使它能够通过IP网。已经拥有Fibre Channel网的用户可以通过调节他们已经存在的SAN以使它们能够扩展到城域网和广域网。FCIP正是这样一种将多个Fibre Channel孤岛连接起来的手段。5.4.2 灾备中心的广域网架构图 57灾备中心广域网逻辑架构示意图如图所示灾备中心与各省级数据中心也有链路连接链路B。链路B的带宽可以同链路A相同。链路B可以有两种使用方法：1. 平时链路B不起用，只有当灾难发生后，由中国人寿通知电信运营商才启用，同时电信运营商也负责将所有以前连接到数据中心的网络路由到灾备中心。2. 链路B做为省公司到总部链路的备份链路，即当链路A发生故障时，省公司通过链路B经过灾备中心访问总部。我们推荐采用第二种方案。5.5 灾备中心的安全体系灾备中心应该遵守中国人寿企业内部的安全策略。灾备中心的安全架构原则上与数据中心一致，与安全相关的软硬件系统的处理能力可能不如数据中心的强大。请参照数据中心高端设计的有关章节。灾备中心的安全应包括以下内容： 所有房产的物理安全 信息安全计算机房和介质存储区域的安全 通讯安全语音和数据通讯安全 网络安全内联网和互联网安全6 灾备中心的管理体系 灾备中心的管理可以分成两部分： 灾备中心的日常管理 灾备中心的应急管理灾备中心的日常管理机构与数据中心相似，可以参照IT治理文档的组织架构部分。另外，灾备中心还负责管理业务永续运行，关于业务永续运行管理可参照以下两章的内容。灾备中心的运维部门平时支持应用开发组的工作。6.1 业务永续管理与中国人寿其他管理流程的关系图6-1列出了业务永续运行管理与ITSM（IT服务管理）其他管理流程的关系。图 61业务永续管理与ITSM其他流程的关系6.2 业务永续管理流程图6-2是业务永续运行日常管理的概要流程。图 62中国人寿永续运行管理流程概览其中业务永续运行经理，业务永续运行组协调员和恢复组组长可以是兼职人员。6.3 计划的测试、培训和演习计划的测试是有效的应急能力的关键要素。测试能够确定和解决计划的缺陷。测试还协助评估恢复人员快速有效实施计划的能力。每一个IT业务永续运行计划要素都应该得到测试以确保各个恢复规程的正确性和计划整体的有效性。应急测试应该涉及到以下领域： 在备用平台上使用备份介质进行系统恢复 在恢复团队之间进行协调 内部和外部的连接性 使用备用设备的系统性能 正常操作的恢复 通知规程为了能从测试中得到最大价值，业务永续运行计划协调人应制定测试计划，测试计划应设计为对所选择的测试要素有明确的测试目标和成功标准。测试目标和成功标准的使用可以增加每个测试要素的有效性并对整个计划进行评估。测试计划应该包括每个测试的详细的事件表和测试的参与者。测试计划还应该清晰地描述范围、场景和后勤。场景可以选择为最糟糕的事故或最有可能发生的事故。它应尽量模仿真实情况。有两种基本的演练方式： 课堂演练 课堂演练的参与者在桌面上对规程进行排演而不实际进行恢复操作。在两种演练类型中课堂演练是最基本和最经济的，应该在执行功能演练之前执行。 功能演练 功能演练比桌面上的演练更进一步，要求虚构事件。功能演练包括模拟和战术演练。通常，为扮演外部机构的角色演员写好脚本，或者有真正的相关机构或供应商参与。功能演练可以包括针对备用站点的实际配置和或系统切换。测试的预演对团队成员来说是有益的，这样可以使他们做好精神准备并有时间对工作负荷进行优化调整。由于缺席或测试与其工作存在冲突，有一些团队成员很可能无法使用。人员的可用性问题有助于计划发现实际响应中可能遇到的情况，这样就为计划的修改提供了重要的参考依据。演练不能打断正常的运行是很重要的。如果在备用设施进行测试，业务永续运行计划协调人应该协调测试日期和设施运行的关系 。测试结果和学习到的经验应该记录到文档中并由测试的参与者或其他适当人员进行检查。在测试中和测试后检查中收集到的有助于提高计划效率的信息应该添加到业务永续运行计划中。对于业务永续运行计划职责的培训应该是对测试的补充。培训至少每年举办一次；拥有计划规定职责的新雇员应该在被雇用后接受短期培训。和业务永续运行计划相关的人员所接受的培训最终应该使得他们能够无需实际文档的协助就能够执行相应的恢复规程。这在由于灾难的影响造成最初几个小时里无法获得书面或电子版本的计划的情况下具有非常重要的意义 。恢复人员应该得到以下计划要素的培训： 计划的目的 团队之间的协调与沟通 汇报规程 安全需求 团队特有的处理过程（通知启动、恢复和重建阶段） 个人职责（通知启动、恢复和重建阶段）6.4 业务永续运行计划的维护业务永续运行计划需要经常维护、修正和更新，以适应不断变化的环境。图6-3是计划的维护流程建议，仅供参考。图 63中国人寿业务永续运行计划的维护流程为了更加有效,计划必须被维持在能够正确反映系统需求、规程、机构架构和策略的就绪状态。由于业务需要的转移、技术的更新或新的内外政策会造成IT系统的频繁变化。所以，应急计划的定期检查和更新是至关重要的，应该做为机构变化管理过程的一部分以确保新的信息能够被添加进来，应急措施能够根据需要被修订。计划应该至少每年进行一次针对正确性和完整性的检查，在计划的任何部分发生重大变化时也应该进行，这是一项基本的要求。某些部分应该得到更频繁的检查，如联络清单。根据系统类型和重要程度的不同，对计划内容和规程的评估可能会更加频繁。计划的检查至少要关注以下内容： 运行需求 安全需求