/ B) S2 Y3 @, {为什么要这么区分？因为新的事故管理流程更强调事故处理的本质特征，也就是“快速恢复”。“快速恢复”可能意味着要投入更高的关注，更多的资源，甚至掩盖问题产生的原因。如果事件不足以对服务产生影响或者威胁，哪怕对IT基础设施造成了影响，也不应当纳入事故管理流程。: B/ a, g. m% U
7 R( j# t& Q2 J) j) y0 U. D5 c6 y
问题管理流程仍然保持原有的含义，着眼于追究问题产生的原因和本质。因此，问题流程的一个重要来源就是事故管理流程。$ S' o- f$ w/ |0 m: }, H( ?
6 v0 D9 u d* c* w9 r6 @# g在前面的讨论中，为了简单起见，我们没有区分事件和事故的区别。事实上，当然只有“事故”才值得或者说才能从业务视图的角度，根据对业务的影响来定级。当然理论上来讲用对“服务”的影响更好，但这个需要IT和业务部门充分沟通后才能实现。但在前面的讨论中，也有一些地方确实指的是“事件”。 , @) n% ^ \( d 6 e: Y' o$ c8 l) a1 o% R
在新的ITIL V3中，对服务持续改进流程进行了定义，其中提出了服务改进的七步法流程：; x @% U; t v. n6 v0 L/ U
! H8 ]: _$ u, h0 o7 a
确定哪些需要衡量 : L; ^8 g; b K! P1 b( W明确哪些可以衡量: Y M( }4 m7 b* e
搜集数据 & z5 ~ _( Y9 S! G e5 \4 r处理数据7 r' J) }/ o8 ]( N4 U. Q& L9 h
分析数据 0 ]9 g# L$ ~ Z! v展示信息并使用信息) T% l) D& A5 K0 P
采取合适的措施 9 `3 ]) @. P4 A7 H 1 L1 |- A5 l" I) ?
在我看来，这简直就是对实现标签管理的精准描述。首先确定需要定义哪些标签；然后明确哪些标签是实际可行的，能为运维人员理解、接受和使用；对嵌入标签的事件流程进行搜集、处理和分析，由于有了标签，这一切都变得相当容易；展示结果，采取措施。3 l! ~1 o/ i( s& ?0 P* S' G
# q$ t$ F- S2 Z, y9 B; z如果我们把实现标签管理本身也作为一项服务，标签的增加、减少乃至重新定义也都可以通过这个流程来实现。 6 S3 \0 t( c& o 6 ~" T, `; k0 j或许还会有人提出疑问，一般的公司中IT事故对业务的影响并没有明示，大家也没有概念，IT自行计算是否有必要，数据是否应当公开，会不会给IT带来不好的影响？1 o6 U% y: h/ M" \( B! B6 Z6 U
- Z7 B; S" Y0 k/ F5 D4 I( Z
传说中鸵鸟会把头埋到沙子里，以躲避即将到来的危险，其实鸵鸟从来没这么做过，这么干的人倒是不少。在业务部门对IT的问题还没有忍无可忍的时候，主动把问题提出来，双方就可以逐步协商服务水平协议的细节。在前期这些肯定仅仅是参考，没人会真正拿出来说事，在合适的过渡期后，再进行有约束力的考核。1 Z+ s0 g x. p9 y
7 ]1 W% C/ h! r8 k0 N, s由于“IT黑洞”的存在，业务部门对IT一直心存不满，做出成绩的业务部门在总结成绩时也只会说领导有方，将士用命，IT只不过是那个“其它”而已。同样是这些人，在真的碰到IT导致的问题时，攻击IT却会不遗余力，在出现其它原因导致的问题时，第一个念头也是把责任推到IT身上。不是他们人品有问题，只不过是因为这样很方便罢了。7 c0 A a% {; S- c% \