本帖最后由 FYIRH 于 2021-1-13 01:09 编辑
- D& i! j! ?5 Z% T. T* A, O) q* p4 O9 H# \
2 \8 q8 H# D9 U- F3 P9 X
* h0 v( }" m6 X4 l: p2 F5 K! _9 V
分类、分级和分线是ITIL事件的三分法。通过分类,事件记录单被赋予分类属性,并被服务台分派往最合适的IT服务工程师手上。在事后还可以通过事件类型以及频率确定某些现状的趋势,用助于问题管理、供应商管理和其他IT服务管理活动。因此事件的准确分类十分重要。同时事件在完成分类后,需要获得所有IT运维服务团队成员的共识。 5 s Z; v$ N/ P2 L
在事件分类的过程中可以应用MECE分析法。MECE(Mutually Exclusive CollectivelyExhaustive)可以理解“相互独立,完全穷尽”。对于事件的分类,我们应该做到不重叠、不遗漏。确保分类后的在统一维度上各部分之间相互独立,不可重叠;所有部分被全面覆盖,完全穷尽。 9 x" O& u9 Z4 G3 K7 Y. O
结合MECE,有以下分类原则供参考: - 服务导向原则:原则上可以按服务内容分类,也可以按设备分类,往往在没有进行服务梳理的组织内可行的是按设备按照信息资产(包括基础设施、软件、硬件、虚拟资源、数据等)分类,但是从服务与业务影响的对应上来看从服务分类更合理,但需要较多的投入。
8 x! M9 _, K! `! U % G$ j! m& \* z- c- M' j- k
+ ]* [! r2 }4 Y& i" a: R- U- 完备性原则:能够涵盖当前所有IT服务对象的所有情形,通常的做法是确定分类大项后,再设置一个“其他”项来归类无法单独列出的类别。但最终被归入“其他”项的比例不应超过10%;这也是事件流程成熟度的标志之一。目前在某些IT服务组织中,由于IT服务与信息安全可能由两个平级部门分别管理,IT服务事件和安全事件之间的界限不清晰。在此种状况下,如果暂时组织架构无法被改变,建议尊重现状,“凯撒的,就应归还凯撒;天主的,就应归还天主”。信息安全事件可以暂时不被事件管理流程管辖,不列入事件分类中。但必须由信息安全部门另行制定规范,并对事件等相关管理流程留有接口。
# k6 v; Y# ]2 |% n& g7 z . V* {& P9 {! i4 ^- y: \) P
- 互斥性原则:分类项之间不能相互包含或者交叉;例如:防火墙故障属于“硬件”事件,还是“信息安全”事件,这的确是个“问题”。但解决起来也不难,我们只需要有统一的分类标准,做到互斥的程度即可。! r' ?8 q$ N+ s& F* n5 H
6 J) a9 Y# Z, m6 c9 i
- 分层原则:当需要从多个维度进行分类时,需要采用多层级分类,否则很容易违反互斥性原则,可采用CTI法则进行分类,即类别(Category)、类型(Type)和条目(Item)。第一层按“业务服务目录”分“类别”(前提条件是定义了服务级别,否则第一级分类采用技术维度),第二层按“技术服务目录”分类型,第三层按“作业活动”分“条目”。) e' G0 V4 j8 T' l0 w, J, i7 V5 `7 D9 Q
K |) L2 Y' Z- W: e7 R& `: d6 t
- 颗粒度适中原则:分类的颗粒度并非越细越好,应该在管理需求和管理成本间找到平衡。
, ]0 o8 ?) y2 I+ o* R; f9 v ' }: N5 N. y# g& z- s
以下是一个事件分类的示例。 表 1-8、事件分类样例
+ H' g. i& O/ v# s! [! D' zITIL先锋论坛原创文章,禁止任何形式的转载,侵权必究!
9 I8 I& E' J) [% `) R6 k! a! j, m1 T |