IT系统的灾难恢复基本指南,了解一下?

服务器 数据中心
公司和组织都应该通过制定灾难恢复计划,将遇到灾难时应有的行动和流程细化,以快速恢复关键业务功能,避免造成收入或业务方面的重大损失。

数据中心可能遭遇的灾难是各种各样的。包括灾难性的自然事件,如洪灾、地震和龙卷风,以及网络攻击、设备故障等,都可以被归类为灾难。

公司和组织都应该通过制定灾难恢复计划,将遇到灾难时应有的行动和流程细化,以快速恢复关键业务功能,避免造成收入或业务方面的重大损失。

什么是灾难恢复?

在IT领域,灾难恢复聚焦于支持关键业务功能的IT系统。“业务连续性”通常与灾难恢复联系在一起,但这两个术语并不能完全互换。灾难恢复是业务连续性的一部分,它更侧重于在发生灾难时保持业务运行的各个方面。如今,IT系统对业务的成功至关重要,因此灾难恢复已成为业务连续性的一个主要支柱。

[[227077]]

灾难损失

如果一个企业对灾难没有任何应对措施,那么灾难所造成的经济和运营上的损失会将其完全压垮。据IT灾难恢复计划(DRP,Disaster Recovery Preparedness)理事会2015年的一份报告显示,一小时的停机时间,就可能会让小公司损失高达8000美元,中型企业高达74000美元,大型企业的损失高达70万美元。而且那还是在三年前,今天可能更高。

某灾难恢复服务提供商的另一项调查显示,超过一半的受访企业(54%)在过去5年里经历的停机时间长达8个多小时。这其中有三分之二的受访者表示,他们的企业因停机造成的损失超过了每天2万美元。

风险评估,识别漏洞

即便你的公司已经制定了某种灾难恢复计划,可能也仍需更新。如果你的公司没有相应的计划,或者正准备进行制定,最好先做一次风险评估,识别IT基础架构的漏洞,并找到可能出现问题的地方。当然,先决条件你必须清楚地了解公司的IT基础设施。

在《灾难恢复期刊》(the Disaster Recovery Journal)最近的一篇博客文章中,作者汤姆?罗普克(Tom Roepke)和史蒂文?戈德曼(Steven Goldman)建议,在保持业务连续性的计划中,将最坏的情况从其他重大威胁中特意分离出来的做法是非常危险的:

“大体上,大家都会去尝试找出或定义最坏的情况。这是一个致命的缺陷,因为它决定了之后整个计划的努力,即使是在潜意识层面。因为当我们插入一个特定的场景时——如瘟疫、地震、网络攻击等,我们就会自动开始思考和计划响应/恢复措施,以应对这一特定的、潜意识定义下的事件。当这种情况发生时,我们不仅会在规划中形成一种隧道式的局限视角,而且也可能面临着增加风险的危险。这是因为在我们将最糟糕的情况特意分离探讨的时候,只有一两个特定的领域会被过度关注,而不是真正的事件。”

罗普克和戈德曼建议,在与项目小组沟通时应关注于“管理危机,重建业务关键职能并恢复一切。”

什么是灾难恢复计划?

在搜索引擎中输入“灾难恢复计划(预案)模板”,会出现几十甚至上百个计划书的模板。这些模板对于你的计划的制定有一定的参考价值。

灾难恢复计划本身应基本包括以下内容:

  • 计划的概述和主要目标。
  • 关键人员和灾难恢复团队成员的联系信息。
  • 灾难发生后紧急响应行动的描述。
  • 整个IT网络和恢复站点的图表。(包括如何到达恢复地点、需要到达的人员说明。)
  • 识别最关键的IT资产,确定最大的停机时间。了解恢复点目标(RPO,Recovery Point Objective)和恢复时间目标(RTO,Recovery Time Objective)。RPO表示当业务恢复重新上线后,应用可以回到或者它的数据允许恢复过去多久的时间点的数据。如果你选择一个5小时的RPO,那么系统必须至少每5小时备份一次。RTO是指灾难发生后,从IT系统宕机导致业务停顿到可以恢复支持各部门运作,业务正常运营所需要的时间。
  • 将用于恢复工作的软件、许可证密钥和系统列出一个表格。
  • 来自供应商的恢复技术系统软件的技术文档。
  • 保险摘要。
  • 处理财务和法律问题的建议。
  • 对公措施(如维护性声明,降低舆论影响)。

[[227078]]

建立灾难恢复团队

该计划应该由负责公司内部关键IT基础设施的IT团队成员协调。其他需要了解该计划的人包括首席执行官或委派的高级经理、董事、部门领导、人力资源和公共关系专员。

除本公司之外,应了解与灾难恢复工作相关的供应商(例如软件和数据备份服务提供商)的联系信息。设施所有者、物业管理人员、执法人员和应急反应人员也应在计划内列出(甚至可以周期性地更新姓名或电话号码)。

在管理层将计划编写完成、批准之后,需要对计划进行测试,并在必要时进行更新。安排下一个审查周期,审核灾难恢复功能。当事件发生后(无论大小),一定要更新、更新、更新。计划不是用来收藏的。

灾难发生了该怎么办?

当灾难已经发生时,就该启动你的事件响应了。确保事件响应团队(如果它与灾难恢复计划团队不同属一支)有一个灾难恢复计划的副本。

事件响应包括,评估情况(知道什么硬件、软件、系统受到灾难的影响)、系统的恢复和后续工作(哪些有用,哪些无效,哪些可以改进)。

下一个趋势?云或DRaaS(灾难恢复即服务)

就像许多企业将IT系统迁移到云端一样,灾难恢复也是如此。云计算的优势包括低成本、更容易的部署以及定期测试计划的能力。然而,这可能会增加带宽需求,或者降低公司的网络性能,而且需要使用更复杂的系统。

2016年,Gartner的相关调查报告中列举了超过250家DRaaS产品提供商,灾难恢复服务市场形势一片大好,有很多具有不同特性产品可供企业选择。限于篇幅,此处不对服务提供商进行过多描述。将灾难恢复交给专业的人来解决确实是一个不错的选择,但应注意对其产品进行全方位的评估。

责任编辑:赵宁宁 来源: IT168
相关推荐

2017-05-05 11:25:43

2018-08-08 09:30:29

服务器知识Linux系统

2024-01-03 08:59:52

2022-03-24 13:36:18

Java悲观锁乐观锁

2020-02-10 14:26:10

GitHub代码仓库

2018-04-12 17:29:43

众筹Linux红旗软件

2018-06-05 17:40:36

人工智能语音识别

2022-10-24 14:03:24

云计算IT托管服务

2019-03-11 14:33:21

Redis内存模型数据库

2023-03-02 08:00:55

包管理工具pnpm 包

2020-12-10 08:44:35

WebSocket轮询Comet

2013-06-21 09:31:01

混合云云爆发故障转移

2017-08-12 13:36:15

虚拟化灾难恢复服务器

2018-07-24 13:19:50

灾难恢复DRaaS备份

2022-03-07 06:34:22

CQRS数据库数据模型

2011-07-22 17:13:45

Active Dire

2017-12-26 09:36:36

数据中心灾难恢复

2020-03-01 17:53:38

Excel大数据微软

2018-07-17 14:42:50

2023-11-18 09:09:08

GNUBSD协议
点赞
收藏

51CTO技术栈公众号