作者介紹

朱祥磊，山東移動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人承擔。

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

文章出處：DBAplus社群（訂閱號ID：dbaplus）