解放運維的雙手，談自動化運維管理平臺設計

做者介紹

戰學超，青航數據架構師。曾任職於NEC軟件、海爾B2B平臺鉅商匯，負責企業數據平臺構建、B2B電商平臺數據管理與搭建。擁有豐富DBA、系統運維架構經驗，擅長數據庫、數據平臺搭建、私有云部署、自動化運維等。

最近一段時間，一直在作和運維、數據庫相關的工做，也算是完成了從開發向運維的轉變。這半年來的研究基本完成了運維管理平臺的第一版架構，這裏寫出來跟你們一塊兒討論交流，以便更好地完成運維工做，擺脫重複運維勞動，儘快轉向自動化運維和雲服務這一方向，完全解放勞動力，實現高效的服務IT。

整體架構

首先是整體架構圖：

能夠看出內容相對仍是比較簡陋一些，指望可以在你們的幫助下，豐富完善起來。

我主要分爲如下幾個部分跟你們介紹：

1. 基礎數據

2. 監控模塊，監控管理平臺

3. 災備管理平臺

4. 安全模塊，安全管理平臺

5. 自動化運維平臺

6. 虛擬化與私有云

7. 運維管理頁面

本文主要對運維管理平臺的這幾個模塊作一個簡單介紹，同時綜合了咱們日常運維遇到過的一些問題，計劃優先完成的模塊。具體以下：

1基礎數據和監控優先

作運維管理平臺通常會有一個優先度，由於不多有公司有充足的運維開發人力一會兒同時開展好幾個模塊。按照優先級快速迭代，永遠是解決IT與業務部門矛盾的銀彈。本人一直也在糾結創建運維平臺的模塊的優先級排序。通過三思仍是決定首先完成基礎數據的收集，這裏的收集的目的是爲了接下來要完成的監控平臺的創建。說到底第一步是監控，前提是收集好基礎數據。

爲何要這樣？首先創建起監控平臺，實現主動監控咱們的業務系統、服務器、網絡的狀況、出現問題，從而能夠第一時間收到告警，這樣在面對IT故障的時候，能夠在與業務部門溝通中佔據優先權，而非等業務投訴了，才知道系統出現故障。

不少公司可能沒有運維開發的能力，此時利用Excel管理基礎數據，Zabbix or其它作監控，也是能夠很快構建出基礎監控平臺來監控IT系統。

2災備緊跟

作好數據採集與監控以後，接下來就要考慮作全局備份。完整、可用的備份集是保障企業數據不丟或是最少丟失的最後一道保障。如何作好備份策略，備份集如何驗證，都必需要提早作好準備和計劃。

2自動化運維與安全並行

在完成了監控和災備以後，運維的冗餘工做量會獲得必定的減小。接下來能夠進行自動化的運維工做，例如自動裝機，自動部署服務，利用自動化運維將平常的重複工做讓系統完成，大大解放運維的勞動力。讓運維能夠有更多的時間和精力保障整個IT系統的安全、穩定和高效。

要完成自動運維的搭建，或是在構思自動化運維平臺時，有一個工做不得不作，那就是：運維標準化和運維流程化。系統安裝版本、JDK、Tomcat部署版本、位置等等，只要提早作好了標準化，才能利用自動化運維工具完成運維的自動化。

運維的流程化是指涉及到某一運維主題如應用發佈，每一步該如何操做，涉及哪些運維節點，前後順序等。明確的運維流程，能夠有條不紊地保障系統的更新和發佈。規範化、流程化的運維操做能夠減小運維過程當中的失誤，也能夠在出現問題的時候，迅速找到問題節點，迅速恢復。

安全一直是一個相對忽略的話題。網絡安全、系統安全、應用安全、數據庫安全等，一旦任何一個節點出現安全漏洞或是故障，都將會給系統帶來毀滅性的災難。安全並非購買了商業設備以後，就能夠高枕無憂。不斷學習，不斷研究系統的漏洞，最大程度地結合自身的專業深度和安全設備，爲整個IT系統築一道厚重的高牆。

4虛擬化和私有云

虛擬化和私有云的搭建的最大目的是爲了節省公司的IT成本。固然也有不少其餘優勢，例如作虛擬機層面的熱備，利用私有云服務快速地搭建須要的服務等。虛擬化和私有云是將來運維的一個方向，必定要把握好時機。給老闆省錢，即是跟老闆要錢的最佳理由。

