标签在运维管理中的应用（3）

就爱抬杠

变传统分类为标签管理，不仅仅是技术上的改变，更是管理思路上的更新。

# a% _% X7 s( |6 o2 a0 NIT管理其实就是服务管理，而IT服务管理的主要部分就是运维服务管理，这是用户的直接感受。并且，系统功能相对来说其实比较容易实现和考评，而保证一个长期、稳定、可持续、可评价和可调整的运维服务水平却不是一件简单的事。

7 {8 Y- _# L: b5 q& Q, k既然是服务，核心问题自然是结果的评价，所有的工作应当围绕这一目标展开，而结果评价的最终标准只能是来自客户，这样才符合面向客户，以客户为中心的原则。当然这里的客户指的是公司内部使用信息系统的内部员工，至于他们如何把服务好公司客户的目标分解到IT这部分来，那是另外一个问题。为了统一起见，在这里还是把这些“客户”称作“用户”。

在前面的运维管理杂谈系列中我曾提到过，这种评价的标准应当是“用户能理解，IT可计算”。说要面向用户，大家都不会反对，但我们在运维管理中实际上是怎么做的？即便传统的事件分类方式是IT内部使用，与用户无关，但分级却不是如此。一般来说，传统的事件分级无非是围绕着影响地域，持续时间，业务系统等几个维度来做，不能及时准确分级暂且不说，即便做到了，这些对用户又有什么意义？用户只关心系统能不能用，好不好用，对用户来说究竟有什么影响，其他的，都是IT内部的事情。

; s1 {; F+ P5 D这样一来，如果IT拿内部的分级标准去跟用户讨论时，就会遇到不小的困难。IT说影响只有这么短时间，范围也不大，但用户可能抱怨说业务已经受到了严重影响，客户感觉很不好；反过来也是成立的，IT已经很紧张了，用户可能还没什么感觉或者虽然有感觉也以为（或“误以为”）是其他原因，并没有觉得是IT的问题。即便这些都统一了，还会出现很多相同的事件分级下用户感受不同，或者相同的用户感受中事件分级不同的情况。

为什么不能拿用户感受直接作为事件分级的标准？
; ^  ^. a4 S- \9 `7 a
因为这用传统的方式是完全无法实现的。试想一下，一个事件产生，大家都在忙于处理，这时需要有这样一个人，他能及时对事件的本质作出明确的判断，对相似事件过去对业务的影响了如指掌，然后给事件做出正确的，面向用户的分级。且不说这样神一样的人存在不存在，即便存在，他的主要职责难道不应该是尽快去处理事件吗？
6 Q3 k. z4 I4 u7 |9 b. j& ]8 S
$ K) B. \  Y8 l" o4 X1 P7 P  q1 `但如果是用标签来管理事件情况就完全不一样了。我们完全可以和用户商定他们关心的主要指标，例如，用事件发生期间业务量的下降作为事件分级的唯一标准，5%一级，10%二级，20%三级等。当然，业务量是否真的下降，这个情况还是比较复杂的，不过我们可以用统计的方法，充分考虑历史同期的业务情况，考虑事件发生后业务回补的情况，而且这个方法还可以随着数据量的增长不断优化，越来越精确。

7 k; c: w0 ^% K( ]  Q8 F这样一来，事件发生以后，所有IT人员还是各做各的，不需要增加任何新的工作量。我们所要做的，就是在系统中增加一个统计的功能，在事件结束后根据对业务量的影响给事件定级，然后把相应的数据及事件的所有标签输入数据库。这时，系统自动计算，计算出带什么标签的事件是何种分级的概率。
' O2 {% u% o7 D; v
当数据积累到一定程度时，就不再需要等事件结束后再给事件定级了，系统可以自动进行预测，当某些特定标签组合出现时，从历史角度来看，50%的概率是一级事件，40%的概率是二级事件……系统也可以根据事先设定好的阈值，自动提升事件级别，保证存在重大隐患的事件得到及时快速处理。做运维管理的人都知道，能够提前发现隐患有多重要，但过去来说，这些主要只能靠技术人员个人经验的积累。
) o1 }5 `' {8 M! ?9 K" h. H
' t  p' ?' g- b- u3 q- \7 l; l. r知识库的积累和使用也是运维管理中的一个比较大的问题。一般的运维人员，对于知识库的重要性都会认同，也愿意在事件处理过程中或结束后进行记录和总结。即便有人不习惯或者不愿意，管理者跟踪和考核也比较方便。但是，在此之后要把这些输入知识库，就不是很多人愿意了。如何保证知识库的质量和数量，以及如何事后利用，就成为始终困扰管理者的问题。类似新浪爱问，百度知道那种方式，需要投入大量的资源，作为企业来说，其实不能也不必用。
2 R% G# j0 w1 }; m8 J1 x
如果用标签管理事件，这个问题就可以得到比较好的解决。运维人员不必做多余的工作，只需要按照要求及时填写运维表单，直至最后的事件总结分析。知识库的抽取是系统自动完成的，传统方式下困扰知识库管理人员的分类查找问题在标签模式下根本不存在，因为关键字都是知识内容自带的，早就预先设定好了。我们还可以把系统功能做出更多的拓展，例如可以在表单流转的相应点上系统自动弹出历史上带有相同标签的事件可能的原因和处理方法，处理结果等。这些工作不必等到表单流转完成再做，只要有标签，就可以做。如果在前端环节嫌可能性太多，则完全可以做出预先的设定过滤。
2 j% K6 D' ~, W0 _% j; \" c6 ]
8 B2 K5 ]3 @$ G$ z' n" P事后，还可以对系统处理的整个过程和各个环节的处理速度和处理质量进行评价。对内部人员的评价可以作为日后考核的依据，对外包人员，对服务厂商的评价可以作为合同付款的条件以及签订相应服务水平协议的依据。

就像自然语言的处理最终从基于规则转变到基于统计一样，运维事件的处理也可以从基于规则转变到基于统计，而且这种统计比自然语言处理要容易得多，因为可以有预先设定的关键字。从本质上来说，所有这一切的依据其实都来自于IT和用户签订的服务水平协议。前面提到过，服务水平协议应当做到“用户能理解，IT可计算”。事件的定级以用户为本就是做到了“用户能理解”，以标签管理为核心，改变预先设定的方式来给事件定级则是“IT可计算”的基础。

1 o* G( X  Q1 f' E4 l+ ^. N3 K; @

$ ~4 A' t$ K" x, U9 K! C6 |1 v/ o6 V$ S
% }: q8 j# U9 h2 ]4 b
) ]7 O9 l: d# f

: {6 m8 o% `* t. X$ Q! {: }: F% T8 |
% E- h4 o! U  k. W$ W