作者介紹

朱祥磊，山東移動BOSS系統(tǒng)架構師，負責業(yè)務支撐系統(tǒng)架構規(guī)劃和建設。獲國家級創(chuàng)新獎1項、通信行業(yè)級科技進步獎2項、移動集團級業(yè)務服務創(chuàng)新獎3項，申請發(fā)明專利13項。

工具篇：構建可視化分布式運維手段

工欲善其事，必先利其器。上篇我們已經(jīng)詳細分享了監(jiān)控相關的知識，然而運維可視化，除了構造可視化監(jiān)控外，還要建立相應的運維手段，云化下的運維工具和傳統(tǒng)架構的有較大不同，對集群式、分布式提出了更高的要求。

1、自動化巡檢

從2011年開始推行巡檢，最初，我們的武器僅僅是一個word文檔、一些excel表格和大量的SHELL腳本，檢查靠人工敲擊命令或者查看表數(shù)據(jù)，內(nèi)容也多數(shù)都僅限于日常維護中已經(jīng)存在的主機，數(shù)據(jù)庫，中間件，進程狀態(tài)等，執(zhí)行效率較差，并且未真正涉及業(yè)務類的健康檢查。

從2014年12月開始，正式引入自動化巡檢工具，工具對原來積累的腳本進行整合，提供可視化操作局面，能夠定期自動執(zhí)行、自動生成巡檢分析報告，巡檢內(nèi)容涵蓋主機、數(shù)據(jù)庫、中間件、應用在內(nèi)的所有監(jiān)控對象，并且隨著巡檢的深入，在2015年起又增加了業(yè)務級別的巡檢內(nèi)容，對于一些關鍵業(yè)務關鍵點也定期進行巡視分析。

1)自動化巡檢內(nèi)容

目前自動化巡檢對象涵蓋了所有的生產(chǎn)主機，固定巡檢內(nèi)容主要包括常見的系統(tǒng)安全隱患、入侵攻擊檢查，安全補丁檢查，系統(tǒng)配置、加固檢查，數(shù)據(jù)庫安全配置檢查，詳細如下：

巡檢工具把歷史積累的SHELL腳本參考上面內(nèi)容進行逐步歸類，作為巡檢工具的基礎項，也可以隨時對巡檢內(nèi)容進行修改，所有的巡檢動作全部可視化，并且巡視項、巡檢方式、巡檢主機等全部可以進行定制，巡檢任務結束后會自動生成巡檢報告，并能通過郵件、短信等渠道第一時間告知關注人。

2)自動化巡檢效果

從2014年底以來，通過將日常巡檢報告自動化，不斷來提升運維的自動化程度，通過腳本管理、故障診斷、拓撲圖執(zhí)行遠程命令調(diào)用等功能規(guī)范日常運維操作。通過巡檢可以保存系統(tǒng)性能數(shù)據(jù)、容量信息、配置信息為系統(tǒng)維護、升級、擴容提供決策數(shù)據(jù)支持;同事通過靈活的工具定制，達到了對各種等資源全面的監(jiān)控、多級鉆取實現(xiàn)性能分析，提升運維的專業(yè)化水平。

2015年中開始，在實現(xiàn)系統(tǒng)自動化巡檢后，我們再接再厲，終于實現(xiàn)了業(yè)務巡檢的工具化，目前業(yè)務相關的巡檢包已涵蓋了系統(tǒng)安全、無紙化、服開配置、業(yè)務規(guī)則等巡檢內(nèi)容共計10類28項業(yè)務，能夠隨時掌控關鍵業(yè)務監(jiān)控度，具體的業(yè)務巡檢內(nèi)容和界面如下：

2、自動化JOB

在系統(tǒng)日常運維中，存在大量重復并且簡單的運維操作，包括最常見主機、中間件、數(shù)據(jù)庫等不同類型的軟、硬件平臺運維。這些運維操作重復而機械，卻易于出錯，占用了大量日常運維人員的精力和時間。