5運維管理集成平臺

在完成了基礎數據採集、CMDB創建、監控平臺、災備、運維自動化、虛擬化和私有云以後，咱們須要一套IT系統來集成各個模塊，統一管理，這即是咱們的運維管理平臺。

後面將圍繞上面幾個部分作一個簡單的概述，簡單概述以後，會陸續推出各個模塊的建設心得，技術方案和踩過的坑等，敬請期待。

基礎數據

巧婦難爲無米之炊，基礎數據即是咱們運維管理平臺的米。基礎數據方面主要分一下幾個部分：

1CMDB

CMDB在這裏更可能是偏向IT設備管理，由於這樣能夠更快地完成。與傳統的CMDB不一樣，咱們把配置管理放在了自動運維模塊了。這裏的CMDB主要是將整個IT部門的硬件資源，已有系統，服務包括供應商作一個管理，爲之後的監控和自動化運維等提供基礎數據。該平臺CMDB的建設思路主要是以產品線和項目爲導向，具體順序說明以下。

1、產品線和項目

首先是肯定整個公司的IT產品線。以某航空公司爲例，涉及到的系統有運行控制系統、飛行排班系統、機務管理系統、B2C官網系統、呼叫中心繫統等。

通過分析判斷，能夠肯定該公司主要分爲兩大產品主線，即：運行相關係統主線和運營相關主線。運行相關涉及到運行控制、飛行排班、機務等各個項目系統；運營相關係統主要有呼叫中心、B2C等。

爲了更好地理解產品線和項目的劃分，再舉一個B2B電商的例子，涉及到的有買賣家管理系統、訂單系統、支付系統、物流系統、對帳系統等。能夠大概分爲銷售產品線：買賣家管理、訂單管理；財務產品線：支付系統、對帳系統；物流產品線：物流系統、第三方物流接口等。

產品線的劃分必定要站在公司的角度進行，能夠結合公司的主要部門，和大產品羣進行劃分。產品線劃分好後，接下來就是梳理整個公司的全部項目，將每個項目，按照所屬產品線進行歸類。

2、IT資產管理

通過產品線劃分和項目歸類以後，能夠一目瞭然地看到目前公司全部的IT系統。接下來根據每個項目梳理項目中涉及到的服務器或是虛擬機。而後還須要從另外一個維度去梳理：每一臺服務器或是虛擬機上面部署的項目，服務(數據庫、Tomcat、WebLogic等)。通過這一步，能夠明確每個項目涉及哪些服務器或是虛擬機，每一臺服務器或虛擬機上又關聯多少個項目，部署了多少服務。

虛擬機在哪些宿主機，宿主機又分佈在哪些物理機上，而這些物理機又部署在哪一個機房的哪一個機櫃；網絡鏈接是怎樣，上行和下行分別是什麼，都須要進行梳理和完善，這樣能夠從硬件層面去關注每個系統的硬件關聯。若是硬件或是網路出現任何問題，能夠快速地清楚知道涉及到的系統和影響度。

3、供應商管理

每個公司的IT設備或是系統基本都會有供應商公司的參與。集中統一管理這些供應商的信息，能夠在系統出現問題的時候緊急聯繫供應商，進行協助解決。

2生產數據庫

生產數據庫做爲基礎數據的重要一環，爲業務數據監控提供主要途徑。咱們在監控模塊中有一個業務監控，主要依賴業務數據庫中的數據，根據業務邏輯進行數據比對，判斷業務的實時性和準確性。

通常在監控和備份的時候，數據庫都會做爲單獨的一個主題進行（由於過重要）。在基礎數據模塊，將全部的生產數據庫信息進行集中採集，能夠很方便地爲之後的數據庫監控和備份等運維工做提供操做對象參考，以避免遺漏。

生產數據庫通常按照數據庫的類型(MySQL、Oracle、SQL Server等)進行分類管理。數據庫的名稱通常即業務系統的名稱，簡單標識，見名知意。

3日誌數據

日誌數據是IT系統的重要數據之一，能夠很好地反映系統的運行情況，系統出現問題的時候，能夠經過反查日誌進行查因、排故。

1、系統日誌

