將時間撥回三十年前的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 將很快就會到來。大路朝天，未來可期！