通過運維自動化工具，將運維操作場景化、可視化、自動化和標準化，將以前需要編輯大量腳本和命令進行的維護操作變?yōu)橹恍枰c擊相關的場景調(diào)用以及輸入合適的參數(shù)，大幅減少運維人員在編寫腳本和命令分發(fā)執(zhí)行所帶來的資源投入。

日常運維場景

日常運維場景是將系統(tǒng)管理員的日常工作項目，集成于同一界面，可對自動執(zhí)行的任務進行處理，并提供統(tǒng)一接入入口和監(jiān)控界面。

首先，系統(tǒng)管理員先進行任務配置，系統(tǒng)管理在任務配置頁面，進行任務分類與任務的配置。使用日常任務之前，需要先配置在相應的任務分類下配置任務，才能使用。

此后，系統(tǒng)管理員在任務視圖是各分類的任務的執(zhí)行頁面。配置任務完成后，打開任務視圖，可看到不同任務分類下已配置的任務，點擊執(zhí)行，進入?yún)?shù)輸入頁面，選擇執(zhí)行的目標設備，輸入?yún)?shù)后，點擊立即執(zhí)行完成運維場景所需要執(zhí)行的運維操作。

自動化告警處理

傳統(tǒng)告警處理，主要靠人工值守進行操作，告警響應速度受到多方面因素的制約，如告警信息發(fā)布及時性，運維人員響應及時性，運維人員對系統(tǒng)熟悉程度等;一旦運維人員錯過了告警，本來有很簡單有效的運維操作沒有被執(zhí)行，就可能導致系統(tǒng)故障。

自動化運維工具通過告警消息自動觸發(fā)故障處理流程，主動高效地識別和解決故障，極大的提升運維對故障的響應速度和縮短故障時間。

• 快速高效地識別、解決和消除服務中斷的根源
• 通過工具來查看、管理、診斷和解決問題
• 整合運維團隊積累的、廠商的專業(yè)工具和知識來加速事件和問題的診斷和解決
• 自動進行故障問題定位并啟用對應

一鍵快速診斷定位性能問題：

• I/O性能問題
• 并發(fā)問題
• 低效SQL或者高負載SQL
• 對象爭用
• 鎖阻塞或HANG

運維管理人員可以通過自動化工具，根據(jù)告警觸發(fā)或手工調(diào)度診斷流程，自動化工具自動進入診斷模塊，首先自動判斷系統(tǒng)所存在問題:如IO問題、并發(fā)堵塞問題、低效SQL或高負載SQL問題、hang等。自動化工具根據(jù)問題類型自動調(diào)度預定處理流程或方案(預定處理腳本集)，最后返回診斷結果。

3.自動可視化發(fā)布

隨著云化后機器數(shù)十倍的增長，傳統(tǒng)“煙囪式”系統(tǒng)應用部署模式耗時耗力，并且手動發(fā)布出錯的機率也非常大，我們嘗試引入互聯(lián)網(wǎng)自動配置部署工具SaltStack，并考慮到SaltStack無WEB配置界面的缺點，在其外面定制開發(fā)了一層WEB可視化界面，從而實現(xiàn)了云化系統(tǒng)下自動化可視化部署。

1)自動化配置管理平臺SaltStack整體架構

SaltStack是一個服務器基礎架構集中化配置管理平臺，具備配置管理、遠程執(zhí)行、監(jiān)控等功能，易于安裝使用，便于擴展，可支撐管理上萬臺服務器或者虛擬機。依托云計算平臺資源池實施部署了SaltStack管理平臺。截至目前，SaltStack管理共計47套Linux系統(tǒng)，涵蓋測試域36套系統(tǒng)以及生產(chǎn)域11套系統(tǒng)，并且還在不斷的擴展?；贑/S架構，劃分為主控端和被控端，分別稱為Master和Minion。兩者基于證書認證，安全可靠，其整體架構如下：

2)SaltStack安裝配置

SaltStack可采用多種方式安裝，通過源碼安裝，將SaltStackMaster部署在RHEL6.5主機，啟動Master進程，并在全部受控機安裝SaltStack，啟動Minion進程。

