|
本文由长河、陈贺、傅盛原创，张翼、王岩校对。
由于IT技术的发展、业务的变化、外部法规的改变，导致变更存在必然性。如何确保变更可控，业务风险可控，变更管理（change management）将大派用场。变更管理强调“稳”，有原则地，可控地“变”，目标是确保变更的方法和程序标准化，对变更进行有效地处理，维持IT服务的稳定性。
ITIL事件中可能蕴含变更，需要通过变更才能排除故障。如果有，则需要再启一个变更单，并关联起来；而在变更过程中，也可能导致次生故障，需要马上解决，则该故障必须与变更关联起来，便于事后变更成败分析。在日常运维中，事件处理中往往蕴含了标准变更。因为该类变更影响不大，安全风险低，通常可以采用预审批的方式由事件处理人员直接实施，提高事件处理效率，如给用户电脑更换一个OS版本、换一台显示器等。
变更管理的输入，可能是运维人员主动发现问题后提交的变更请求（RFC），也可能是业务部门提出的需求的RFC，但最常见的是事件管理过程中为解决事件而提交的RFC。在这种情形下应避免或减少为了解决事件的变更反而导致发生新的事件甚至灾难。变更和事件流程之间强调互通信息，互相联动，两者存在起承转折的多种联系。
在事件的处理中，如果对业务有影响及需要变更CMDB内CI或CI关系，则需要提交RFC，并通过变更管理流程处理。当变更对业务影响较低，风险较低并经多次实施无一出错时，可以被预定义为标准变更。在执行此标准变更时，既可以提交标准变更单，也可以由以事件单形成，直接提示CMDB管理员进行操作，从而实现“例外事件例行化”。但此类流程间接口也应预先被确立。
同样的，在ITSM中，若事件的处理需要通过变更实现时，需要将事件单与变更单关联。在此操作过程中，实施成功的变更后，事件被解决；而不成功的变更，有可能引发新的事件。
事件和变更间的联动，目前有两种做法，一种做法是事件转变更后，事件状态标记为“挂起”，待变更实施完成后，立刻转入事件流程，此时事件“关闭”。另一种是事件处理过程中，如果触发变更，由服务台和客户沟通，告知其该事件将“关闭”，并转入变更流程，并且事件单和变更单关联。前者能形成闭环流程，“故障不消，事件不闭“；而坏处是变更需要足够的前导时间（除非是紧急变更），这将导致挂起时间过长，有违事件管理流程的初衷——尽快解决事件。后者的好处是事件马上被“解决”，表面上事件管理相关KPI未受影响；但坏处是事件有可能最终未解决，而导致客户满意度下降。
ITIL先锋论坛原创文章，禁止任何形式的转载，侵权必究！
| 
转播
分享
淘帖
()