IT透視三步曲（AMT 王艷編譯）

圖1展示了經(jīng)典的銀行事件模式，即竊賊們在竊取口令進入帳戶后所做的事情。我們可以看到在帳戶上的事件活動模式，在一段很短的時間里，發(fā)生了先是登陸，緊接著是密碼修改，然后是一個新的自動支付命令。圖2中這種模式的兩個例子發(fā)生在不同的背景下。第一個例子中，三件事是直接一個接一個發(fā)生的。而在第二個例子中，三件事兩兩之間會有一次帳戶余額查詢。事實上，在三件事之間還可能會出現(xiàn)其它的一些操作，但是只要這三個關(guān)鍵事件在很短的時間里都出現(xiàn)了，我們就應該把它們標記為可疑事件。例如，一個竊賊可能會先登陸修改密碼后退出。然后過一會又會登陸執(zhí)行一個新的自動支付命令。為何中間間隔的時間如此之短？因為竊賊們想要在別人注意到帳戶被盜之前快點執(zhí)行轉(zhuǎn)移支付。

圖1展示了針對可疑的銀行活動監(jiān)控器應該能做點什么。它必須能夠檢測一系列不同背景的連環(huán)（此例中為三個）關(guān)鍵事件，如果它們之間的時間間隔很短，那么創(chuàng)建一個警報事件。監(jiān)控器監(jiān)控到可疑的帳戶活動時，我們要求其要檢測出不同背景和不同時機下的一些與可疑事件相類似的事件模式。在一些撲朔迷離的情況里，可疑的活動可能會同時涉及到好幾個帳戶，因此這時的事件模式不會是在一個時間間隔下的簡單事件序列，而是長期在幾個帳戶之間所進行的并發(fā)且相互關(guān)聯(lián)的一系列事件。然而，針對檢測網(wǎng)上銀行盜竊案例和核實轉(zhuǎn)帳來說，在我們圖上所展示的這種監(jiān)控簡單系列事件模式的能力已經(jīng)算是一個不錯的開始了。

針對該銀行案例，我想指出一點，一個事件模式通常包括：

• 幾個事件，它們中的一些可能共享公用的數(shù)據(jù)元素。
• 這些事件可能需要以一個特定的順序出現(xiàn)，可能允許不屬于這種模式的事件在模式事件兩兩之間出現(xiàn)。
• 此模式中的一些事件可能獨立發(fā)生，也可能以任意的順序發(fā)生，而模式的另一些事件可能要先有前奏才會發(fā)生。
• 可能在一定的時間間隔后，一些事件一定會發(fā)生，并且這些事件會對數(shù)據(jù)做一些限制。

事件的模式可能會變得十分復雜。而且要完整地表示它們需要很詳盡地描述。因此IT透視的第一步是要求制定一條精確的事件模式描述。

軟件科學家們在用程序設計語言來做與此相似的事情已有四十年了。計算機科學家們也幾乎一直在開辟事件和時間選擇邏輯的理論。因此這一步并不難，不需要一些非常新的科學。只要去做就好了。

第二步：檢測事件模式

電子商務正卯足了勁加速前進。在過去，企業(yè)之間要花上一個星期或更多時間來進行交易，而現(xiàn)在只要數(shù)個小時就可以了。因此企業(yè)的管理也要與時俱進，而且需要靠這些工具來實現(xiàn)。

在全球事件云中，事件模式匹配是模式檢測所需的最基本的技術(shù)。這項技術(shù)至今仍在襁褓之中。業(yè)務活動監(jiān)控的趨勢是：制定模式檢測引擎來監(jiān)控涉及到幾個事件（包括順序事件、間隔事件以及并發(fā)事件）的復雜模式。對一些應用軟件來說，在調(diào)度過程（所謂的執(zhí)行的可量測性）中，模式匹配執(zhí)行的速度變得至關(guān)重要?？闪繙y性包含了三個維度，待檢測模式的數(shù)量，事件進入事件云所伴隨的速度，以及時間。

事件模式檢測引擎的一個好的基準目標可能會是每秒以逐千個模式的速度進行測試：即監(jiān)控一千個不同事件模式的能力，這些模式的復雜性與我們的銀行案例相似，即一個事件云以每秒一千個的速度在產(chǎn)生新事件。

這是一個極富挑戰(zhàn)性的基準，但是這樣的技術(shù)就要成功了。同時，許多地區(qū)的電子商務都可能通過性能略遜一疇的事件模式檢測引擎來實現(xiàn)IT透視。

