给信息系统上“保险”卡在哪儿

2007年11月1日，国标《信息系统灾难恢复规范》颁布实施。《规范》自颁布至今已有将近两年时间，而企业的信息系统恢复建设鲜有成功案例，原因到底是什么？人们对《规范》所持的态度如何？在实际实施过程中又碰到哪些问题呢？

2009年9月16日14时25分，申银万国的交易系统突发异常并瘫痪，直至14时52分，即离收盘不到10分钟才恢复正常。系统故障发生后所有股票交易均无法进行，在营业部看盘交易的投资者普遍焦急万分，对近半个小时未能交易可能造成的损失唏嘘不已。

2008年12月5日9时30分开始，北京移动100多个营业厅系统瘫痪，暂时无法提供服务，营业厅里排起了等待办理业务的长龙。截止到当日12时30分，北京移动100多个营业厅才逐渐恢复各项业务办理。

2006年4月20日上午10点56分，银联通信网络和主机出现故障，造成银行卡跨行交易不能正常进行。虽然银联及时发现问题并对此进行了全力以赴的抢修，但到当天下午5点10分为止，全国大部分的成员机构和商户只是基本恢复正常，直到晚上8点，银联跨行交易网络才得以全面恢复……

信息系统的中断给企业带来的损失不胜枚举，单位越来越重视信息系统的灾难恢复建设。2007年11月1日，国标《信息系统灾难恢复规范》（以下简称《规范》）颁布实施，各单位积极响应，都在积极规划和建设灾难恢复系统。

《规范》自颁布至今已有近两年时间，而企业的信息系统恢复建设鲜有成功案例，原因到底是什么？人们对《规范》所持的态度如何？在实际实施的过程中又碰到哪些问题呢？

驱动力要明确

谈到信息系统的灾难恢复建设，人们不约而同地都会谈到驱动力。“信息系统的灾难恢复建设最大的难点在于驱动力。”铁道部信息技术中心技术支持部处长耿青云谈到，“只有IT部门着急，效果肯定不明显。”

对此，北京趋势引领信息咨询有限公司总经理邓宏持同样观点：一个企业建设信息系统灾备，是CEO关注，董事会关注，还是IT经理关注，关注的人层次不一样，实施的效果肯定也不一样。如网游公司，游戏线一掉，玩家就会觉得没意思，下次就不会再玩你的游戏了。信息系统的灾难恢复建设直接影响到公司的生存发展，公司从上到下对信息系统的灾难恢复建设都应非常重视，业务部门也应该参与进来。

关于驱动力，中国民航信息集团网络股份有限公司运行部副总经理龚文认为：“企业花那么多钱去建灾备系统，就说明高管不是不重视，而是认识上有问题。有些高管认为一大笔钱花出去之后，灾备就可高枕无忧了。其实不然，生产系统一扩容，灾备系统就要扩容。而且灾备系统很少被用到，高管就会觉得钱花得很亏，对建设灾备系统提不起兴趣来。但如果能出台一个有关灾备的强制性法规，对于推动信息系统灾难恢复建设应该有效。”他还认为，每个单位都自行建立一个数据中心是一种浪费，如果大家联合起来建立一个可以复用的灾备中心，就能很好地节省资源。

对此，中国石油天然气集团东方地球物理公司信息技术中心副总工程师王雨很是赞同：“《规范》只是建议性的规范，而不是法律，不具有强制性，执行力度不够。信息系统灾难恢复建设涉及到数据中心、灾备系统，成本很高，又不能产生直接的经济效益，一般企业下不了决心去做。如果从国家层面出台一些强制性的政策，执行起来就要顺畅得多。”

要为业务服务

国家信息中心信息安全研究与服务中心副主任叶红认为，信息系统的灾难恢复建设，要从业务层面来推动。民航、税务和海关等行业对灾难恢复建设都很重视，是因为这些行业的业务离不开信息系统，业务逼着它们必须重视。国家信息中心正在建设国家电子政务外网，一期建设时没有启动灾备建设，而在二期的建设中，灾备被列为重要建设内容，主要是因为二期工程要求所有部委把公众服务的业务全部迁移到电子政务的外网上来。这样，国家信息中心的压力就非常大，对系统的灾备建设需求就非常迫切。

