[[161887]]

嘉賓介紹

　　季文軒

　　北京云途騰科技有限責(zé)任公司高級(jí)系統(tǒng)架構(gòu)師，Magic-Stack自動(dòng)化平臺(tái)作者

　　熱衷開(kāi)源技術(shù)的研究，包括系統(tǒng)架構(gòu)、運(yùn)維開(kāi)發(fā)、負(fù)載均衡、分布式存儲(chǔ)及云計(jì)算等領(lǐng)域，擅長(zhǎng)大規(guī)模集群的運(yùn)維工作。擁有三年云計(jì)算基礎(chǔ)設(shè)施規(guī)劃和OpenStack開(kāi)發(fā)經(jīng)驗(yàn)。

　　背景

　　隨著信息時(shí)代突飛猛進(jìn)般的持續(xù)發(fā)展，IT運(yùn)維已經(jīng)成為IT服務(wù)中最重要的組成部分。近年來(lái)，云計(jì)算、大數(shù)據(jù)等技術(shù)日趨成熟，生產(chǎn)應(yīng)用自動(dòng)化運(yùn)維也被推到了風(fēng)口浪尖。通過(guò)傳統(tǒng)手段對(duì)大型計(jì)算機(jī)集群進(jìn)行運(yùn)維即使是簡(jiǎn)單的日常備份、服務(wù)器狀態(tài)監(jiān)控和報(bào)警，效率也十分低下，因此對(duì)自動(dòng)化運(yùn)維的需求已經(jīng)迫在眉睫。

　　傳統(tǒng)運(yùn)維的弊端：

　　1.由人來(lái)發(fā)起運(yùn)維事件，運(yùn)維人員被動(dòng)、效率低。

　　2.系統(tǒng)異構(gòu)性大，缺乏高效的運(yùn)維流程。

　　3.隨著云計(jì)算大數(shù)據(jù)的爆發(fā)帶來(lái)更大的困難，極度缺乏一套高效的運(yùn)維工具。

　　由于這些問(wèn)題的存在，自動(dòng)化應(yīng)該遵循四化原則：管理體系化、工作流程化、人員專(zhuān)業(yè)化、任務(wù)自動(dòng)化。

　　以監(jiān)控作為自動(dòng)化運(yùn)維的核心概念

　　運(yùn)維工作效率不高，主要原因是響應(yīng)速度。由于大量的人員長(zhǎng)期盯著報(bào)警頁(yè)面，等待故障，然后通知相應(yīng)人員。所以在生產(chǎn)系統(tǒng)中，需將服務(wù)器的狀態(tài)監(jiān)控作為自動(dòng)化運(yùn)維的核心問(wèn)題。下圖為自動(dòng)化運(yùn)維平臺(tái)處理流程圖，由監(jiān)控來(lái)驅(qū)動(dòng)運(yùn)維事件的發(fā)起、處理和結(jié)束，由ElkStack 、Zabbix 和 Zabbix-Agent來(lái)獲取到服務(wù)器的日常工作狀態(tài)和服務(wù)信息，并生成時(shí)序統(tǒng)計(jì)圖等用于成果分析。

　　通過(guò)精準(zhǔn)有效的報(bào)警策略做到專(zhuān)業(yè)的事由專(zhuān)業(yè)的人去做。生產(chǎn)系統(tǒng)已經(jīng)實(shí)現(xiàn)了郵件、微信、短信告警等功能，可以根據(jù)故障類(lèi)型和影響級(jí)別及時(shí)通知到相應(yīng)人員，并且可以根據(jù)SLA進(jìn)行事件升級(jí)。后續(xù)還可以針對(duì)微信平臺(tái)進(jìn)行持續(xù)開(kāi)發(fā)，提供更多功能，比如說(shuō)模板化處理機(jī)制的問(wèn)題。

　　舉個(gè)例子，服務(wù)器的磁盤(pán)占用率達(dá)到百分九十的時(shí)候，告警也會(huì)自動(dòng)通過(guò)微信通知到相應(yīng)的處理人員，這時(shí)候處理人員只需采取從微信中選擇，并操作對(duì)應(yīng)的清理垃圾模板，如：數(shù)據(jù)修復(fù)模板、清理歷史日志模板等，進(jìn)行清理作業(yè)即可。

　　以模板化部署為自動(dòng)化運(yùn)維的必備利器