Master和Minion在通信時需要進行認證，因此需在/etc/salt/master中配置Master節(jié)點的IP地址，在/etc/salt/minion中指明Master端的地址以及本機的唯一標示。這樣在Master端認證和統(tǒng)一配置時可以通過唯一標示進行。配置文件使用YAML$key:$value格式。

3)SaltStack應用

在我們的業(yè)務系統(tǒng)中，主要按照操作系統(tǒng)以及應用進行分組，具體分組方式如下：

cat/etc/salt/master.d/nodegroup.conf  
nodegroups:  
redhatDatabase:‘redhat-db’  
redhatAPP:‘redhat-app’  
suseAPP:‘suse-app’  
suseDatabase:‘suse-db’ 

受控機器的信息展現(xiàn)是通過grain組件進行展現(xiàn)的，基本使用方法如下：

salt'redhat-db1'grains.ls查看grains分類

salt'redhat-db1'grains.items查看grains所有信息

salt'redhat-db1'grains.itemosrelease查看grains某個信息

4)可視化界面發(fā)布

通過在SaltStack外部，定制開發(fā)WEB界面，使得整個發(fā)布部署過程和發(fā)布結果全部可視化，具體的應用步驟如下圖所示：

目前在多臺服務器上實現(xiàn)了并行批量執(zhí)行命令，根據(jù)不同業(yè)務特性進行配置集中化管理、分發(fā)文件、采集服務器數(shù)據(jù)、操作系統(tǒng)基礎及軟件包管理等。

4、自動化數(shù)據(jù)管理

云架構下的IT系統(tǒng)越來越多，數(shù)據(jù)庫管理員需要面對成百上千的數(shù)據(jù)庫，另外隨著云架構下的大數(shù)據(jù)平臺等技術的不斷深入，數(shù)據(jù)存儲將邁入EB級別，傳統(tǒng)手工數(shù)據(jù)管理的難度越來越大。同時云架構中出于開發(fā)、測試、培訓以及數(shù)據(jù)對外共享變現(xiàn)等環(huán)節(jié)需要從生產(chǎn)環(huán)境中同步和遷移大量數(shù)據(jù)，其中亦會涉及大量用戶隱私數(shù)據(jù)。而之前整體IT系統(tǒng)數(shù)據(jù)流和業(yè)務流的關系不太清晰，業(yè)務數(shù)據(jù)可視化展示程度很低，缺少可視化的企業(yè)整體數(shù)據(jù)地圖，對于數(shù)據(jù)的維護困難重重。

1)云架構下數(shù)據(jù)管理規(guī)劃

為解決傳統(tǒng)數(shù)據(jù)管理上的痛點，讓數(shù)據(jù)管理相關工作更加標準化和流程化，我們借鑒國內(nèi)外IT業(yè)界先進的數(shù)據(jù)管理和運營經(jīng)驗，著手在數(shù)據(jù)管理領域的自動化運營工具作出了規(guī)劃。整體規(guī)劃如下：

在此規(guī)劃的基礎上，著手建設了在云架構下的數(shù)據(jù)安全管理以及數(shù)據(jù)生命周期管理兩個主要運營場景的自動化工具化建設，其他還處在建設階段。

2)云架構下數(shù)據(jù)生命周期管理

根據(jù)核心生產(chǎn)系統(tǒng)中數(shù)據(jù)的特點建立多層次數(shù)據(jù)存儲體系，將用戶訪問頻率較低的遠期歷史數(shù)據(jù)按規(guī)劃從生產(chǎn)環(huán)境轉(zhuǎn)移到歷史數(shù)據(jù)中心和大數(shù)據(jù)平臺中，在不影響絕大部分用戶應用感知的情況下，有效管控系統(tǒng)整體數(shù)據(jù)增長，既降低系統(tǒng)運營成本，又滿足最終用戶的數(shù)據(jù)需求。我們的數(shù)據(jù)生命周期管理自動化工具，由數(shù)據(jù)管理員針對不同種類的數(shù)據(jù)梳理的數(shù)據(jù)生命周期策略進行可視化的管理，以自動化方式按不同周期識別歷史數(shù)據(jù)并將歷史數(shù)據(jù)完整地遷移到歷史數(shù)據(jù)中心或其他大數(shù)據(jù)平臺中。