海关总署全国海关信息中心李震认为：“从我们的经验来看，信息系统的灾难恢复建设必须有相应的业务流程来配合容灾切换，这样才能真正保障业务遇到灾难的时候不中断。系统的灾备建设是为业务服务的，企业是否建灾备中心，取决于业务需求。海关每年为国家贡献的税款相当可观，如果系统停一天，会给国家造成巨大的损失。”

“灾备就像买保险，不能去考虑它能挣多少，而是为了保障信息系统的安全，进而保障业务顺利进行。”国家税务总局信息中心处长杨慧平介绍，国家税务总局刚刚实施了金税三期工程，在南海建立了一个灾备中心，这个灾备中心既备份总局的数据和业务系统，也集中备份各个省税务局的数据和核心业务系统。目前，信息中心已经把6个省的核心征管系统实时地备份到灾备中心中来。

解决轻两头问题

对于目前企业进行信息系统灾难恢复建设存在的问题，中国信息化推进联盟业务持续管理专业委员会秘书长于天分析，主要存在着“重中间轻两头”的现象，也就是说，企业对技术方案都很重视，而对前期的立项和组织机构的设立，以及后期的维护、更新和演练不够重视。

组织机构的设立对灾备建设来说非常重要，中国信息化推进联盟专家梁程举例说，宝洁和第三方服务机构签了灾难恢复规划（DRP）外包合同，以对ERP系统进行有力的监控。宝洁和第三方机构成立了联合小组，对整个项目，甚至在细节上都监控得很好，比如一个报表什么时候生成，晚了多长时间，应该如何处理，该如何惩罚，都能进行很好的控制。

人员保障是另外一个关键因素。海关总署全国海关信息中心李震介绍说，在人员保障上，海关总署组建了一个灾备科技领导小组，由署级领导牵头，海关总署科技司和全国海关的科技处都要参与其中。这样的组织给灾备建设提供了有力的保障。

在后期的演练和维护上，于天认为，目前许多单位虽然对灾难恢复系统进行了一定的测试，但没有对计划流程和人员进行充分演练。演练不够充分，所制定的DRP中存在的问题就无法及时暴露出来，也就不能进行及时改进。

专家篇

灾难中将业务进行到底——BCM进行灾难恢复全生命周期管理

2007年11月1日正式实施的国标《信息系统灾难恢复规范》（GB/T 20988-2007，以下简称《规范》）是我国目前较为实用的关于灾难恢复建设的标准，对各企业进行灾备建设具有重要的指导意义。该标准的内容完全符合国际流行的BCM（业务连续性管理）最佳惯例。然而，中国标准通常有个特点，就是篇幅短小，条款简洁，文字精练。如果没有对标准进行配套的宣传解释和相应的理论培训，标准在贯彻执行时就难免遇到一些问题。

建立组织机构

国标中明确要求设立灾难恢复组织机构，通常包括灾难恢复领导小组、灾难恢复规划小组、灾难恢复运维小组。这充分反映了我国的灾难恢复建设国家标准的先进性和科学性，也是中国标准与国际惯例相结合的体现。

然而目前许多单位对这三个小组的建立，在理解和执行上都存在不同程度的不足。

关于领导小组  因为灾难恢复的最终目标就是恢复业务的运行，所以整个灾难恢复活动与全企业各个部门都紧密相关。因此，如何使各部门都积极参与灾难恢复的建设过程，有效地协调各部门的资源，是灾备建设成败的关键环节。因此，成立一个强有力的领导小组来调动、分配和协调各种资源就显得非常重要。

但是许多单位对高管层领导参与灾难恢复建设工作的重要性认识不足，在成立灾备领导小组时，参与的人员级别并不够高，或者虽有高管层人员参与，却只是挂名，并不参与实际工作。另外，某些单位的灾难恢复领导小组在灾备系统规划建设完成后，人员就发生变化，灾难恢复领导小组实际只是一个临时性的组织。

关于规划小组 规划小组具体负责灾难恢复建设的项目规划、需求分析、策略选择、设计实施、DRP制定和演练等工作。这些工作涉及到整个企业的各个业务部门及技术、行政和后勤保障相关部门，因此，规划小组的人员组成是一个非常关键的环节，他们必须覆盖所有相关的部门，而且必须指定专人配合。