　　對(duì)于運(yùn)維工程師來(lái)說(shuō)，真正意義上維護(hù)服務(wù)器的工作并不算繁重，真正繁重的應(yīng)該是環(huán)境的部署，有的時(shí)候環(huán)境實(shí)施部署會(huì)占據(jù)到運(yùn)維工作百分之八十以上的時(shí)間。由于操作系統(tǒng)版本的不統(tǒng)一，手動(dòng)且隨意的初始化系統(tǒng)環(huán)境，不同軟件包的版本更新等一系列的問(wèn)題，會(huì)導(dǎo)致工程師部署運(yùn)維工具或公司產(chǎn)品時(shí)，總會(huì)出現(xiàn)各種各樣非常奇妙的囧境。

　　所以，我將模板化部署作為自動(dòng)化運(yùn)維的第二塊內(nèi)容，下圖為自動(dòng)化運(yùn)維平臺(tái)流程范例。通過(guò)cobber可以模板化操作系統(tǒng)，系統(tǒng)初始化配置，軟件包版本控制，從而做到整個(gè)計(jì)算機(jī)集群基礎(chǔ)環(huán)境完全一模一樣。減少了因?yàn)榛A(chǔ)環(huán)境不同而導(dǎo)致部署錯(cuò)誤。

　　當(dāng)然僅僅是系統(tǒng)的模板標(biāo)準(zhǔn)化還遠(yuǎn)遠(yuǎn)不夠，我們還可以通過(guò)結(jié)合Ansible Playbook 將運(yùn)維常用的工具腳本化，這樣不僅僅是為了減少人為因素的出錯(cuò)點(diǎn)，更可以通過(guò)批量執(zhí)行大大的提高工作效率。同時(shí)，還可以通過(guò)Ansible 進(jìn)行并行的配置管理。

　　在我設(shè)計(jì)的運(yùn)維平臺(tái)中有兩個(gè)核心組件，分別是告警調(diào)度引擎(messageserver)和事件調(diào)度引擎(jobserver)，告警調(diào)度引擎主要作用于分析日常報(bào)警信息，通過(guò)報(bào)警事件、時(shí)間、機(jī)器、類(lèi)別等維度生成圖表。事件調(diào)度引擎的主要功能是根據(jù)相應(yīng)的告警項(xiàng)目，自動(dòng)處理事件從而實(shí)現(xiàn)自動(dòng)化運(yùn)維的目的。

　　自動(dòng)化技術(shù)思想

　　有了上述的幾張圖和方案，相信運(yùn)維的大部分效率是可以帶動(dòng)起來(lái)的。但是，這真的就是自動(dòng)化嗎?當(dāng)然不是，自動(dòng)化運(yùn)維不僅僅是工具上的革新，更多的是思想上的轉(zhuǎn)變，流程上的優(yōu)化，這將會(huì)是一個(gè)持續(xù)改進(jìn)的過(guò)程。

　　首先，運(yùn)維需要規(guī)范化流程化。其次，運(yùn)維工具容器化，將常用的運(yùn)維工具和公司產(chǎn)品構(gòu)建到容器或者VM中，盡量減少部署時(shí)間。再次，日常維護(hù)需腳本化，通過(guò)配置管理工具實(shí)現(xiàn)自動(dòng)配置維護(hù)，并且盡量減少人工的處理與參與。***，是自動(dòng)化。

　　我認(rèn)為一個(gè)真正的自動(dòng)化運(yùn)維平臺(tái)并不只是通過(guò)人或者通過(guò)技術(shù)去減少人工的參與成本，而是需要和運(yùn)維產(chǎn)品相結(jié)合，最終做到智能運(yùn)維。這樣的話(huà)產(chǎn)品本身就可以做到自維護(hù)，從而形成一個(gè)完整的個(gè)體。

　　我們?cè)谧詣?dòng)化運(yùn)維平臺(tái)建設(shè)的多年實(shí)踐中，往往花時(shí)間最多的是在運(yùn)維流程優(yōu)化、權(quán)限控制、日志審核、等功能上。后期我們還整合了跳板機(jī)的功能并應(yīng)用整合到我們的自動(dòng)化運(yùn)維平臺(tái)中。

　　現(xiàn)在部署一套環(huán)境僅需要二十分鐘。100臺(tái)服務(wù)器同時(shí)上線效率提高了35倍。環(huán)境日常維護(hù)或者應(yīng)用部署上線已經(jīng)很少登陸到單獨(dú)的節(jié)點(diǎn)上去操作，只要通過(guò)系統(tǒng)統(tǒng)一的平臺(tái)操作基本都能搞定。我想或許自動(dòng)化運(yùn)維只是Ops到DevOps轉(zhuǎn)型所衍生出的一種特性吧！未來(lái)將走向全面智能運(yùn)維時(shí)代。