变更管理中的风险控制

上次在博客写的CRAMM 是一种方法（详情请参考：浅谈IT风险管理的方式），可以让 IT 部门很容易进行风险的评估，并且很容易帮助 IT 在相关的资产上，有效的识别可能被威胁所利用的弱点，因此造成风险。可是，变更管理 ( Change Management ) 所致力想要预防的风险，似乎是一种措施、一种管理，可能是预防性的，也可能是事后补正的，都是要避免或是再度避免疏失所产生的风险。

先看一张图：

威胁 ( Threat ) 需要预防 ( Prevention ) 及降低 ( Reduction )，方法可以利用 CRAMM 的方式。之后，任何的事件，可能是安全事件 ( 比方说木马程式的侦测 )，需要侦测 ( Detection )，侦测就需要方法及工具，方法及工具的使用，可能需要变更 ( Change ) 的评估 ( 图上没说，但是这是观念 )！当事件 ( Incident ) 发生，我们需要去抑制 ( Repression )，这个抑制的方式及工具的使用，也需要变更 ( Change ) 的评估 ( 图上也没说，但是这是观念 )。之后，可能发生了损坏 ( Damage )，就需要修正 ( Correction )，并且重建 ( Recovery )！完成之后，也需要评估 ( Evaluation )。从修正到评估，其实都脱离不了变更的管理。

变更管理 ( Change Management ) 其实是人类的一个很难达成的境界。因为在 ITIL 的要求是：需要找一个“标准化”的方式，来进行变更管理。想想看，这一个标准化，可能含盖的范围，大到公司决定整个 IT 的战略方向，小到可能同意用户更改一个用户密码 ( password )，因为这些事情，或多或少，都会给 IT 带来风险。为了避免风险，就有可能必须要利用变更管理的模式，来进行管理。

在理论上，变更管理有两个环节要注意。一个 approval 另外一个是 authorization。Approval 其实很容易理解，就是相关的层级必须要批准这一个变更，可能是基于“财务”、“业务”或是“技术”方面的考虑。可是，在此阶段，并没有真正去实行。可能是同意去调研，可能同意立项，也可能同意开始进行开发，或是进行测试！但是，authorization 就不同了，如果被 authorized 之后，意味着可以进行生产或是上线了。

变更在执行 authorization 的时候，其实有两个环节要去看：测试报告 ( Test Report ) 及退路计画 ( back out plan )。测试报告其实比较容易理解！当上线之前，这份测试报告能够说服所有的委员，同意这一个东西已经通过完整的测试，才能 authorize 上线。这其实又是一个难点！到底，要如何测试才算完整？在 ITILv3 的 Service Validation and Test 提到了 18 种测试，比起 ITILv2 Release 提到的4 种，更令人头疼。退路计画比较好办，最常见的退路就是 Backup & Restore ( 备份及回存 )，一但如果上线失败，可以立即回到出发点，避免风险发生。

在紧急的时候，变更管理的 authorization 是可以同意不用测试的，也就是说至少退路计画要准备好。所谓的紧急，是时间上的急迫，需要速度去支持的。也因此，没有时间完成测试。但是，利用了退路计画，也保障了风险得以控管。

风险小的变更，其实也可以批次处理，或是先处理再审批 ( approval & authorization )。至于哪些是风险小的？这其实需要变更管理的团队去考虑。通常是发生频率高的，不会影响配置 ( configuration )。但是，别忘记事后的审批！比方说：根据每个月的报告，来进行审查及改进意见的推进。

变更管理在设计上，是不参与实施的。但是，必须时时监督、时时协调，并且领导事后的一些检讨 ( Post Implementation Review )。作为再下次的改进意见！有人就问，如此这般的变更管理，会不会阻碍了效率？当然了，寻求一个平衡，是永远必经的道路。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友