容灾白皮书Word格式.docx
《容灾白皮书Word格式.docx》由会员分享，可在线阅读，更多相关《容灾白皮书Word格式.docx（42页珍藏版）》请在冰豆网上搜索。
但是我们该如何保护这一资源？
假设您就是某企业的一位高级管理人员，当您的企业遭遇以下事故时，您将如何去面对：
1．某一天，证券公司的交易数据因操作失误而损坏；
2．某一天，保险公司的所有保单数据因电源故障而丢失；
3．石油勘探公司辛苦一年获取的地质数据因人为的恶意操作而丢失；
4．医院保存的所有病历因为磁带的损坏而无法使用；
……
这样的例子还有很多很多。
那么这样的事故所带来的后果是什么？
至少，很难想象这个不幸的企业还能毫发无损的健康生存。
因为，对于信息时代的企业而言，健全的信息往往是维持其运转所必须的基本条件。
所以，如何保护企业的信息资源，如何使企业免遭信息灾难，已经成为企业所必须考虑的沉重问题。
1.2IT大集中－把蛋都装进篮子里
在计算机应用的早期，是大型主机一统天下的时代。
这是一种高度集中的信息应用模式。
昂贵的计算机和同样昂贵的存储设备躲藏在幽深的机房里，客户仅能依靠哑终端与主机进行交互，以完成自己的工作。
随着IT设备的降价和网络技术的发展，客户机/服务器体系结构和浏览器/服务器体系结构这样的信息应用模式应运而生。
这两种全新的信息应用模式，降低了用户进入计算机应用系统的门槛，推进了计算机应用在现代社会的全面普及，并产生了今天计算机应用分布式存在和数据存储分布式存在的局面。
合久必分，分久必合。
随着网络速度的进一步提高以及高速存储设备的降价，高速信息交换、大容量存储等困扰IT人员多年的问题基本得到了解决。
同时，过于分布的应用和数据所导致的日益昂贵的维护和运营费用，已经给大型企业的发展带来了束缚。
于是，大集中的号角重新吹响。
目前，在银行信息化领域，数据大集中已经成了一个热门的话题。
在国内，中国工商银行在2000年就前瞻性地启动了数据大集中工程，并在2002年完成了全部工程的建设。
现在，中国工商银行已经将分布在全国各地的四十多个数据中心整合为互相连接、互为备份的北京、上海两大数据中心，建成了全行统一的计算机系统平台。
同时，国内的其它银行和大型证券公司也纷纷迎头赶上。
大集中已经成为包括银行、证券、保险等行业在内的整个金融信息化发展的大趋势。
鉴于信息资源对于企业的宝贵作用，我们不妨把它们比作一枚枚金蛋，而信息基础设施就是用来装这些金蛋的篮子。
过去，不同的金蛋分布在不同地域的篮子里，而大集中所带来的信息基础设施整合则意味着我们将把越来越多的金蛋放进同一个篮子。
此刻，一个不得不考虑的问题出现了：
如果这个篮子翻了，怎么办？
覆巢之下，岂有完卵？
1.3容灾－覆巢之下，亦有完卵
2001年9月11日，美国世贸中心双子大厦遭受了谁也无法预料的恐怖打击。
灾难发生前，约有350家企业在世贸大厦中工作。
事故发生一年后，重返世贸大厦的企业变成了150家，有200家企业由于重要信息系统的破坏，关键数据的丢失而永远的关闭、消失了。
其中的一家公司称，自己要恢复到灾难前的状态需要50年的时间。
2003年，当AT＆T无线试图对Siebel客户关系管理（CRM）软件进行升级的时候，原定一个周末就能完成的项目演变为一场历时六个星期的灾难。
这次CRM软件的升级使AT＆T无线损失了1亿多美元，仅增加的用户欠款、员工加班费和承包商的佣金就高达7500万美元。
此外，技术故障也导致该公司去年第四季度的新增用户数急降82％。
而其损失并不仅限于这些，AT＆T无线对分析师发布警告称：
“2004年上半年的用户退网率将进一步增加。
”
2003年，国内某电信运营商的计费存储系统仅发生了两个小时的故障，就造成400多万元的损失。
这些尚不包括对公司声誉的影响所导致的无形资产流失。
这些灾难的发生或许是偶然而难以预料的，但是，对灾难的预防却绝对不应该是一个偶然的话题。
据IDC的统计数字表明，美国在2000年以前的10年间发生过灾难的公司中，有55%当时倒闭。
剩下的45%中，因为数据丢失，有29%也在两年之内倒闭，生存下来的仅占16%。
国际调查机构GartnerGroup的数据表明，在由于经历大型灾难而导致系统停运的公司中，有2/5再也没有恢复运营，剩下的公司中也有1/3在两年内破产。
美国德克萨斯州大学的调查显示：
“只有6%的公司可以在数据丢失后生存下来，43%的公司会彻底关门，51%的公司会在两年之内消失。
另一份针对这一课题的研究报告也显示：
在灾难之后，如果无法在14天内恢复信息作业，有75%的公司业务会完全停顿，43%的公司再也无法重新开业，20%的企业在两年之内被迫宣告破产。
美国明尼苏达大学的研究也表明，在遭遇灾难的同时又没有灾难恢复计划的企业中，将有超过60%在两到三年后退出市场。
而随着企业对数据处理依赖程度的递增，此比例还有上升的趋势。
灾难的发生对企业的打击往往是致命的。
但是，面对灾难，企业就真的不堪一击吗？
答案是否定的！
同样是令人恐怖的“9.11”，世贸大厦倒塌后，在世贸大厦租有25层的金融界巨头摩根斯坦利公司最为世人所关注。
但是事发几个小时后，该公司宣布：
全球营业部可以在第二天照常工作。
这都是因为该公司建立的数据备份和远程容灾系统，它们保护了公司的重要数据，在关键时刻挽救了摩根斯坦利，同时也在一定程度上挽救了全球的金融行业。
这一独特的例子说明了什么？
它说明拥有先知先觉的防范意识和充分的技术准备，即使是在突如其来的覆巢之灾下，亦有完卵，亦有企业的一线生机。
因此，预防灾难的发生，充分考虑灾难发生后的快速恢复手段，成为现代企业的一门必修课。
其实，在这一问题上，中国古代的智者早就提出了自己的观点：
生于忧患，死于安乐。
无论是对一个国家，还是一个企业，都是如此。
第二章容灾概述
概述|容灾的实质是确保永不停顿的业务运营|容灾的IT实现
2.1概述
常言道，“知己知彼，百战不殆”。
要实现容灾，首先要了解我们的“敌人”－灾难。
那么，哪些事件可以定义为灾难呢？
典型的灾难事件是自然灾难，如火灾、洪水、地震、飓风、龙卷风、台风等，还有其它如原先提供给业务运营所需的服务中断，如设备故障、软件错误、电信网络中断和电力故障等等。
此外，人为的因素往往也会酿成大祸，如操作员错误、破坏、植入有害代码和恐怖袭击。
现阶段，由于我国很多行业正处在高速发展的阶段，很多生产流程和制度仍不完善，加之缺乏经验，这方面的损失屡见不鲜。
事实上，我国2003年遭遇的“非典”，某种意义上也是灾难。
对此，我们认为需要做到两点：
一是建立切实可行的应急机制，这主要包含一套基于充分且清楚地将风险予以分类定义的业务持续计划，二是在危机突然降临时，此计划能被有效执行。
对于IT系统，除了上述的灾难之外，与系统相关的计划外宕机也可视作灾难（见图1）。
图1.停机原因分析－北美
自“9.11”之后，全球各企业均认识到灾难防范保护的重要性。
某些大型金融机构之所以能够在两天内恢复营业，其主要原因是它们不仅象一般公司那样在内部进行数据备份，而且在数英里外的数据备份中心也保留着数据备份。
这些备份都是通过数据备份软件和数据复制软件进行的。
采取了这种措施后，一旦工作现场发生意外，企业就可以立即使用另一套数据。
华尔街的金融机构重新对灾难恢复的步骤做了评估，并认识到灾难恢复只是技术手段之一，它们开始强调BusinessContinuity-业务连续性而不仅仅是DisasterRecovery-"
灾难"
恢复。
因为过去的"
恢复计划并没有强调全局性及对整个市场的影响，而如何维持业务的连续运作将成为企业运营风险评估中至关重要的一环。
事实证明，只有对数据存储备份制定完备、持续且可执行的容灾计划，特别是业务连续计划，才能为人们提供万无一失的数据安全保护。
严格的说，容灾计划包括一系列应急计划，如业务持续计划（BCP-BusinessContinuityPlan），业务恢复计划（ERP-BusinessRecoveryPlan），运行连续性计划（COOP-ContinuityofOperationsPlan），事件响应计划（IRP-IncidentResponsePlan），场所紧急计划（OEP-OccupantEmergencyPlan），危机通信计划（CCP-CrisisCommunicationPlan），灾难恢复计划（DRP-DisasterRecoveryPlan）等等。
业务持续计划（BCP）
它是一套用来降低组织的重要营运功能遭受未料的中断风险的作业程序，它可能是人工的或系统自动的。
业务持续计划是高层管理人员的首要职责，因为他们被委任于保护公司的资产及公司的生存。
业务持续计划的目的是使得一个组织及其信息系统在灾难事件发生时仍可以继续运作。
为了能对灾难事件有适当的对策，严密的计划及相关资源的投入是必须的。
业务恢复计划（BRP）
它也叫业务继续计划，涉及紧急事件后对业务处理的恢复，但与BCP不同，它在整个紧急事件或中断过程中缺乏确保关键处理的连续性的规程。
BRP的制定应该与灾难恢复计划及BCP进行协调。
BRP应该附加在BCP之后。
操作连续性计划（COOP）
COOP关注位于机构（通常是总部单位）备用站点的关键功能以及这些功能在恢复到正常操作状态之前最多30天的运行。
由于COOP涉及到总部级的问题，它和BCP是互相独立制定和执行的。
COOP的标准要素包括职权条款、连续性的顺序和关键记录和数据库。
由于COOP强调机构在备用站点恢复运行中的能力，所以该计划通常不包括IT运行方面的内容。
另外，它不涉及无需重新配置到备用站点的小型危害。
但是COOP可以将BCP、BRP和灾难恢复计划作为附录。
危机通信计划（CCP）
机构应该在灾难之前做好其内部和外部通信规程的准备工作。
危机通信计划通常由负责公共联络的机构制定。
危机通信计划规程应该和所有其它计划协调，以确保只有受到批准的内容公之于众，它应该作为附录包含在BCP中。
通信计划通常指定特定的人员作为在灾难反应中回答公众问题的唯一发言人。
它还可以包括向个人和公众散发状态报告的规程，例如记者招待会的模板。
计划（IRP）
事件响应计划建立了处理针对机构的IT系统攻击的规程。
这些规程用来协助安全人员对有害的计算机事件进行识别、消减并进行恢复，这些事件的例子包括：
对系统或数据的非法访问、拒绝服务攻击、或对硬件、软件、数据的非法更改（如有害逻辑：
病毒、蠕虫或木马等）。
本计划可以包含在BCP的附录中。
灾难恢复计划（DRP）
正如其名字所表示的，DRP应用于重大的、通常是灾难性的、造成长时间无法对正常设施进行访问的事件。
通常，DRP指用于紧急事件后在备用站点恢复目标系统、应用或计算机设施运行的IT计划。
DRP的范围可能与IT应急计划重叠，但是DRP的范围比较狭窄，它不涉及无需重新配置的小型危害。
根据机构的需要，可能会有多个DRP附加在BCP之后。
场所紧急计划（OEP）
OEP在可能对人员的安全健康、环境或财产构成威胁的事件发生时，为设施中的人员提供反应规程。
OEP在设施级别进行制定，与特定的地理位置和建筑结构有关。
设施OEP可以附加在BCP之后，但是独立执行。
BCP关注在中断期间和之后维持机构的业务功能。
业务功能的一个可能的例子是工资的支付处理或客户的信息处理。
BCP可以专门为某个特定的业务处理编写也可以涉及到所有关键的业务处理。
IT系统在BCP中被认为是对于业务处理的支持。
在某些情况下，BCP可能没有涉及到对过程的长期恢复并使其回到正常运行状态，而只是包含过渡的业务连续性需求。
灾难恢复计划、业务继续计划和场所紧急计划可以附加在BCP之后。
在BCP中设定的职责和优先顺序应该和其在操作连续性计划（COOP）中的一致以消除可能的冲突。
按一般惯例，备用站点维持机构（通常是总部）要支持长达30天的运行，直到整个系统恢复到正常状态，COOP正是为了达到这个要求而制定的。
BCP涉及到在重大中断期间和之后维持业务处理所需的业务功能和IT系统。
BRP记录了机构在备用站点进行业务处理的持续规程。
与BCP不同，BRP不涉及在紧急事件期间对关键处理的连续性维持。
DRP是指设计用于重大和通常是毁灭性灾难之后的目标系统、应用程序或计算机设施的恢复，它是以IT为主的计划。
两个计划都提供了IT系统的恢复和继续规程。
由于包括了对无需重新部署到备用站点的小型中断进行系统恢复的规程，所以这类计划比DRP的范围更广泛。
计算机事件响应计划建立了使安全人员可以确定、防止和恢复针对机构IT系统进行的计算机攻击的规程。
OEP则提供了在人员的健康和安全以及环境或财产等受到威胁的紧急情况下，设施工作人员所遵循的指导方针。
计划的制定者之间必须进行协调以确保各自的策略和规程能够互为补充，必须将所有有关计划、系统和处理的变化情况反馈给系统和相应处理计划的制定者。
2.2容灾的实质是确保永不停顿的业务运营
让我们来看一个真实的故事：
FredAlger基金管理公司的总部设在世贸中心北楼的93层。
在上个世纪90年代，FredAlger曾是美国业绩最好的一家基金管理公司。
它旗下的“光谱共同基金”（Spectramutualfund）的年均收益率曾达到让人惊羡的29%。
然而，公司2000年的业绩大幅下滑，其前景不容乐观。
2001年9月11日上午发生恐怖袭击后，该公司正在上班的35人全部遇难，老板DavidAlger也在其中，这对FredAlger公司来说无疑是灭顶之灾。
所幸的是，该公司居安思危，在繁荣期建设的IT系统早早就考虑到容灾的需要，在50英里以外的新泽西中心区建有一个数据备份点。
“9?
11”过后的第三天，该公司幸存无几的人在那里发现，袭击之前所有的交易记录和所有的研究报告都有详细备份，并被完好无损地保留了下来。
所以，FredAlger公司没有选择关张，而是决定重建。
他们并非盲目地不认输。
几年前就已退休的FredAlger，在弟弟David去世后立刻再度出山。
当整个市场在去年9月17日重新开市时，FredAlger公司成了华尔街经纪公司中的股票大买家。
此后，当其他基金管理公司的业绩在去年出现滑坡时，他们的利润反而因此大大增加。
很快，FredAlger公司的投资管理队伍也空前兴旺起来，并在第五大道的2层楼建立了新的总部。
类似的故事令全世界在一夜之间认识到，金融市场的数据备份和交易备份绝对不能缺少。
自美国建国以来，华尔街就一直主宰着美国的金融。
而此次袭击已经给了华尔街以致命的一击。
事实上，对世贸中心的袭击完全改变了纽约的金融景观。
以往，曼哈顿4/5写字楼的底层都是金融服务机构。
而如今，这些金融机构中的一半以上都迁走了，大多都换了个小地方。
在曼哈顿中心区的5万名金融服务人员中，已有19000名离开了这个城市。
其中也有像摩根斯坦利和高盛公司这样的“金融巨人”。
因此，即使在曼哈顿区还在燃烧时，监管者们已经开始考虑，如何才能重振金融业，并让它强大到足以抵御下一次灾难。
在银行家和监管者们看来，“9?
11”并不能被称为信用事件。
但下一次灾难，不论是什么样的灾难，它一定会是一场信用事件。
在庞大的支付链条上，一旦某个具有实力的环节受到支付困难的威胁，整个市场，如外汇交易或美国财政债券交易就有可能出现大塞车。
为此，英国的金融服务管理局在一个储存有备份数据的秘密地点，进行了多次“业务持续”演习。
美国的监管者也抛出一份建议书。
这份建议书的目的在于，要保持市场参与者之间实时的信息和通信联系，即保持数据备份点之间的通信联系。
监管者和市场应该能够抵御住沉重的打击，并应在4小时以内恢复工作。
而对那些由15～20家大银行和5～10家证券公司所组成的金融主干系统来说，在它们主要参与的市场中应享受优先权，须在一天之内恢复营业。
在“9311”以前，银行之间（包括独立的通信和信息技术系统之间）的应急计划很少有彼此的沟通。
为此，设在巴塞尔的发达国家10国“金融稳定性论坛”，已经起草了一个“应急协议名单”。
被列入这一名单的，都是些全球最重要的金融实体。
根据这个协议，名单中的金融实体的监管方可以在任何情况下及时取得联系。
此外，美国监管机构已经提出，要持续不断地进行应急计划测试，以对付“一切可以想象得出的事件”。
例如，进行产业范围的战争预演已经提到议事日程，而“无线战争”被最先纳入其中。
那么，如何确保企业业务的连续运营以及数据的安全呢？
严格的说，业务持续计划的建立和实施过程，实际上是进行一个涉及企业运营的项目，因此也涉及到项目管理的方方面面。
标准的业务持续计划项目应按如下流程进行：
1。
项目启动和管理
确定业务持续计划（BCP）实施过程的相关需求，包括获得管理支持、以及组织和管理项目使其符合时间和预算的限制要求。
2。
风险评估和控制
确定可能造成机构及其设施中断的灾难、具有负面影响的事件和周边环境因素，以及事件可能造成的损失、防止或减少潜在损失影响的控制措施，提供成本效益分析以调整控制措施方面的投资，达到消减风险的目的。
同时，由于风险会随着系统的发展而变化，所以风险管理过程也必须是动态的。
3。
业务影响分析
确定由于中断和预期灾难可能对机构造成的影响，以及用来定量和定性分析这种影响的技术。
确定关键功能、恢复优先顺序和相关性以便确定恢复时间。
4。
制定业务连续性策略
确定和指导备用业务恢复运行策略的选择，以便在恢复时间目标范围内恢复业务和信息技术，并维持机构的关键功能。
5。
应急响应和运作
制定和实施用于事件响应以及对事件所引起状况进行稳定的规程，包括建立和管理紧急事件运作中心，该中心用于在紧急事件中发布命令。
6。
制定和实施业务连续性计划
设计、制定和实施业务连续性计划，以便在恢复时间目标范围内完成恢复。
7。
意识培养和培训项目
准备建立对机构人员进行意识培养和技能培训的项目，以便业务连续性计划能够得到制定、实施、维护和执行。
8。
维护和演练业务连续性计划
对预先计划和计划间的协调性进行演练、并评估和记录计划演练的结果。
制定维持连续性能力和BCP文档更新状态的方法，使其与机构的策略方向保持一致。
通过与适当标准的比较来验证BCP的效率，并使用简明的语言报告验证的结果。
9。
公共关系和危机通信
制定、协调、评价和演练在危机情况下与媒体交流的计划；
制定、协调、评价和演练与员工及其家庭、主要客户、关键供应商、业主／股东以及机构管理层进行沟通和在必要情况下提供心理辅导的计划，确保所有利益群体能够得到所需的信息。
10。
与公共当局的协调
建立适用的规程和策略，用于同地方当局协调响应、连续性和恢复活动，以确保符合现行的法令和法规。
当然，实际应用中，如果受时间、成本等因素的限制，加之容灾目标有限（企业不需要承担应由政府负责的国计民生之重任），我们可以简化并适当改变上述标准流程。
事实上，随着IT系统在企业内部应用的深入，IT系统更容易受到各种灾难的伤害而导致中断，特别是在许多情况下，关键资源可能属于不可控范围（如电力和电信）。
对于倚仗IT系统的企业来说，从确保业务连续能力的角度出发，可以依据下列容灾规划步骤：
1．灾难类型分析
2．业务冲击分析
3．当前业务环境及恢复能力分析
4．容灾策略制订
5．容灾方案设计
6．业务连续性流程设计
7．业务连续性流程及容灾方案管理和测试
每一个步骤的相关职责一般会落在“计划协调人”或“应急计划制订人”的身上，他们通常是职能或资源部门的经理。
协调人在其他相关系统或业务处理部门的职能经理和资源经理的协助下制定应急策略；
应急计划协调人通常管理应急计划的制定和执行。
2.3容灾的IT实现
除了详尽的容灾计划，实际上还需要合理的IT系统架构来确保企业的容灾计划得以实现。
对于IT系统而言，在技术层面上，容灾需要考虑：
*数据版本保护－建立容灾的多版本保护底线（BottomLine）
*实时数据保护－数据复制，近乎0的数据丢失，数据一致性
*应用系统恢复－恢复时间（包括数据库恢复）、应用版本的一致性（PTF）等
*网络系统恢复－数据访问点变化、建立新网络路径、动态路由（收敛时间/稳定性）
*容灾切换决策－及时发现灾难（容灾系统管理）、容灾切换的损失和补救办法
*容灾切换过程－变更管理
同时，无论任何时候，备份都是非常重要的，并要定期测试备份的可靠性。
一种技术只能减少或防止某些类型的灾难的影响。
除了简单或一成不变的应用，在没有特别要求的情况下，尽量不要采用操作系统层面以上的数据复制技术。
而没有文档化的流程就相当于没有流程，没有流程的系统能够在要求时间内恢复完全靠运气（通常不能）。
另外，在通常情况下，IT系统相关的灾难备份方案设计都必须考虑以下五大因素，
1，灾难类型
需要考虑哪些灾难？
怎样的灾难？
会使业务中断多久？
2，恢复速度
灾难发生后需要多久来启动及运行系统？
能否承受数天或数分钟的等待？
3，恢复程度
需要恢复每条记录和交易吗？
可以使用上星期或昨天的数据吗？
需要恢复一切吗？
有不相关的文件吗？
什么是合法隐含的要求？
有少数的一组人输入交易吗？
他们可以重新输入灾难期间丢失的交易吗？
这些交易十分重要而不容许丢失吗？
4，可用的技术
必须结合考虑所选技术在本地区的适用性、实现条件以及在实施时是否受某些现有条件的制约？
5，方案总体成本
实现灾难备份需要多少投资？
不实现灾
升级会员 