運維自動化與標準規范化:解析、設計及實現(1)
2016-02-20 19:34:07 來源: 史影/童寧/韓曉光 高效運維 評論:0 點擊:
本文主要介紹我們的運維自動化系統如何設計與實現的,在介紹運維自動化時,首先需要先探討一下運維標準規范化與自動化關系,因為這是大多數運維自動化的必經之路,也是很多運維體系成長的必經之路。
一、運維標準化、規范化、流程化
要做運維自動化,首先要落實運維體系的標準化、規范化、流程化。否則,如果不規范標準化,很難具體實施運維自動化。
在開發運維自動化系統過程與執行中,會有很多事情無法開展,或很難執行下去。
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.4 數據庫模型設計
數據庫模型(部分)設計如圖2-3所示。
圖2-3
2.5 工單流程設計
基于ITIL理念的事件工單流程如圖2-4所示。
圖2-4
2.6 系統架構示意圖
基于我們的運維現狀及需求等內容,我們的系統架構設計如下圖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-12所示是系統服務狀態監控信息。由client客戶端抓取系統服務狀態信息,然后反饋給服務器端進行統計與展示。在各種監控配置方面,一方面采取服務器端主動抓取監控信息(如上述的網址監控),另一方面,由客戶端程序主動抓取當前系統的監控信息(如系統賬號、文件系統、配置、服務等),并通過C/S架構發(數據以json格式為主)給服務器端接收。
圖3-12
如圖3-13所示是自動化管理中的系統自動部署模塊,具有批量查詢IP使用情況、派發客戶端、部署與配置系統等功能。自動化部署主要基于kvm、Saltstack等開發而實現。
圖3-13
想了解IT運維更多內容,請參閱 電子工業出版社:《系統運維全面解析》
空間門戶:http://xhnetops.home.news.cn/
如何一起愉快地發展
“高效運維”公眾號(如下二維碼)值得您的關注,作為高效運維系列微信群的唯一官方公眾號,每周發表多篇干貨滿滿的原創好文:來自于系列群的討論精華、運維講壇線上精彩分享及群友原創。“高效運維”也是互聯網專欄《高效運維最佳實踐》及運維2.0官方公眾號。
提示:目前高效運維新群已經建立,歡迎加入。您可添加蕭田國個人微信號xiaotianguo8 為好友,進行申請,請備注“申請入群”。
重要提示:除非事先獲得授權,請在本公眾號發布2天后,才能轉載本文。尊重知識,請必須全文轉載,并包括本行。
【編輯推薦】