通過作業(yè)化自動化的思路，以自動化平臺方式實現(xiàn)數(shù)據(jù)生命周期管理的全程，減少人力在策略管理、數(shù)據(jù)遷移和數(shù)據(jù)清理中的人工投入，主要目標在于：

• 策略管理：在平臺中對數(shù)據(jù)生命周期管理策略進行有效管理;策略定義包括數(shù)據(jù)生命周期定義，數(shù)據(jù)遷移策略定義，數(shù)據(jù)清理策略定義;定義數(shù)據(jù)生命周期作業(yè)，定時進行數(shù)據(jù)生命周期作業(yè)調(diào)度
• 數(shù)據(jù)遷移：根據(jù)平臺中的配置的數(shù)據(jù)生命周期策略定義，請理作業(yè)實施數(shù)據(jù)的自動化遷移，數(shù)據(jù)遷移過程無需人工干預，不同數(shù)據(jù)平臺間數(shù)據(jù)遷移
• 數(shù)據(jù)清理：數(shù)據(jù)重要程度，清理過程可以通過配置為自動執(zhí)行和人工確認執(zhí)行。根據(jù)平臺中的配置的數(shù)據(jù)生命周期策略定義，作業(yè)實施數(shù)據(jù)的自動化清理

3)云架構下數(shù)據(jù)安全管理

根據(jù)生產(chǎn)系統(tǒng)中敏感數(shù)據(jù)分布情況，建立敏感數(shù)據(jù)策略化管理。在數(shù)據(jù)從生產(chǎn)環(huán)境中向未安全環(huán)境，包括開發(fā)、測試、培訓和對外數(shù)據(jù)共享等，進行數(shù)據(jù)遷移和同步的過程中，因應數(shù)據(jù)安全管理員制定的敏感策略對數(shù)據(jù)進行自動化安全脫敏，減少敏感數(shù)據(jù)外泄的可能。

目前數(shù)據(jù)安全自動化管理工具，實現(xiàn)從敏感數(shù)據(jù)識別，脫敏策略配置，數(shù)據(jù)遷移配置，以及數(shù)據(jù)在線和離線脫敏全程，自動化安全地將數(shù)據(jù)從生產(chǎn)環(huán)境向非安全環(huán)境遷移，同時在遷移過程中實施敏感數(shù)據(jù)脫敏。

分析篇：利用大數(shù)據(jù)實時分析助力運維

數(shù)據(jù)是金礦，隨著云化的深入，價值數(shù)據(jù)之間分散到海量機器中，需要采用大數(shù)據(jù)技術進行集中化處理，并助力運維。我們公司進行了積極嘗試，引入flume+kafka+spark+分布式內(nèi)存庫redis等開源技術自主進行大數(shù)據(jù)運維分析，取得了一定的效果。

整體架構如下圖所示?？紤]到來自業(yè)務系統(tǒng)的數(shù)據(jù)是多元化的，既包括了軟、硬件基礎設施日志數(shù)據(jù)，也包括各類應用服務的日志數(shù)據(jù)，這兩類日志數(shù)據(jù)通過主機和分布式軟件代理服務、分布式消息采集服務和分析服務處理后，以流數(shù)據(jù)的方式轉(zhuǎn)給大數(shù)據(jù)平臺和報表平臺：

分布式數(shù)據(jù)(應用日志等)采集

整個分布式采集分為如下四個部分：

• 數(shù)據(jù)采集：負責從各個節(jié)點上實時采集日志數(shù)據(jù)，可以指定目錄或文件，通過flume實現(xiàn)，僅增量采集數(shù)據(jù)。
• 數(shù)據(jù)接入：由于上述采集數(shù)據(jù)的速度和數(shù)據(jù)處理的速度不一定同步，增加分布式消息曾作為緩沖，防止丟失數(shù)據(jù)，采用kafka。
• 流式處理：對采集的數(shù)據(jù)進行實時分析，選用spark-streaming+redis實現(xiàn)。
• 數(shù)據(jù)輸出：對分析結果存儲在mysql數(shù)據(jù)庫中，并進行告警展示。

