基于用戶體驗的信息系統(tǒng)主動運維平臺

吳 舜 ，許大衛(wèi) ，魏 征 ，胡成臣 ，向萬紅 ，郭 前 ，唐亞哲

（1.國網(wǎng)冀北電力有限公司信息通信分公司 北京 100053；2.西安交通大學(xué) 西安 710049；3.遠光軟件股份有限公司 珠海 519085；4.南京云帕信息技術(shù)有限公司 南京 211100）

1 引言

在電網(wǎng)企業(yè)信息系統(tǒng)運維實踐中，即使配置、部署了各種各樣的監(jiān)控系統(tǒng)，也常有業(yè)務(wù)系統(tǒng)出現(xiàn)問題卻怎么也找不到故障點的情況。究其原因，主要是當(dāng)前大部分監(jiān)控系統(tǒng)是分離地監(jiān)控業(yè)務(wù)系統(tǒng)組成部分的工作狀態(tài) （如網(wǎng)絡(luò)、服務(wù)器、數(shù)據(jù)庫等），并且這些監(jiān)控的級別很低，沒有區(qū)分用戶和業(yè)務(wù)，也沒有從業(yè)務(wù)系統(tǒng)本身的工作狀態(tài)尋找原因。尤其在網(wǎng)絡(luò)環(huán)境下，僅知道某個交換機端口的吞吐率或者分組丟失率，很難發(fā)現(xiàn)某個業(yè)務(wù)運行不正常的原因。本文的工作目標(biāo)是解決上述問題，通過監(jiān)控業(yè)務(wù)系統(tǒng)尤其是網(wǎng)絡(luò)中運行的業(yè)務(wù)系統(tǒng)的通信行為，實現(xiàn)基于用戶體驗的主動運維。

通常，一個業(yè)務(wù)系統(tǒng)具有針對某個具體業(yè)務(wù)的多種功能，如財務(wù)系統(tǒng)通常會有各種報賬、查詢等。作為終端用戶的財務(wù)統(tǒng)計人員，直接操作在業(yè)務(wù)系統(tǒng)上，便發(fā)生了對應(yīng)于各種功能的操作，定義這些操作為相應(yīng)的此業(yè)務(wù)系統(tǒng)上的用戶行為。

在業(yè)務(wù)系統(tǒng)的實際運行中，行為的響應(yīng)速度直接反映了用戶業(yè)務(wù)運行是否正常，也影響著終端用戶的用戶體驗，過長的響應(yīng)時間（出現(xiàn)故障時甚至導(dǎo)致響應(yīng)時間無限長）將直接導(dǎo)致用戶使用系統(tǒng)時的不適。例如，用戶點擊“已完成單據(jù)查詢”，在多長時間之后業(yè)務(wù)系統(tǒng)做出響應(yīng)并展示出相應(yīng)的結(jié)果，直接影響著業(yè)務(wù)系統(tǒng)的用戶體驗滿意度。

作為業(yè)務(wù)系統(tǒng)的運維人員，需要在用戶體驗下降時及時發(fā)現(xiàn)終端用戶在使用業(yè)務(wù)系統(tǒng)時存在的問題，這就要求運維人員能通過某種方式實時了解用戶對業(yè)務(wù)系統(tǒng)的使用情況，并且對用戶滿意度進行評估，出現(xiàn)問題時及時解決。

本文提出的主動運維平臺通過對業(yè)務(wù)系統(tǒng)的實時監(jiān)控，以用戶發(fā)生各種行為時產(chǎn)生的流量為輸入，借助細粒度網(wǎng)絡(luò)流量分析方法識別出每個用戶行為，并且給出用戶發(fā)生此行為的響應(yīng)時間，也就是用戶行為性能，幫助運維人員及時發(fā)現(xiàn)系統(tǒng)存在的問題，提供優(yōu)化業(yè)務(wù)系統(tǒng)的依據(jù)，提高用戶體驗。

2 系統(tǒng)設(shè)計

針對引言中提出的功能需求，本平臺采用自頂向下的設(shè)計思路，要得到用戶發(fā)生某個行為的響應(yīng)時間，就需要知道在用戶發(fā)生此行為對應(yīng)的流量中，最開始和最末尾部分流量的時間點，二者之間的差值就是用戶在此行為上的體驗時間。而在通常情況下，系統(tǒng)獲取到的網(wǎng)絡(luò)流量是各個用戶各個行為產(chǎn)生流量的混合體，所以在上述層次之下便是如何識別出特定用戶行為的流量，故系統(tǒng)最終設(shè)計為一種上下雙層結(jié)構(gòu)。

