将时间拨回三十年前的1989年，那一年第一家中国公司（中国银行）登上了世界500强的榜单，第一条横贯太平洋海底的光纤开通了，冷战时代的标志物柏林墙也倒塌了。在IT监控界Micromuse公司成立了，随后该公司推出的监控产品Netcool成为20世纪90年代和21世纪初领先的集中监控管理工具。在进入中国后就开始横扫中国IT界：四大行、四大运营商（还有网通的时代）几乎中国顶尖IT公司都在使用的这款产品。

遥想当年这套软件帮助了无数的IT组织管理它们的IT环境，提升维护效率，确保了业务的稳定。然而在过去40年里，IT环境发生了翻天覆地的变化。IT不再以蜗牛的速度来演进，各种新的应用程序和服务以令人眼花缭乱的速度不断的推出，同时云计算、容器、大数据、人工智能等技术的出现又再次加速这一步伐。逐渐的我们发现大量的IT事件层出不穷，业务服务无法得到保证。

到底为什么Netcool不能解决我的问题，它不再酷了呢？

“经典”的探针，完美兼容上个世纪的产品

Netcool的Probes提供了大量的开箱即用的数据采集能力，但是针对的对象都是北电，3com等上个世纪的产品。然而对某公司、华三等新兴厂商却鲜有提供，更不用说AWS、阿里云等新兴的云平台了。这主要是因为Netcool是从电信领域起家的，所以该公司致力于与电信设备的整合。在官网上搜索一下，你会发现一长串与朗讯、北电的开箱即用的集成清单，近几年也増加些某公司的设备，但除此之外就没什么了。你无法找到于当今流行的比如像zabbix，Cacti 等IT监控系统的集成。

当然也是由于2006年IBM Tivoli收购Micromuse后对该产品的集成拓展不足造成的。但根本的原因还是：Netcool的发明本来就是为了管理像交换机这种传统电信设备的。因此，如果你想监控朗讯5ESS交换机(当然前提是你现在还可以找的到)或支持3GPP协议的无线设备，那么Netcool是一个非常好的选择。但是如果您想管理一个现代的、基于云的IT环境，那就没有那么幸运了，这需要付出大量的成本来开发相关的系统集成接口。

不可维护的事件处理规则

现在，让我们假设你可以将相关监控工具进行集成，数据可以发送到Netcool中。那么你要如何对这些接入的事件进行去重、压缩、过滤和关联以减少告警噪音呢? 没错就是**写脚本！**如果您熟悉Netcool Omnibus，您可能知道规则文件是什么样的。它是一个庞大的代码集合，控制接入事件数据的处理。换句话说，Netcool希望您自己编写并维护自己的事件处理系统。

在过去，当我们在数据中心仅需要管理有限的设备时，这种方法很容易奏效。当时，IT环境一年到头都不会改变，所以大多数情况下，都不需要更改规则文件。然而，IT技术发展到今天，我们的监控事件出现了爆炸式增长，因为我们需要管理数百种不同且不断发展的应用程序和底层基础设施。靠编写脚本是不可能跟上的，原因是它成本太高、太容易出错，而且效率也太低了。

面向对象的事件处理设计

Netcool是为这样一个时代而设计的:“单节点集中计算的大型机，单一线路，IT和网络环境的任何问题都会造成很严重的影响，不能容忍任何故障”，主要面向的用户是系统和网络管理员。主要解决的将大量重复事件归并为单个可操作的告警。因此，需要使用过滤规则来减少噪音、自定义规则来对不同警报建模或关联在一起。

这种设计是一种面向对象的事件处理，而非面向服务的。虽然你可以再采购Tivoli TBSM工具，但是你辛苦地构建服务映射，并将它们导入Netcool Impact(同样需要单独采购)中，得到的也仅仅是一个服务与基础设施的关联视图，并不能显示事件对业务服务造成的影响也无法支撑进行根源定位。

但是现代事件管理系统已经不只是查看孤立的实时事件数据。而是需要通过关联类似的历史事件和CMDB关系来准确地确定事件的优先级，通过学习历史事件模式来预测未来事件，然后在这些模式重现时发出警报等高级能力，才能解决复杂IT环境带来事件风暴的挑战。

虽然，Netcool已经不再适应当今IT环境的发展了，但是仍然有大量IT组织无法痛下决心进行替换，每年总是修修补补自己开发一些新的功能，同时还付着昂贵的费用购买维保。

到底是什么原因造成了这种现象的呢？