然而，很多单位的规划小组成员往往以IT部门的人员为主，基本上没有各业务部门的人员参与，这就使得规划小组在进行项目规划、需求分析等工作时，很难调动各种资源，自然也无法充分地分析各种数据，得出客观合理的需求结果，更无法协调所需灾备需求资源。这样，很难保证灾难恢复建设的顺利进行，也无法保证所建成的灾备系统真正有效。

关于维护小组  维护小组也就是灾难恢复日常运行小组，主要负责灾备中心的日常运维、技术支持、DRP维护，以及事发时的控制和评估、执行业务恢复等。维护小组也不应该只是由IT部门的人员组成。事实上，IT人员只是侧重于系统和技术的维护，整个小组还应该有负责业务功能和流程、应急响应、安保的人员，同时还要有行政后勤人员参与。

但目前各单位的灾难恢复维护小组通常主要都是由IT部门的人员组成，这必然给DRP的日常维护及事发时的启动埋下隐患。

有效确定需求

通常人们认为灾难恢复建设的第一步是确定灾难恢复需求，然后才能决定恰当的解决方法——灾难恢复策略。但在现实中，我们常常发现灾备项目小组历尽千辛万苦整理出来的需求分析报告和制定出来的相关灾备策略，在最后评审时却发现需求分析的结果与实际业务需求有偏差，只能重新开始。造成这种现象的主要原因并非小组人员不够努力，也不完全是业务部门配合不够，而是缺少一个完善的灾难恢复组织机构来保证灾难恢复需求分析工作的顺利进行。

走出策略误区

《规范》中给出了制定灾难恢复策略的七要素，以及根据这七个要素对灾难恢复能力划分的六个等级，这无疑为各单位制定灾难恢复策略提供了一个很好的参考指南。

然而在实际工作中，人们常常还是会陷入某些误区。比如说：过分注重灾难恢复的技术方案，而忽视了整个业务恢复流程的有效性，造成技术支持的RTO值（反映所允许的中断时间）要求很高（这造成投资大大增加），而整个恢复流程的RTO值所满足的要求并不太高。还有些单位混淆对RPO（反映所允许丢失的数据量）的要求与对RTO的要求。许多单位对RPO要求很高，这是可以理解的（尤其是关系到国计民生的业务），但对RTO值的要求却不一定很高（如零中断）。譬如，发生重大灾难时，银行的自动取款业务允许中断几小时，但客户存款数据却不能有任何丢失。做到零丢失是完全可能的，而要做到零中断却是较难的，有时即使技术上做到了，业务流程也不可能做到。

考虑灾难恢复策略时应该更多地关注整个业务的恢复流程，而不仅是注重技术方案——最好的技术方案并不一定是技术指标最高的，而是从整个业务恢复流程来看是最合理的。因此，对各种恢复策略进行成本效益分析时也应从整个业务流程来考虑，这样才可能得出合理的业务恢复RTO值，并选择合理的灾难恢复策略。

加强演练和培训

虽然大多数企业在制定了灾难恢复计划（DRP）后都清楚应该进行认知培训、测试演练及维护更新，《规范》中对这些提出了明确的要求。但是在实际执行中，多数企业在这方面做得不全面。这主要表现在以下几个方面：

其一，对认知活动不够重视。虽然大多数企业完成DRP后会进行相关的培训，但培训人员的覆盖面不够广，还有很多应该了解DRP的人并未得到相应的培训，而对全体员工的灾难恢复认知宣传就更加不足，这必会影响事发时DRP的启动和执行效果。

其二，演练不够充分。许多单位虽然对灾难恢复系统进行了一定的测试，但普遍缺乏对计划流程和人员进行充分的演练，这就无法确保DRP的有效性。

其三，维护更新不及时。由于演练不够充分，所制定的DRP中存在的问题就无法及时暴露出来，也就不能及时改进。此外，由于灾难恢复组织机构不够完善，企业内部发生的变更可能得不到及时反映，也就无法对DRP进行相应的更新。另外，由于目前我国尚缺乏强制性的相关法规，无法对DRP提出强制性的审计要求，而企业的自查有时会流于形式，这也使得DRP不能得到定期的有效更新。