2.1 行為性能測量

本文提出的主動運維平臺以監(jiān)聽的方式實施，通過監(jiān)聽用戶流量，識別分析用戶行為，度量行為的時間，最終實現(xiàn)對業(yè)務(wù)系統(tǒng)的實時監(jiān)控。

運維平臺在網(wǎng)絡(luò)中部署的典型拓撲如圖1所示，平臺串接在網(wǎng)絡(luò)之中，以用戶發(fā)生各種行為時的流量和內(nèi)置規(guī)則庫作為輸入，如圖2所示，最終得到的輸出便為識別出的用戶行為以及每個行為的用戶體驗時間。

圖1 智能運維平臺在網(wǎng)絡(luò)中的位置

圖2 平臺輸入輸出示意

本平臺測量的目標(biāo)系統(tǒng)是電網(wǎng)企業(yè)信息系統(tǒng)典型的B/S架構(gòu)的客戶端，特點是使用HTTP請求和響應(yīng)與服務(wù)器進行交互。需要注意的是，在本平臺中最后得到的是某個行為的用戶體驗時間，而不是行為發(fā)生時某個HTTP請求和其響應(yīng)之間的耗時，故在本平臺對于用戶發(fā)生某個行為時產(chǎn)生的一大批HTTP請求和響應(yīng)中，取最開始和最后的請求響應(yīng)對，并且計算第一個請求響應(yīng)對的請求時間點到最后一個請求響應(yīng)對的響應(yīng)時間點的時間差，從而判斷用戶從最開始發(fā)生此行為一直到行為完成的耗時，也就是用戶體驗時間。例如，當(dāng)用戶在某財務(wù)系統(tǒng)上點擊“已完成單據(jù)查詢”鏈接時，會產(chǎn)生一系列HTTP請求與響應(yīng)，在本系統(tǒng)的研究中，只取具有先后順序的HTTP請求和響應(yīng)，如圖3所示。

圖3 一個行為產(chǎn)生的HTTP請求和響應(yīng)

為描述方便，本文使用字母表示發(fā)生的HTTP請求響應(yīng)對，圖3中最開始的圓A代表第一個請求響應(yīng)對，最后的圓Z代表最后一個請求響應(yīng)對，本運維平臺首先識別出圓A，記錄下圓A的請求和響應(yīng)時間戳，之后只需要識別出期望的圓Z，并且記錄下圓Z的請求時間戳和響應(yīng)時間戳，用圓Z的響應(yīng)時間戳減去圓A的請求時間戳就是此行為的用戶體驗時間，如式（1）所示。

在圖3中，本平臺對于“已完成單據(jù)查詢”行為，只需要依次捕捉請求響應(yīng)對A和Z的到來，對于其他如請求響應(yīng)對B、C，放過即可。通過可配置的規(guī)則來決定對于某個行為，平臺需要捕獲到哪兩個請求響應(yīng)對。換句話說，規(guī)定平臺需要關(guān)聯(lián)哪兩個請求響應(yīng)對才能識別一個行為，并且得到這個行為的用戶體驗時間，將這種可配置的規(guī)則稱為關(guān)聯(lián)分析規(guī)則，規(guī)則樣例見表1。

表1 關(guān)聯(lián)分析規(guī)則樣例

綜上所述，本平臺以請求響應(yīng)對A、B、C等作為待關(guān)聯(lián)數(shù)據(jù)輸入，以可配置的關(guān)聯(lián)分析規(guī)則作為規(guī)則輸入，最終得到用戶發(fā)生的行為以及用戶體驗時長。也就是說，請求響應(yīng)對A、B、C是底層提供給上層的服務(wù)數(shù)據(jù)，同TCP/IP網(wǎng)絡(luò)的分層原理一樣，將這一層稱為關(guān)聯(lián)分析層。顯然，像請求響應(yīng)對A、B、C這樣的請求響應(yīng)對，并不是直接可以從網(wǎng)絡(luò)中不做任何處理就可以獲取到的，在第3節(jié)中將敘述如何獲得請求響應(yīng)對A、B、C。

2.2 請求響應(yīng)對識別

像A、B、C這樣的請求響應(yīng)對，在本平臺中一般代表某個特定行為的開始或結(jié)束，因此是具有特定語義的，稱本層為語義抓取層。語義抓取層為關(guān)聯(lián)分析層提供具有語義特性的請求響應(yīng)對，供上層進行關(guān)聯(lián)分析，也就是為上層提供服務(wù)數(shù)據(jù)。