以往，業(yè)務支撐網(wǎng)中的日志分布在各服務器上，每次檢索要逐一登陸到各服務器操作，嚴重影響效率;同時，日志留存于操作系統(tǒng)本地，會受到存儲空間限制而循環(huán)覆蓋，導致重要數(shù)據(jù)丟失;由于對關鍵日志缺乏保護，也給監(jiān)控、審計帶來諸多困難。

隨著業(yè)務發(fā)展，來自硬件、操作系統(tǒng)和中間件的日志量不斷膨脹，獨立而分散的日志管理模式已不能滿足日益增長的維護需求，特別在事件回溯、問題分析及報表統(tǒng)計相關工作中，其基礎數(shù)據(jù)均源自這些紛繁蕪雜的日志單元，亟需形成統(tǒng)一管理、綜合分析、集中展現(xiàn)的新型一體化管理機制。為此一直進行著日志集中化改造的嘗試。

起初，以HTTP服務器日志統(tǒng)計為例，傳統(tǒng)解決方式是定期(按5分鐘、小時或天)截斷日志，然后通過FTP上傳到一臺服務器統(tǒng)一處理，在有些日志的計算處理前需要考慮日志排序問題。這樣的日志同步可以支持幾臺到幾十臺規(guī)模的并發(fā)服務，但當管理的服務器達到幾十臺，而有大量的服務器中間會有下線、上線或變更時，集中的日志定期同步更顯得難于管理，且日志同步要避開白天的高峰，往往需要用凌晨的低峰時段同步，24小時下來，上G的日志同步也是風險很高的操作。而成為瓶頸的日志排序合并操作也會妨礙其他后續(xù)計算的周期。其邏輯架構如下所示。

目前實現(xiàn)了應用分布但日志集中的遠程存儲模式，通過UDP協(xié)議實現(xiàn)小局域網(wǎng)內(nèi)的日志廣播，然后在多臺匯聚服務器上實現(xiàn)各種日志的并發(fā)計算。如圖所示：

為保證日志流傳輸?shù)目煽啃?，對整個傳輸鏈進行了改造，實現(xiàn)了多個特性：非阻塞的適配器、網(wǎng)絡劃分、負載均衡、傳輸高可用性、傳輸監(jiān)控能力及可以動態(tài)調(diào)整的Push/Polling模式。

無論是網(wǎng)絡設備、應用服務器還是中間件，其日志需要與Flume節(jié)點對接，這就涉及到協(xié)議適配的問題，為此專門針對企業(yè)總線(eBus、UAP)、前端Web容器及交易中間件配置協(xié)議適配驅(qū)動，將日志以流的方式傳輸給Flume代理，協(xié)議適配層提供了較豐富的協(xié)議適配驅(qū)動，能夠支持來自各層面基礎設施的日志數(shù)據(jù)對接，目前已成功接入的基本組件有交換機、負載均衡器、各刀片服務器操作系統(tǒng)及應用程序，如圖所示：

當采用適配器連接Flume代理時，應用服務會調(diào)用異步附加組件AsyncAppender輸出日志流，如果Flume代理宕機，且無備份節(jié)點時，會導致應用服務器阻塞，我們針對一些適配器配置了non-Blocking特性參數(shù)，當啟用此參數(shù)時，即使日志流寫入失敗，不會影響正常業(yè)務運行。

為確保基于UDP廣播的傳輸模式不會形成網(wǎng)絡風暴，我們按照不同的業(yè)務范疇、不同的組件類型劃分子網(wǎng)，同一子網(wǎng)內(nèi)的應用服務器僅與當前子網(wǎng)的Flume代理通信。在高可用性方面，應用服務器以UDP協(xié)議在子網(wǎng)內(nèi)廣播日志數(shù)據(jù)，UDP包被多個Flume代理節(jié)點截獲，某一時刻僅有一個Flume Agent處于Active狀態(tài)，其他為Standby，當Flume節(jié)點宕機時，其他節(jié)點可以無縫接替繼續(xù)工作，所有Flume Agent通過Flume Master節(jié)點管理，實現(xiàn)主備接管和配置同步功能。如圖所示：

