Chinaunix首页 | 论坛 | 博客
  • 博客访问: 11627471
  • 博文数量: 8065
  • 博客积分: 10002
  • 博客等级: 中将
  • 技术积分: 96708
  • 用 户 组: 普通用户
  • 注册时间: 2008-04-16 17:06
文章分类

全部博文(8065)

文章存档

2008年(8065)

分类: 服务器与存储

2008-12-14 14:16:51

   你将从这则消息获悉什么:这则消息讨论变化控制(或者缺少变化控制)在灾难恢复上的影响,提供一些最优的应用实践信息……

  你的灾难恢复(DR)计划文件还需要从保险库(Vault)当中找回9磁道的磁带或是从Windows NT 3.51 server的outline恢复程序吗?大多数计划没有那么过时。当被问到所在公司近期的灾难恢复计划的详情时,大部分致力于灾难恢复计划的IT从业者都会微笑,然后通常是承认它需要得到关注。DR计划为什么跟不上IT基础设施的发展,有很多原因,下面是其中最普遍的。

  •   这个计划当初就是为了满足审计需要而开发的,而今却不能再用了。
  •   这个计划不能按常规测试或维护。
  •   改变控制(或改变管理)时没有将灾难恢复计划考虑进去。
  •   缺乏一个正式的改变控制的流程。

  Gartner最近的一项有关灾难恢复的杂志显示,大约51%的人在预定维护周期中对灾难恢复环境进行了改变,只有35%依赖工作变化管理过程(production change management process)。到目前为止,缺少变化控制是灾难恢复计划或者灾难恢复环境的最大敌人。实际上,变化管理的缺失或不足会引发灾难。许多案例证实中断主要是由缺乏计划的程序软件升级产生的。中小型企业由于缺乏资源和资金,提到改变控制尤其面临挑战。这常常导致花费更长的周期用于解决问题而不能防止这些问题。

  下面简要列出任何规模的IT企业都应考虑的关于灾难恢复的对应的变化控制事项:

  •   实施一个变化控制过程,假使在目前还不具备,其不必很精密,但是未经预先审查,不应允许进行任何IT变化。
  •   当评估变化影响时,要确保变化控制考虑到灾难恢复环境和/或计划文件。这可能不是简单的问题,包括一些确认形式。
  •   灾难恢复必须是系统开发生命周期的一部分,而不是事后的想法。
  •   灾难恢复计划必须成为一个正在进行的过程,而不能被认为是一个带有结果的方案。
  •   灾难恢复协调者(或灾难恢复负责人)应参与变化审查过程。
  •   不要等到下一个灾难恢复测试进行时才去更新灾难恢复环境以适应工作环境的变化。
  •   要像重视关键的生产系统那样重视灾难恢复计划和灾难恢复环境,并进行相应的维护。

  必须提醒那些向制造商定制了热站(hot-site)的企业,尽管灾难恢复环境直到其被需要时才会物理地存在,但是他们有责任通知制造商对工作环境所作的将会影响灾难恢复环境的任何配置变化。这并不仅仅是在重新签订合同时去做,而是在变化实际作出前做以确保出现的任何技术和合同问题在计划程序当中得到处理。

  正如我们按常规(技术上)测试我们的灾难恢复计划和程序,你的变化管理程序也应进行测试。仅仅是变化控制的存在不能自动地保证过程有效。这其实可以象进行post-change review那样简单,在实施前确定各个方面以及变化可能产生的影响是否都被考虑到了。

  IT机构想要帮助他们的变化管理过程达到成熟,可以选择模仿的IT产业最优的实践和方略,如那些ITIL构架(IT Infrastructure Library)中所论述的。

  无论是世界一流还是入门级,变化控制不只是防止你的机构受到缺乏规划的IT变化的影响,还会协助保持生产和灾难恢复IT环境充分同步,确保全部相关文件和程序得到良好的维护。

阅读(612) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~