如前所述，用戶在點擊“已完成單據(jù)查詢”時，會產(chǎn)生一系列HTTP請求和響應(yīng)，該層應(yīng)該如何區(qū)分不同的HTTP請求和響應(yīng)是一個問題。在本層使用語義抓取規(guī)則，規(guī)定滿足特定條件的HTTP請求和響應(yīng)才是特定的請求響應(yīng)對A或者其他。例如表2中的語義抓取規(guī)則，其中第一條規(guī)則規(guī)定：HTTP請求中URI的字段值與正則表達式“Ywdjywc.*”匹配，HTTP請求中 referer的字段值與正則表達式 “index.jsp”匹配，同時服務(wù)器對這個HTTP請求的響應(yīng)數(shù)據(jù)與正則表達式“ywc_data”匹配，如果這3個正則表達式都可以匹配到，則認(rèn)為捕獲到了A請求響應(yīng)對，之后將其輸出到一張按用戶IP地址分開的表中，見表3。表3作為語義抓取層的輸出、關(guān)聯(lián)分析層的輸入，由語義分析層提供給關(guān)聯(lián)分析層，之后由關(guān)聯(lián)分析層進行關(guān)聯(lián)分析。

表2 語義抓取規(guī)則樣例

表3 語義抓取層輸出樣例

綜上所述，語義抓取層的輸入為用戶操作業(yè)務(wù)系統(tǒng)時產(chǎn)生的一系列HTTP請求和響應(yīng)，也就是網(wǎng)絡(luò)中的原始流量以及一張內(nèi)置的語義抓取規(guī)則表，輸出為提供給上層的關(guān)聯(lián)分析數(shù)據(jù)，也就是請求響應(yīng)對。

因此，整個平臺最終分為兩層：關(guān)聯(lián)分析層和語義抓取層。兩層的輸入、輸出及相互間的關(guān)系可用圖4表示。自底向上，首先語義抓取層將用戶產(chǎn)生的流量與語義抓取層規(guī)則庫進行匹配，得到的輸出為每個用戶產(chǎn)生的不同請求響應(yīng)對；而語義抓取層的輸出作為關(guān)聯(lián)分析層的輸入，關(guān)聯(lián)分析層將下層提供的輸入數(shù)據(jù)與關(guān)聯(lián)分析規(guī)則庫進行關(guān)聯(lián)分析，最終得到識別出的用戶行為及每個行為的用戶體驗滿意度。

圖4 系統(tǒng)分層架構(gòu)設(shè)計

3 關(guān)鍵技術(shù)實現(xiàn)

如第2節(jié)所述，要得到用戶發(fā)生某個行為的響應(yīng)時間，就需要知道在用戶發(fā)生此行為對應(yīng)的流量中，最開始和最末尾部分流量片段的時間點，二者之間的差值就是用戶在此行為上的體驗時間。在系統(tǒng)的實現(xiàn)過程中，同一個用戶在一段時間內(nèi)會發(fā)生多個行為，而每個行為由行為開始和行為結(jié)束兩部分組成，因此，多個行為之間的開始和結(jié)束在時間上會發(fā)生覆疊，記行為1的開始時間為t1，結(jié)束時間為 t2，行為2的開始時間為 t3，結(jié)束時間為 t4，上述問題可以描述為t1

針對上述情況，本平臺在實現(xiàn)中采用了一種保存用戶行為上下文的辦法，即用戶行為候選表。這張表中保存了用戶一段時間內(nèi)可能會發(fā)生的所有行為，例如，當(dāng)系統(tǒng)在t1時刻檢測到行為1的開始時，便在用戶行為候選表中加入行為1，并且記錄時間點t1。同樣，隨后系統(tǒng)會在用戶行為候選表中加入行為2，并記錄時間點t3。對于后面t2時刻到來的行為1結(jié)束點，只需要查找用戶行為候選表便可以命中行為1，并且得到行為1的用戶體驗時間。同理，可繼續(xù)命中行為2并且得到其用戶體驗時間。系統(tǒng)的關(guān)鍵實現(xiàn)在于用戶行為體驗時間測量算法，具體計算過程如下。

輸入：用戶請求響應(yīng)對標(biāo)識碼表（表3）、關(guān)聯(lián)分析規(guī)則表（表 1）。

輸出：用戶行為體驗耗時。