(灰色框為備機)

為便于維護人員及時了解日志傳輸?shù)墓ぷ鳡顟B(tài)，對Flume的相關命令進行了封裝，在統(tǒng)一界面上展現(xiàn)來自Flume不同端口的數(shù)據(jù)接收情況。

對于超大規(guī)模的營業(yè)廳前端用戶交互日志采集，采用UDP、FTP方式可能會導致過高的網(wǎng)絡、磁盤I/O資源消耗，因此首先保證整個架構過程中，除在匯聚服務器和日志中心外的Flume節(jié)點上均不產(chǎn)生文件落地，僅在匯聚服務器中實現(xiàn)了對來自多個Flume代理的數(shù)據(jù)聚合和排序。同時在業(yè)務高峰時段，日志采集處理能力有限，F(xiàn)lume代理會從Pushing模式切換為Pulling模式，即從采集轉(zhuǎn)為采樣。

2、實時數(shù)據(jù)聚合+分組

利用大數(shù)據(jù)集中處理平臺的處理流程主要分兩部分，通過消息隊列處理Flume采集的日志，再通過ElasticSearch建立索引，最終將數(shù)據(jù)、索引導入在mysql集群。如下：

大數(shù)據(jù)平臺主要分析營業(yè)廳與用戶交互日志，其中包括實時的用戶體驗、服務器請求記錄。用戶體驗日志是用戶在瀏覽器中每一步操作的性能評估，主要包括用戶每一步操作的名稱(如點擊按鈕、鍵盤錄入、下拉框的選擇、復選框的勾選及頁面刷新等);用戶操作整體響應時間及其構成部分：客戶端響應時間(包括頁面元素渲染時間、頁面JavaScript腳本執(zhí)行時間)、網(wǎng)絡耗時(包括網(wǎng)絡中的傳輸時延及第三方內(nèi)容服務CDN的處理時間)、服務器運行時間。通過用戶體驗日志可以了解到用戶每一步操作的感知狀況，準確了解性能故障對用戶操作的影響;此外，用戶操作和用戶請求是相互關聯(lián)的，通過關聯(lián)關系可以找到每一步用戶操作的具體含義，如(某一步操作是在繳費業(yè)務的錄入用戶號碼操作)。

然后就是對用戶操作業(yè)務聚合，即按時間順序、用戶操作的業(yè)務名稱、用戶號碼等對用戶真實的操作情景予以重建，這樣做的好處是從整體上了解某一筆業(yè)務的操作繁瑣程度(難易度、友好性);了解某一筆業(yè)務在哪一步較慢，是慢在網(wǎng)絡層面、客戶端層面、服務器層面還是用戶自身原因(如間歇性停留)導致的;了解業(yè)務分布情況及成功率、轉(zhuǎn)化率等。為確保業(yè)務聚合的并行計算高效，我們采取了spark流處理機制完成。目前主要應用了如下幾個場景：

場景1：以下圖為例，通過大數(shù)據(jù)的數(shù)據(jù)聚合+分組手段，實現(xiàn)對用戶行為的模式匹配，將多個操作歸結到一筆業(yè)務中，實現(xiàn)用戶體驗不好根本原因是IT原因造成還是非IT因素造成(用戶問題、營業(yè)員操作問題)：

場景2：結合大數(shù)據(jù)的分析，掌握用戶的操作規(guī)律、操作習慣，并基于這些分析進行頁面優(yōu)化，如在合適位置投放廣告，發(fā)布符合大眾需求的產(chǎn)品與優(yōu)惠：

