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

就爱抬杠

标签具有方便使用者的先天优势，其劣势则在于可能会定义不清，同义词难以分辨，效果高度依赖于算法的设计以及训练用语料库的选择等。然而在运维管理这一特定的领域中，这些劣势却都是可以避免的。

由于运维管理本身具有高度组织性，标签的选择和设定完全可以通过严格的流程来实现，这样一来，定义不清和同义词的问题就都可以解决了。如果还觉得给定的标签不够用，我们也可以把标签分为公共标签，个人标签，应用比较广泛，为大家所接受的个人标签可以通过一定流程升级为公共标签，反之也是成立的。
3 f  S# L6 }7 B7 @4 r
具体来说，我们可以设定一个标签集，每个人都可以在其中根据自己工作的特点，选择对自己来说最适用的标签子集。在一个事件的整个流程中，每个人都有权根据具体情况给事件贴上与自己的技术能力匹配的标签。和原有的分级分类有本质不同的是，标签不分级别，不分维度，使用者不需要一定选了“主机”的分类才能再去选“CPU故障”的分类，他完全可以贴上自己对事件性质的直接认定。例如作为前台使用者来说，只需要贴上某某系统慢或者某某系统服务中断的标签就可以了；一线的处理者如果对于事件性质有着非常明确的判断，他也完全可以直接贴上相应的标签，直接转入处理流程。

作为从事具体工作的技术人员，他的工作其实也遵从“二八定律”，20%的事件发生的概率有80%，其余的80%加在一起发生概率也只有20%。根据工作的具体情况，他可以选择给这20%的事件贴上一个直接标明性质的标签，而对于其余的80%不常发生的事件，则可以通过在事件处理流程中标签的不断完善来逐步界定。更具体的来说，他甚至可以为自己维护的几台主机创建专用的标签，只要他能说清那些标签到底有什么含义。

做到这里，贴标签或者说分类的过程几乎可以说已经简化到极致了，当然前提是大家都认为对事件正确分类是有必要。在传统的模式中，即使大家认识到正确分类的重要性，由于处理上的繁琐，很有可能造成分类上的垃圾数据，最终导致分析结果不准，对分类不认可，分析结果更不准......的恶性循环。

有了标签以后如何处理和应用？这就用到了在“数学之美”中提到的概率分析法，当然这种场景比自然语言的分析不知道要简单多少倍。其实，标签就是不分维度和级别的预先设定的关键字，有了含这么多关键字的数据，作为运维管理人员来说，可以进行多种多样的分析，处理起来是非常方便的。

上面说的是事后的处理和分析，其实标签本身还可以作为“预测”使用。对于运维管理来说，很重要的一个问题就是要快速恢复，而快速恢复的前提是对事件的快速反应，快速反应的前提则是准确定级，这样才能把好钢用在刀刃上，不松懈怠慢，也不草木皆兵。在传统的方式里，定级本身就是个大问题。前台人员缺乏经验和能力来准确定级，但流转到了后台那里，又往往失去了处理的最佳时机。还有，当短时间内事件重复发生时，可能就要对事件快速升级，但在传统方式里，如何能够准确快速地归并“重复事件”又是个让人头疼的问题，只靠前台人员的经验与责任心是远远不够的。
! o, h; z$ E8 G7 O- ^$ f/ L) S
5 B& L4 O( T; ?' }' H) P' w有了标签，就可以对事件进行概率分析。事件的准确定级在事后做当然是没有问题的，这样一来，我们就可以计算何种级别的事件通常都包括哪些标签，计算出当哪些标签出现时，出现何种级别事件的概率是多少。再给这种概率设定阈值，到达何种阈值就通知何种级别的人关注和处理。而且，在给定的信息系统内，这种计算的准确性会随着数据的积累而不断增加，只要做就有用，越做越有用。

值得注意的是，在上面提到的这个“预测”的过程中，唯一要求的就是同样的标签有着同样的含义，而对这个含义是否明确，是否为其他人所理解则没有任何要求。相比传统方式，对运维人员的专业要求可以说降低了不少。是训练不同基础和水平的人对同样的问题有同样的认识容易，还是告诉他们你们只要做到自己前后一致就可以了容易？这个问题的答案显而易见。
- f; \& `3 y  n: [; }
那么，是不是说事件的定级一定要这么做呢？可不可以直接定级呢？如果换个角度来看，事件的级别当然也是标签，只不过有权贴这个标签的人权限要求可能高些罢了，如果确实需要，直接定级完全没有问题。
  M* E' q2 F5 [) h; ]  X
! D$ P/ L, S+ u: b总之，在运维管理的应用范围内，标签就是不分维度和级别的预先设定的关键字。在运维支持系统中，如果在开发的时候就把标签作为缺省的要求做进去，即便大家都不习惯，想换回传统的模式，也完全没有问题。因为从这个意义上来说，传统模式不过就是分了维度和级别的关键字而已，只是标签模式的一个子集罢了。


0 ]9 g) Y4 Q$ B' d