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

來源:m.ctocio.com.cn 2016-03-25 20:11:00

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

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

要做運維自動化,首先要落實運維體係的標準化、規範化、流程化。否則,如果不規範標準化,很難具體實施運維自動化。

在開發運維自動化係統過程與執行中,會有很多事情無法開展,或很難執行下去。

1.1對於運維自動化與標準規範化的認識

對於運維自動化、標準規範化的認識與理解。

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

極端類型一:極端排斥流程標準及自動化,認為這是噱頭,不幹實事,不出成果。

這種類型的人做事貌似風風火火,思考規劃10分鍾,邊想邊幹1整天,結果到了明天再重來——典型地邊計劃邊實施邊填坑,結果是又忙又亂又出錯。

其實這種類型的問題就出在:事前沒有規劃好,事中沒有實施好,事後沒有總結好,無規矩不成方圓。

針對該類型,我們的觀點是:標準規範與自動化是當前主流運維成熟進階的必經之路。

流程標準很重要,必須要執行與持續完善,這是運維自動化以及公司運營一切的基礎。

看過複雜的航空線路圖,航海線路圖,鐵路交通圖吧!是不是會感歎標準化與自動化的重要性。

運維工作也是一樣的道理,例如在實際項目過程中,你要上新業務買設備,則需要提出技術需求,找財務、上級會簽審批,然後還得招投標(內部邀標),簽合同,收到貨得付款,設備入庫備案,初始化設備,自動化部署係統,自動化部署應用,自動采集信息與告警……等等,正是這些規範流程,運維自動化才使我們的運維工作高效能、高質量、低風險。

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

如此一遍又一遍的死循環,必須做到極致。如此結果是今年的需求,明年服務器才到貨,後年業務才上線,為了部署一次性就全麵全部OK,就費盡窮舉一切可能,但凡有例外,就認為不是自動化,標準化。

這樣做貌似流程規範做到了天衣無縫,但其結果往往是人算不如天算,因為時間事情隨時在變,最後在實際生產中還是會有意外尷尬事情發生……

針對該類型,我們的觀點是:流程規範是最佳實踐方法論,但不是目的。

從哲學角度,這個世界不完美,因此2/8原則與持續性改進應該是思考與解決事情的一種最佳實踐。流程標準固然很重要,但是流程標準目的是為了很好地執行並解決事情,而不是要卡死、堵死一係列意外。

我們沒必要糾結於高大全的標準與自動化,我們需要從運維需求出發,痛點出發,持續改進與解決運維實際問題。

例如,在做自動化部署過程,總會有一些例外的情況。例如批量部署saltminion,由於係統版本,安裝批次不一樣。導致有些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.4數據庫模型設計

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

                                圖2-3數據庫模型(部分)設計

2.5工單流程設計

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

                              圖2-4基於ITIL理念的事件工單流程

2.6係統架構示意圖

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

                                       圖2-5係統架構示意圖

三、運維自動化係統平台實例介紹

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

                                  圖3-1係統一級菜單與二級菜單

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

                                   圖3-2數據庫表的查詢

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

                                  圖3-3係統性能信息圖表

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

                              圖3-4資產管理模塊中的硬件配置模塊

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

                           圖3-5基於Wordpress定製的係統以作為知識庫係統

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

                                      圖3-6事件信息模塊

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

                               圖3-7集成融合了現有基調網絡監控產品

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

                                  圖3-8基於ELK深度定製的日誌監控模塊

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

                                       圖3-9日誌安全與審計

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

                                圖3-10基於Cacti深度定製的網絡流量監控

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

                                       圖3-11網址鏈接狀態監測模塊

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

                               圖3-12係統服務狀態監控信息

如圖3-13所示是自動化管理中的係統自動部署模塊,具有批量查詢IP使用情況、派發客戶端、部署與配置係統等功能。自動化部署主要基於kvm、Saltstack等開發而實現。

                               圖3-13自動化管理中的係統自動部署模塊

點擊查看原文

相關鏈接