1：從用戶請求響應(yīng)對標(biāo)識碼表中取出一個IP地址和其對應(yīng)的請求相應(yīng)對標(biāo)識碼，如（192.168.0.1，A）；

2：使用3中的標(biāo)識碼在用戶行為候選表中匹配用戶的候選行為；

3：if命中某個候選行為

4：then輸出得到的用戶行為并且計算此行為的體驗耗時；

5：刪除此候選行為；

6：else

7：使用3中標(biāo)識碼查找關(guān)聯(lián)分析規(guī)則表；

8：if查找到可能的用戶行為

9：then將查找到的用戶行為加入用戶行為候選表；

10：記錄行為的開始時間等信息；

11：else

12：丟棄此次的請求相應(yīng)對標(biāo)識碼；

13：end if

14：end if

15：返回至步驟1

4 實驗結(jié)果

4.1 功能測試

本平臺按照如圖1所示的拓撲在某電網(wǎng)企業(yè)財務(wù)系統(tǒng)進行了測試，根據(jù)最終得到的輸出統(tǒng)計出用戶體驗時間最長的10種行為，并且給出了每種行為的用戶體驗時間，如圖5所示。

圖5 某財務(wù)系統(tǒng)行為性能統(tǒng)計

從圖5可以看出，在這個財務(wù)系統(tǒng)中最慢的行為是“進入系統(tǒng)”行為，這說明這個行為的用戶體驗較差，用戶登錄后進入系統(tǒng)可能從服務(wù)器加載了大量數(shù)據(jù)，從而導(dǎo)致服務(wù)器響應(yīng)過慢；或者網(wǎng)絡(luò)負載過重，使得數(shù)據(jù)傳輸過慢；也可能是使用了不合理的SQL查詢、服務(wù)器負載過重等?？傊\維人員可以通過這種方式實時監(jiān)控系統(tǒng)中用戶在業(yè)務(wù)系統(tǒng)上各個行為的體驗，對有問題的行為進行專項優(yōu)化。

4.2 吞吐率測試

對吞吐率進行測試，在平臺上使用離線流量進行測試。具體來說，針對不同大小、不同比例的混合流量進行處理，根據(jù)最終處理完整個離線流量的時間來計算平臺的吞吐率。由于本平臺的目標(biāo)流量是某財務(wù)管控系統(tǒng)流量，故將純目標(biāo)流量與其他無關(guān)流量進行不同比例的混合，最終得到5種離線流量，見表4。測試結(jié)果即在不同比例流量下的不同吞吐率。

表4 不同比例的混合流量

圖6為在5種不同混合流量下測試得到的系統(tǒng)吞吐率。可以看出，從流量1到流量5吞吐率逐漸變高，這是因為無關(guān)流量的增加并不會增加本系統(tǒng)的負荷，本系統(tǒng)只對流量中的目標(biāo)流量進行處理，從而表現(xiàn)出系統(tǒng)吞吐率的升高。一般情況下，網(wǎng)絡(luò)中的流量不會總是無關(guān)流量或者目標(biāo)流量，所以采取混合流量的方法進行測試是十分合理的。

圖6 不同混合流量下測試得到的系統(tǒng)吞吐率

4.3 內(nèi)存測試

對設(shè)備進行長時間的模擬在線環(huán)境測試，將目標(biāo)流量從另外一臺設(shè)備打入本平臺，監(jiān)控系統(tǒng)的內(nèi)存使用情況，測試系統(tǒng)的穩(wěn)定性，圖7是系統(tǒng)運行72 h內(nèi)存的變化情況。圖7中有兩條線是因為本系統(tǒng)運行時需要兩個例程?？梢钥闯?，系統(tǒng)的內(nèi)存開銷很低，并且運行穩(wěn)定。

5 結(jié)束語

圖7 系統(tǒng)運行72 h內(nèi)存占用情況

本文提出了一種識別用戶行為并且測量用戶行為體驗的方法，同時將其平臺化，幫助運維人員定位業(yè)務(wù)系統(tǒng)中存在的缺陷。使得運維人員在用戶體驗下降時，及時發(fā)現(xiàn)終端用戶在使用業(yè)務(wù)系統(tǒng)時存在的問題，運維人員通過這種方式實時監(jiān)控系統(tǒng)中用戶在業(yè)務(wù)系統(tǒng)上各個行為的體驗，對有問題的行為進行專項優(yōu)化。

本文的創(chuàng)新主要有以下幾點。

