作者介紹
戰學超，青航數據架構師。曾任職於NEC軟件、海爾B2B平台巨商匯，負責企業數據平台構建、B2B電商平台數據管理與搭建。擁有豐富DBA、系統運維架構經驗，擅長數據庫、數據平台搭建、私有雲部署、自動化運維等。
最近一段時間，一直在做和運維、數據庫相關的工作，也算是完成了從開發向運維的轉變。這半年來的研究基本完成了運維管理平台的初版架構，這里寫出來跟大家一起討論交流，以便更好地完成運維工作，擺脫重復運維勞動，盡快轉向自動化運維和雲服務這一方向，徹底解放勞動力，實現高效的服務IT。
總體架構
首先是總體架構圖：
可以看出內容相對還是比較簡陋一些，期望能夠在大家的幫助下，豐富完善起來。
我主要分為以下幾個部分跟大家介紹：
-
基礎數據
-
監控模塊，監控管理平台
-
災備管理平台
-
安全模塊，安全管理平台
-
自動化運維平台
-
虛擬化與私有雲
-
運維管理頁面
本文主要對運維管理平台的這幾個模塊做一個簡單介紹，同時綜合了我們平常運維遇到過的一些問題，計划優先完成的模塊。具體如下：
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的建設思路主要是以產品線和項目為導向，具體順序說明如下。
一、產品線和項目
首先是確定整個公司的IT產品線。以某航空公司為例，涉及到的系統有運行控制系統、飛行排班系統、機務管理系統、B2C官網系統、呼叫中心系統等。
經過分析判斷，可以確定該公司主要分為兩大產品主線，即：運行相關系統主線和運營相關主線。運行相關涉及到運行控制、飛行排班、機務等各個項目系統；運營相關系統主要有呼叫中心、B2C等。
為了更好地理解產品線和項目的划分，再舉一個B2B電商的例子，涉及到的有買賣家管理系統、訂單系統、支付系統、物流系統、對賬系統等。可以大概分為銷售產品線：買賣家管理、訂單管理；財務產品線：支付系統、對賬系統；物流產品線：物流系統、第三方物流接口等。
產品線的划分一定要站在公司的角度進行，可以結合公司的主要部門，和大產品群進行划分。產品線划分好后，接下來就是梳理整個公司的所有項目，將每一個項目，按照所屬產品線進行歸類。
二、IT資產管理
經過產品線划分和項目歸類之后，可以一目了然地看到目前公司所有的IT系統。接下來根據每一個項目梳理項目中涉及到的服務器或是虛擬機。然后還需要從另一個維度去梳理：每一台服務器或是虛擬機上面部署的項目，服務(數據庫、Tomcat、WebLogic等)。經過這一步，可以明確每一個項目涉及哪些服務器或是虛擬機，每一台服務器或虛擬機上又關聯多少個項目，部署了多少服務。
虛擬機在哪些宿主機，宿主機又分布在哪些物理機上，而這些物理機又部署在哪個機房的哪個機櫃；網絡連接是怎樣，上行和下行分別是什么，都需要進行梳理和完善，這樣可以從硬件層面去關注每一個系統的硬件關聯。如果硬件或是網路出現任何問題，可以快速地清楚知道涉及到的系統和影響度。
三、供應商管理
每一個公司的IT設備或是系統基本都會有供應商公司的參與。集中統一管理這些供應商的信息，可以在系統出現問題的時候緊急聯系供應商，進行協助解決。
2生產數據庫
生產數據庫作為基礎數據的重要一環，為業務數據監控提供主要途徑。我們在監控模塊中有一個業務監控，主要依賴業務數據庫中的數據，根據業務邏輯進行數據比對，判斷業務的實時性和准確性。
一般在監控和備份的時候，數據庫都會作為單獨的一個主題進行（因為太重要）。在基礎數據模塊，將所有的生產數據庫信息進行集中采集，可以很方便地為以后的數據庫監控和備份等運維工作提供操作對象參考，以免遺漏。
生產數據庫一般按照數據庫的類型(MySQL、Oracle、SQL Server等)進行分類管理。數據庫的名稱一般即業務系統的名稱，簡單標識，見名知意。
3日志數據
日志數據是IT系統的重要數據之一，可以很好地反映系統的運行狀況，系統出現問題的時候，可以通過反查日志進行查因、排故。
一、系統日志
系統日志主要是包括操作系統級別的日志，包括物理機、宿主機、虛擬機等部署有操作系統的系統日志。一般主要關注以下幾種日志：系統操作日志、安全日志、定時任務日志等。
系統操作日志可以看到什么用戶什么時間登錄了哪台操作系統，做了什么操作等；安全日志可以判斷系統是否已遭受或是正在遭受攻擊，是否有過危險操作等；定時任務日志可以看到部署在系統中的定時任務是否按時准確地執行完成。
系統日志主要反映系統級別的運行情況，一定要做好備份和分析的工作。
二、應用日志
應用日志一般分應用服務日志和業務操作日志。應用服務日志指如Tomcat、Nginx運行時候產生的日志等，通過其可以看到應用服務運行的健康情況；業務操作日志主要是業務系統將部分業務操作或是業務錯誤寫到日志中，可能單獨一個日志文件也可能集成到應用服務日志中。業務操作日志是進行業務審計，業務監控的重要數據源。
三、數據庫日志
這個不多說，數據庫中的數據往往是企業的核心資產。數據庫日志反映着數據庫的每一步每一個事務的操作，以及數據庫運行的監控狀況，進行日志監控和分析時，數據庫日志是不可缺少的。
四、設備日志
設備日志往往是比較容易忽略的。但設備日志可以直觀地反映出設備運行的狀況，以及設備出現問題的時候，可以通過日志快速准確地找到原因。如交換機日志、防火牆日志等。通過防火牆日志可以看出系統是否遭受攻擊，交換機日志可以看到網絡流量是否呈現陡增陡降等突發狀況。實時監控和管理設備日志是日志管理的重要工作之一。
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自動化運維
在這里簡單介紹一下運維自動化涉及到的內容。結合前面說的運維流程化中的流程，大概分為以下幾點：
1、服務器申請與操作系統自動安裝（自動安裝的操作系統是經過系統安全加固和優化后的系統）。
2、系統部署服務（如數據庫，Tomcat等）的申請和自動部署。一般要求版本統一，或是特定版本。部署的服務需要從自建軟件倉庫或是自建的Yum源進行自動安裝。
3、應用發布申請與應用的自動部署。我們這里采用的是開發從代碼庫中檢出代碼通過編譯服務器進行編譯，將編譯后的程序包和配置文件（如果修改的話）在系統進行提交發布申請；測試人員收到開發的發布申請后，點擊發布，發布程序先執行備份，然后自動發布到測試環境，測試人員進行測試，測試有誤，回滾測試環境，流程退回至開發，如無誤則點擊生產發布（有的公司會要求預生產發布測試）；運維人員收到測試通過的包和發布時間后，點擊創建發布即可。到時會定時在服務器先備份后發布。
4、應用變更申請流程與上述類似，都是先經過測試，再進行變更。服務器變更申請如擴容等會根據資源利用率和硬件資源池進行評估后，給出變更建議。
此外自動運維平台還提供架構自動診斷、壓力測試、系統巡檢、故障自診斷等方面的功能，具體不再一一贅述。
總結
運維管理平台的建立涉及到運維工作的方方面面，以減少運維重復工作，提高運維效率為目標，如果大家有新的意見和建議的話，歡迎一起溝通交流。
轉自：http://www.sohu.com/a/141415011_487514