BCM是最佳方法

解决以上所述灾难恢复建设中遇到的各种问题的最佳方法是BCM。BCM是专门帮助组织机构应对灾难的一体化管理方法。相对于应对公共突发事件的问题，BCM主要是解决组织机构自身应对灾难的问题。BCM方法论的核心内容被归纳为10个国际最佳惯例。

项目启动与管理：确定BCM项目需求，获得高管层的支持，建立BCM组织机构及各小组人员的责任，明确BCM项目的范围，确定计划编制时间表等。

风险评估和控制：识别可能的威胁和风险，确定应采取的控制措施等。

业务冲击分析（BIA）：确定关键业务功能和流程，确定RTO和RPO，以及确定互依赖性及优先级别等。

制定业务持续策略：根据BIA的结果制定恢复策略（包括企业级和部门级策略），进行成本效益分析，选择最佳的策略等。

应急响应和措施：制定和贯彻执行用于事件发生后进行响应并使状态得到稳定的流程（应急预案），建立和管理紧急运行中心，该中心作为紧急情况时期的指挥中心。

编制和贯彻执行业务持续计划：设计、编制和贯彻执行业务持续计划以提供满足恢复时间目标（RTO）和恢复点目标（RPO）的业务持续。

认知和培训计划：制定相关的计划，对相关人员进行培训，使其掌握必要的技能来执行BC/DR计划，并对全体员工进行BCM认知教育，从而将BCM融入到整个企业的文化中去。

维护及演练业务持续计划：制定测试计划，以测试系统和技术的可靠性；制定演练计划，以检验BC计划流程和人员行为的有效性；对测试和演练结果进行评价并提出改进意见；制定计划维护和更新的流程。

危机沟通：制定、协调、评估和演练危机沟通计划，这些计划用于与各类利益相关者、外部机构、以及媒体等的沟通。

与外部机构的协调：建立适当的流程和计划来与外部机构进行协调，从而完成持续和恢复活动，同时确保符合相应的法令法规要求。

这十个最佳惯例包含了任何组织机构为应对灾难所应做的各项工作（包括预案制定、贯彻执行、演练维护及认知培训等等），按照这十个最佳惯例制定的各种预案覆盖了灾难恢复的六个阶段（6R模型）：

1.减小（Reduce)：事件发生前为预防灾难的发生所应做的准备工作。

2.响应（Respond）：事件发生时，按照计划进行响应和评估。

3.恢复（Recover）：按照优先级别启动相应的恢复计划来使相关流程和支持功能恢复到稳定的运行状态。

4.重启（Resume）：按照优先级别重新启动事先确定的关键业务运行。

5.重建（Restore）：灾难过去后，执行相关程序修复或重建永久站点及其内容，并重建原来的正常运行。此时的业务运行通常是在后备（或临时）中心进行。

6.返回（Return）：按计划将后备（或临时）中心的业务运行返回到永久站点。

以上这六个阶段形成了一个完整的灾难恢复生命周期，如左图所示。

可以看出，BCM的主要内容（十个国际最佳惯例及6R模型）完全与国家标准 《信息系统灾难恢复规范》的要求相一致。事实上，《规范》中对灾难恢复建设的基本要求正是参照BCM的国际最佳惯例提出的，这是因为企业的DRP本来就属于企业业务连续性计划（BCP）的一部分，可将DRP看作是一种专门针对IT服务业务的BCP，而且DRP的制定与BCP的制定在方法上也是基本一致的。一个完整的DRP和BCP都应该包含6R模型中各阶段所需的程序和计划（预案）。因此，参照BCM的方法论来制定灾难恢复建设的标准是非常合理的。

真的万事俱备了吗——如何确保业务连续性计划成功

在DR/BC（灾难恢复/业务连续性）实践中，企业收集的最重要的定量参数就是恢复时间目标（RTO）和恢复点目标（RPO）。那么，怎样的计划才称得上是优秀的DR/BC计划呢？

BC遭遇多种挑战

