灾难恢复计划

损失减少损失减少 企业灾难恢复计划七步曲企业灾难恢复计划七步曲 正如现实生活中其它事物的不可预料性一样 企业很难预先知道其网络 数据 中心运作过程中何时会受到威胁 但减轻灾难的后果并不是一个轻松的过程 下面笔者给出可以帮助企业提 供实用指南并实现高效的业务连续性和灾难恢复计划的七个步骤 第一步 承认灾难的可能性 业务连续性及灾难恢复的第一步是承认自己的单位会碰到可以损害企业发 展的现实性威胁 如果企业没有在一个高级的层次上采取这一步 其它的步骤 就免谈 第二步 列表并分类企业面临的威胁 企业及其社会环境的性质能够影响一个单位所面临的威胁类型 在列示了 威胁之后 单位应当根据这些威胁对不同系统的可能影响对其分类 应当在灾 难的响应成本和可容忍的 宕机时间 之间实现平衡 可容忍的 宕机时间 越少 则企业就需要越多的成本来创建恰当的响应 比如 一些系统必须在几 分钟或几秒内实现功能恢复 还有一些系统可容忍的 宕机时间 为几小时 还有其它系统即使 宕机时间 多达几天也不会产生严重的后果 第三步 概要描述单位的业务连续性和灾难恢复技术的基础结构 业务连续性和灾难恢复技术基础结构的关键技术要素由以下几部分组成 关键数据中心 一个可以备份主要数据中心资源的远程站点 高带宽的网络连 接等部分组成 在整个数据中心 业务连续性和灾难恢复的最佳策略都要遵循 所有要素成分都保持冗余性的观点 在生产性和备份数据设施中都应当运行多 台主机和服务器 如果一个生产性系统的一个组件碰到了一个问题 此系统组 件就立即将其功能转移给本地的备份系统 这可以作为对付灾难的第一道防线 在业务连续性和灾难恢复策略中 最关键的要素之一就是电源 根据调查 电力故障是最为常见的也是可预防的中断性故障 不管企业的网络带宽多么大 如果一个粗心大意的施工人员偶然弄断了光 纤 其作用也就寿终正寝了 网络的连接不但要足够 还要在一个更宽广的 WAN 技术范围内遵循不同的途径 避免业务限于停顿 第四步 清查单位的 IT 资产 一旦单位已经草拟了其业务连续性和灾难恢复基础结构的拓扑 下一步就 是要制定 IT 资产的一个精确而详细的目录 这就使得单位能够理解需要保护的 资源和业务过程 现在有不少业务管理工具有助于制定和维护 IT 资源的精确目录 这些工具 的厂商都提供了一些依靠软件代理来优化 IT 基础结构的工具模块 并可将硬件 和软件资产的细节及其配置参数存储到配置管理数据库中 CMDB 第五步 设置服务水平期望并定义意外事故策略 配置管理数据库中 CMDB 不但存储着单位软件和硬件资产的细节信息 还包含着服务水平的约定要求信息 这些约定要求可以定义正常运行时间及这 些资源的恢复参数 回想前面的第二步 高级管理部门对服务水平期望作出要 求是很重要的 因为这些能够决定在某次故障中的 5 分钟内或 5 小时之内某种 特定的资产是否必须启动和运行 这种决定可以直接影响高级管理部门日后会 寻求支持的业务连续性和灾难恢复的成本支出 根据对 IT 资产及配置和服务水平约定的清晰理解 单位就可以定义意外事 故的应对策略 这些策略必须得到主管人员的支持 因而需要将 IT 资产的性能 直接与企业需求联系起来 为了形成这种重要的联系 单位需要执行业务影响 分析来充实系统需求 过程 系统交互关系的细节 主管人员必须理解系统瘫 痪的后果 以便于支持意外事故的应对策略 第六步 制定一个业务连续性和灾难恢复的计划 意外事故的应对计划应当直接根据意外事故的应对策略 详细表述不同部 门和个人的角色和责任 以保持技术系统的可用性 并阐明紧急情况下恢复 IT 系统的过程 意外事故的应对计划的关键元素还包括资源需求 培训需要 培 训练习和测试的频率 维护时间表 数据库备份的时间表等 意外事故的应对计划的阶段包括以下几个方面 一是灾难降临时的通知过 程 二是应急团队动员后的恢复过程 三是回归正常运作过程 第七步 测试业务连续性和灾难恢复计划 在定制了正式的策略和过程之后 最为重要然而却最容易被忽略的一个方面 是灾难恢复计划 企业必须从一开始就测试其计划的完整性和有效性 然后再 在运作过程中重新测试 以确保对 IT 基础结构和业务过程的日后改变不会产生 策略改变的需要 此外 单位应当创建测试平台 以精确地反映日常的业务条件 以使演练 可以模拟真实的条件 在当今复杂的条件下 要让企业防御每一种灾难事故确实有点儿困难 但 是 在无法预料的事情发生后 如果企业采用了恰当的技术 清晰的服务水平 期望 实用的恢复策略 再通过灾难恢复计划和严格的测试方法 单位就可以 将灾难对业务的影响降至最低 企业业务连续性和灾难恢复规划实施企业业务连续性和灾难恢复规划实施 企业部署了全面的灾难恢复规划 而不到 10 的中小企业拥有危机管理 应 急措施 业务重组和业务恢复计划 对于中小企业来说 部署灾难恢复计划是十分重要的 根据 Gartner 调查显 示 五分之二的企业在五年内都经历过至少一次严重灾难 此外 灾难的发生 频率比我们想象中的还要高 因为大约 80 的应用程序停工是人为的或者进程 出错造成的 而不是因为灾难或者技术故障 设置一个停机时间限制 当我们在部署灾难恢复计划时 最开始的目标应该是确定恢复点目标和恢 复时间目标 灾难恢复点目标 RPO 指明了可以允许的数据丢失范围 而恢复 时间目标 RTO 则是应用程序可以允许的停工时间范围 即根据可承受的最长 停电时间来确定 如果灾难真的发生了 那么你的公司可以承受多长时间呢 一个小时 一 天 还是一个星期 那些需要立即恢复运行的公司必须投入更多的资金来进行 灾难恢复部署 而那些几天内仍然可以继续运行的公司则可以投入较少的资金 同样来说 较高的灾难恢复点目标相对来说更加昂贵 但是中小企业必须权衡 预防性支出与重要数据丢失带来的潜在高额费用之间的关系 认真确定灾难恢 复点目标和恢复时间目标能够帮助你合理分配资源 而不会浪费成本 如果你的公司对于确定灾难恢复点目标和恢复时间目标 那么就可以使用 业务影响分析 BIA 业务影响分析方法依据的基本假设条件就是 公司的每一 个因素都依赖于任何其他因素的持续运行 但是有些因素比其他因素要更加重 要 业务影响分析优先考虑了关键任务数据和系统 它能够帮助公司在考虑灾 难性事件时将资源进行合理分配 BIA 可以让 IT 经理和中小企业业主清楚地看 到 如果他们不部署灾难恢复计划 他们将可能损失的成本价值 建立灾难恢复计划 当确定了 RPO 和 RTO 之后 你就可以正式建立灾难恢复计划了 当你在 建立灾难恢复计划时 要牢记以下这些最佳做法 要让公司所有的利益相关者参与进来 而不只是 IT 部门 举例来说 人力 资源部在对员工进行灾难恢复计划培训以及计划沟通中时将发挥重要的作用 所以人力资源部应该参与进来 首席执行官和其他高级管理人员对于保证灾难 恢复计划的资金和公司性购买方面是必不可少的角色 如果你的公司场所是租 赁的 那么物业管理也应该了解你的计划 此外 最好还要告知当地的执法部 门你所要实施的计划 将所有的利益相关者参与到规划和部署中是十分重要的 防止数据仓库的产生 也许你会认为将文件保存到桌面是很方便的事情 但是这却是个不好的习惯 员工的个人电脑硬盘通常没有得到 IT 部门的备份支 持 所以最好部署一个中央服务器来解决这种令人头疼的问题 让所有的员工 能够规范地使用电脑 优先备份 确定需要保存的数据以及保存时间 然后执行存储策略来优先 备份关键数据和应用程序 首先要备份最关键的部分 现场备份和非现场备份 我们现在拥有各种备份技术 从在线备份服务到 磁盘和磁带解决方案等 在考虑选择何种备份服务时 最好选择既可以进行现 场备份又可以进行非现场备份的备份服务 那样当你的主要业务场所无法使用 时也可以对数据和应用程序进行备份 举例来说 有了磁盘镜像 至少会有两 个硬盘同时进行复制和存储数据 那么 如果其中有一个磁盘出现故障 系统 就可以自动切换至另一台磁盘 不管这两个磁盘在同一数据中心或是分布在不 同城市 这样就可以减少数据和服务的损失 确保远程访问 数据保存期限和网络访问同样重要 如果实体办公室不能 避免灾难的发生 员工还是需要接入网络基础设施来保持业务运行 如果让所 有员工实现远程访问不现实 至少密钥持有者应该能够进行远程访问 确定了停工时间限制以及部署了灾难恢复计划后 有必要进行定期测试 当然 测试需要花费一定的时间和金钱 所以公司的测试频率可以根据预算来 设置 作为一个基准来说 中小企业至少每年进行两次测试 如果每年对整个 系统进行两侧测试不能实现 至少也应该定期地对最关键的应用程序和系统进 行测试 另外 在公司旺季的时候也应该进行测试 并且不需要告知所有的员 工 除了必要的几个工作人员外 这样做是为了模拟真正的灾难 最后 IT 经 理在每次测试后都应该对灾难恢复系统进行审查 看看哪些地方容易出现故障 以及时纠正错误 有效的灾难恢复计划对于企业生存发展力是至关重要的 根据 McGladrey 和 Pullen 事务所统计 每年每 500 个数据中心就会发生一次灾难事故 其中 43 的 灾难事故造成无法挽回的损失 而另外的 29 企业将会被迫关闭两年 灾难恢 复相当于企业保险 是你的企业不可缺少的部分 确保灾难恢复 DR 计划的实施 在今年早些时候提出的一份灾难恢复 DR 报告中 Forrester 研究公司建议 在 制定灾难恢复计划时 要采取以下七个步骤来确保争取到新的 额外的 正在 运行的基金 1 实施一套连续性的管理流程 技术支持灾难恢复的准备工作 这并不是 一个连续的策略或者计划 在能争取到技术和服务的基金之前 你应该将灾难 恢复的准备工作看作是一个连续性的流程 而不是一个一时的事件 并且为此 制定一个总体的框架 2 进行业务影响分析 BIA 和风险评估 在 IT 部门争取到资金之前 IT 部 门的人员必须坐下来与业务部门人员进行交流 共同确定哪些是公司里最关键 的流程 哪些依赖于 IT 资源并计算出由于发生故障而引发的成本 然后 你还 需要制定出一份风险评估 以确定特定风险的概率和频率 3 计算出停机所产生的成本 理解停工成本是非常重要的 这有利于帮助 业务人员和 IT 部门确定在每一个业务流程中可接受的停机时间和数据丢失 指 导将来的技术和服务投资 4 发展影响的情况 不只是解决 灾难 要解决所有的风险 业务部门 和 IT 部门必须要同风险管理专家合作一起评估那些真正的破坏性事件的风险 例如 电力故障 IT 故障 人为错误 设备故障 自然灾害和人为灾害 当管 理者考虑灾难恢复的准备计划时 他们通常是先考虑为那些反常的事件做准备 例如 飓风 地震和恐怖主义事件等等 现实情况是 那些发生的灾难或主要 业务的中断最常见的原因通常是人为事件 例如 停电和 IT 故障 灾难恢复计 划者和 IT 运营专家必须要是管理人员明白灾难恢复的准备工作不仅仅是应对 灾难 而是应对那些像公司停工这样的事故的发生 5 将灾难恢复 DR 看作是竞争的必要手段 如果你的公司停工 这就有可 能为你的竞争对手提供机会扩大他们的市场份额 同样 正常开工就可以与竞 争对手有平等的机会竞争市场份额 这有助于重新提起关于灾难恢复的讨论 要制定一份保险策略确保灾难恢复 灾难复原 将它作为一个竞争的必要手段 大多数公司 不只是金融服务公司都有一个备用的站点 并且利用先进的复制 技术来保护数据 公司应该与同行或竞争对手保持一致 6 制定一个灾难恢复 DR 服务目录 正如你与业务部门合作确定需求一样 也