1.缺少动因 得过且过

虽然面向服务的运维概念提出很多年了，但是绝大多数的运维团队还是面向单个事件的管理，这是因为IT规模刚刚进入爆发期，以事件为中心的运维管理体系还能勉强支撑，IT维护的团队会要求各个专业团队并行值班，业务出现问题每个团队分头定位，经常出现所有团队都没问题，但是业务服务就是不可用的现象。因为都是小问题，随便编个理由就推脱了。这种现象有点像是温水煮青蛙，没有出现严重的IT业务故障，他们是不会疼得从锅里跳出来的。

2.被事件规则绑架

大多数Netcool建设都在5年以上，积累了大量的事件处理规则，并且这些规则多是以代码形式存在的，鲜有说明。随着人员的更替，许多规则就算失效了但是也无人敢动，所以也就被“绑架”了，只能购买昂贵的维保服务不断地在老系统上进行持续更新。

3.沉默成本不愿舍弃

对于Netcool的上世纪UI风格大家普遍无法接受，绝大多数团队都在此基础上进行了定制化的开发。开发出来的交互大家已经习惯了，替换起来还需重新适应，团队又要走出舒适区，也就多一事不如少一事了。

除了以上IT组织内部的问题外，市场上缺乏可替代产品也是非常重要的因素。虽然近几年各种IT运维软件层出不穷，DEVOPS、AIOPS、NOOPS各种理念也不断推出，但是真正专注到监控，定位在集中事件处理上的却非常少见。对于事件处理的功能大多数软件都是兼职进行，无论是事件丰富、压缩、过滤等基本功能，还是事件聚类、影响分析、根因定位等高阶能力都是缺失的。

到底一款什么样的产品才能在适应IT发展带来的挑战，又能降低IT组织替换Netcool的风险呢？

面向工具的集成能力

作为新一代的集中监控平台，定位是对监控数据的汇聚和集中处理，而不是基础数据的采集。因此需要具备强大的工具集成能力，不仅能够提供市场主流的监控工具和IT管理平台开箱即用的集成，还应该支持丰富的接口协议，可以灵活的集成各种自行开发的监控工具。

事件规则可维护能力

在当今AI机器学习尚不成熟的情况下，在集中事件处理过程中，基于规则的事件处理仍然占据主导。但是新一代事件平台，决不能走脚本化规则配置的老路，要让事件处理规则配置能够零门槛，任何人都可以维护。如果要做到可维护，首先就需要能够让人易于理解，使用人类语言而非机器语言；其次，需要提供规则的统计分析，让维护人员掌握每条规则的使用情况；再次，定义处理规则后能够进行快速验证，包括验证触发条件，以及处理的结果数据；最后，事件被规则处理的过程应该是可追溯的，每条告警事件可以清晰的看到是被哪些规则所影响。

面向服务故障管理能力

所谓的面向服务的故障管理能力，系统需要能够从业务服务的维度，将孤立的各个领域的事件进行聚类，后续机器处理是指可以输出给专业的系统进行处理，例如：输出给智能运维平台进行根因分析计算；让人处理就不仅仅是将所有事件打组展示，而更需要提供一系例的故障定位和分析工具，能够从时间和架构等各个维度提供数据的交互展示能力，便于故障的快速定位。

持续运营的产品能力

正所谓，冰冻三尺非一日之寒，集中监控的建设也并不是一蹴而就的，建设得好仅仅是开始，还需要持续不断的运营优化。但是如何运营呢？最基本的是对系统不断测量与优化，向系统业务目标不断推进。而集中监控的目标应该是：“及时准确告警与高效快速排障”，所以要想运营好集中监控系统，就需要针对这些目标定义出测量指标。例如：告警的准确性可以从监控的漏报率、误报率、派单率等维度建立；而高效快速排障则可以从故障发现时长、响应时长、定位时长等维度进行衡量。然而这些指标靠人工进行统计与分析是不可持续的，就需要新一代监控产品具备在线的指标统计和分析能力，并且根据分析结果给出进一步的建议以不断优化，从而不断提升告警的准确性与及时性，加快故障排查的速度与效率。

当然除了以上这些能力外，集中事件平台的事件丰富、压缩、过滤等能力也是必备的，灵活的事件通知能力以及开放的系统接口都是基本能力。

相信随着国内IT组织的不断壮大，国产软件的创新能力不断增强，中国的Netcool 将很快就会到来。大路朝天，未来可期！