系統日誌主要是包括操做系統級別的日誌，包括物理機、宿主機、虛擬機等部署有操做系統的系統日誌。通常主要關注如下幾種日誌：系統操做日誌、安全日誌、定時任務日誌等。

系統操做日誌能夠看到什麼用戶什麼時間登陸了哪臺操做系統，作了什麼操做等；安全日誌能夠判斷系統是否已遭受或是正在遭受攻擊，是否有過危險操做等；定時任務日誌能夠看到部署在系統中的定時任務是否按時準確地執行完成。

系統日誌主要反映系統級別的運行狀況，必定要作好備份和分析的工做。

2、應用日誌

應用日誌通常分應用服務日誌和業務操做日誌。應用服務日誌指如Tomcat、Nginx運行時候產生的日誌等，經過其能夠看到應用服務運行的健康狀況；業務操做日誌主要是業務系統將部分業務操做或是業務錯誤寫到日誌中，可能單獨一個日誌文件也可能集成到應用服務日誌中。業務操做日誌是進行業務審計，業務監控的重要數據源。

3、數據庫日誌

這個很少說，數據庫中的數據每每是企業的核心資產。數據庫日誌反映着數據庫的每一步每個事務的操做，以及數據庫運行的監控情況，進行日誌監控和分析時，數據庫日誌是不可缺乏的。

4、設備日誌

設備日誌每每是比較容易忽略的。但設備日誌能夠直觀地反映出設備運行的情況，以及設備出現問題的時候，能夠經過日誌快速準確地找到緣由。如交換機日誌、防火牆日誌等。經過防火牆日誌能夠看出系統是否遭受攻擊，交換機日誌能夠看到網絡流量是否呈現陡增陡降等突發情況。實時監控和管理設備日誌是日誌管理的重要工做之一。

4知識庫

在基礎數據中，咱們單獨設立知識庫這樣一個模塊，主要包含事件庫、問題庫、經典案例庫、解決方案庫等。

事件庫主要是在運維工做中遇到的一些運維事件或是事故，在事件庫中詳細記錄事件的緣由和處理過程。若是涉及到需求變動或是須要修改系統進行解決的，此時由事件庫進入到問題庫。

問題庫涉及到問題解決流程，問題解決的過程當中，可能涉及到應用變動發佈等。經過問題庫的統計能夠側面反饋系統的情況。

經典案例庫記錄瞭解決經典問題的方式和方法。例如記錄了防火牆故障，交換機故障時如何從查找緣由到排故到解決的過程，以供解決相似故障處理參考。

解決方案庫主要存放一些經典的解決方案如Nginx+Tomcat+Redis的部署方案、MySQL的HA、Oracle的RAC等等解決方案。以便在構建新的系統的時候能夠快速地選擇解決方案。

基礎數據爲之後的運維工做作鋪墊，基礎數據的收集必定要全面，不能遺漏，不然就是之後運維的一個潛在問題點。

監控模塊

監控模塊主要分爲如下幾個部分：

1系統監控

主要監控系統層面的健康情況如內存、CPU告警、硬盤存儲不足等等，系統層面的監控能夠快速反應系統問題，運維工程師能夠提早處理可能出現的系統問題。

2網絡監控

經過進行網絡監控，包括網絡的正常性，是否聯通，網絡訪問量是否陡增陡降等，來監控和預防網絡問題帶來的故障。

3應用監控

主要監控應用的可用性如Tomcat的端口、Nginx的端口、錯誤日誌等等。應用出現問題致使應用不可用，均可以經過應用監控及時發現。

4數據庫監控

主要監控數據庫的可用性，經過監控數據庫狀態，日誌是否有警告錯誤，表空間等方面來監控數據庫可用與否。

5業務數據監控

經過業務數據監控以監控系統中是否含有業務邏輯錯誤的狀況。例如：每一筆訂單支付成功都應該有對應的支付流水號和物流流水號。經過監控數據庫中的數據，來觀察是否已經生成支付流水和物流流水。

6全鏈路監控

經過全鏈路監控能夠明確地看到業務操做的每一步正確與否。

7第三方監控

以上6種監控基本都是從公司內部進行監控的，若是是公司級別的網絡問題或是服務器大面積故障，可能就難以經過內部監控獲得信息，此時須要借第三方雲監控進行協助監控，如監控寶、聽雲等產品。

