運維自動化與標準規范化解析、設計、實現

作者：史影童寧韓曉光 2017-04-18 12:20:02

本文主要介紹我們的運維自動化系統如何設計與實現的，在介紹運維自動化時，首先需要先探討一下運維標準規范化與自動化關系，因為這是大多數運維自動化的必經之路，也是很多運維體系成長的必經之路。

一、運維標準化、規范化、流程化

要做運維自動化，首先要落實運維體系的標準化、規范化、流程化。否則如果不規范標準化，很難具體實施運維自動化。在開發運維自動化系統過程與執行中，會很多事情就沒法開展，很難很好地執行下去。

1.1 對于運維自動化與標準規范化的認識

對于運維自動化、標準規范化的認識與理解。不同企業圈子，每個人的理解總會有差異性，但總體方向應該是一致的：我們需要運維自動化、標準化，因為它能促使我們的工作更加高效、智能、有規則，有預見性……對于運維自動化，標準規范化的認識，這里舉例說明兩種極端類型。

極端一類型：極端排斥流程標準及自動化，認為這是噱頭，不干實事，不出成果。極端一類型做事貌似風風火火，思考規劃10分鐘，邊想邊干1整天，結果到了明天再重來----典型地邊計劃邊實施邊填坑，結果是又忙又亂又出錯。其實極端一類型的問題就出在：事前沒有規劃好，事中沒有實施好，事后沒有總結好，無規矩不成方圓。

針對極端一類型，我們的觀點是：標準規范與自動化是當前主流運維成熟進階的必經之路。

流程標準很重要，必須要執行與持續完善，這是運維自動化以及公司運營一切的基礎。看過復雜的航空線路圖，航海線路圖，鐵路交通圖吧，是不是會感嘆標準化與自動化的重要性。運維工作也是一樣的道理，例如在實際項目過程中，你要上新業務買設備，則需要提出技術需求，找財務、上級會簽審批，然后還得招投標(內部邀標)，簽合同，收到貨得付款，設備入庫備案，初始化設備，自動化部署系統，自動化部署應用，自動采集信息與告警…..等等，正是這些規范流程，運維自動化才使我們的運維工作高效能、高質量、低風險。

極端二類型：極端追求標準流程。例如還是上述購新業務及采購設備流程。極端二類型做事非常規范細致：

while (true): {

調研;

開會;

統計需求;

提交審批;}

如此一遍又一遍的死循環，必須做到***。如此結果是今年的需求，明年服務器才到貨，后年業務才上線，為了部署一次性就全面全部OK，就費盡窮舉一切可能，但凡有例外，就認為不是自動化，標準化。這樣做貌似流程規范做到了天衣無縫，其結果人算不如天算，時間事情隨時在變，***在實際生產中還是會有意外尷尬事情…..

針對極端二類型，我們的觀點是：流程規范是***實踐方法論，但不是目的。

從哲學角度，這個世界不***，因此2/8原則與持續性改進應該是思考與解決事情的一種***實踐。流程標準固然很重要，但是流程標準目的是為了很好地執行并解決事情，而不是要卡死、堵死一系列事情。我們沒必要糾結于高大全的標準與自動化，我們需要從我們運維需求出發，痛點出發，持續改進與解決運維實際問題。

例如，在做自動化部署過程，總會有一些例外的情況。例如批量部署salt minion，由于系統版本，安裝批次不一樣。導致有些salt安裝依賴包沒有而部署失敗。這就要考慮，自動部署環節是要考慮增加更多狀態部署細節，還是保留一個精簡的狀態部署方案。或許對于一個例外問題，例外分析與解決，而不是為了這一個例外而變動所有的全體。記住，不要認為搞個運維自動化系統，部署一個saltstack，puppet工具就能解決所有運維問題。

1.2 運維自動化與標準規范化的關系

任何一個企業運行都有很多配套的公司流程標準，否則很多事情將一團亂麻，根本無法推行，運維自動化也不例外，實施自動化前提需要標準規范與流程化。比如如果系統版本，主機名，IP不統一規范，則可能會導致saltstack部署執行，zabbix自動化發現，日志監控部署，應用部署等一系列問題。

沒有良好的標準與自動化解決方案，運維人員常會背黑鍋

運維自動化需要規范標準化，當然運維自動化又促進規范標準化。運維自動化，標準化需要落實，不能空談，不能只說不練，有“法“不依。標準要深入人心，融入日常行為思想中，達到個人與集體的潛移默化間的一致性，共通性。例如，我們總會碰到一些不規范的程序員，隨意往線上部署了一段代碼，搞得系統緩慢，***由運維人員背黑鍋。

標準與自動化往往是由業務、IT環境需求驅動的

諸如上述，運維自動化與標準化往往是由業務，IT環境驅動的，逐步優化完善出來的，或者是被動逼出來的。比如由于業務增長迅速，系統(應用)環境需求天天都有都很多。那你還是手工一臺臺系統(應用)部署么，或許就算鍵盤敲到手抽筋仍然沒完成業務需求，這時突然你又發現部署的代碼不一致…..此時估計整個人都快要”瘋掉了”，或許此時你對運維自動化，標準規范化的理解與需求會透徹骨子里。

標準與自動化需要持續性改進優化

運維自動化不是一籌而就，而是逐漸持續性優化改進(ITIL理念)的，實施。沒有任何一個企業創立之初，其IT架構就非常高大上，上來就構建全球機房，初始就設計一個超級高性能，高安全的系統，立刻滿足上億的UV請求……這些或許沒必要，也幾乎不可能。

