[[161887]]

嘉賓介紹

　　季文軒

　　北京云途騰科技有限責任公司高級系統架構師，Magic-Stack自動化平臺作者

　　熱衷開源技術的研究，包括系統架構、運維開發、負載均衡、分布式存儲及云計算等領域，擅長大規模集群的運維工作。擁有三年云計算基礎設施規劃和OpenStack開發經驗。

　　背景

　　隨著信息時代突飛猛進般的持續發展，IT運維已經成為IT服務中最重要的組成部分。近年來，云計算、大數據等技術日趨成熟，生產應用自動化運維也被推到了風口浪尖。通過傳統手段對大型計算機集群進行運維即使是簡單的日常備份、服務器狀態監控和報警，效率也十分低下，因此對自動化運維的需求已經迫在眉睫。

　　傳統運維的弊端：

　　1.由人來發起運維事件，運維人員被動、效率低。

　　2.系統異構性大，缺乏高效的運維流程。

　　3.隨著云計算大數據的爆發帶來更大的困難，極度缺乏一套高效的運維工具。

　　由于這些問題的存在，自動化應該遵循四化原則：管理體系化、工作流程化、人員專業化、任務自動化。

　　以監控作為自動化運維的核心概念

　　運維工作效率不高，主要原因是響應速度。由于大量的人員長期盯著報警頁面，等待故障，然后通知相應人員。所以在生產系統中，需將服務器的狀態監控作為自動化運維的核心問題。下圖為自動化運維平臺處理流程圖，由監控來驅動運維事件的發起、處理和結束，由ElkStack 、Zabbix 和 Zabbix-Agent來獲取到服務器的日常工作狀態和服務信息，并生成時序統計圖等用于成果分析。

　　通過精準有效的報警策略做到專業的事由專業的人去做。生產系統已經實現了郵件、微信、短信告警等功能，可以根據故障類型和影響級別及時通知到相應人員，并且可以根據SLA進行事件升級。后續還可以針對微信平臺進行持續開發，提供更多功能，比如說模板化處理機制的問題。

　　舉個例子，服務器的磁盤占用率達到百分九十的時候，告警也會自動通過微信通知到相應的處理人員，這時候處理人員只需采取從微信中選擇，并操作對應的清理垃圾模板，如：數據修復模板、清理歷史日志模板等，進行清理作業即可。

　　以模板化部署為自動化運維的必備利器

　　對于運維工程師來說，真正意義上維護服務器的工作并不算繁重，真正繁重的應該是環境的部署，有的時候環境實施部署會占據到運維工作百分之八十以上的時間。由于操作系統版本的不統一，手動且隨意的初始化系統環境，不同軟件包的版本更新等一系列的問題，會導致工程師部署運維工具或公司產品時，總會出現各種各樣非常奇妙的囧境。

　　所以，我將模板化部署作為自動化運維的第二塊內容，下圖為自動化運維平臺流程范例。通過cobber可以模板化操作系統，系統初始化配置，軟件包版本控制，從而做到整個計算機集群基礎環境完全一模一樣。減少了因為基礎環境不同而導致部署錯誤。

　　當然僅僅是系統的模板標準化還遠遠不夠，我們還可以通過結合Ansible Playbook 將運維常用的工具腳本化，這樣不僅僅是為了減少人為因素的出錯點，更可以通過批量執行大大的提高工作效率。同時，還可以通過Ansible 進行并行的配置管理。

　　在我設計的運維平臺中有兩個核心組件，分別是告警調度引擎(messageserver)和事件調度引擎(jobserver)，告警調度引擎主要作用于分析日常報警信息，通過報警事件、時間、機器、類別等維度生成圖表。事件調度引擎的主要功能是根據相應的告警項目，自動處理事件從而實現自動化運維的目的。

　　自動化技術思想

　　有了上述的幾張圖和方案，相信運維的大部分效率是可以帶動起來的。但是，這真的就是自動化嗎?當然不是，自動化運維不僅僅是工具上的革新，更多的是思想上的轉變，流程上的優化，這將會是一個持續改進的過程。

　　首先，運維需要規范化流程化。其次，運維工具容器化，將常用的運維工具和公司產品構建到容器或者VM中，盡量減少部署時間。再次，日常維護需腳本化，通過配置管理工具實現自動配置維護，并且盡量減少人工的處理與參與。***，是自動化。

　　我認為一個真正的自動化運維平臺并不只是通過人或者通過技術去減少人工的參與成本，而是需要和運維產品相結合，最終做到智能運維。這樣的話產品本身就可以做到自維護，從而形成一個完整的個體。

　　我們在自動化運維平臺建設的多年實踐中，往往花時間最多的是在運維流程優化、權限控制、日志審核、等功能上。后期我們還整合了跳板機的功能并應用整合到我們的自動化運維平臺中。

　　現在部署一套環境僅需要二十分鐘。100臺服務器同時上線效率提高了35倍。環境日常維護或者應用部署上線已經很少登陸到單獨的節點上去操作，只要通過系統統一的平臺操作基本都能搞定。我想或許自動化運維只是Ops到DevOps轉型所衍生出的一種特性吧！未來將走向全面智能運維時代。