业务惟一永恒不变的就是改变。因此，企业BC可能遭遇多种挑战：如果业务中断，该启用哪个计划呢？计划是否拥有足够的灵活性，从而可进行适当的调整呢？能否快速确定中断所产生的影响？能否找出所有在中断后需要调整的地方？……

此外还有协作问题，哪些任务应该优先处理呢？要是计划中部分关键的资源，如某个团队、某个应用程序或某个设备无法及时到位，那又应该怎么办呢？各种可变因素看起来是无穷无尽的。事故管理团队能否得到足够的信息来做出决策？他们在哪里获取信息，又如何获取呢？他们在作出决策之前，和其他执行计划的各个团队是否进行过有效沟通呢？

企业经过不懈努力编写并经过无数次演练得到的计划，是否足以应付公司可能出现的意外呢？如果出现的情况超出了计划范围，业务连续性又该如何保障呢？

只采用场景计划还不够

很多人在制作计划时都采用基于场景的方法。但是我们该知道，出现业务中断会有4个无法预知的条件：不知道会发生什么情况，在什么时候发生，会带来怎样的影响，以及会持续多长时间。场景计划看起来很不错，但是就像战争计划一样，它很可能在遭遇第一个“敌人”之后就开始失效了。

可行的、能够应对各种意外情况的业务连续性管理计划，有赖于有效的方法论、面向目标的分析、组织以及客观条件。

风险分析可以减少、防止或者缓解应对策略所带来的风险。当然，并不是所有威胁都能得到缓解，那些仍然存在的弱点在制定计划时应该特别注意。与其针对不可缓解的风险制定场景计划，不如采取一种更有针对性的策略，利用这些威胁去寻求它们可能带来的具体威胁或者几种相关的威胁。风险分析已经成为准备过程中有用的工具。

大多数的业务影响性分析（BIA）都期望能够确定对业务功能的危险程度。简单地说，BIA能够通过对品牌（或声誉）、客户、需求调整及收益的影响，威胁对企业所有功能造成的危险程度进行排序。

这些分析都只关心某一项功能或者流程出问题时对公司的影响，据此制定的计划必然会忽略大部分功能具有的相互关联性。因此，企业还需要对那些可能影响业务连续性的关键操作进行更加透彻的分析。

不管是为一个设备、一个部门、一个业务流程，还是一个IT系统或应用制定连续性计划，企业都有必要了解其相关的关键资源。这些资源，如设备、技术、供应商、职员及流程，是连续性计划中必不可少的元素。一个良好的BC计划，包含了解决这些关键资源缺失或者不足问题的策略。这样，这个计划就能够应对任何的中断，而不仅仅是一个特定场景或一系列的假设情况。

如果一个公司希望很好地保持连续性，或者从严重的事故中得以恢复，就必须深刻理解业务功能。同样，应该很好地理解服务等级协定，并在计划中得以体现。

制定BC应注意什么

企业是否已经做好了准备应对突发事件，如何管理这些措施，应该如何跟踪事情发展的人物、事件、时间、地点和进展呢？

首先，企业的计划必须与实际运营情况同步。这需要企业及时更新计划，在相关计划中体现业务的变化。值得注意的是，与实际操作同步的计划在遇到中断时会更容易管理。

其次，计划必须是可操作的。计划的每一个重要部分都需要落实到行动或者任务中，并且据此分配资源并指定完成的时间点。切实可行的计划允许恢复团队在每一个预期的里程碑确定进展。每个计划或者计划任务必须包含对必要资源的理解，以便事故管理团队能够为最需要的地方及时调度关键资源。

最后，计划还必须对协作需求有良好理解。团队成员都需要在计划中描述清楚，并界定其职责的范围和限制。执行团队都必须充分认识到每个功能的危险程度和与其他相关功能之间的关系，相关的计划中必须包含有相应的恢复操作。

不管是单独的计划还是总体的事故管理流程，都要列举清楚谁负责什么事情。每一个参与者，哪怕是不进行直接操作的公司高管，都必须了解整体组织结构及相应的职责。