場景3：實現(xiàn)基于業(yè)務監(jiān)控的入侵檢測機制，我們基于集中日志分析，利用大數(shù)據(jù)技術實現(xiàn)基于業(yè)務聚合的CC攻擊分析方法，將用戶操作與瀏覽器請求建立關聯(lián)，首先將URI請求按用戶操作聚合，形成用戶操作序列，再按照時間先后順序及一定的業(yè)務規(guī)則將用戶操作聚合為業(yè)務單元，通過對業(yè)務單元數(shù)據(jù)分析判斷是否存在入侵檢測。大大提高了針對仿真式DDos攻擊的鑒別準確度。

下圖是近期發(fā)現(xiàn)的感染木馬病毒的終端列表：

3、深入性能診斷

我們基于集中日志實時分析，可用于性能診斷等場景，并總結了一些寶貴經(jīng)驗：如網(wǎng)絡故障關聯(lián)分析和診斷、診斷企業(yè)總線調(diào)用外部域時發(fā)生的故障、基于接口報文的后端交易調(diào)優(yōu)、針對RPC的性能分析等。

1)網(wǎng)絡故障診斷

網(wǎng)絡延遲故障一般可以從用戶體驗的網(wǎng)絡耗時一項直接診斷定位，但有時很難一下子定位，也需要從用戶請求中，如從HTTP服務器和WAS服務器的耗時份額對比中推導，亦可以從用戶請求服務器代碼路徑中推導出來。

從下圖1看，某用戶請求在IHS(HTTP服務器)上耗費的時間為14.69s，而端到端路徑分析，在WAS(APP服務器)上的耗費時間為2.57ms，因此分析可知時間主要耗費在HTTP服務器上，而HTTP服務器主要作為一個代理與用戶終端交互，因此分析得知有2種可能：在終端用戶到HTTP服務器之間的鏈路上出現(xiàn)了網(wǎng)絡故障，或HTTP服務器出現(xiàn)了性能問題，而經(jīng)過監(jiān)控發(fā)現(xiàn)其他業(yè)務運行均正常，HTTP服務器線程池使用正常，如圖2所示，因此通過排除法得知網(wǎng)絡故障可能性較大。

圖1 端到端路徑分析

圖2 HTTP服務器的線程池使用情況

另外通過服務器響應字節(jié)數(shù)進一步證實之前的推論，返回大小相比其他同類請求來說較大，如下圖所示。

2)基于接口報文進行的后端交易優(yōu)化

我們CRM交易處理程序基于C/C++實現(xiàn)，這導致交易中間件無法向基于JVM的前端Web服務一樣實現(xiàn)運行時環(huán)境注入并動態(tài)改變監(jiān)控行為，只能通過捕獲應用程序觸發(fā)的操作系統(tǒng)底層業(yè)務邏輯實現(xiàn)，這種情況下無法實現(xiàn)前端與后端的單筆交易關聯(lián)。為解決此問題，首先對CICS應用服務進程啟動多線程跟蹤，將truss日志輸出流重定向到UDP，發(fā)送給外部服務器，truss會跟蹤到一些極基礎的函數(shù)調(diào)用，使用truss跟蹤的好處是，當和被跟蹤進程依附和解除依附時，對被跟蹤的進程不會造成影響，因此可以在生產(chǎn)環(huán)境中使用。此外，可以對CICS連接到Oracle的會話，在數(shù)據(jù)庫中啟動10046事件跟蹤，跟蹤數(shù)據(jù)庫的調(diào)用軌跡，這種方式的好處是：填補了CICS跟蹤的空白，實現(xiàn)了對業(yè)務的梳理;壞處是：只能小范圍開啟，需要在生產(chǎn)隔離出單獨的一套中間件，并在此環(huán)境中回放報文處理過程。

下圖是通過啟用數(shù)據(jù)庫10046事件跟蹤后，梳理出的合約機校驗接口的業(yè)務邏輯(部分)。

服務篇：建立面向云服務的運維架構