二、運維自動化系統設計

如下以一個實際的運維自動化系統為例，介紹一些該系統平臺的設計與實現的內容。

2.1 運維自動化需求

隨著業務規模逐漸增大，IT運維環境會越來越龐大復雜，這些將驅使運維工作需要科學規范化的管理。這要求我們用較少的人力、物力資源做更多的工作，必須高效、準確執行任務。

當前市場上已經有很多成熟的(商業、開源)運維產品工具，各有特色也各有利弊，這也同時造成一個尷尬局面：運維人員要不斷學習和管理很多運維產品工具，但卻很難有找出一個很好適應本企業(持續不斷)定制化需要的產品工具。因此很多有實力的企業都會選擇自主運維及開發。

從運維大環境來看，IT運維綜合管理已成為主流運維管理發展方向，運維+開發成為運維發展的大趨勢。我們不再單純、局限地依靠某個網管監控產品，而是需要運維自動化，提供體系化運維解決方案，包括系統網絡管理、CMDB資產信息管理、知識庫管理、乃至ITSM信息服務流程管理等。

2.2 系統概要設計介紹

如圖2-1所示，本運維自動化綜合管理平臺的設計理念是：盡量融合、統一管理現有的各個運維工具平臺，統一監控管理系統資源，有效關聯整合數據信息。自主開發(同時基于現有運維管理工具二次開發)出適合自身需要的綜合運維管理平臺。

本解決方案立足從三大維度構建，分別是IT運維流程、IT監控平臺整合、IT運維自動化。這三大維度主要具有如下幾大功能模塊。

IT運維流程：資產管理、知識庫管理、安全管理、事件管理、日常事項管理。
IT監控平臺整合：監控報警管理、日志管理、性能管理、報表管理。
IT運維自動化：應用管理、配置管理、程序運行管理。

2-1 系統邏輯架構設計

本解決方案使用的開發語言及工具：

后端及系統客戶端開發主要通過Python、Shell等程序語言實現。
信息采集寫入MySQL數據庫。
前端WEB展示以及與后臺數據層、應用層的邏輯交互通過Django框架實現。
界面修飾美化使用Bootstrap等框架工具。

2.3 程序功能框圖設計

根據我們的需求，程序功能框圖設計如下圖所示。

2-2 程序功能框圖

2.3 數據庫模型設計

數據庫模型(部分)設計如圖2-3所示。

圖2-3

2.4 工單流程設計

基于ITIL理念的事件工單流程如圖2-4所示。

圖2-4

2.5 系統架構示意圖

基于我們的運維現狀及需求等內容，我們的系統架構設計如下圖2-5所示。

圖2-5

三、運維自動化系統平臺實例介紹

如圖3-1所示是系統一級菜單與二級菜單，對應了上述設計的各主要模塊。

圖3-1

如圖3-2所示在全局查詢里，可以輸入任意要查詢的關鍵字。該模塊主要是基于數據庫表的查詢，而不是對于日志的查詢。該模塊會基于關鍵字，模糊遍歷所有的關鍵庫表，然后將查詢結果自動組織后再反饋到Web展示。

圖3-2

如下圖3-3所示是系統性能信息圖表。該模塊主要使用echarts前端繪圖工具，后端邏輯處理使用了django restframework框架模塊進行信息序列化。性能數據來自系統客戶端采集入庫信息。

圖3-3

如圖3-4所示是資產管理模塊中的硬件配置模塊。主要是資產的增刪改查功能。對于大量資產信息的錄入是通過后臺管理中的信息導入模塊(將固定格式的Excel資產信息表)批量錄入到系統中。該模塊主要通過Django CBV方式快速實現。

圖3-4

如圖3-5所示是基于Wordpress定制的系統以作為知識庫系統。用于日常信息、知識資料的發布與共享。

圖3-5

如圖3-6所示是事件信息模塊。本模塊基于ITIL流程理念。系統平臺一些重要的事件信息會自動觸發事件流程，并需要人為交互去響應處理不同類型級別的事件。對于不同類型的事件，在處理時，所觸發的流程也有所不同。

圖3-6

如圖3-7所示是集成融合了現有基調網絡監控產品。通過該運維自動化管理平臺，實現了對現有各種分散的工具軟件的統一整合集成。

圖3-7

如圖3-8所示是基于ELK深度定制的日志監控模塊。基于各類日志信息進行監控與統計。

圖3-8

如圖3-9所示是日志安全與審計。主要是針對服務器系統、網絡設備等安全日志進行監控與審計。系統日志的采集使用了rsyslog和logstash shipper客戶端兩種方式采集發送信息。對于audit審計日志，則首先在被管節點上配置審計策略，然后由logstash shipper進行日志采集與發送。

圖3-9

如圖3-10所示是基于Cacti深度定制的網絡流量監控。主要是動態實時地監控各個主要節點的網絡流量。

圖3-10

如圖3-11所示是網址鏈接狀態監測模塊。可自動或手動監控一些(自定義的)重要網址連接狀態。

圖3-11

如3-11所示是系統服務狀態監控信息。由client客戶端抓取系統服務狀態信息，然后反饋給服務器端進行統計與展示。在各種監控配置方面，一方面采取服務器端主動抓取監控信息(如上述的網址監控)，另一方面，由客戶端程序主動抓取當前系統的監控信息(如系統賬號、文件系統、配置、服務等)，并通過C/S架構發(數據以json格式為主)給服務器端接收。