忽视变更控制会毁掉你的灾难恢复计划

bfhf5753

你从这篇文章中可以学到这些：讨论了灾难恢复上的变更控制(或者缺乏变更控制-change control)的影响，并且提出了一些很好的实践信息。
　　你的灾难恢复(DR)计划文档仍然涉及9磁道磁盘、或者仍然描述了从Windows NT 3.51服务器上的恢复过程?虽然大多数公司的计划中并没有我说的这样过时的技术，但是大多数参与公司数据灾难恢复计划的信息技术从业者当被问及它们公司目前的灾难恢复计划怎样时，他们都会无可奈何的以微笑回应。并且，他们中的很多也承认灾难恢复是需要被注意的。有很多的原因可以解释为什么DR计划已经和公司的架构不再同步了;下面的一些是常见的原因：
　　● 被开发的机会仅仅是用来满足审核的需求的，并且该计划已经过时
　　● 计划从根本上并没有得到测试以及维护
　　● 计划仅仅在固定的时间点上得到维护(例如：一年一次或者再一次测试后)
　　● 变更控制(或者变更管理)并没有将灾难恢复考虑在内
　　● 缺乏正规的变更控制流程
　　最近在《灾难恢复杂志》公布的Gartner公司的调查显示：大约51%的回馈者对灾难恢复环境作周期性的改变，而35%的回馈者依赖于产品变更管理过程才做出改变。
　　到目前为止，忽视变更控制是灾难恢复计划或者灾难恢复环境最大的敌人。事实上，不存在或者不充分的变更管理是灾难的起因。有很多的例子证实都是由非常差的灾难恢复计划所导致的，当然也会由常规的软件升级所导致。一些小的以及中型企业(SMB)当遇到变更控制时都由于缺乏资源以及资金而面临挑战，而且解决问题比防止问题发生会花更多的时间。
　　下面是变更控制相关条目的摘要列表，任何规模大小的需要信息技术部门的企业都需要考虑以下几点涉及到灾难恢复的因素：
　　● 如果还没有变更控制过程的列表，那么请实现一个。该列表不必非常详细，但是在复查前不应该允许做任何信息技术方面的变动
　　● 在评估变更影响前，确保变更控制将灾难恢复环境以及计划文档考虑进去。要包含一些简单问题以及一些验证形式
　　● 灾难恢复必须是系统开发周期的一部分并且不要成为事后想法
　　● 灾难恢复计划必须成为计划中的一部分，而不应该在项目结束时才被考虑
　　● 灾难恢复协调员(或者负责灾难恢复的人员)需要参与到变更复查过程
　　● 不要等到下次灾难恢复测试才更新你的灾难恢复环境，以反映你对环境的变化过程
　　● 灾难恢复计划以及灾难恢复环境应该在产品系统阶段就被重点考虑，并且应该据此进行设计和维护
　　那些使用厂商提供热点(hot-site)的企业应该得到提醒：虽然一个灾难恢复环境物理上不一定存在直到真正有需求时，但是这些企业需要让厂商知道产品环境中的每一个配置上的变化，而这些变化则会影响到灾难恢复环境。这一工作不应该在续约的时候才去做，而应当在变更前就做，这样就可以确保任何引起的技术以及契约问题在计划阶段就已经确定了。
　　就像我们测试我们的灾难恢复计划和过程(基本的)，同样建议去测试你的变更管理过程。变更控制的少量存在不会自动确保该过程的效率。测试变更管理过程和进行变更后复查一样简单，并且它能够确保变更的每一个方面及其可能的影响都在实现前就作了考虑。
　　需要让变更管理过程实现成熟化的信息技术公司也许会遵从信息技术业内最好的建议或者指导，比如在信息技术基础架构库(ITIL)框架中提到的一些建议。
　　无论是世界级还是入门级的变更控制，它不仅仅保护你的公司免遭非常差的IT变更计划影响，并且它也可以帮助产品和灾难恢复IT环境完全同步，同时确保所有的相关文档以及过程得到很好地维护。

本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u2/71105/showart_971395.html