第三步：事件模式提取

IT透視的這一步是向前——或向上的一次最大飛越！

就執(zhí)行事件處理的新人來說，事件模式可能會亮出足夠的復雜度來挑釁新人們的理解能力。而他們?yōu)楹螒撔枰嬲チ私膺@些模式——因為他們在管理業(yè)務時感到太吃力了！要實現(xiàn)IT透視，就要將IT層里的事件模式所包含的信息傳達給企業(yè)中各司其職的人員。傳達前要將事件模式的數(shù)據(jù)聚集并進行提取。

例如，圖2展示了一個交易案例，其涉及到四個企業(yè)，一個買方，一個賣方，一個拍賣機構(gòu)以及一個結(jié)算機構(gòu)。本質(zhì)上我們是在分析一個電子商場或電子供應鏈中的事件活動。這些事件包括買方向拍賣機構(gòu)提出產(chǎn)品申請。賣方單獨進入拍賣機構(gòu)的目錄。這兩個事件使拍賣機構(gòu)能告知買方可能符合其要求的產(chǎn)品。因此，買方可以向賣方發(fā)送一個接受信息并向拍賣機構(gòu)詢價。然后拍賣機構(gòu)向賣方和結(jié)算機構(gòu)發(fā)送開始結(jié)算事件，這樣就進入了交易的結(jié)算階段，這之后，由結(jié)算機構(gòu)充當中間人來完成買方和賣方之間產(chǎn)品和款項的交換。這個模式案例展示了交易層事件之間的因果和時間關(guān)系。

您真的不想看到象這樣的事件模式，是嗎？

四個企業(yè)中任何一個企業(yè)的業(yè)務管理人員都不想在一次談判中就完成所有的交流事件。實際上若牽涉到幾個買方和賣方，詳情可能會比這個案例還要復雜得多。針對這種交易，管理者們想各自提取與他們在公司的職責相關(guān)的事件模式。就拿CFO來說吧，他可能只想知道產(chǎn)品的資料，價錢，支付額。而且他可能想在交易成功發(fā)生時，將每一次交易的數(shù)據(jù)都匯入到他的總分析表中。另一方面，就這一相同事件模式來說一個IT管理者可能要的資料與上面截然不同，他想要的是對此交易提供的IT支持方面的時間資料，尤其是出現(xiàn)了如果另一方對緩慢的回復有所不滿的情況。

提取的任務是按各管理者所需將此交易層的相關(guān)事件分別傳送給他們。我們通過創(chuàng)建新的事件（根據(jù)交易層模式計算而來，并且它們涵蓋了提取資料）來實現(xiàn)這個任務。并且我們把它們視作較高層事件。圖4展示了提取的概念。

那些幾近完成但似乎慢下來或拋錨的交易的提取也同樣重要。例如，一次交易進行到結(jié)算階段但是花的時間遠遠超過正常的完成時間。原因何在？是不是有些交易事件顯示出現(xiàn)了一個競爭者以一個較好的價錢進入交易？通過向買方提供折扣是否能完成結(jié)算？這是一個依賴于事件檢測模式的實時交易。

事件模式集聚和提取其功能是為了向您大致介紹您所需要的IT層事件云。為使同一事件模式案例的不同提取資料能在同一時間傳達給不同的人，我們傳送事件模式提取請求的技術(shù)必須要很靈活。

目前事件模式集聚和提取的技術(shù)尚在雛形階段。人們還要求它有處理復雜事件的能力，這樣它在功能上真的會遠遠超越BAM。我相信這樣的初始產(chǎn)品可能會在2004年的秋天問世。

總而言之，IT透視的三個步驟是：

1．詳細描述事件模式。
2．可升級執(zhí)行型事件模式匹配。
3．事件模式集聚和提取。

我們即將要實現(xiàn)IT透視，并且實現(xiàn)的速度快得令人匪夷所思。2003年，我們還在討論，要制定出商業(yè)工具來實現(xiàn)基于事件處理的IT透視，這到底需要花多少時間，我們還以為整個行業(yè)起碼要過個十年才能走完這三步?，F(xiàn)在，到了2004年，看來這三步五年內(nèi)就能大功告成了。光陰荏苒，不久的一天，我們都能買到IT透視產(chǎn)品，并用它們來深入了解我們當代所有的企業(yè)都在做何忙碌。