目前我們的運維模式是基于ITIL的，從服務臺、時間管理、變更管理、可用性管理、容量管理、CMDB等思路逐步建設整個系統(tǒng)，這種運維思路在傳統(tǒng)架構下沒問題，但在云計算下大規(guī)模運維的時候，越來越難以應對，或者說過多的聚焦于流程和規(guī)范的情況下，很難提升運維敏捷性和精細性。當前，IT支撐系統(tǒng)正在向資源池、SOA架構快速演進，系統(tǒng)支撐能力逐步具備了服務化的能力。通過對系統(tǒng)能力組件化和服務化，并配合系統(tǒng)彈性伸縮等能力，將支撐系統(tǒng)的能力以“服務”的形式提供，屏蔽內(nèi)部過多的細節(jié)，可以實現(xiàn)“IT即服務的新型敏捷支撐與運維模式。

為適應“IT即服務”的新型運維模式，嘗試打破原有按照專業(yè)(主機、存儲、數(shù)據(jù)庫、中間件、網(wǎng)絡……)和項目劃分的組織架構，按照資源池運營管理模式進行架構重構，把運維工作劃分為服務運營、資源運營兩個核心維度，并以此為核心組織進行基礎設施層面的構建和上層的管理運營，如下：

經(jīng)過上述調(diào)整，大大降低了之前各個專業(yè)之間協(xié)同難度以及不同專業(yè)間的專業(yè)壁壘，例如支撐一個項目，原來需要主機組提供主機資源、網(wǎng)絡組提供網(wǎng)絡、數(shù)據(jù)庫組提供數(shù)據(jù)庫等，現(xiàn)在提前建好資源池，資源池的運維人員通過云管理平臺幾乎可實現(xiàn)一切底層設施，每個人對各個專業(yè)門檻也大大降低了要求，適應了大規(guī)模環(huán)境下的運維要求。

考慮到資源池初始階段還有很多傳統(tǒng)架構和云架構并存，且資源池需要提前建設，上述劃分僅適應運營階段需要，我們在運營團隊中橫向構建了跨專業(yè)的虛擬團隊，作為項目小組，人員跨資源運營和服務運營的成員組成，例如擴容項目組、工程項目組、業(yè)務連續(xù)性項目組等，作為臨時需要時的一個扁平化團隊，如下圖所示：

通過上述組織架構調(diào)整，結合我們在資源池管理平臺實現(xiàn)的IAAS和PAAS的自動管理功能，大大降低了運維難度，同時規(guī)避了繁瑣的運維流程，初步實現(xiàn)了敏捷運維能力。同時根據(jù)測算，在人員配備上，如果按照傳統(tǒng)運維架構，2000臺服務器規(guī)模需要不同專業(yè)運維人員12人以上，而采用新的運維架構，只需3-4人即可。

上述是在組織架構上適應云服務的運維，在技術上，我們公司積極推進企業(yè)級資源池、第三代CRM的IAAS和PAA融合架構建設，實現(xiàn)應用節(jié)點容量通過服務方式自動擴展，做到集中統(tǒng)一管控，深入運維提升核心掌控能力，目前本項目正在建設中，如下圖所示：

效果和后續(xù)計劃

通過近兩年的持續(xù)探索，引入了較多的互聯(lián)網(wǎng)開源運維工具，并經(jīng)過定制化改造，目前已經(jīng)初步搭建了面向云化架構下的系統(tǒng)運維架構。通過完善相應的監(jiān)控、維護工具和數(shù)據(jù)分析，簡化了系統(tǒng)運維難度，大大提升了系統(tǒng)維護效率;另外通過系統(tǒng)建設，運維人員接觸到很多新的互聯(lián)網(wǎng)化運維工具，人員自身的能力和工作積極性有了較大提升;而新工程項目建設時，。因為從各層級有了可視化操作工具，項目建設難度大大降低，減少了較多的項目協(xié)調(diào)工作，人員投入也從之前的8-9人變?yōu)?-3人承擔。

盡管目前引入了較多的云化運維工作，但目前各個工具還相對比較分散，未來我們計劃對各個運維工具統(tǒng)一建設，能夠集中到一個統(tǒng)一的操作平臺上，各個工具也能夠作為一個整體相互協(xié)調(diào)運作。