作者介紹

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

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

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

1、自動化巡檢

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

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

1)自動化巡檢內容

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

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

2)自動化巡檢效果

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

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

2、自動化JOB

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

通過運維自動化工具，將運維操作場景化、可視化、自動化和標準化，將以前需要編輯大量腳本和命令進行的維護操作變為只需要點擊相關的場景調用以及輸入合適的參數，大幅減少運維人員在編寫腳本和命令分發執行所帶來的資源投入。

日常運維場景

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

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

此后，系統管理員在任務視圖是各分類的任務的執行頁面。配置任務完成后，打開任務視圖，可看到不同任務分類下已配置的任務，點擊執行，進入參數輸入頁面，選擇執行的目標設備，輸入參數后，點擊立即執行完成運維場景所需要執行的運維操作。

自動化告警處理

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

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

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

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

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

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

3.自動可視化發布

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

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

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

2)SaltStack安裝配置

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

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

3)SaltStack應用

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

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

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

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

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

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

4)可視化界面發布

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

目前在多臺服務器上實現了并行批量執行命令，根據不同業務特性進行配置集中化管理、分發文件、采集服務器數據、操作系統基礎及軟件包管理等。

4、自動化數據管理

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

1)云架構下數據管理規劃

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

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

2)云架構下數據生命周期管理

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

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

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

3)云架構下數據安全管理

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

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

分析篇：利用大數據實時分析助力運維

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

整體架構如下圖所示。考慮到來自業務系統的數據是多元化的，既包括了軟、硬件基礎設施日志數據，也包括各類應用服務的日志數據，這兩類日志數據通過主機和分布式軟件代理服務、分布式消息采集服務和分析服務處理后，以流數據的方式轉給大數據平臺和報表平臺：

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

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

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

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

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

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

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

為保證日志流傳輸的可靠性，對整個傳輸鏈進行了改造，實現了多個特性：非阻塞的適配器、網絡劃分、負載均衡、傳輸高可用性、傳輸監控能力及可以動態調整的Push/Polling模式。

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

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

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

(灰色框為備機)

為便于維護人員及時了解日志傳輸的工作狀態，對Flume的相關命令進行了封裝，在統一界面上展現來自Flume不同端口的數據接收情況。

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

2、實時數據聚合+分組

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

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

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

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

場景2：結合大數據的分析，掌握用戶的操作規律、操作習慣，并基于這些分析進行頁面優化，如在合適位置投放廣告，發布符合大眾需求的產品與優惠：

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

下圖是近期發現的感染木馬病毒的終端列表：

3、深入性能診斷

我們基于集中日志實時分析，可用于性能診斷等場景，并總結了一些寶貴經驗：如網絡故障關聯分析和診斷、診斷企業總線調用外部域時發生的故障、基于接口報文的后端交易調優、針對RPC的性能分析等。

1)網絡故障診斷

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

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

圖1 端到端路徑分析

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

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

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

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

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

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

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

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

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

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

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

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

效果和后續計劃

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

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

【編輯推薦】