容灾项目咨询方案技术建议书

xx公司冗灾项目建设咨询方案 技术建议书附件xx公司冗灾项目建设咨询方案技术建议书xxx公司专有信息声明本方案建议书属商业机密文件，书中的所有信息均为xxx公司机密信息，仅限于xx公司冗灾项目组内部使用。务请妥善保管并且仅在与项目有关人员范围内使用，未经xxx公司明确作出的书面许可，不得为任何目的、以任何形式或手段（包括电子、机械、复印、录音或其它形式）对本文档的任何部分进行复制、存储、引入检索系统或者传播。尽管xxx公司已经尽力使本文档内容的完整性和有效性，但仍可能有技术方面不够准确的地方或印刷错误。若需求有所变化，xxx公司将对有关内容进行相对应的调整，并在本建议书未来版本中体现。关于本文档文档信息文档名称xx公司冗灾项目建设咨询方案技术建议书作者xxx公司说明 本文档是xxx公司根据对xx公司冗灾项目相关需求的理解，在与xx公司冗灾项目组相关领导和技术人员初步技术交流的基础上，从容灾的角度，为xx公司冗灾项目提供的服务建议。修订历史 (REVISION HISTORY)RevSectionTypeDateAuthorRemarks1.02008-03-24创建建议书1.12008-03-28修订内容范围本文档是xx公司冗灾中心建设研究项目技术建议书。适用的对象本文档仅适用于xx公司冗灾中心建设研究项目组及参与该项目的决策者、评估者。目录1.项目背景51.1.前言51.2.信息化现状62.XX公司容灾中心建设方法论82.1.业务连续性方法论82.1.1.风险分析122.1.2.业务影响分析142.1.3.可恢复性评估162.1.4.制定恢复策略172.1.5.容灾方案设计192.1.6.业务持续计划设计262.1.7.业务持续计划的演练和维护292.1.8.xx公司冗灾项目建设规划建议293.容灾中心建设咨询项目实施方案313.1.任务一、当前环境调研分析313.1.1.工作目标313.1.2.工作内容323.1.3.工作交付成果333.1.4.完成标准333.2.任务二、风险分析343.2.1.工作目标343.2.2.工作内容343.2.3.工作交付成果343.2.4.完成标准353.3.任务三、业务影响分析353.3.1.工作目标353.3.2.工作内容353.3.3.工作交付成果363.3.4.完成标准373.4.任务四、灾难恢复策略设计373.4.1.工作目标373.4.2.工作内容373.4.3.工作交付成果373.4.4.完成标准383.5.任务五、灾难恢复系统总体规划架构设计383.5.1.工作目标383.5.2.工作内容383.5.3.工作交付成果383.5.4.完成标准393.6.任务六、项目管理393.6.1.工作目标393.6.2.工作内容393.6.3.工作交付成果403.6.4.完成标准404.项目费用估算411. 项目背景1.1. 前言删减1.2. 信息化现状公司信息化建设起步于2002年，通过多年的不断建设和积累，2002-2006年间先后建立了以下系统：1、物流管理信息系统：该系统业务覆盖公司采购、销售、仓库、运输、质量、生产、财务和人力资源管理，系统运行环境为：IBM X346 2X3.0CPU 双机冗余磁盘阵列柜，OS：Windows Server 2003SQL20002、生产综合管理系统：实现公司各生产厂、车间日常生产管理、设备管理、统计报表等，运行环境为： DELL 主频：Xeon 3.0 内存：2G 硬盘：3块146G做RAID5/ WINDOWS 2003ServerOracle 8i3、实时数据库系统：通过采集站采集公司各生产装置DCS上的实时数据，通过组态后再进行发布。运行环境为：DELL 主频：Xeon 3.0 内存：2G 硬盘：3块146G做RAID5/ WINDOWS 2003ServerInfoplus.214、内部网络平台：以网站形式动态发布公司各类信息，系统运行环境为：IBM X346 3.2CPU，内存：2G硬盘：3块146G OS：Windows Server 2003SQL20005、外部网络平台：以网站形式向外界动态发布公司相关信息，系统运行环境为：IBM X346 3.0CPU，内存：1G硬盘：2块72G OS：Windows Server 2003SQL20006、DHCP服务器：实现公司内部IP分配、地址解析和转发。运行环境为：HPLC3000 CPU 1G，内存：512MB 硬盘：2块72G OS：Windows Server 20037、内部EMAIL服务器：实现公司内部EMAIL功能。运行环境为：HP LC2000 CPU 1G，内存：512MB 硬盘：2块72G OS：Windows Server 20008、内部实时通讯服务器：运行RTX及时通讯软件，实现公司内部实时通讯功能。运行环境为：HP CPU 1.8G，内存：512MB 硬盘：2块72G OS：Windows Server 20002006年7月，为了进一步提高公司管理水平，提高企业的市场竞争力，公司开始在xx分公司实施ERP一期项目并与2007年3月上线使用，取得了很好的效果。接着开始ERP项目二期的实施，预计10月份全部上线。目前ERP系统的运行环境为：ERP生产机IBM p570（4C16G）双机系统，ERP开发测试机p550Q（4C12G两分区），BW生产机p550Q（4C16G），BW开发机p520Q（2C8G），portal生产开发机p550Q（4C16G两分区），存储磁盘阵列DS6800，SAN存储架构，并采用IBM 3582磁带库做数据备份。2. xx公司容灾中心建设方法论2.1. 业务连续性方法论从整个计算机系统的发展来看，容灾经过了一个很长时间的发展过程，在上个世纪60年代，通常进行的都是集中式处理系统，每个系统具备一些简单的灾难恢复计划，通常恢复时间也很长，都以周为单位计算，进行的数据备份和恢复也都处于被动式的模式。到了70年代，随着计算机系统的逐渐普及，应用逐渐有集中式系统转到分散式系统，这个时候，系统开始考虑一些简单的业务恢复计划，恢复的时间也开始以天为单位。到了90年代，网络的飞速发展，系统有开始走向集中，这个时候，对业务的连续性要求就更高，要求恢复时间也小时为单位，系统需要考虑避免高可用的风险。到了今天，企业应用系统进一步飞速发展，业务要求能够达到行业级别的业务连续计划，此时，要求实现业务系统的更高可用性，恢复时间甚至要求达到实时的水平。业务的发展使得企业对业务连续性的要求也越来越高。在业务连续性中，以下几个概念非常重要，它们也是衡量业务持续及容灾需求的指标。恢复时间目标（RTO）恢复时间目标（Recovery Time Objective，简称RTO）是指灾难发生后，从I/T系统宕机导致业务停顿时刻开始，到IT系统恢复至可支持各部门运作、业务恢复运营之时，此两点之间的时间段称为RTO。一般而言，RTO时间越短，即意味要求在更短的时间内恢复业务至可使用状态。虽然从管理的角度而言，RTO时间越短越好，但是，这同时也意味着更多成本的投入。对于不同行业的企业来说，其RTO目标一般是不相同的。即使是在同一行业，各企业因业务发展规模的不同，其RTO目标也会不尽相同。RTO目标的确定可以用下图来说明：如上所说，RTO目标越短，成本投入也越大。另一方面，各企业都有其在该发展阶段的单位时间赢利指数，该指数是通过业务影响分析（Business Impact Analysis）咨询服务，以访谈、问答和咨询的方式得到确定的。在确定了企业的单位时间赢利指数后，就可以计算出业务停顿随时间而造成的损失大小。如上图，结合这两条曲线关系，我们将可以找到对该企业而言比较适合的RTO目标，即在该目标定义下，用于灾难备援的投入应不大于对应的业务损失。恢复点目标（RPO）恢复点目标（Recovery Point Objective，简称RPO）是指对系统和应用数据而言，要实现能够恢复至可以支持各部门业务运作，系统及生产数据应恢复到怎样的更新程度。这种更新程度可以是上一周的备份数据，也可以是上一次交易的实时数据。与RTO目标不同，RPO目标的确定不是依赖于企业业务规模，而是取决于企业业务的性质和业务操作对数据的依赖程度。因此，RPO目标对相同行业的企业而言会有些接近，而对于不同行业的企业来说仍可能会有较大差距。RPO目标的确立仍是以咨询的方式，通过与各业务部门主管的交流，了解业务流程和IT应用的关系，以及通过回答问卷的方式，确定能够支持该企业核心业务的RPO目标。通常可以用以下1到5的等级来衡量企业业务连续性的成熟度。在长年灾难服务提供的过程中，IBM在业务持续服务方面形成了一套完整的实施方法论，如下图所示，它包括分析、设计、和实施三个阶段的咨询和技术服务，IBM又将该三个阶段工作划分为七个步骤，即“风险分析”、“业务影响分析”、“可恢复性评估”、“恢复策略制定”、“灾难恢复方案设计”、“业务持续计划设计”和“业务持续计划演练和维护”。IBM采用业务持续咨询方法论来规划和设计出企业的业务持续计划。该广受验证的实施方法论的7个步骤由三个阶段串连而成： 分析阶段包含“风险评估”、“业务影响分析”、及可恢复性评估。此阶段提供对灾害潜在损失、各种冲击、及现行恢复能力等方面的量化及质化的分析评估，同时也根据需求来向客户建议必需的措施及迅速的解决方案来实现完全的恢复能力。 设计阶段包含“恢复策略制定”及企业“灾难恢复整体解决方案设计”。此阶段根据分析阶段的结果来制定出企业的恢复策略，规划及设计出为实现企业业务持续所必需的行动与解决方案，以达到企业在组织、流程及技术层面的恢复需求。 实施阶段包含“业务持续计划设计”及“业务持续计划的演练和维护”。此阶段将建立业务持续计划、实施业务持续计划的桌面演练、执行业务持续计划及灾难恢复的测试、设计业务持续计划的维护方案。其中，业务持续计划中将包括企业的“业务恢复计划”和“技术恢复计划”。我们建议，企业的业务持续计划的设计及拟定应该是一个持续并循环往复的过程，每一阶段都能持续不断的改进，并且在实际工作中体现有效性与高效性。上述业务持续计划的分析、设计与执行三个阶段，正如上图所绘，可根据其特性分类，分为与企业业务相关及技术相关的不同步骤，共分为以下七个步骤： 风险分析 业务影响分析 可恢复性评估 恢复策略制定 灾难恢复方案设计 业务持续计划设计 业务持续计划的演练与维护以下将分别介绍这七个步骤。2.1.1. 风险分析风险分析（Risk Analysis）分析可能对企业业务系统和IT系统的安全性造成威胁的各种风险因素并提出相应的对策和改进方案。因此，风险分析的工作将不仅仅只是提出补救措施，还将定义出对于风险的预防措施。风险分析的目标是： 对企业可能面临的主要威胁性风险进行质与量化的评估。 按照各风险的严重性，分别定义其所处的风险层次和级别。 根据各风险发生的可能性，分别定义其所处的风险级别。 定义风险矩阵图（如上图所示）。 提出应对风险的建议（避免风险、转移风险、或接受风险）。风险分析的进行方式为： 首先通过召开启动会议来说明风险分析的目的、参加人员需求与职责、设计及分发调查问卷、安排访谈与现场巡视的进度。 辨认现存风险：搜集财务资料、实施人员访谈、巡视当地状况、检查物理设施、分析搜集到的数据、审核各设施和设备的操作程序（包括IT和非IT）。 评估风险冲击：检视损失冲击、开发评估分析细节、记录评估结论、定义冲击的等级和层次。 确定合理的减低风险威胁的处理方法和优先次序。 记录风险分析工作中的发现与建议。 制作书面风险分析报告 向管理阶层汇报工作成果和最终交付项目。实施风险分析给客户带来的效益是： 降低由于不安全、不可靠与不适宜的管理所造成的威胁和风险。风险分析的对象通常为“基础设施与技术”、“人的因素”、和“不可抗力”三个层面，同时，又分为内部原因和外部原因，具体如下表所示：基础设施和技术人的因素不可抗力内部员工外部人员气候自然灾害w 硬件故障w 技术缺陷w 电源故障w 电压波动w 电源接地不良w 电缆老化w 空调损坏w 消防设施毁坏w 通讯线路中断w w 病毒w 误操作w 盗窃w 蓄意破坏w 粗心或无知w 辞职w 情绪波动w w 病毒w 黑客攻击w 误操作w 入室行窃w 蓄意破坏w 间谍活动w 示威活动w 消防灌水w w 严寒w 冰雪w 恶劣气候w 崩塌w 雷击w 龙卷风w 海啸w 交通堵塞中断w w 水位过高w 地震w 火灾w 塌方w 飞行器撞击w 爆炸w 火山爆发w 内部原因外部原因2.1.2. 业务影响分析业务影响分析（Business Impact Analysis，简称BIA）收集、分析及汇总及排序当信息系统一旦遭遇灾害对各项重要关键性业务的影响程度，并依据其优先级提出恢复策略建议。通过业务影响分析可验证实施容灾解决方案的必要性及需求。业务影响分析的目标是： 确定企业的关键业务流程。 定义各关键业务可容许中断的最大时间长度。 确认各关键业务数据丢失的可容许程度。业务影响分析的进行方式为： 首先通过召开启动会议来说明业务影响分析的目的、参加人员需求与职责、设计及分发调查问卷、安排后续访谈行程。 执行后续访谈，收集问卷、与参加人员共同检查问卷内容以确定：w 重要业务项目w 恢复时间目标（Recovery Time Objectives）的需求w 业务中断的影响w 各部门执行恢复所需的资源 开发初步总结 举行复审会议来验证以下项目：w 验证各业务项目恢复优先级w 验证恢复时间目标w 验证重要数据的完整 制作书面业务影响分析报告。 向管理阶层作总结报告。实施业务影响分析给客户带来的效益是： 了解不同中断时间对各业务造成的直接与间接损失及优先级。 开发恢复策略目标。2.1.3. 可恢复性评估可恢复性评估（Recoverability Assessment）定义现行各业务流程的恢复能力及现行技术环境的特征，它将从架构、平台、技术、基础设施、组织结构、恢复流程等各层面来评估企业目前的恢复能力。在可恢复性评估中将证实企业当前的业务恢复能力，而在业务影响分析之后，可确定企业需要的恢复能力，这样，将可发现当前恢复能力与需要的恢复能力之间的差距，从而在“恢复策略制定”工作中，根据此差距可规划出企业的恢复策略。可恢复性评估的目标是： 评估使用现有处理流程与程序，IT作业目前是否能够恢复、需要多少时间恢复、以及可能的数据丢失数量。可恢复性评估的进行方式为： 首先通过召开启动会议来说明项目目的、参加人员的需求与职责、设计及分发 调查问卷、安排访谈与现场访视行程。 复审现有文件。 举行可恢复性评估研讨会。w 记录现行备份时间长度与方式。w 确定持续时段。w 定义运行重要应用所需资源。 举行异地分储设施的稽查。 记录可恢复性评估结果。 定义适当的业务持续需求。 制作书面可恢复性评估报告。 向管理阶层作总结报告。实施可恢复性评估给客户带来的效益是： 正确地得出企业当前的恢复能力。 为恢复策略的制定提供理论依据。 评估恢复所需投资。2.1.4. 制定恢复策略恢复策略制定（Recovery Strategy）依据前述各项分析和评估的结果和发现，定义消减当前恢复能力与恢复能力目标之间差距的高层次计划（High level plan）。业务影响分析（BIA）是一项深入的研究，用于确定业务之间的关键功能和其中的关键点。然后对该关键点及与其相关的可能发生的损失进行权衡，以决定可能的业务持续策略和所需成本。利用这一信息，管理层可以依照风险几率和业务需要的优先次序，制订出适当的业务持续策略。可恢复性评估与业务影响分析共同作用，对数据中心的流程和当前的恢复能力进行分析。着重于数据中心环境的分析，其中包括硬件、软件、网络和工作流程。通过正常的数据收集、深入的采访和数据分析，可恢复性评估将帮助您了解系统及其与整体业务之间的关系。根据业务影响分析所确定的恢复能力目标与可恢复性评估所确定的当前恢复能力的差距，即可设计和制定出各业务流程的恢复策略。使业务部门所需要的恢复方案（业务影响分析）和系统部门所具备的恢复能力（恢复能力）同步十分重要。IBM为XXX通过业务影响分析和可恢复性评估所进行的顾问工作，将产生一个全面的业务持续策略，并提出为了业务持续所需要进行的改变，以及各种相关的具体建议；配合目前最新的IT可行技术，提出最适当的灾难恢复策略。制定恢复策略的目标是： 消减当前恢复能力与恢复能力目标之间差距的高层次计划（High level plan）。 解决方案的投资估算。 建立短期、中期、长期策略。 提出对组织与运作的建议。恢复策略制定的进行方式为： 依据前述各项分析，配合目前技术，提出最适当的灾难恢复短、中、长期策略。 估算各种解决方案的投资成本与效益分析。 召开研讨会确认恢复策略。 向管理阶层作总结报告。实施恢复策略制定给客户带来的效益是： 明确了恢复方案的策略计划与所需投资。 2.1.5. 容灾方案设计灾难恢复方案设计（Recovery Solution Design）依据恢复策略来详细设计所选择的最适用的容灾技术方案。IBM建议，在设计容灾方案时，应综合考虑基础设施、硬件平台、软件技术、网络配置、IT组织、技术恢复流程等方面。根据1992年在美国加州阿纳海姆制定的国际标准SHARE 78的定义，容灾技术方案可以根据以下主要方面所达到的程度而分为七个层次： 备份/恢复的范围 灾难恢复计划的状态 主生产中心与灾备中心之间的距离 主生产中心与灾备中心之间是如何相互连接的 数据是怎样在两个中心之间传送的 允许有多少数据被丢失 怎样保证更新的数据在在灾备中心被更新 灾备中心可以开始进行恢复工作的能力即从低到高的七种不同层次的容灾解决方案。如下图所示，该七个层次的技术方案标准分别是：很明显，这七个层次所实现的恢复目标是不同的、实施费用也不同。以上七个级别的容灾技术方案的特点和区别，可以参见如下描述：层次RTORPO灾备中心备份方式数据更新/恢复主机Tier 072hrs以上24hrs以上无磁带本地磁带关机Tier 172hrs以上24hrs无磁带远程磁带关机Tier 224-72hrs24hrs专有的磁带磁带关机Tier 312-24hrs文件级专有的电子文件，定时的活动Tier 44-12hrs日志级专有的电子文件或日志，时间段活动Tier 52-4hrs交易级专有的电子数据，软件活动Tier 630-60min交易级专有的电子数据，系统/硬件活动Tier 730-60min交易级专有的电子数据，系统/硬件活动0层：无异地备份数据 (No off-site Data) 对于使用0层灾难恢复解决方案的业务，可称其为没有灾难恢复计划，主要表现为： 数据仅在本地进行备份恢复，没有任何数据信息和资料被送往异地，没有处理意外事故的计划。 恢复时间：在此种情况下，恢复时间不可预测。 事实上也不可能恢复。例如，目前我们通常在机房内所做的数据备份，备份介质保留在机房内，用于本地的数据恢复。 当灾难发生时，数据备份和设备有可能一同被毁，无法进行恢复。1层：有数据备份，无备用系统（Data Backup with No Hot Site）使用1层灾难恢复解决方案的业务，通常将需要的数据备份到磁带上，然后将这些介质运送到其它较为安全的地方。但在那里缺乏能恢复数据的系统，若数据备份的频率很高，则在恢复时丢失的数据就会少些。 此类业务应能忍受几天乃至几星期的数据丢失。例如， PTAM（Pickup Truck Access Method）是一种许多数据中心所采用的标准备份方式。在完成所需的数据备份后，用适当的运输工具将它们送到远离本地的地方，同时备有数据恢复的程序。 灾难发生后，一整套系统安装需要在一台未开启的计算机上重新完成，系统和数据可以被恢复并重新与网络相连。这种灾难恢复方案相对来说成本较低(仅仅需要运输工具的消耗以及存储设备的消耗)。但恢复的时间长，且数据不够新。2层：有数据备份，有备用系统 （Data Backup with Hot Site） 使用2层容灾解决方案的业务会定期将数据备份到磁带上，并将其运到安全的地点。在备份中心有备用的系统，当灾难发生时，可以使用这些数据备份磁带来恢复系统。 虽然还需要数小时或几天的时间来恢复数据以使业务可用，但不可预测的恢复时间减少了。 2层相当于在1层上增加了备份中心的灾难恢复。备份中心拥有足够的硬件和网络设备来维持关键应用的安装需求，这样的应用是十分的关键的，它必须在灾难发生的同时，在异地有正运行着的硬件提供支持。 这种灾难恢复的方式依赖于PTAM方法去将日常数据放入仓库，当灾难发生的时候，再将数据恢复到备份中心的系统上。 虽然备份中心的系统增加了成本，但明显降低了灾难恢复时间，系统可在几天内得以恢复。3层：电子链接（Electronic Vaulting） 使用3层容灾解决方案的业务，是在2层解决方案的基础上，又使用了对关键数据的电子链接技术。电子链接将磁带备份后更改的数据进行记录， 并传到备用中心，使用此种方法会比使用传统的磁带备份更快地得到更新的数据。所以，当灾难发生后，只有少量的数据需要重新恢复，恢复时间会缩短。 由于备用中心要保持持续运行，与生产中心间的通讯线路要保证畅通，增加了运营成本。 但消除了对运输工具的依赖，提高了灾难恢复速度。 例如，某企业在每天下班后，将当日的流水全部记录下来，通过网络传到备份中心；备份中心在备用系统上，重新将所有业务重做，保证与生产中心的一致性。这一领域的产品可以分四层：1） 存储设备层：IBM-ESS-PPRC、IBM-DS4000-RM、EMC-SRDF、HP-EVA-StorageWorks Continuous Access、FALCONSTOR-IPSTOR、NETAPP等。2） 操作系统及系统软件层：IBM-GEORM、VERITAS-Storage Replicator/Volume Replicator、LEGATAL- RepliStor。3） 数据库层：IBM-DB2-HADR、IBM-INFORMIX-HDR、ORACLE-ORACLE- DATA GUARD等。4） 应用程序层：应用程序开发时考虑到数据的复制。4层：使用快照技术拷贝数据 （Point-in-time Copies） 使用4层灾难恢复方案的业务，对数据的实时性和快速恢复性要求更高些。1-3层的方案中较常使用磁带备份和传输，在4层方案中开始使用基于磁盘的解决方案。此时仍然会出现几个小时的数据丢失，但同基于磁带的解决方案相比，通过加快备份频率，使用最近时间点的快照拷贝恢复数据会更快。 系统可在一天内恢复。 4层灾难恢复可有两个中心同时处于活动状态并管理彼此的备份数据，允许备份行动在任何一个方向发生。接收方硬件必须保证与另一方平台在地理上分离，在这种情况下，工作负载可能在两个中心之间分享，中心1成为中心2的备份，反之亦然。在两个中心之间，彼此的在线关键数据的拷贝不停地相互传送着。在灾难发生时，需要的关键数据通过网络可迅速恢复，通过网络的切换，关键应用的恢复也可降低到小时级。支持这种工作方式的产品包括IBM-HAGEO、VARITAS-Global Cluster Manager。5层：交易的完整性 （Transaction Integrity） 使用5层灾难恢复方案的业务，要求保证生产中心和数据备份中心的数据的一致性。 在此层方案中只允许少量甚至是无数据丢失，但是该功能的实现完全依赖于所运行的应用。 5层除了使用4层的技术外，还要维护数据的状态 - 要保证在本地和远端数据库中都要更新数据。 只有当两地的数据都更新完成后，才认为此次交易成功。 生产中心和备用中心是由高速的宽带连接的，关键数据和应用同时运行在两个地点。当灾难发生时，只有正在进行的交易数据会丢失。 由于恢复数据的减少，恢复时间也大大缩短。数据库的数据复制功能一般可以工作在这样的方式下：IBM-DB2-HADR、ORACLE-ORACLE- Replication等。6层：少量或无数据丢失 （Zero or little data loss） 6层灾难恢复方案可以保证最高一级数据的实时性。 适用于那些几乎不允许数据丢失并要求能快速将数据恢复到应用中的业务。 此种解决方案提供数据的一致性，不依赖于应用而是靠大量的硬件技术和操作系统软件来实现的。这一级别的要求很高，一般需要整个系统应用程序层到硬件层均采取相应措施。1）应用程序层采用基于交易（TRANSACTION）的方法开发。2）数据库可以采取数据复制。IBM-DB2-HADR、IBM-INFORMIX-HDR、ORACLE-ORACLE- DATA GUARD等。3）操作系统使用集群软件、站点迁移软件、数据复制软件：IBM-HACMP、VARITAS-Global Cluster Manager等。4）硬件层使用同步的数据复制：IBM-ESS-PPRC、IBM-DS4000-RM、EMC- SRDF或使用带有CONSISTANCY-GROUP功能的异步数据复制IBM-ESS-PPRC、IBM-DS4000-RM。7层：解决方案与具体业务相结合，实现自主管理 (Highly Automated , Bussiness Integrated Solution) 7层灾难恢复方案在第6层的基础上，集成了自主管理的功能。在保证数据一致性的同时，又增加了应用的自动恢复能力，使得系统和应用恢复的速度更快、更可靠（按照灾难恢复流程，手工操作也可实现整个恢复过程）。 7层可以实现0数据丢失率，同时保证数据立即自动地被传输到恢复中心。7层被认为是灾难恢复的最高级别，在本地和远程的所有数据被更新的同时，利用了双重在线存储和完全的网络切换能力。7层是灾难恢复中最昂贵的方式，但也是速度最快的恢复方式。当一个工作中心发生灾难时，7层能够提供一定程度的跨站点动态负载平衡和自动系统故障切换功能。现在已经证明，为实现有效的灾难恢复，无需人工介入的自动站点故障切换功能需要一个应该纳入考虑范围的重要事项。 在实际选择容灾方案时，需要在方案本身、宕机时间和实施方案所需成本三者之间找到一个平衡点。 三者的平衡关系 2.1.6. 业务持续计划设计业务持续计划设计（Business Continuity Planning）定义、书面化与测试在灾难发生之前、之中与之后的企业营运组织架构与任务职责，以确定可被接受的业务持续运作的规范。IBM建议，业务持续计划将主要由“业务恢复计划”和“技术恢复计划”两方面来组成。其中，业务恢复计划为：当灾难事件发生时，为确保企业关键业务功能连续运作而必须遵循的恢复程序和实施细节。技术恢复计划为：当灾难事件发生时，在灾备中心建立和执行基础架构恢复所必须遵循的恢复程序，包括IT系统和相关设施。为有效并高效的实施业务持续计划，还必须为灾难恢复和业务持续设计相应的组织架构和人员职责。业务持续计划设计的目的是： 定义、制作、建置与测试于灾害发生前、中、后的组织架构设计与行动计划，以确保公司各重要关键业务的持续运作。业务持续计划设计的进行方式为： 首先召开启动会议来说明项目目的、参加人员需求与职责、分发业务规范工作手册（Workbook）、确定工作手册返回日期。 收集与分析工作手册内容。 确认下列项目的备份处理：w 重要应用系统w 系统软/硬件w 数据库w 网络w 特殊需求w 备份处理w 数据保存w 系统安全。 确认下列项目的持续处理w 系统持续w 本地用户w 远程用户w 入网机构w 服务者w 供货商w 人员w 特殊需求w 次序/优先级 开发业务持续计划的细节。 确定各项工作的负责人及其应完成职责。 开发灾难通报程序。 开发业务恢复工作项目图表及时间安排 开发回切作业处理。w 设备修复与重购w 建筑物重建w 数据回归w 业务切换 完成业务持续计划初稿。 制作业务持续计划的桌面演练计划，演练活动包括：演练时间、演练范围、目标、参加人员、所需资源、假设状况、衡量标准、过程叙述、结果讨论与计划维护。 建立业务持续计划维护的处理规范：包括正常计划维护、根据演练结果的维护、由于各项变更而产生的维护、定期维护、回切作业的维护。 在灾备技术系统建立后，实施业务持续计划实际测试。 根据桌面演练与测试，完成对业务持续计划的完善和修订。 向管理阶层作总结报告。业务持续计划设计给客户带来的效益是： 建立紧急应变组织与行动的指导文件。 作为演练和测试的指导方针。用于企业业务持续计划的稽核。2.1.7. 业务持续计划的演练和维护业务持续计划的演练和维护通过对业务持续计划的桌面演练、实际测试、和维护管理，确保业务持续计划保持最新及有效性。xxx公司将在业务持续计划的初步计划开发完成后，为xx公司实施桌面演练；同时，xxx公司将为xx公司开发“桌面演练计划”以供xx公司日后自行实施桌面演练时使用。此外，我们建议xx公司每年执行一次桌面演练。xxx公司将在xx公司灾备技术方案实施完毕后，协助为xx公司实施业务持续计划的实际测试（真实演练）。同时，将为xx公司开发“真实演练计划”以供xx公司日后自行实施真实演练时使用。此外，我们建议xx公司每两年执行一次真实演练。业务持续计划的维护包括： 日常计划维护 根据演练结果的维护 由于各项变更而产生的维护 定期维护 恢复计划和回切计划的维护2.1.8. xx公司冗灾项目建设规划建议为了提高xx公司企业业务系统的可靠性、保障业务的连续运行，根据前期的客户需求分析，xx公司的容灾项目的最终建设目标为：在xx公司总部建设系统的同城灾备中心，来保障系统的可靠性和业务的持续运行能力。建议实现该目标分两部分组成：第一阶段主要为咨询工作，完成以上所述的风险分析，业务影响分析，可恢复性评估，恢复策略，和容灾方案设计，该容灾方案设计可根据客户指定品牌平台或者不针对平台进行框架性设计，并提供多个的方案供客户选择。从而获得对容灾项目的全面分析和规划。第二阶段为根据第一部分工作结果，进行容灾项目的实施，业务持续计划的设计，演练，维护。3. 容灾中心建设咨询项目实施方案在容灾中心建设的第一阶段，xxx公司可为xx公司完成以下六大服务任务。完成第一阶段的目标。3.1. 任务一、当前环境调研分析3.1.1. 工作目标根据IBM业务连续性的方法学，一个企业的业务连续运作能力通常从体现在6个层次-基础架构、IT技术、应用和数据、流程、组织、策略。其中，基础架构主要指机房环境，包括机房的进出制度、空调、电源安全等；IT技术主要包括主机、存储、网络、中间件等；应用和数据包括应用和数据安全、备份策略、应用架构等；流程包括业务流程、IT流程等；组织包括组织架构、人力资源管理、组织之间协作等；策略包括财务策略、安全策略、可靠性策略、风险管理策略等。这六个层次的任何一个方面的缺陷都将影响企业的运作。当前环境分析主要是针对业务冲击分析的结果，收集目前的系统现状，从架构、平台、技术、基础设施、组织结构、恢复流程等各层面来评估企业现行各业务流程的恢复能力， 通过本阶段的工作，得出各业务流程所牵涉的企业资产及资源（人力资源、IT架构、技术储备、技术使用程度、网络环境等），并分析得出目前业务环境是否能够支持容灾需求、冗余程度、可能造成的数据损失等报告，从而得出目前现状与预期恢复目标之间的差距。这个差距将作为容灾策略决策的重要依据。当前环境分析的实施主要从以下方面来分析和评估：当前环境分析的工作主要分为两个大的阶段：阶段一：对xx公司现有应用系统现状进行调研。调研阶段要达到以下几个目标：l 清楚了解各应用系统的软硬件平台（中间件、操作系统、硬件平台、网络平台、存储平台、数据结构等）、实施情况、运行情况；l 清楚了解各应用系统的备份策略和备份手段和其他备份现状信息；l 清楚了解个应用系统在相应领域的建设计划和需求；l 对以上情况进行分类、分析和总结，并对典型情况进行详细说明。阶段二：系统可恢复能力分析，这个阶段要达到以下目标l 明确各信息系统的基础架构、IT技术、应用和数据、流程、组织、策略现状；l 清楚各信息系统在基础架构、IT技术、应用和数据、流程、组织、策略方面的可恢复能力的状况；l 了解各种可以提高可恢复能力的可能方法；3.1.2. 工作内容该任务主要负责收集目前xx公司信息系统现状，并对系统现状进行整理、分类和分析。并从多个层面对系统的可恢复能力进行调研，了解目前系统响应灾难的能力，分析现在的系统能力与xx公司实际业务需要的系统可恢复能力之间的差距，并提出相关的改进建议。l 系统现状调研n xxx合创提供一个信息收集模版，包括各软硬件平台和备份系统现状的典型内容；n xxx合创收集相关的情况，并且进行初步的分析和筛选，并对每套应用系统进行一次现场验证n 根据访谈的结果，xxx合创作进一步的分析，并向xx公司项目组进行初步汇报；n 根据沟通结果，xxx合创通过进一步的验证或小范围研讨会的形式，最终确定现状情况；n 提交xx公司信息系统现状调研报告予xx公司项目组。l 可恢复能力分析n 和xx公司一起确认各信息系统可恢复能力分析的访谈单位；n xxx合创制定可恢复能力的分析表格，根据系统现状进行初步分析，并和各访谈单位一起确认；n 根据访谈的结果，xxx合创作进一步的分析，并向xx公司项目组进行初步汇报；n 根据沟通结果，xxx合创通过进一步的验证或小范围研讨会的形式，最终确定目前的可恢复能力，和业务影响分析所需要的可恢复能力进行比较，找出现状和预期目标之间的差距；并根据差距提出相关的改进建议；n 提交xx公司信息系统可恢复能力分析报告予xx公司项目组。3.1.3. 工作交付成果在当前环境分析中，xxx合创将递交下列交付件：xx公司系统现状调研报告现状调研报告主要根据xx公司所有业务系统的建设情况以及已运行业务系统硬件现状、网络情况、数据结构、备份情况等进行详细描述和分析。该报告的预期主要提纲如下：l 调研工作执行情况总结： l xx公司应用系统调研范围l xx公司应用系统硬件情况l xx公司应用系统网络情况l xx公司应用系统系统运行情况l xx公司应用系统备份系统与备份策略l xx公司应用系统数据结构和数据容量情况l 附录：调研纪录 可恢复能力分析报告,可恢复能力报告主要从多个层面对系统的可恢复能力进行调研，了解目前系统响应灾难的能力，分析现在的系统能力与xx公司实际业务需要的系统可恢复能力之间的差距，并提出相关的改进建议。3.1.4. 完成标准xxx合创提交xx公司系统现状调研报告和可恢复能力分析报告并得到xx公司项目经理签字确认后，本任务完成。3.2. 任务二、风险分析3.2.1. 工作目标根据的IBM业务持续性方法论，风险分析是属于分析阶段的一个咨询活动。从通常意义上来说，风险分析（Risk Analysis）是针对可能会对一个企业的应用系统和IT系统的安全性造成威胁的各种风险因素进行评估和分析并有针对性的提出相应的对策和改进方案。在xx公司风险分析咨询活动中，xxx公司的顾问将分析可能对企业应用系统和IT系统的安全性造成威胁的各种风险因素并提出相应的对策和改进方案。包括：用户部门现有的风险和灾难管理手段评估、评估各种灾难威胁的可能性、确定未被控制的灾难会对用户部门系统造成的影响等。3.2.2. 工作内容风险分析的进行步骤具体为：l 召开项目启动会议：说明风险分析的目的、此次分析的范围、参与人员的要求与职责、解释将会实用的咨询方式，解释调查问卷，并就安排访谈与现场巡视等达成一致等。l 收集信息：通过、实施人员访谈、巡视当地状况、检查物理设施、检查各设施和设备的操作程序（包括IT和非IT）等方式来搜集相关资料和信息。由于xx公司的IT系统已经适度集中，所以xxx公司的咨询顾问会对xx公司的核心设施和设备所在地进行访谈。l 分析信息：对上一步得到的资料和信息进行分析和评估，如记录评估结论、判别风险级别、确定合理的减低风险威胁的处理方法和优先次序、记录发现与建议等。l 准备报告：对得到的结果按照客户要求进行整理并准备报告。l 提交书面xx公司信息系统风险评估报告。l 向xx公司项目领导小组汇报工作成果和最终交付项目。3.2.3. 工作交付成果xx公司信息系统风险评估报告，主要内容包括：l 确定xx公司核心应用系统面临的威胁/风险l 分析威胁/风险带来的影响l 记录发现的问题和提出的建议l 对风险发生可能性分级、分类l 可能采取的预防措施3.2.4. 完成标准xxx公司提交xx公司信息系统风险评估报告并得到xx公司项目经理签字确认后，本任务完成。3.3. 任务三、业务影响分析3.3.1. 工作目标在IBM业务连续性方法论中，业务影响分析是第二步。业务影响分析（Business Impact Analysis）的定义主要是针对各种业务流程进行分析，通过走访各业务部门的相关人员，了解各种业务流程本身对企业的重要程度。同时根据一定的评判原则，得出在核心流程由于灾难的发生而无法正常进行时对企业本身的损失情况。这种损失可能是可以量化的例如单据的丢失、计算的错误而导致的直接损失；也可以是无形的损失例如客户满意度及竞争优势的丢失。通过可量化和不可量化损失的综合考虑，得出各种核心业务流程由于灾难受损的可容忍程度及损失的决策依据，体现在IT系统上，主要是下面的二个重要指标：l 数据恢复点目标（RECOVERY POINT OBJECTIVE）：体现为该流程在灾难发生后，恢复运转时数据丢失的可容忍程度；l 恢复时间目标（RECOVERY TIME OBJECTIE）：体现为该流程在灾难发生后，需要恢复的紧迫性也即多久能够得到恢复的问题；这二个指标对于不同的业务流程可能相差非常之大，各个流程本身对这二个目标的优先程度也是不一样的，有的流程可能要求数据丢失程度较小，但恢复时间可以较长，而另一些流程可能要求短时间内恢复，但数据丢失程度可以放大一些。这二个指标直接影响所使用的容灾策略及技术方案，并指导企业的投入成本。本阶段的工作主要是进行业务影响分析，确立xx公司各应用系统的恢复指标。3.3.2. 工作内容xxx合创将为xx公司提供业务影响分析服务，内容包括：1.为应用系统开发业务影响分析调查问卷；2.为应用系统填写问卷和访谈人员召开一次说明会，介绍项目背景、工作方法、访谈过程和调查问卷填写方式；3.收集调查问卷反馈；4.分析调查问卷提供信息，为业务影响分析研讨会做准备；5.针对每个关键应用，与访谈人员就调查问卷内容举行一次为期不超过两天的访谈，确认以下信息：a) 应用系统功能b) 应用系统数据、信息流向c) 应用系统受损时不可量化损失情况d) 应用实现方式e) 应用不可用时的后备手段f) 后备手段数据丢失情况g) 应用关键时段h) 可接受应用停顿和数据丢失情况i) 应用输入、输出信息j) 应用所对应的基础设施k) 应用所需关键资源l) 当前使用的系统备份、容灾方式6.分析访谈所收集信息，初步确定应用系统受灾难影响程度、RTO、RPO、关键资源、应用相互依赖性等结论；7.召开一次为期不超过一天的业务影响分析研讨会，讨论分析结论，并形成应用系统RTO、RPO结论在所有应用系统访谈和BIA研讨会结束后：1. 分析所有应用系统所确定的RTO和RPO，初步确定应用系统分级原则2. 召开一次为期不超过两天的研讨会，与xx公司讨论并确定RTO和RPO3. 给出针对每个应用的恢复所需最小资源列表4. 撰写业务影响分析结论报告5. 与x