BCM计划的演练也很不容易。要实现计划演练的价值，必须在真实环境中操作。演练的计划不能考虑各种最好的情形。从某种程度上来说，演练就是要让参与者遭遇意外，让他们不舒服。只有在演练中模拟真实环境，才能检验出公司对中断的准备情况，才能看出有哪些工作需要进一步改进。演练应该挑战参与者的应变能力——用他们的知识和经验去探索计划之外的策略和方法。

最后，如果BCM计划是针对公司各种未知情况的，应该反映公司本身的复杂性。准备计划没有捷径可走，它不是仅仅在已知的列表中进行一项项检查，也不是某个业界标准的实现过程。

实施篇

100%有效性如何保障——企业部署IT恢复解决方案实例剖析

Barkley广告公司一直坚持建设业务连续性、灾难恢复策略。当他们还是一个仅有50人的工作室时，就开始为成为美国最大的广告公司而做好准备。

如今，公司已经拥有340名员工，以及一批稳定的客户，其中包括“24小时健身”和“赫尔兹伯格钻石”等著名品牌。

如今，Barkley广告公司的业务连续性的高可用性正在继续推进业务发展。“即使我们主要的文件服务器出现持续一天的故障，我们的业务也不会受到严重影响。”公司网络经理Larry Penrod介绍说。

多条腿走路

为了实现系统100%有效性的目标，Penrod计划的第一步就是为所有使用HP刀片硬件、VMware虚拟化软件及各种存储平台的服务器创建虚拟备份。

“这让我们体会到了VMware的高可用性和分布式资源规划的好处。”他说，“我们所有的存储用EMC的产品进行了集中，充分利用他们的各种硬件、软件及专业服务。”

他还使用了VMware的Storage Vmotion将运行在服务器上的数据从旧存储系统迁移到新系统上。同时，他还用EMC的MirrorView同步工具将VMware的环境复制到了另一套也使用HP刀片服务器的备份环境中。

接下来，Penrod的业务连续性和灾难恢复计划要做的是远程访问、离线磁带存储和接近100%的笔记本电脑办公的备份。但考虑到廉价的硬盘、便宜的带宽和简化的IT过程，他决定把这一步迈得更远一些。

“我们将RPO（恢复点目标）从24小时缩短到了1小时，将RTO（恢复时间目标）从72小时缩短到了4小时。”他说，“但是，现在的成本仅仅是几年前的四分之一左右。”

“两三年前，你完全无法想像用这么低的成本完成这样的工作。现在整个过程都变得非常简单，存储成本直线下降，网络带宽成本也更便宜。”他说，“所有容易出错的人工步骤都实现了自动化，让事情变得更加简单。”

实现集中化与虚拟化

自动化处理与集中化技术是业务连续性计划实现的关键。IBM公司系统与技术部负责业务连续性策略与计划的高级顾问John Sing表示，通过自动化处理，可以享受到业务连续性的好处。

“切实可行的业务连续性计划有一个先决条件，那就是要有一个集中化的简单的IT环境。”Sing说，“如果环境太复杂，那复制环境将会很麻烦，其效果也变得不尽如人意。”

要创建一个灾难恢复计划，需要做评估与测试，集中化与环境简化计划同样需要这些工作。“大部分公司认为灾难恢复和其他项目一样，”Sing说，“因此不会调用全公司的资源来做这件事情。”

实现集中化与环境优化的最好方法就是使用虚拟化技术。“服务器虚拟化能让企业轻松应付一个完全不可挽回的状态——企业只需在另一个虚拟站点将它恢复就可以了。”Sing说。

他建议计划从集中化开始，并发挥虚拟化的全部功效——包括服务器虚拟化和存储虚拟化。“存储虚拟化也需要先进行集中化处理，建立一个对各个厂商存储服务器的单控制点，并将存储虚拟化列入日常管理计划中。”

这些虚拟化的存储可以通过一个控制台进行管理，数据可以在虚拟存储池中随意复制。“企业只有把虚拟化和集中化都做好了，业务连续性部署的其他步骤才能及时实现。”

“业务连续性要取得成功的一个关键因素是确定好可恢复的范围。”Sing表示，“项目的范围需要很实际，并不断扩展——不要期望一步到位。”

接下来要做的是进行风险与优先级评估，并确定需要恢复业务流程的顺序。有了这些信息，企业就能进一步确定需要实现的恢复时间能力。