（1）本平臺相比于傳統(tǒng)的服務(wù)器端監(jiān)控，創(chuàng)新性地實現(xiàn)了與之相對應(yīng)的用戶端體驗監(jiān)控，多維度的監(jiān)控提供了更有力的運維信息。

（2）本平臺將用戶體驗監(jiān)控與系統(tǒng)組件監(jiān)控有機結(jié)合起來，更細粒度地分析出發(fā)生故障時是在哪個組件上、因為哪種用戶行為導(dǎo)致組件運行出現(xiàn)問題。

（3）本平臺不但進行用戶行為識別，并且測量每個用戶行為的用戶體驗時間，為運維人員提供強有力的故障追蹤及優(yōu)化依據(jù)。

（4）本平臺以旁路的方式監(jiān)聽網(wǎng)絡(luò)流量，無需在用戶一端安裝任何軟件等，對用戶使用業(yè)務(wù)系統(tǒng)完全無干擾。

（5）本平臺的設(shè)計采用典型的分層設(shè)計，極大地減少了系統(tǒng)各模塊之間的耦合性，從而使得開發(fā)與開發(fā)、開發(fā)與測試、測試與測試之間都可以互不干擾地進行，極大推動了項目進度。

本文的關(guān)鍵技術(shù)在于通過監(jiān)聽用戶流量、識別分析用戶行為、測量行為的體驗時間，最終實現(xiàn)對業(yè)務(wù)系統(tǒng)的實時監(jiān)控。本平臺以用戶發(fā)生各種行為時的流量和內(nèi)置規(guī)則庫作為輸入，計算第一個請求響應(yīng)對的請求時間點到最后一個請求響應(yīng)對的響應(yīng)時間點的時間差，從而計算用戶體驗時間，最終得到的輸出便為識別出的用戶行為以及每個行為的用戶體驗時間。

本平臺下一步還需要對除了HTTP之外的其他協(xié)議進行功能方面的擴展，以滿足不同的應(yīng)用場景。在性能方面，本文已經(jīng)探究出更快速的語義抓取算法，目前正在整合中，之后可以支持更多用戶、更復(fù)雜的系統(tǒng)監(jiān)控。

1 Chen Y,Mahajan R,Sridharan B,et al.A provider-side view of web search response time.Proceedings of the ACM SIGCOMM,Hong Kong,China,2013:243～254

2 Cherkasova L,Gardner R.Measuring CPU overhead for I/O processing in the Xen virtual machine monitor.Proceeding of USENIX Annual Technical Conference,Boston,MA,USA,2005:387～390

3 Hassidim A,Raz D,Segalov M,et al.Network utilization:the flow view.Proceedings of IEEE INFOCOM,Turin，Italy,2013:1429～1437

4 Meyer T,Wohlfart F,Raumer D,et al.Measurement and simulation of high-performance packet processing in software routers. Proceedings of Leistungs-, Zuverl覿ssigkeits- und Verl覿sslichkeitsbewertung von Kommunikationsnetzen und Verteilten Systemen,GI/ITG-Workshop MMBnet,2013

5 Balachandran A,Voelker G M,Bahl P,et al.Characterizing user behavior and network performance in a public wireless LAN.ACM SIGMETRICS Performance Evaluation Review,2002,30(1):195～205

6 Li H,Hu C C.ROOM:rule organized optimal matching for fine-grained traffic identification.Proceedings of IEEE INFOCOM,Turin,Italy,2013

7 吳舜,蘇丹,吳佳等.基于 Tilera平臺的網(wǎng)絡(luò)細粒度應(yīng)用行為識別.電信科學(xué),2013,29(11):94～98

Wu S,Su D,Wu J,etal.Fine-grained network traffic identification based on tilera platform.Telecommunications Science,2013,29(11):94～98

8 朱凱,張超,張凱等.基于TCP數(shù)據(jù)包層分析的移動互聯(lián)網(wǎng)用戶體驗的評估方法.北京郵電大學(xué)學(xué)報,2014,37(s2):40～45

Zhu K,Zhang C,Zhang K,et al.Assessment of user’s QoE for mobile internet based on TCP packet layer analysis.Journal of Beijing University of Posts and Telecommunications,2014,37(s2):40～45

9 Viswanath B,Bashir M A,Crovella M,et al.Towards detecting anomalous user behavior in online social networks.Proceedings of the 23rd USENIX Security Symposium,San Diego,CA,USA,2014

10 Barford P,Plonka D.Characteristics of network traffic flow anomalies.Proceedings of the 1st ACM SIGCOMM Workshop on Internet Measurement,San Francisco,USA,2001:69～73