經過監控能夠主動及時地獲得系統的故障信息，在與業務部門的溝通中，化被動告知爲主動監控，也爲解決故障贏得寶貴的時間，這樣能夠把影響範圍和影響時間降至最低。

災備管理平臺

災備管理，有條件的話能夠兩地三中心，即同城實時，異地延遲備份。注意必定不能所有都是實時備份，不然在出現問題的時候，尤爲是數據篡改實時同步到備份端的話，也將是錯誤的數據。因此必定要有實時和延遲的策略。另外備份層面能夠分數據庫備份、文件備份(如應用程序包等)、虛擬機備份和存儲級別的備份。

有備份就必定要有驗證，並且驗證要持續不間斷，有計劃地實施。只要經過驗證可用的備份集才能保障系統的可用性。

在災備管理模塊存儲各類系統的應急預案，這樣在出現災難性故障的時候，能夠迅速啓動應急預案，進行災難處理。

自動化運維和安全

1安全

安全管理必不可少，而自動化運維是爲了最大程度地減小運維的重複勞動，提升運維的工做效率。自動化運維減小的工做量能夠轉化爲更多對系統安全的關注。

安全模塊主要從上圖的幾個方面進行：

登陸服務器經過堡壘機，而非直接SSH登陸，另外利用堡壘機作系統操做審計，利用業務操做日誌作業務審計（通常很難）。經過審計挖掘潛在的系統風險和威脅，防患於未然。

UMS即用戶帳號管理。操做系統的用戶和業務系統的用戶密碼每每沒有一個統一集中的地方進行管理，這些管理員級別的帳戶一旦泄漏，危害是很大的。因此經過UMS進行對這些用戶的管理，而且指定責任人、權限和密碼修改策略，最大程度地避免密碼泄漏和丟失的風險。

企業中通常有多種安全設備，防火牆、WAF、IPS等，經過一個統一管理入口，既列舉了全部的安全設備，也方便操做。這裏每每是經過URL跳轉到各類安全設備的管理界面。

漏洞管理平臺主要是幾個爬蟲去爬當前主流系統漏洞和最新的漏洞，在平臺進行反饋，以便運維工程師及時得到漏洞信息和思考處理辦法。

當運維的服務器數量上來的時候，自動化運維就顯得很是重要了。例如漏洞管理平臺發現一個新的漏洞時，須要在幾百臺服務器上打補丁，此時沒有運維自動化，每一臺都登陸處理的話，將是很是大的一個工做量。

2自動化運維

在這裏簡單介紹一下運維自動化涉及到的內容。結合前面說的運維流程化中的流程，大概分爲如下幾點：

一、服務器申請與操做系統自動安裝（自動安裝的操做系統是通過系統安全加固和優化後的系統）。

二、系統部署服務（如數據庫，Tomcat等）的申請和自動部署。通常要求版本統一，或是特定版本。部署的服務須要從自建軟件倉庫或是自建的Yum源進行自動安裝。

三、應用發佈申請與應用的自動部署。咱們這裏採用的是開發從代碼庫中檢出代碼經過編譯服務器進行編譯，將編譯後的程序包和配置文件（若是修改的話）在系統進行提交發布申請；測試人員收到開發的發佈申請後，點擊發布，發佈程序先執行備份，而後自動發佈到測試環境，測試人員進行測試，測試有誤，回滾測試環境，流程退回至開發，如無誤則點擊生產發佈（有的公司會要求預生產發佈測試）；運維人員收到測試經過的包和發佈時間後，點擊建立發佈便可。到時會定時在服務器先備份後發佈。

四、應用變動申請流程與上述相似，都是先通過測試，再進行變動。服務器變動申請如擴容等會根據資源利用率和硬件資源池進行評估後，給出變動建議。

此外自動運維平臺還提供架構自動診斷、壓力測試、系統巡檢、故障自診斷等方面的功能，具體再也不一一贅述。

總結

運維管理平臺的創建涉及到運維工做的方方面面，以減小運維重複工做，提升運維效率爲目標，若是你們有新的意見和建議的話，歡迎一塊兒溝通交流。

 

 

 

 

 

 

 

 

轉自：http://www.sohu.com/a/141415011_487514