赛门铁克公司存储与服务器管理部的产品市场高级经理Dan Lamorena指出：“每个公司都在优化业务连续性计划。他们需要查看他们所拥有的每一个应用程序或服务，如电子邮件、网络门户、ERP系统等。对于基本的数据有效性需求，他们会考虑采用备份解决方案，有时他们还会做磁带或硬盘的备份，并存放到异地，以保证数据的安全。”

这种备份解决方案是基于扫描的，因此可能会丢失一些数据，因为在备份之后，系统数据又发生了一些变化。“如果公司不能承受任何的数据丢失，那么他们就应该使用更好的备份方案。”Lamorena说。这就是镜像，能够为数据做实时的备份；或者使用数据复制，在异地站点间实现同步。

分级数据保护

Gartner和TechTarget的报告都指出，业务连续性与灾难恢复业务对IT经理来说是最重要的事情。因此，大部分公司都在寻求相关的解决方案。

“我们有一个名为分级数据保护的策略，”Overland存储公司全球销售副总裁Bob Farkaly说，“我们针对不同类型的数据提供不同等级的保护措施，因为这些数据的价值是不一样的。”

比如说，文件和打印数据通常是价值最低的，而价值较高的通常是那些与业务紧密相关的应用程序，例如ERP系统、CRM系统和电子邮件。

“问题的关键在于理解数据的价值，并为其提供相应的保护措施。”Farkaly说，“大部分业务在没有电子邮件、ERP系统或者订单管理系统的情况下都无法运行，因此对这些系统需要特别重视。”

导致灾难发生的原因可能是硬件故障，也可能是病毒导致的应用程序问题，还可能是自然灾难或者人为攻击。“企业必须应对所有这些可能发生的情况，”他说，“这就跟买保险一样。”

“RPO是IT经理在制定业务连续性计划时必须考虑的重要指标。”他说，“企业需要搞清楚以下几个问题：企业允许丢失数据的范围是多大？能够容忍的时间有多长？这些需要通过分析得到答案。”

应用程序有效性

“基于存储的业务连续性计划的最后一点是应用程序有效性。”Lamorena说。这和故障转移、集群和镜像等一样，是企业要实现高可用性必须考虑的解决方案。

“安装软件来监控那些和业务紧密相关的应用程序，”他说，“这能告诉你，程序什么时候是正常的，或者哪个存储系统或应用程序出现了问题。如果出现问题，它能够自动启动在同一数据中心或异地数据中心其他服务器上同样的应用程序来替换问题应用。”

要实现数据高可用性，公司需要部署镜像和数据复制解决方案，以及高可用性的集群解决方案，以保证每个应用服务器都至少通过两种方式访问到数据。这样，如果其中一种访问途径或者数据所在的存储设备出现了故障，就有了替代的访问数据的途径。“这种将数据访问从一种途径切换到另一种途径的方法称为故障转移。”Farkaly说。“这是一种有效的方法，能够在硬件或软件出现故障时起到很好的保护作用，这种方法在数据中心经常用到。”

但这也并非万无一失，对于关键数据，还需要多一些备份手段。“万一故障转移过去的存储设备也出现问题，那数据岂不是就无法挽回了？”他说，“这种情况下企业需要采用集群技术。这是另一种高可用性故障转移方式。”使用集群技术能够保持备份数据的同步。

这种情况下，如果访问路径或者其中一个数据服务器出现故障，这种故障转移机制就能够绕过故障点，访问另一份数据，继续处理业务。

集群软件监控数据库与服务器的健康状态，保证了网络和存储设备都正常工作。一旦它们出现任何故障，故障转移软件或者集群软件就能启动别的服务器上的应用。

Lamorena表示：“集群是一种高端的IT恢复解决方案，要求应用之间相互协调。大多数复杂的数据中心都有来自多个厂商的应用，让它们在一起协同工作是一种挑战。”

（责编：yangyang）

(本文不涉密)
责任编辑：

转载：感谢您对网站平台的认可，以及对我们原创作品以及文章的青睐，非常欢迎各位朋友分享到个人站长或者朋友圈，但转载请说明文章出处。